用了一年 AI 编程效率工具，我的电脑悄悄少了 200G
先说结论：这 200G 不是被某个单一软件“吃”掉的，而是十几处看似不起眼的缓存、索引、依赖包和日志文件，一年下来逐渐堆积的结果。如果你正在用 Cursor、GitHub Copilot、通义灵码这类 AI 编程工具，并且感觉系统盘空间越来越紧张，那这篇文章大概率能帮你找回几十甚至上百 G 的空间。
我在去年初开始重度使用 AI 编程工具，主力是 Cursor，配合 Copilot 做代码补全，偶尔用通义灵码处理中文注释和文档生成。原本只是为了提升写代码的效率，没想到一年后系统盘亮起了红灯。用 SpaceSniffer 扫了一圈，才发现罪魁祸首不只是 Node _modules 和 Docker 镜像，真正的大头全是 AI 工具的“隐藏资产”。这篇博客我就把自己踩坑、排查、清理、优化的一整套过程完整记录下来，包括每类缓存的具体位置、占了多少空间、哪些能安全删、哪些需要配置规避，以及几款主流 AI 编程工具的真实磁盘占用表现。
如果你也是 AI 编程的重度用户，或者你的开发机开始出现空间告急，这篇文章值得你花十分钟看完，然后照着操作一遍，应该能省下（或者说找回）不小的存储空间。
1. 空间去哪了？先搞清楚 AI 编程工具的“隐藏资产”清单
很多人的第一反应是“我装了一堆 AI 插件，每个才几百 MB，能占多少？”实际上，AI 编程工具不像普通软件那样只占用安装目录的空间，它们会在后台持续产生大量数据，而且这些数据散落在系统的各个目录里，普通卸载根本清不干净。
1.1 深层索引与分析缓存是最大的空间黑洞
以 Cursor 为例，它的底层基于 VS Code 架构，但为了提供“读懂整个项目”的能力，会额外构建一套项目级向量索引。只要你打开过一个规模稍大的代码仓库，Cursor 就会自动把目录里的代码切片、嵌入、建索引，这个过程产生的数据存放在两个位置：~/.cursor-server和~/.cursor。
前者是远程开发/多端同步用的服务端组件，后者是本地 IDE 配置、扩展缓存和索引数据的存放地。我目前本机上这两个目录加起来一共占了 46.8G，里面最夸张的是~/.cursor/User/workspaceStorage，单个工作区缓存就能到几个 G。
这类索引文件的特点是“建起来很慢、删了又会重建”。我的处理思路是：对仍在活跃开发的项目保留索引，对已经归档的老项目直接把整个目录移除，需要时再重新打开，让 Cursor 按需重建。下面是我本机扫描出的真实数据：
| 缓存位置 | 存放内容 | 我的实测大小 |
|---|---|---|
| ~/.cursor-server | 远程服务端组件、日志、临时文件 | 12.3G |
| ~/.cursor/User/workspaceStorage | 各工作区的持久化缓存（含索引） | 28.5G |
| ~/.cursor/User/globalStorage | 全局组件缓存（AI 会话记录等） | 5.1G |
| ~/.cursor/cacheddata | 代码切片与嵌入向量缓存 | 0.9G |
1.2 依赖与环境组件的持续膨胀
AI 编程工具普遍内置了 Python 运行时、TypeScript 语言服务、Node.js 运行时等组件。这些组件本身不是问题，真正的问题在于它们会“随用随长”。比如 Cursor 内置的 Python 环境，如果你在开发中安装过额外的包（用于代码分析、格式化、本地调试等），这些包会被写入 Cursor 自有的 Python 环境目录，与系统 Python 完全隔离，卸载 Cursor 后这些依赖包会残留在磁盘上。
另外，像 Continue、Cody 这类开源 AI 插件，很多会直接调用 Python 脚本和 Node 模块。每当你安装一个新插件，它就会拉取一整套依赖树。我实测发现~/.continue目录里光是一个本地代码索引的虚拟环境就占了 3.4G。
1.3 会话记录、日志与快照文件的堆积
这是最容易忽略的部分。AI 编程工具与普通编辑器的最大区别在于，它会完整保留你和 AI 的每一次交互记录，包括提问内容、代码 diff、文件版本快照等。
以 Copilot 为例，它在~/.config/GitHub Copilot下保存日志和会话状态，单次会话的日志文件很小，但高频使用一年后累计可达几个 G。Cursor 则在~/.cursor/log目录下保留详细的 UI 日志和 AI 请求日志，日志文件按月切割，从不自动清理。
这里有个反直觉的点：Cursor 的 time travel（时间旅行）快照功能默认开启，每次保存文件时自动创建快照版本。如果你在一个大型项目上频繁保存，几个月下来快照文件累计数量非常可观，而我实际查看后发现其中 90% 以上都是从未使用过的中间版本。这个功能关了并不影响 AI 功能本身的正常使用。
2. 动手清理实战：从扫描定位到安全瘦身的完整路径
搞清楚空间从哪里来之后，接下来的核心问题就是：怎么安全地把空间拿回来，同时不影响正常开发。
2.1 先用可视化工具定位大目录，别凭感觉乱删
我的建议是，任何清理动作之前，先做一次全盘扫描。Windows 下我用的是 WizTree（比 SpaceSniffer 快得多），macOS 下用 DaisyDisk 或者直接配合du命令。扫描之后你才能看到真实占用，而不是靠猜。
针对 AI 编程工具的缓存目录，可以直接在终端里进行精确统计：
# macOS / Linux du -sh ~/.cursor ~/.cursor-server ~/.config/GitHub\ Copilot ~/.continue 2>/dev/null # Windows PowerShell（按实际用户目录调整） Get-ChildItem -Path "$env:USERPROFILE\.cursor","$env:USERPROFILE\.cursor-server" -Recurse -ErrorAction SilentlyContinue | Measure-Object -Property Length -Sum如果某个目录大小明显异常（比如workspaceStorage超过 10G），基本可以断定是索引和会话缓存的堆积。
2.2 精确清除 Cursor 索引缓存与工作区残留
对于已经不再活跃的老项目，直接删除对应的 workspaceStorage 子目录即可。操作路径是~/.cursor/User/workspaceStorage，你会看到形如a1b2c3d4e5f6...的哈希命名文件夹，每个对应一个工作区。可以通过文件夹里的workspace.json文件确认具体是哪个项目路径。
在 macOS / Linux 上，可以用下面的命令查看每个子目录对应的工作区路径：
for d in ~/.cursor/User/workspaceStorage/*/; do echo "$d: $(cat "$d/workspace.json" 2>/dev/null | grep -o '"folder":"[^"]*"' | head -1)" done确认后，只删除那些对应项目已经不再维护的目录，保留活跃项目的索引，避免重新打开大型项目时白等很久。
2.3 彻底清理 Copilot、Continue 与内嵌运行时的残留
Copilot 的日志和会话数据清理起来相对简单，直接删除~/.config/GitHub Copilot下的 chat 和 logs 目录即可。注意不要动~/.github-copilot这个目录，那里面存的是你的登录凭证和配置，删掉之后需要重新授权。
Continue 插件的索引数据在~/.continue/index目录，删除后下次打开会自动重建，代价是首次索引会比平时慢一些。如果你平时用 Continue 管理多仓库上下文，建议只删index下的向量库文件，保留~/.continue/config.json配置。
对于 Cursor 内置的 Python 运行时，在确认不用它的“Run in Cursor Python”功能后，可以删除目录中的 Python 环境子目录，位置通常在 Cursor 安装目录下的resources/app/extensions或~/.cursor/extensions。我实测最稳妥的方案是保留 extensions 目录本身（否则插件配置会出问题），只删除其中体积超过 500M 且不再使用的语言运行时子目录。
2.4 Docker、Node 与包管理器的关联垃圾也不能放过
如果你在项目里用了 Docker 做 AI 应用的运行环境，那 Docker 镜像和构建缓存基本都是几十年不清理的状态。docker system df命令可以快速看占用。
docker system df docker image prune -a # 清理所有无标签镜像（慎用！先确认没在用） docker builder prune -f # 清理构建缓存 docker volume prune -f # 清理未被任何容器使用的数据卷Node 项目的老熟人了：node_modules不用多说，pnpm store也是一个隐蔽大坑，pnpm 的全局内容寻址存储默认在~/.pnpm-store，多次大版本迭代后旧包会永久留存。清理方法是：
pnpm store prune npm cache clean --force我实测下来，Docker 清理释放了 11G，pnpm 和 npm 缓存释放了 4G。
3. 从源头解决：让空间不再悄悄蒸发
清完存量之后，如果不去修改默认行为，过不了多久空间又会涨回来。这一节讲的是如何从源头控制这些“隐形成本”。
3.1 关闭/裁剪 Cursor 的高频快照与自动索引
Cursor 的设置里有一个Files: Snapshot选项（在 Settings 搜索 snapshot 即可），默认是unchanged，也就是只在文件内容未交付的前提下保留快照。我建议对非核心项目改成never，或者干脆全局关闭，仅在需要回溯历史版本时临时打开。
这听起来像在“降低安全性”，但实际操作中我发现 AI 编程工具的版本回溯能力远不如 Git，真要靠它找回代码不如提交到 Git 分支里。所以我的建议是：把版本管好交给 Git，Cursor 的快照功能可以关掉。
自动索引方面，在 Cursor 的配置里可以设置cursor.index.disabled为true，或者使用工作区设置来关闭特定目录的索引。缺点是部分 AI 重构和跨文件引用的准确率会下降，但对于中小型项目影响不大。
3.2 把缓存迁移到非系统盘
Windows 用户如果只有 C 盘没法换，macOS 和 Linux 用户可以灵活处理。比较通用的做法是把几个已知的缓存目录做成符号链接，指向大容量磁盘。
# macOS / Linux 操作顺序： # 1. 备份原目录 mv ~/.cursor/User/workspaceStorage ~/Data/cache/cursor-workspaceStorage # 2. 创建软链接（macOS 下用 ln -s） ln -s ~/Data/cache/cursor-workspaceStorage ~/.cursor/User/workspaceStorage注意符号链接创建之后，Cursor 升级或插件安装可能会把目录删掉重建，导致链接断开，所以建议做一个简单的定时任务检查链接有效性。Windows 下可以用mklink /J创建目录联接（junction），对开发者来说效果相同。
3.3 定期自动清理脚本，告别手动巡检
我一直信奉“能自动化就不手动”，所以写了一个简单的 shell 脚本，每月定时清理 AI 编程工具产生的日志和临时文件：
#!/bin/bash # ai-cache-cleanup.sh # 清理 AI 编程工具日志、临时文件和历史索引 echo "=== AI 编程工具缓存清理开始 ===" # Cursor - 只清理超过 30 天的旧日志 find ~/.cursor/log -type f -mtime +30 -delete 2>/dev/null # Cursor - 清理已被标记为删除的会话缓存 find ~/.cursor/User/workspaceStorage -name "*.tmp" -type f -delete 2>/dev/null # Copilot - 清理日志 rm -rf ~/.config/GitHub\ Copilot/logs 2>/dev/null # Continue - 清理无效索引 find ~/.continue/index -name "*.bin" -mtime +90 -delete 2>/dev/null # Docker - 清理悬空镜像（保留 24 小时内的） docker image prune -f --filter "until=24h" 2>/dev/null echo "=== 清理完成 ==="配合 cron 跑即可：
crontab -e # 每月 1 号凌晨 3 点执行 0 3 1 * * * /path/to/ai-cache-cleanup.sh >> /var/log/ai-cache-cleanup.log 2>&1对于日常使用比较克制的开发者，这套脚本能维持缓存总量在可接受范围内。但如果你真的每天都重度使用 AI 重构和全库检索，那你需要的不是“清理”，而是“限制索引范围”——在 Cursor 的设置中把不需要纳入上下文的目录（node_modules、dist、build、vendor、.git）全部加到排除列表里。道理很简单：AI 检索这些目录不仅拖慢速度，还会让索引体积直接爆炸。
4. 实测盘点：2025 年主流 AI 编程工具的磁盘占用与取舍
为了让你心里有数，我把自己用过的几款 AI 编程工具的磁盘占用情况做了个横向对比。以下数据均为我本机一年使用后的实测结果，操作系统为 macOS 14，内存 32G，不同机器和使用强度会有差异，但相对比例值得参考。
| 工具 | 安装体积 | 一年缓存与索引体积 | 占用特点 | 清理难度 |
|---|---|---|---|---|
| Cursor | 850M | 46.8G | 高性能索引换来的高占用 | 中（需区分活跃与归档项目） |
| GitHub Copilot | 200M（插件） | 4.2G | 日志多，索引少 | 低（删日志即可） |
| 通义灵码 | 150M（插件） | 2.1G | 中规中矩，缓存集中 | 低 |
| Continue | 100M（插件） | 3.4G | 本地索引与虚拟环境 | 中 |
| Bito | 120M（插件） | 6.1G | 聊天记录与检索库偏大 | 中 |
结论很明显：头号空间杀手就是 Cursor，但这也是目前综合体验最好的 AI 编程工具。它的空间消耗来源于向量索引的高频写入和历史会话的累计，本质上是“用空间换智能”。关键看你怎么取舍。
4.1 月度体检替代“攒一年再大扫除”
经验之谈：大扫除的最佳时机不是磁盘满了才做，而是每月做一次轻度体检。打开终端跑一下前面两条命令，花 10 秒看看~/.cursor、Docker、node_modules的实时大小，心里有数就能避免系统盘直接红到告警。
4.2 磁盘空间之外，还要注意内存和 CPU
清理磁盘的过程中我还发现，这些 AI 编程工具不仅吃硬盘，还会占用不小的内存和 CPU。Cursor 的索引进程@cursor/runner在后台会持续跑，即使你什么都没打开。如果你有 16G 内存，开几个项目加上 AI 插件，内存很容易爆。
我的处理方式是：在 Cursor 中把“Run in background”相关的选项关掉，用完直接 Command+Q 退出。同时，用系统的资源监视器确认没有后台残留进程。实测这能让开发机风扇安静很多。
5. 空间省回来了，但 AI 编程工具真的值得用吗？
清理完空间，最后聊点个人体会。这一年我靠 AI 编程工具确实写了不少项目，整体效率提升非常明显，但代价也在上文里了：空间被吃、内存被吃、还有“AI 写完了代码我还要花时间 review”的隐形成本。
我的建议是：对超过 5 万行代码的老项目，适度使用 AI 重构功能，别让它对整个仓库做全局改写；对新项目和新启动的项目，可以放心让它生成初始骨架和单文件代码。空间管理也一样，不要等磁盘红了一半再来救，工具的缓存和索引策略要在一开始就摸清楚并配置好。
另外提一个小小的隐藏技巧：Cursor 的 workspaceStorage 在项目移动路径后会产生大量“孤儿缓存”，因为旧路径对应的缓存不会自动删除。如果你经常在多个仓库之间切换，建议每个月手动清理一次workspaceStorage目录下那些workspace.json指向不存在路径的子目录。这一条简单的习惯，在一年维度上帮你省下的空间比你想的要大得多。
写到最后，我的系统盘从剩余 18G 恢复到了 226G。坐在亮绿灯的磁盘剩余容量面前，我只有一个感觉：该早一点动手的。
