开发者的噩梦，有时候是 AI 亲手送的。
这周有个叫 Sebastien Guillemot 的开发者，本想用 Claude 写个脚本自动清理 /tmp 垃圾文件，结果 AI 直接把他的整个用户主目录给端了——约 700GB 数据，相当于一周的工作成果瞬间蒸发。
安全机制反而成了帮凶
事故链条很有意思。Anthropic 的安全系统检测到任务有风险，自动把模型从 Fable 5 降级到 Opus 4.8。听起来是负责任的防守，对吧？但问题恰恰出在这。
降级后的模型在安全测试中确实正确识别了主目录和 /tmp 是危险路径，但测试结束后的清理环节，因为测试逻辑和清理逻辑复用了同一个变量名，意外删除了用户主目录。
最讽刺的是，Claude 在删光主目录后，完美保留了 /tmp。这大概就是 AI 版的"精准打击"吧。
复杂方案被简化，隐患埋下
Guillemot 原本的方案其实挺严谨——检测正在运行的智能体、延迟清理对应目录。但他嫌代码太复杂，要求简化。于是安全审查被触发，模型降级，逻辑冲突，连锁反应。
他事后推测，如果由编码能力更强的 Fable 5 执行，或许能发现变量名冲突。但这属于事后诸葛亮，没人能确认。
给所有用 AI 干活的人提个醒
这起事故暴露了几个扎心的事实：
- AI 能识别风险，不代表能规避所有逻辑错误。识别危险路径只是第一步，测试代码本身的 bug 照样能绕过安全判断。
- "简化方案"要谨慎。复杂的防御逻辑往往是保命符，删掉它等于裸奔。
- 备份才是终极防线。Git、Nix、会话日志只能恢复部分数据，无法替代完整备份。
Guillemot 后来靠 Git 仓库和日志恢复了大半数据，但那些没被版本控制捕捉的零散文件，可能永远找不回来了。
我的看法
这事让我想到一个更本质的问题：我们正在把越来越危险的操作交给 AI 执行，但 AI 的"安全机制"本身也是代码，也会犯错。当安全机制和业务逻辑耦合在一起，反而可能产生新的漏洞。
与其指望 AI 永远不出错，不如从一开始就假设它会出错，然后做好隔离和备份。比如给 AI 一个受限的沙箱环境，或者至少让它操作前先打快照。
对了，那个变量名冲突的 bug，放到人类程序员身上可能早就被 review 抓出来了。但 AI 的代码审查，居然也是 AI 自己——这算不算一种"监守自盗"？
AI 安全 的路还很长，这次事故算是给行业交了笔昂贵的学费。
评论 (0)