（来源：机器之心）

编辑：冷猫

哦豁，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 脚本，在检测到模型被降级时自动暂停会话，防止低能力模型继续执行高风险操作。

安全机制判定任务「太危险」，需要交给更弱的模型来处理。但更弱的模型恰恰更容易犯错，尤其是在需要精确处理变量作用域、文件路径这类细节的场景中。

「犯错是人之常情，但要把事情彻底搞砸，还得靠电脑。」