一夜跑出 3800 美元账单：程序员把 Claude Code 玩成了“分叉炸弹”
一台发烫的 Mac，一张差点失控的账单
科技新闻里常见那种“AI 改变工作流”的故事，往往从效率、生产力和未来感讲起。但最近这篇开发者自述让我想起另一面：AI 工具也会把人类最古老的工程事故，重新包装一遍，再用更贵的方式上演。
事情发生在 2026 年 2 月底。一位使用 Claude Code 的开发者，早上坐到电脑前，发现 Mac 完全没反应，按键、触控板、指纹识别统统失灵，机器底部还烫得吓人。他第一反应甚至不是软件问题，而是几个月前泼过茶，怀疑硬件终于报废。结果真正的“元凶”藏在另一个方向：他前一晚新写的 SessionStart Hook，会在 Claude Code 启动时再拉起两个后台 Claude 实例，而每个新实例又会重复同样的启动流程。
是的，这基本就是一个 AI 时代版本的 fork bomb——分叉炸弹。1 变 2，2 变 4，4 变 8，指数级膨胀。电脑不是坏了，而是被自己亲手配置的自动化规则活活拖死了。更戏剧性的是，当他终于删掉配置、压住惊魂，打开计费页面时，最可怕的问题才浮出水面：API 账单会不会直接炸穿公司财务系统？
老事故有了新外衣：从 Unix 时代到 Agent 时代
如果你学过一点操作系统，就知道 fork bomb 并不新鲜。它的原理朴素得像黑色幽默：一个进程不断复制自己，直到机器资源耗尽。过去这是课堂上的经典案例，也是系统管理员会提醒新手别乱玩的危险把戏。可到了今天，这类问题借着“AI Agent”“自动化编排”“工具调用”这些时髦词，又回到了现实生产环境，而且危险性更高了。
原因很简单。传统 fork bomb 毁掉的主要是本地 CPU、内存和系统响应；而 AI 工具链里的 fork bomb，除了吃掉本地资源，还会持续调用远端模型 API，把资源消耗直接换算成真金白银。一次配置错误，不只是电脑卡死，还是一张实时跳字的账单。开发者文中提到，看到 Usage 页面还在往上加钱时，心跳都快和风扇转速同步了。最终之所以没有酿成更夸张的财务事故，竟然是因为 Claude Code 本身体积偏重，Bun、React 和 TUI 这一串技术栈把单实例内存占用堆得太高，机器先撑不住了。换句话说，这次救他的，恰恰是软件“不够轻巧”。
这听起来非常荒诞，但也非常现代：糟糕的工程实现，偶然充当了最后一道保险丝。你很难说这是幸运，还是行业还没准备好把“自动执行权”交给模型。
Claude Code 爆红背后，开发者到底在拿它做什么
这篇自述之所以有意思，不只是因为它像一场大型翻车现场，还因为它把当下开发者使用 AI 编程工具的真实状态拍得很清楚。作者并不是一个盲目追捧 Agent 的人。相反，他一开始对“全自动 AI 编程流程”是抗拒的，甚至明确反对过相关提案。但在公司逐渐把 AI 协作视为新常态后，他做了很多工程师都会做的事：你可以不喜欢它，但你不能不理解它。
于是他开始系统研究 Claude Code，甚至给团队做内部培训，还围绕这个工具搭了一整套个人工作流。比如把失败操作记下来，方便回溯模型又做了什么蠢事；比如把对话摘要、项目状态、截图 OCR 结果收集起来，尽量压缩上下文窗口的浪费；再比如自动从 Slack、GitHub、Notion 里抓待办，让模型帮忙整理一天的任务优先级。
说白了，这不是“让 AI 替你写代码”那么简单，而是把大模型塞进一个越来越复杂的个人操作系统里。它开始接触你的命令行、文档、聊天记录、项目状态，扮演一个介于实习生、秘书和脚本调度器之间的角色。问题也正出在这里：当模型被赋予越来越多入口，哪怕只有一个 Hook 配错了，也可能引发链式反应。
这就是为什么这件事不该只被当成笑话看。它不是某个开发者手滑那么简单，而是 AI coding agent 正在从“聊天窗口里的建议器”升级成“能主动调工具、跑脚本、改环境”的执行体。执行体的错误，永远比建议器的错误贵。
贵，不只是贵在 Token，而是贵在失控
文中最抓人的数字当然是 3800 美元。这个金额足够让任何团队主管皱眉，也足够让无数普通开发者重新审视“AI 编程到底值不值”。不过我觉得更值得关注的，不是这 3800 美元本身，而是它揭示出的成本结构变化。
过去团队采购开发工具，成本通常比较稳定：许可证、云主机、CI/CD、监控服务，都是大致可预测的。而到了 LLM 时代，工具成本开始高度弹性化。你写一个糟糕的循环，可能以前只是多跑几分钟 CPU；现在却可能变成持续数小时、跨多个实例、不断调用模型的计费黑洞。尤其在 Claude Code、Cursor、Copilot Workspace、Devin 这类强调代理式工作的产品中，计费模型和执行链路是捆在一起的。工具越“自动”，成本越“不自动”。
这也是为什么越来越多公司开始重新谈三件以前不算性感、现在却非常关键的事：预算上限、权限隔离和可观测性。说得直白一点，AI Agent 不能只看“能不能做事”，还得看“出了事能不能刹住车”。有没有消费预警？有没有任务级别的费用追踪？有没有沙箱限制它乱起进程、乱读文件、乱调外部服务？这些问题以前更像基础设施团队的工作，现在正迅速变成所有使用 AI 编程工具的团队都要面对的现实。
而且，这场事故还暴露了另一个尴尬事实：模型的“记忆”并没有宣传中那么可靠。作者自己做了一堆补丁式技能，来帮 Claude Code 记住项目状态、提炼上下文、回看历史操作。某种程度上，这很像开发者在给 AI 工具外接义肢。你当然可以说这是一种高阶玩法，但也可以反过来说：如果一个工具需要用户自行搭十几层脚手架，才能在真实工作里稳定发挥，那它离“成熟生产力工具”还有距离。
这件事为什么重要：AI 编程正在进入“工程治理”阶段
我一直觉得，AI 编程工具在 2023 年和 2024 年的关键词是“惊艳”，到 2025 年是“普及”，而从 2026 年开始，行业会越来越多谈“治理”。因为大家已经不再满足于让模型补几行代码、解释几个报错，而是希望它真正参与项目流程。可一旦它真的参与流程，所有老派软件工程问题——权限、审计、回滚、计费、监控、故障隔离——都会卷土重来，而且更复杂。
这次 Claude Code 分叉炸弹，就是一个非常典型的信号。它提醒我们，Agent 不是“更聪明的聊天机器人”，而是一种新的执行层。只要它接上 Hook、脚本和系统工具，就必须像对待自动化运维系统那样对待它。你不会让一个没限流、没告警、没权限边界的运维脚本自由运行一整夜；同样，你也不该让一个会自动调用模型和命令行的 AI Agent 在缺乏护栏的情况下自由繁殖。
这也引出一个值得行业继续争论的问题：未来的 AI 编程工具，到底应该更开放，还是更保守？开放意味着极高的可定制性，高手可以搭出惊人的工作流；保守意味着更强的安全边界，减少灾难性误操作。Cursor、Claude Code、OpenAI 相关 agent 产品，乃至各种开源代理框架，现在都在这条钢丝上走。我的判断是，面向企业和团队协作的产品，最终一定会向“默认保守”靠拢，把危险能力锁进更严格的权限模型里；而把高自由度留给明确知情、愿意承担风险的高级用户。
说到底，这起事故既好笑，也有一点刺痛。它像一则技术圈寓言：我们一边嫌弃 AI 不够聪明，一边又急着把越来越多控制权交给它；我们以为自己在训练工具，最后却常常是在给自己的系统埋雷。只是以前雷炸掉的是 shell，现在炸掉的是 shell 加账单，再加一整套工作流的信心。
从这个角度看，那台发烫的 Mac 倒像一个很诚实的隐喻：AI 编程正在升温，行业也差不多该认真摸一摸机身温度了。