Codex 正在吞噬你的 Mac 磁盘空间？

一个不起眼的 HN 帖子，戳中了 AI 编程工具的痛点

Hacker News 上出现了一条标题颇为惊悚的帖子：「Codex is EATING my Mac's disk space」。帖子本身只有 3 分和 1 条评论，信息量极低，但它指向的问题却值得每一位使用 AI 编程助手的开发者警惕——本地 AI 工具的磁盘占用，正在成为一个被忽视的隐性成本。

由于原帖没有提供具体的技术细节，我们无法确认是缓存文件、模型权重、日志堆积还是索引数据库导致的膨胀。但「Codex」这个词本身已经足够说明问题：无论它指的是 OpenAI 的 Codex 模型本地缓存，还是某个同名 AI 编程工具，这类工具的共同特征是——它们会在本地留下大量「看不见」的数据。

为什么 AI 编程工具会悄悄吃掉磁盘

模型文件与向量索引

现代 AI 编程助手通常需要在本地保存模型文件或嵌入向量索引。一个中等规模的代码补全模型动辄占用数 GB，而向量数据库在索引大型代码库时也会迅速膨胀。这些文件往往存放在用户目录的隐藏文件夹中，普通的磁盘清理工具很难发现。

向量索引（Vector Index）：AI 编程助手为了在大型代码库中实现语义搜索或上下文检索，通常会把代码片段交给嵌入模型（Embedding Model）转成高维向量，再存入向量数据库（如 FAISS、Chroma、LanceDB 等）。向量本身是浮点数数组，单条 768 维或 1536 维的向量就要占用数 KB，一个几十万文件的仓库轻易就能生成数百万条向量，加上索引结构（HNSW 图、倒排表等）的额外开销，占用几个到几十 GB 并不罕见。这些数据往往放在隐藏目录里，且重建索引成本高，工具通常不会主动删除，于是成为磁盘占用的隐形大户。

缓存与日志的滚雪球效应

AI 工具在运行过程中会缓存大量的上下文、对话历史和推理日志。单次请求的缓存可能只有几百 KB，但日积月累，尤其是在高频使用场景下，这些缓存可能增长到数十 GB。更麻烦的是，很多工具默认不会自动清理旧缓存。

为何缓存默认不清理：多数 AI 工具的缓存设计以「命中率优先」为目标——保留旧缓存能减少重复的模型调用和网络请求，从而降低延迟与 API 费用，因此清理策略往往比较保守，甚至默认关闭。同时，日志常被用于调试、审计和效果评估，工具方倾向于长期保留。用户侧的困境在于：这些目录名不直观、分散在 ~/Library/Caches、~/.cache、应用支持目录等多处，系统自带的「存储空间」面板也难以归类到具体应用，导致问题只有在磁盘告警时才被发现。

如何排查和应对

如果你怀疑自己的 Mac 磁盘被某个 AI 工具占用，可以按以下步骤排查：

1. 使用 du -sh ~/Library/Caches/* 查看缓存目录的占用情况
2. 检查 ~/.codex、~/.cache 等常见隐藏目录
3. 用 find ~ -name "*.log" -size +100M 定位大日志文件
4. 在工具的设置中查找缓存清理选项，或手动删除已知的缓存目录

对于开发者来说，更根本的解决方案是在使用 AI 编程工具时养成定期检查磁盘占用的习惯，而不是等到系统提示「磁盘空间不足」才去处理。

命令说明与安全提示：du -sh ~/Library/Caches/* 会按目录汇总大小，-s 表示只显示总计、-h 表示人类可读单位；若输出过多可加 | sort -rh | head -20 只看最大的前 20 项。find ~ -name "*.log" -size +100M 中的 +100M 表示大于 100 MB 的文件。手动删除前建议先确认目录归属：删除模型权重或向量索引会导致下次启动时重新下载或重建，耗时且可能产生流量费用；删除正在被进程占用的文件也可能引发异常。更稳妥的做法是先退出相关应用，再清理明确的缓存子目录，并留意工具是否提供 cache clean 之类的官方命令。

一个更大的信号

这条帖子虽然信息量有限，但它反映了一个更大的趋势：随着 AI 工具越来越深度地嵌入开发工作流，它们带来的资源开销（磁盘、内存、电量）正在从「可忽略」变成「需要管理」。AI 编程工具在提升效率的同时，也在悄悄地把成本转移到用户的硬件上。

对于工具开发者而言，这是一个产品体验问题——默认的缓存策略、自动清理机制、磁盘占用的可见性，都应该被认真对待。对于用户而言，这是一个提醒：AI 工具的效率红利并非免费，定期做一次磁盘体检，可能比多装一个清理软件更有用。