Claude安全机制大翻车！AI怒删开发者700 GB主目录
编辑：冷猫
哦豁，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 目录，则安然无恙。