你的AI编程助手,正在偷偷吃掉你的SSD

2026 年 6 月 14 日，一位 ID 叫 1996fanrui 的开发者在 OpenAI Codex 的 GitHub 仓库里提交了一个 issue 。他跑了 21 天 Codex CLI ，累计往自己的 SSD 里写入了37TB数据。年化一下：640TB。

这是什么概念？一块主流消费级 SSD 的"终身写入配额"（ TBW ）大约在 150-600TB 之间。翻译一下，就是这个跑在你笔记本上、号称帮你提升生产力的 AI 编程助手，一年就能把你一块 1TB SSD 的全部寿命烧光。

而这一切，发生在你毫无察觉的情况下。

消费电子市场蹉跎多年，尚未收获人工智能创造的利润，反而先挨了两记 AI 铁拳——一记是电价，一记是 SSD 。

一、当"补全"变成"Agent"，你的硬盘就成了它的草稿纸

要理解这场灾难怎么发生的，得回到 2021 年那个"AI 只是补全"的温和年代。

那时候 GitHub Copilot 刚刚出生。它是 VS Code 里的一个扩展，没有独立进程，没有本地数据库，没有 Agent 循环。你敲一段代码，它给你灰灰地补几行建议——请求，响应，结束。它是无状态的，跟一个语法高亮插件的资源消耗没有本质区别。

这个温和年代在 2023 年前后被两件事终结。一件叫 Cursor ，一件叫 Agent 。

2022 年下半年，四个 MIT 学生创立了 Anysphere ， 2023 年 3 月发布了 Cursor 第一版。这是一个非常关键的架构决定：Cursor 从第一天起就不是"寄生"在编辑器里的插件，而是一整个 fork 自 VS Code 的独立 Electron 应用——自己的进程、自己的配置目录、自己的日志系统。两年半后， Anysphere 估值 293 亿美元。

真正的范式转移发生在 2025 年。 2 月 24 日， Anthropic 发布 Claude Code ； 4 月 16 日， OpenAI 开源 Codex CLI 。这两个东西跟 Copilot 有本质区别——它们不是被动补全，而是主动执行。它们会读文件、写文件、跑命令、看结果、再决定下一步。它们是 loop ，是 Agent 。

这次转移背后有一个几乎没人讨论的技术后果：Agent 模式必须持久化状态。

补全模式是无状态的，请求响应完事。但 Agent 模式必须记住上下文：现在在做什么任务、上一步跑了什么命令、返回了什么、跟模型的对话历史是什么、每一步的中间结果是什么。这些东西必须写到磁盘上。而且不是一次写完，是持续写、持续更新、持续追加。

于是本地 SSD 从"用户的存储介质"，静悄悄地变成了"Agent 的工作内存"。

这个变化没有任何一家厂商在发布会上讲过。因为对产品经理来说，这不是一个 feature ，只是一个"implementation detail"。但对用户的 SSD 来说，这是一场灾难的开始。

二、每一个"合理决策"都在往用户的硬盘里埋雷

回过头看 Codex 的 37TB 案例，最可怕的不是数字本身，而是每一个导致这个数字的技术决定，在做出的当下都是"合理的工程判断"。

决策一：用 SQLite 存本地状态。 Chrome 用 SQLite 、 Firefox 用 SQLite 、 iMessage 用 SQLite——它是本地应用的默认选择。 SQLite 默认开启 WAL （ Write-Ahead Logging ）模式，每一次事务都要落盘。对每分钟写几次的普通应用， WAL 没问题。但对每秒可能触发几十次状态更新的 Agent 呢？

决策二：把日志级别默认设为 TRACE 。 1996fanrui 在 issue 里贴出了~/.codex/logs_2.sqlite的分布：

最诡异的是，SQLite AUTOINCREMENT计数器走到了55 亿。也就是说 Codex 在 21 天里往这张表里写了 55 亿条记录，然后又删掉了绝大部分，只留下 50 万条。5.5 billion 写入换来 500k 保留，写放大比大约 10,000 倍。

TRACE 里都是什么呢：

128,764x TRACE: inotify event ... name: Some("ld.so.cache")
 37,982x TRACE: inotify event ... name: Some("locale.alias")
 23,843x TRACE: inotify event ... name: Some("passwd")

翻译成人话就是：每一次系统打开ld.so.cache这种"每个 Linux 进程启动都要碰一下"的系统文件， Codex 都要往 SQLite 里写一条 TRACE 日志。

这个 bug 的完整样貌是这样的：某个 OpenAI 工程师，为了排查某个具体问题，把日志级别开成了 TRACE ，配置好 SQLite sink ，然后……忘了改回来。这个配置随着 Codex CLI 一起发到了 GitHub 上 94.9k star 的仓库，跑到了几十万开发者的机器上。

决策三：codex_otel.log_only和codex_otel.trace_safe两条遥测路径。 这两条合起来占了保留字节的 25.3%。名字就暴露了目的——OpenTelemetry 遥测。 Codex 在本地跑一份"用于给 OpenAI 团队看的诊断数据"，占据你的 SSD 寿命。

这里的悖论很妙：遥测本应帮工程师改进产品，但它是写在用户硬件上的。用户为 OpenAI 的工程改进付出了物理磨损，却没有任何知情或选择的机会。

Anthropic 的 Claude Desktop 走的是另一条路——Electron 应用。 GitHub issue #43390 里一位 MacBook Pro M5 用户抓到了完整证据：

一小时内 13GB 。 macOS 的诊断系统直接把它标为"超出正常阈值"——正常应用的可接受阈值是 99KB/s 持续， Claude Desktop 干到了 2000-5000KB/s 。

调用堆栈也很清楚： Electron 里的 libuv I/O 线程池，在不停地调 kernel 的write() syscall 。写到哪里？~/Library/Application Support/Claude/vm_bundles/，一个 13GB 的目录。

更抽象的是级联反应： macOS 的 APFS 守护进程apfsd因为跟不上写入量，两天内出现 4 次 CPU 资源违规； Spotlight 的spotlightknowledged一周内爆发 6 次，因为它在拼命尝试给一个每秒都在变的 13GB 目录建索引。Claude Desktop 一个应用，触发了整个 macOS 系统的连锁反应。

三、六天修复，但如果没人发现呢

Codex 的 37TB 问题不是 2026 年 6 月才出现的。 1996fanrui 描述的现象已经持续了 21 天，仓库里还有一串平行 issue——#17320 （更早的 WAL 问题）、#22444 （悬挂的文件描述符）、#20563 （ idle I/O 被诊断为 WAL churn ）。问题积累了半年，一直没有大规模引爆。

真正的引爆点是三件事叠加：

6 月 22 日，有人把 issue #28224 发到了 Hacker News 首页。评论区第一条高赞就是："同样问题也在 Claude Code 上。它把 debug log 写到~/.claude/logs，我不得不 symlink 到 tmpfs 才停下来。"这条评论把两个厂商的问题串起来了——这不再是"某一个产品的 bug"，而是"AI 编程助手这一类产品的架构病"。

6 月 22-23 日， Notebookcheck 、 The Register 、 TechTimes 陆续跟进，标题一个比一个吓人："OpenAI Codex has a critical bug that could kill your SSD in under a year"。

6 月 23 日， OpenAI 紧急合并三个 PR （#29432 、#29457 、#29599 ），减少约 85%日志。 1996fanrui 自己关闭了 issue 。

从问题公开到修复合并，六天。这个响应速度对 OpenAI 来说是极快的。

但反过来问：如果没有那场 Hacker News 讨论，这个 bug 会存在多久？

看 issue 的时间戳，答案很可能是"直到有人的 SSD 真的坏掉为止"。

注意，我们没有说 OpenAI 故意在烧用户的硬盘，只是陈述一个客观存在的现象——在硬件性能过剩的年代，软件对本地资源的粗放消耗，只能靠用户里少数几个愿意写 SQL 查询、自己算写放大、贴到 GitHub 的人来纠正。

四、四家厂商，同一种病

把当下 AI 编程助手赛道的主要玩家放到同一个横截面上比较，核心问题不是"谁功能强"——那种榜单每周都有人做——而是谁在用户的硬件上表现得更像一个懂事的租客。

Anthropic Claude Code ：终端书呆子，桌面版是灾难。 CLI 版相对克制，主要写入~/.claude/。真正的重灾区是 Desktop——8-13GB/h 、 13GB 的vm_bundles目录、连锁触发 APFS 和 Spotlight 崩溃。 Anthropic 官方对 issue #43390 的处理姿态耐人寻味——最终被打上了invalid标签，理由是"Issue doesn't seem to be related to Claude Code"。也就是说，官方把桌面版的问题从 Claude Code 仓库里"甩"了出去。这本身是一种典型的组织架构对用户体验的反噬——桌面客户端归 App 团队， CLI 归 Coding 团队，但用户看到的都是 Claude 。

OpenAI Codex CLI ： Rust 底座上的 SQLite 灾难现场。 Rust + Tokio + SQLite 在服务端场景里几乎是最佳实践的组合。但当它跑在用户机器上、以 TRACE 级别记录一切、并且把这些记录塞进 SQLite WAL——它就变成了一台"精心设计的 SSD 磨损机"。它反映的是 Codex 团队在把服务端最佳实践搬到本地 CLI 时的"上下文错位"。 Codex 唯一让人稍微欣慰的一点是：它的问题被公开且完整地暴露在了 GitHub 上。 Rust 项目、开源代码、 issue 追踪透明——用户能看到具体是哪个 target 、哪个 level 在耗盘。

Cursor ：估值 293 亿美元，资源治理是黑箱。 Cursor 在这次事件里显得比较"安静"——但这不是因为它没问题，而是因为它的问题更难被外部审计。它是 fork 自 VS Code 的 Electron 应用，闭源，通过订阅收费。用户在官方论坛贴过一个截图，标题很直白："Is this disk usage right or am I tripping?"——重启一次 Cursor ，瞬间往磁盘写 100MB 。也有人写过一篇技术博客，靠把 Cursor workload 移到一块独立 SSD 上来"隔离"污染。这种 workaround 本身就说明了问题的存在。

GitHub Copilot ：最"传统"、也最不出事的那个。 Copilot 在这次事件里几乎是唯一的"没事人"。它是 VS Code 扩展，跑在 extension host 里，不是独立进程。没有独立的 SQLite 数据库，没有独立的 vm bundle 。但这不是因为 Microsoft 更懂资源治理，而是因为 Copilot 还没有完成向 Agent 的彻底转型。 GitHub Community 上已经有开发者在问"Where does VS Code Copilot store the local index?"——GitHub 官方的回复很典型："Beyond that we don't document the exact file names."

"Beyond that we don't document"是当下所有 AI 编程助手的共同姿态：本地资源消耗是黑箱。

四家厂商在"资源预算意识"这一栏上，表现完全一致。

五、性能迷雾之下，谁在为 SSD 磨损买单

这场异化，是三个自我强化的机制把行业锁死在这条路上的必然结果。

第一个机制是硬件过剩。 消费级 SSD 从 2015 年 SATA 时代的 500MB/s 顺序写入，涨到了 2025 年 PCIe 5.0 时代的 14000MB/s ，翻了近 30 倍。 TBW 从 150TB 涨到了 600-1200TB 。硬件性能的指数级增长意味着，软件工程师在写代码时不再需要考虑 I/O 成本。一个每秒往 SSD 写 5MB 的应用，在 2010 年是不可想象的，在 2025 年却是"无感"的。硬件性能变成了容忍软件粗放的缓冲垫。

第二个机制是融资节奏。 Cursor 两年半从 0 到 293 亿美元估值。这种融资节奏必然导致产品优先级向"新功能、新模型、新能力"倾斜。没有一家 VC 会为"我们的 CLI 只写 100MB 日志"给你估值。

第三个机制是可观测性文化。 OpenTelemetry 、结构化日志、 TRACE 级 tracing——这一整套现代软件工程的最佳实践，在服务端环境里是绝对正确的。因为服务端跑在云上，磁盘是公司的成本，可以按需扩容。但当同一套 stack 直接搬到用户的笔记本上跑，"公司的可观测性"就变成了"用户的 SSD 磨损"。

三个机制合起来构成了一个封闭循环：硬件够快，所以软件可以粗放；融资够热，所以只顾冲功能；工程文化默认全量日志，所以本地写入越来越大——而所有这些成本，都被静悄悄地转嫁到了终端用户的物理硬件上。

用户的 SSD 寿命成了一种未定价的公共资源，谁都可以取用。

这跟环境议题里的"外部性"是同一个逻辑。工厂排污水的成本被转嫁给了下游居民，因为下游居民没法起诉、没法定价、没法维权。软件粗放的成本被转嫁给了用户的 SSD ，因为 SSD 磨损没法起诉、没法定价、没法维权。在一个理想的市场里，用户应该能对"我的 SSD 被烧了多少 TBW"进行定价，然后从软件厂商那里拿回补偿。但这个市场根本不存在。

这里就出现了性能迷雾最欺骗性的一面：你的 M5 MacBook Pro 装了 926GB SSD ，即使一小时被写掉 13GB ，剩余空间还有 524GB ，一切"看起来"正常。你的 CPU 使用率大部分时候不到 20%，你不会想到有一个后台进程正在把你的 SSD 寿命一点点吸干。性能迷雾让"资源被消耗"这件事，从"用户可感知的即时反馈"，变成了"用户不可感知的累积伤害"。

厂商在管理 token 上做到了 dashboard 、 pricing tier 、 rate limit 一应俱全，因为 token 是它们的成本。它们在管理你的 SSD 上却没有任何机制，因为 SSD 是你的成本。

六、下一场爆雷之前，谁来守住底线

给三个剧本。

最可能的剧本：表面修复，实质延续。 OpenAI 修好了 Codex 的 640TB bug ， Anthropic 大概率会在压力下改进 Claude Desktop 的 vm_bundles 行为——但都是"应急修补"级别，不会有任何一家把"资源预算"作为 first-class feature 。用户界面上不会出现"本月本地磁盘写入： X GB"的仪表盘。因为一旦有了这个仪表盘，用户就会开始对比、开始抵触、开始削价。厂商没有动力去可视化一个转嫁给用户的隐性成本。

最危险的剧本：一起标志性事件促成的过度反应。 某个知名开发者的 SSD 因为 AI Agent 的持续写入而提前失效，媒体大规模跟进，欧盟或加州出台"AI 应用本地资源披露"法规。这会导致行业陷入合规风暴，一批小厂商倒闭，大厂商为了合规大幅缩水功能，最终损害的还是用户体验。

最乐观的剧本：开源社区推动"AI Agent 资源标准"的形成。 出现一个类似 SNIA 或 W3C 的组织，提出"Local Agent Resource Envelope"规范。厂商在这个规范下竞争"最低 footprint"作为差异化卖点，就像今天手机厂商竞争"最长续航"。资源治理从工程问题变成产品问题，从产品问题变成竞争问题，最后变成用户福利。

我个人的判断偏向"最可能"，但会往"最乐观"偏一点点——因为 1996fanrui 那种自己写 SQL 查询、自己算写放大、自己贴到 GitHub 的开发者社区文化，是这个行业里少数还能对"工具理性异化"形成有效制衡的力量。这份 issue 从提交到合并 PR 用了六天，这已经证明了透明化压力的有效性。

问题是，透明化压力只对开源产品有效。对 Cursor 这种闭源的、估值 293 亿美元的、把自己包装成"AI 时代的 IDE"的产品，谁来施加透明化压力？

答案不会来自厂商。也很难来自监管。可能只能来自那些愿意花一个下午去测算自己 SSD 写入量、然后把结果贴到 GitHub 上的人。

回到开头那个 37TB 的数字——它不是一个 bug ，它是一个物种性缺陷的显影。软件工程的核心目标（高效、可靠、用户友好）与 AI 工具的实际实现之间，出现了根本性的异化。这场异化不会自我修复。它需要有人一次次把 TRACE 日志的具体行数贴出来，需要有人一次次把 8-13GB/h 的写入速率抓下来，需要有人一次次把"我们不 document 具体文件名"的答复转发到 Hacker News 首页。

在一个硬件性能可以无限兜底的时代，你的 SSD 寿命，是这场悄悄进行的军备竞赛里，那个不会说话、也没人为它说话的受害者。