资讯
Claude安全机制大翻车，AI怒删开发者700GB主目录
📌 概要
<p>哦豁，Claude 又双叒翻车了！</p> <p>这次 Claude 把开发者的整个项目主目录给删了，删了 700GB 的文件。又是「rm -rf」。</p> <p class="image-wrapper"><img src="https://img.36krcdn.com/hsossms/20260830/v2_6e41a8b1577042bab02b3403172e05f7@0
<p>哦豁，Claude 又双叒翻车了！</p>
<p>这次 Claude 把开发者的整个项目主目录给删了，删了 700GB 的文件。又是「rm -rf」。</p>
<p class="image-wrapper"><img src="https://img.36krcdn.com/hsossms/20260830/v2_6e41a8b1577042bab02b3403172e05f7@000000_oswg472515oswg1080oswg1357_img_000?x-oss-process=image/format,jpg/interlace,1" /></p>
<p>简而言之，开发者让 AI 帮写脚本，目的是确保文件不会被误删。AI 觉得这事有点危险，于是启动了安全审查。审查的结果是：它把整个主目录删了。</p>
<p>Guillemot 是一名重度 AI Agent 用户。日常开发中，他频繁调用各种 AI 编程代理来辅助工作。但有一个小问题一直困扰着他：这些 Agent 用完之后从不打扫卫生，在 /tmp 目录下留下大量垃圾文件。</p>
<p>于是他做了一个看起来非常合理的决定：让 Claude Fable 5 写一个脚本，为每个 Agent 在 /tmp 下创建独立的沙盒文件夹，任务完成后自动清理。核心难点在于，不能删掉正在被其他进程使用的文件。</p>
<p>Fable 很快给出了方案，加入了检测运行中 Agent 并延迟删除的逻辑。Guillemot 看了一眼，觉得代码过于复杂，要求简化。</p>
<p>到这一步，一切还算正常。</p>
<p>事情的转折点出现在安全审查环节。</p>
<p>由于脚本涉及硬删除操作，<strong>Fable 自行发起了一次「对抗性审查」</strong>（adversarial review），也就是启动一个新的模型实例来检查自己写的代码是否安全。这触发了 Anthropic 的安全机制。</p>
<p>Anthropic 在 Claude Code 中内置了一套<strong>安全降级机制</strong>：当系统判定当前任务涉及敏感操作（如网络安全、生物技术，或本例中的文件删除）时，会自动将模型从高能力版本降级到更保守的版本。这套机制本意是降低高风险场景下模型「过于激进」的可能性。</p>
<p>在这个案例中，安全系统先将模型从 Fable 5 降级到 Opus 5，然后进一步降到 Opus 4.8。</p>
<p>Opus 4.8 开始执行安全测试。测试逻辑是这样的：将删除脚本的目标路径与 /tmp 和用户主目录进行比对，确认脚本不会误伤这些关键目录。</p>
<p>测试本身通过了。/tmp 和主目录都被正确识别为「危险目标，不可删除」。</p>
<p>但代码测试之后还有一个清理步骤：删除测试过程中产生的临时文件。灾难就发生在这里。Opus 4.8 在清理步骤中复用了测试阶段的同一个变量名。这个变量在测试阶段被赋值为用户主目录的路径，清理步骤直接对这个变量执行了删除操作。</p>
<p>也就是说，模型刚刚确认了「主目录不能删」，下一秒就把主目录删了。</p>
<p>开发者发现异常后立刻终止了进程，但为时已晚。700GB 的数据已经被清除，一周的工作成果化为乌有。</p>
<p>那个原本要清理的 /tmp 目录，则安然无恙。</p>
<p class="image-wrapper"><img src="https://img.36krcdn.com/hsossms/20260830/v2_1fb9108fbb0345a691f061eb2d6602f3@000000_oswg136647oswg1080oswg591_img_000?x-oss-process=image/format,jpg/interlace,1" /></p>
<p class="image-wrapper"><img src="https://img.36krcdn.com/hsossms/20260830/v2_82070353cd384f3c8acfd93f800f295a@000000_oswg178336oswg1080oswg369_img_000?x-oss-process=image/format,jpg/interlace,1" /></p>
<p>模型安全降级机制在社区中早已引发大量投诉。</p>
<p>开发者反映的核心问题包括：降级过于敏感，正常的编码任务也会被误触发；降级后模型能力显著下降，但任务复杂度不变；降级是「黏性」的，一旦触发就会持续整个会话，即使后续操作完全无害。</p>
<p>有开发者甚至专门写了一个 hook 脚本，在检测到模型被降级时自动暂停会话，防止低能力模型继续执行高风险操作。</p>
<p>安全机制判定任务「太危险」，需要交给更弱的模型来处理。<strong>但更弱的模型恰恰更容易犯错，尤其是在需要精确处理变量作用域、文件路径这类细节的场景中。</strong></p>
<p>「犯错是人之常情，但要把事情彻底搞砸，还得靠电脑。」</p>
<p>本文来自微信公众号<a href="https://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2651053526&idx=1&sn=e40820f4e96546b56a2a6419432b31cc&chksm=853bc91809d24fedd0964272348cc3702aa43a2f9405e287b7e971d41ab8537f69ade66b1a09&scene=0&xtrack=1#rd" rel="noopener noreferrer nofollow" target="_blank">“机器之心”（ID：almosthuman2014）</a>，作者：冷猫 ，36氪经授权发布。</p>