哦豁,Claude 又双叒翻车了!
这次 Claude 把开发者的整个项目主目录给删了,删了 700GB 的文件。又是「rm -rf」。
简而言之,开发者让 AI 帮写脚本,目的是确保文件不会被误删。AI 觉得这事有点危险,于是启动了安全审查。审查的结果是:它把整个主目录删了。
Guillemot 是一名重度 AI Agent 用户。日常开发中,他频繁调用各种 AI 编程代理来辅助工作。但有一个小问题一直困扰着他:这些 Agent 用完之后从不打扫卫生,在 /tmp 目录下留下大量垃圾文件。
于是他做了一个看起来非常合理的决定:让 Claude Fable 5 写一个脚本,为每个 Agent 在 /tmp 下创建独立的沙盒文件夹,任务完成后自动清理。核心难点在于,不能删掉正在被其他进程使用的文件。
Fable 很快给出了方案,加入了检测运行中 Agent 并延迟删除的逻辑。Guillemot 看了一眼,觉得代码过于复杂,要求简化。
到这一步,一切还算正常。
事情的转折点出现在安全审查环节。
由于脚本涉及硬删除操作,Fable 自行发起了一次「对抗性审查」(adversarial review),也就是启动一个新的模型实例来检查自己写的代码是否安全。这触发了 Anthropic 的安全机制。
Anthropic 在 Claude Code 中内置了一套安全降级机制:当系统判定当前任务涉及敏感操作(如网络安全、生物技术,或本例中的文件删除)时,会自动将模型从高能力版本降级到更保守的版本。这套机制本意是降低高风险场景下模型「过于激进」的可能性。
在这个案例中,安全系统先将模型从 Fable 5 降级到 Opus 5,然后进一步降到 Opus 4.8。
Opus 4.8 开始执行安全测试。测试逻辑是这样的:将删除脚本的目标路径与 /tmp 和用户主目录进行比对,确认脚本不会误伤这些关键目录。
测试本身通过了。/tmp 和主目录都被正确识别为「危险目标,不可删除」。
但代码测试之后还有一个清理步骤:删除测试过程中产生的临时文件。灾难就发生在这里。Opus 4.8 在清理步骤中复用了测试阶段的同一个变量名。这个变量在测试阶段被赋值为用户主目录的路径,清理步骤直接对这个变量执行了删除操作。
也就是说,模型刚刚确认了「主目录不能删」,下一秒就把主目录删了。
开发者发现异常后立刻终止了进程,但为时已晚。700GB 的数据已经被清除,一周的工作成果化为乌有。
那个原本要清理的 /tmp 目录,则安然无恙。
模型安全降级机制在社区中早已引发大量投诉。
开发者反映的核心问题包括:降级过于敏感,正常的编码任务也会被误触发;降级后模型能力显著下降,但任务复杂度不变;降级是「黏性」的,一旦触发就会持续整个会话,即使后续操作完全无害。
有开发者甚至专门写了一个 hook 脚本,在检测到模型被降级时自动暂停会话,防止低能力模型继续执行高风险操作。
安全机制判定任务「太危险」,需要交给更弱的模型来处理。但更弱的模型恰恰更容易犯错,尤其是在需要精确处理变量作用域、文件路径这类细节的场景中。
「犯错是人之常情,但要把事情彻底搞砸,还得靠电脑。」
本文来自微信公众号“机器之心”(ID:almosthuman2014),作者:冷猫
