程序员让 AI 帮忙”打扫卫生”，结果 AI 把他攒了几年的家当全扬了——这不是段子，是 8 月底真实发生的事。
8 月 26 日，重度 AI Agent 用户 Guillemot（就是之前研究过 Xbox 破解的那位）在 X 上发帖：他让 Claude Code 写一个清理 /tmp 临时文件的脚本，结果主目录里 700GB 数据被 rm -rf 删了个精光，其中包含整整一周的工作成果。
最魔幻的是，这场灾难正是发生在 AI”安全检查”的过程中——它本来是要证明自己不会乱删东西。
一、事故还原：从”清理 /tmp”到”主目录蒸发”
事情的起因很小。Guillemot 平时重度依赖各种 AI 编程 Agent，这些 Agent 干活勤快，但从不打扫战场，/tmp 目录被临时文件塞得满满当当。于是他让 Claude Fable 5 写一个脚本：为每个 Agent 建独立的沙盒文件夹，任务结束后自动清理，但不能删掉正在被其他进程使用的文件。
Fable 5 很快给出方案，加入了检测运行中 Agent、延迟删除的逻辑。Guillemot 觉得代码太复杂，让它简化。到这里一切正常。
转折出现在安全审查环节。因为脚本涉及 rm -rf 硬删除，Fable 5 主动启动了一次”对抗性审查”（adversarial review）——拉一个新的模型实例来检查自己的代码是否安全。这一步触发了 Anthropic 内置的安全降级机制：系统判定任务涉及敏感操作（文件删除），自动把模型从高能力的 Fable 5 一路降级到 Opus 5，最后降到 Opus 4.8。
Opus 4.8 开始执行安全测试：把删除脚本的目标路径和 /tmp、用户主目录做比对，确认脚本不会误伤关键目录。测试顺利通过——/tmp 和主目录都被正确识别为”危险目标，不可删除”。
但代码测试之后还有一步：清理测试过程中产生的临时文件。灾难就发生在这里。Opus 4.8 在清理步骤里复用了测试阶段的同一个变量名，而这个变量在测试时被赋值为用户主目录的路径——清理命令直接对着这个变量执行了删除。
翻译一下就是：模型前脚刚确认”主目录不能删”，后脚就把它删了。Guillemot 发现异常后立刻 Ctrl+C，但 700GB 已经没了。/tmp 里原本该清理的垃圾安然无恙，主目录却先走一步。他后来靠 git 仓库、Nix 包管理、会话日志和工作树把大部分内容拼了回来，但没有任何完整备份的那一周代码，永远找不回来了。
二、真正的凶手：不是模型笨，是”安全降级”帮了倒忙
这场事故最值得玩味的地方，是 Anthropic 的安全设计整个拧反了。
它的初衷很正确：遇到高风险操作，不让能力太强的模型”莽撞动手”，换成更保守的模型来兜底。但现实狠狠抽了这张设计图一巴掌——越是需要降级的操作，往往越考验精确的推理能力。变量作用域、路径解析、状态残留，这些编程里最容易翻车的细节，恰恰是弱模型最不擅长的地方。Fable 5 大概率能在测试阶段就嗅出变量名复用的问题；而 Opus 4.8 只会老老实实跑完测试，再老老实实把主目录删掉。
安全研究员复盘时还指出了更深层的隐患：可能存在 TOCTOU 竞态（检查-使用竞态，检查完到执行之间状态被改变）和沙箱边界缺陷，Agent 可以绕过本应待着的工作区。说白了，你以为它被关在笼子里，其实笼子有条缝——一旦越界，Agent 的破坏范围和你本人一模一样。
社区对这套降级机制的怨气也积攒已久，可以概括为”三宗罪”：
- 触发太敏感：日常编码任务只要沾上”删除””网络””系统调用”这类字眼就自动降级，正常活也遭殃；
- 降级有粘性：一旦触发就黏住整个会话，后面哪怕是无害步骤也继续用弱模型跑；
- 能力降了，活儿没减：弱模型接手后面对的仍是原任务的完整复杂度。
已经有开发者自己写了 hook 脚本：只要在会话里检测到降级就立刻暂停整个会话，宁可让任务卡死，也不让弱模型碰自己的文件。这是创可贴式的自救，但也侧面说明官方机制有多不让人放心。
三、这不只是 Claude 的问题：Agent 都跑在你的权限上
Guillemot 的遭遇，只是 AI 编程工具闯祸清单上最新的一笔。在此之前，有基于 Claude 的工具误删过公司数据库，有人的 Mac 主目录在仓库清理命令里因 shell 参数展开出错被整个删光。
这些事故背后是同一个架构缺陷：Agent 直接以你的用户权限运行在宿主机上，中间没有一层能拦住它删除关键目录。你以为开了沙箱，实际上默认配置下，Agent 能碰的就是你当前的权限——你对主目录有写权限，它就有。所谓”沙箱”，很多时候只是”它平时只改项目文件”这种默契，不是硬隔离。
行业内正在形成共识：coding agent 应该跑在容器或微虚拟机里，让它的主目录只映射到工作区，而不是映射到你真实的文件系统。否则厂商把安全口号吹得再响，一次变量名冲突就能把底线击穿。
对 Anthropic 来说，这个时间点也格外糟糕。它正筹备年内上市，估值传闻在两万亿美元上下，同时猛攻企业市场，和 Salesforce 一起推 Claudeforce。企业客户买 AI Agent，最看重的就是那句承诺：”它不会把我的东西搞没。”现在 Claude 亲手删了用户 700GB——这不是外部攻击，不是数据泄露，是安全机制自己干出来的事。同期还有 Claude Code 额度争议、索尼华纳起诉训练数据侵权，三连暴击叠在一起，坏消息的乘数效应远比单条事故更伤。
四、四条防线：让 AI 编程不再”删库”
这事儿能防，而且不难。分享四条我验证过的措施：
第一，隔离。 让 Agent 在一次性虚拟机或强隔离容器里干活，干完即焚。本机文件它碰不到，最坏情况就是那个临时环境没了，重开一个。现在 AI 编程工具 生态里这类方案越来越成熟，值得专门配一套。
第二，关掉自动删除。 不少 Agent 框架有清理中间产物的钩子，默认开着。把它关了，让删除变成显式动作，别让后台悄悄进行。
第三，审批门。 任何 rm、format、git reset --hard 这类不可逆操作，强制人工确认。宁可多点一次，别等它跑完才发现少了一块盘。配合 MCP 工具调用日志 这种可追踪、可回滚的方案，每一步都能看到 Agent 干了什么。
第四，定期快照。 让 Agent 动本机前先 git stash 或开个系统快照。真出事，十分钟回滚，不用对着空目录发呆。我在这篇 Claude Code 代码审查怎么做 里强调过同样的原则：AI 改完先跑校验，过不了就不让提交。
五、老达点评
第一，安全机制需要自己的安全机制。Anthropic 这次把”降级”当万能保险，结果把高能力模型换成了处理不了复杂局面的低能力模型，等于给拆弹专家递了把剪刀。“谁来审查审查者”，这是所有 AI 安全设计都要回答的问题。
第二，审批疲劳是最贵的账单。前阵子大家聊 AI 审批疲劳，说一路点同意点成了肌肉记忆，Agent 顺势把审批权收走了。这次的 700GB，就是这种疲劳最贵的一次账单——不是钱，是数据。
第三，对普通用户来说，我的建议很直接：信任可以给，锁得自己配。让 AI 碰本机文件前，先想清楚三件事——它在哪个环境跑？删除操作要不要我确认？出事了能不能回滚？这三条想清楚了，AI 编程 Agent 才能从”拆家工具”变成真正的生产力。包括 Claude Code 最近的持续更新 也在补 Agent 工具链的坑，方向是对的，但护栏这件事，别指望厂商替你焊完。
代码可以无限生成，删掉的数据找不回来。把笼子亲手焊牢，钥匙别轻易塞出去。
相关阅读：
