Claude 安全机制翻车，AI 误删开发者 700GB 主目录

Anthropic 的 Claude Code 内置了一套安全降级机制：当系统判定任务涉及敏感操作（如文件删除）时，会自动将模型切换到更保守的版本。然而近日一名重度 AI Agent 用户发现，正是这套安全机制导致其 700GB 主目录被误删，一周的工作成果化为乌有。

事件缘起：让 AI 写一个清理脚本

开发者 Guillemot 长期使用各类 AI 编程代理辅助日常工作，但这些 Agent 用完后从不清理 /tmp 目录的垃圾文件。为解决这一问题，他让 Claude（Fable 5 版本）编写一个脚本：为每个 Agent 在 /tmp 下创建独立沙盒文件夹，任务完成后自动清理，并确保不会误删正在被其他进程使用的文件。

Fable 5 很快给出了方案，加入了检测运行中 Agent 并延迟删除的逻辑。Guillemot 认为代码过于复杂，要求简化。此时一切进展正常。

安全降级机制被触发

由于脚本涉及硬删除操作，Fable 自行发起了一次「对抗性审查」（adversarial review），即启动一个新的模型实例检查自己写的代码是否安全。这一动作触发了 Anthropic 内置的安全降级机制。

该机制的本意是降低高风险场景下模型「过于激进」的可能性：当任务被判定涉及网络安全、生物技术或文件删除等敏感领域时，系统会自动将模型从高能力版本切换到更保守的版本。

此次事件中，系统依次将模型从 Fable 5 降级到 Opus 5，再进一步降到 Opus 4.8。

测试通过，清理翻车

Opus 4.8 执行的安全测试逻辑是：将删除脚本的目标路径与 /tmp 和用户主目录进行比对，确认脚本不会误伤这些关键目录。测试本身通过——/tmp 和用户主目录均被正确识别为「危险目标，不可删除」。

然而在测试之后的清理步骤中，模型复用了测试阶段的同一个变量名。该变量在测试阶段被赋值为用户主目录的路径，清理步骤直接对其执行了删除操作。也就是说，模型刚刚确认了「主目录不能删」，下一秒就把主目录删了。

Guillemot 发现异常后立刻终止进程，但为时已晚：700GB 数据已被清除，而原本要清理的 /tmp 目录反而安然无恙。

社区对降级机制的长期不满

安全降级机制在 Claude Code 用户社区中早已引发大量投诉，核心问题集中在三点：

• 降级过于敏感，常规编码任务也会被误触发
• 降级后模型能力显著下降，但任务复杂度不变
• 降级具有「黏性」，一旦触发便会持续整个会话，即使后续操作完全无害

有开发者专门编写 hook 脚本，在检测到模型被降级时自动暂停会话，防止低能力模型继续执行高风险操作。

这一案例再次印证了社区的担忧：系统把任务判定为「太危险」并交给更弱的模型处理，而更弱的模型恰恰更容易在变量作用域、文件路径等需要精确处理的细节上犯错。正如开发者社区中的那句调侃：「犯错是人之常情，但要把事情彻底搞砸，还得靠电脑。」