Claude在脚本测试中删除开发者700GB的主目录数据

开发者塞巴斯蒂安·纪尧姆（Sebastien Guillemot）让Anthropic旗下的Claude写一个脚本，把他运行的每一个AI编程代理都隔离在/tmp目录下各自独立的文件夹里，并在代理运行结束后自动清理这些文件。根据他本人的说法，以及Tom's Hardware和AI Times的报道，2026年8月27日，这个脚本非但没有完成预定任务，反而删除了他的整个主目录，摧毁了大约700GB的数据，外加将近一周的工作成果。

纪尧姆经常使用AI代理来完成日常开发工作，他一直很不满的是，很多代理运行结束后并不会清理自己留下的垃圾文件，共享目录/tmp里因此堆积了大量无用数据。于是他要求Claude——报道中提到其内部代号为Fable——添加隔离和清理逻辑。Claude最初给出的方案加入了检测逻辑，用来延迟删除那些仍被正在运行的代理占用的文件，但纪尧姆认为由此产生的代码太复杂，要求换一个更简单的实现方式。

先做了对抗性审查，任务却在中途被降级

由于这个脚本涉及永久性删除数据，Claude自己决定先做一次所谓的对抗性审查（adversarial review）：它启动了另一份自身的副本，在正式执行脚本之前先检查自己的工作是否存在安全隐患。据AI Times援引纪尧姆的说法，就在这个审查过程进行到一半的时候，Anthropic的安全分类器判定这个脚本风险足够高，于是自动把负责处理它的模型降级——先是从Opus 5降到Opus 4.8。这次降级并不是纪尧姆主动要求的，而是安全系统自身针对一个具备删除文件能力的脚本所做出的风险评估触发的。

被降级为Opus 4.8之后，Claude执行了对抗性审查预先安排好的安全测试，检查脚本里写明的删除目标是否会命中/tmp或用户主目录这类危险路径。这项检查的效果完全符合预期：在测试阶段，这两条路径都被正确标记为危险目标。纪尧姆表示，他认为降级之前使用的Opus 5——据称在编程任务上的表现优于Opus 4.8——很可能会发现接下来发生的问题。

测试和清理共用同一个变量名，酿成大祸

这次安全检查只覆盖了脚本的测试阶段，并没有覆盖紧随其后的清理步骤。任何代码测试之后都需要自己的清理动作，而Claude在编写清理这一步时，重复使用了它此前已经用来存放测试目标路径的那个变量名。由于测试和清理两个阶段共用同一个变量，这个变量在安全检查期间安全地指向一个隔离的测试路径，可等到清理步骤真正运行时，它却指向了纪尧姆真实的主目录——Claude随即对这个目录执行了相当于递归删除的操作。

• 大约700GB的数据被删除，其中包括纪尧姆近一周的工作成果
• Anthropic的安全分类器在任务执行到一半时，把负责处理脚本的模型从Opus 5降级为Opus 4.8，纪尧姆本人并未要求这样做
• 对抗性安全审查正确地把/tmp和主目录标记为危险的删除目标——但它只检查了测试阶段，没有检查清理阶段
• 整个项目最初想要清理的/tmp垃圾文件，在这次删除事故之后依然原封不动

纪尧姆把这次经历发到网上之后，这个故事很快传开，其他开发者纷纷提到一些专门用来隔离AI编程代理、或者在发生这类事故后帮忙恢复数据的第三方工具——Tom's Hardware举了Termaxa这样一个例子。Tom's Hardware还直接点出了其中的讽刺之处：如今已经出现了一整类专门用来防范AI代理误删数据的安全工具，而这一次恰恰是因为在开发这一类工具的过程中，才发生了这起删除事故。

纪尧姆一发现情况不对就立刻中止了这个进程，但为时已晚，主目录里的大部分内容已经无法挽回。他表示，自己主要是靠git仓库、Nix存储数据和会话日志把大部分数据一点点拼凑回来的，而不是靠备份——按他自己的说法，他所使用的众多AI代理里，从来没有哪一个被要求去做过备份。

这对使用AI编程代理的团队意味着什么

对于已经在日常开发工作中采用Claude、Cursor等AI编程代理的中文开发团队来说，这起事件提醒人们：安全系统的内部状态——包括当前处理任务的模型版本——可能在运行过程中发生变化，而监控终端的人却看不到任何提示。对抗性审查检查的是脚本的意图，并不等于检查了该脚本实际执行的每一个阶段。任何允许代理执行破坏性命令的工作流程，即使看起来像是在隔离的测试环境中，仍然需要一份不依赖代理“正确行事”的独立备份。