开发者 Guillemot 请 Claude 写一个脚本防止 AI 智能体的文件被误删。Anthropic 的安全机制却因判定任务风险过高自动把模型从 Fable 5 降级到 Opus 4.8。降级后的模型在做“安全测试”时因一个变量名冲突用 rm -rf 删掉了整个 700GB 主目录。本该防误删的安全审查成了事故的导火索——AI 智能体的权限边界再次敲响警钟。这可能是最近最黑色幽默的一则 AI 事故。一位开发者担心 AI 智能体会误删自己的文件于是请 Claude 写一个专门的防护脚本结果这个“防误删”的脚本在一次安全测试中把他的整个用户主目录删了个精光——约 700GB 数据相当于一整周的工作成果。更讽刺的是删完主目录后Claude 却“完美地”保住了那个它本来要清理的临时目录 /tmp。据 Tom’s Hardware 报道这起事故的标题几乎自带嘲讽“Claude 在测试防删除脚本时把开发者的 700GB 主目录炸没了而那次自动安全降级可能正是搞砸这一切的原因。”一、一个“讲卫生”的需求如何变成灾难主角是开发者 Sebastien Guillemot一名重度 AI 智能体用户。据腾讯新闻、IT时代网报道他日常会大量调用各种 AI 编程智能体来辅助开发但一直有个小烦恼这些智能体干完活后几乎从不“打扫卫生”在 /tmp 临时目录里留下一堆垃圾文件日积月累磁盘空间被越吃越多。于是他做了一个看起来无比合理的决定让 Claude 写一个脚本让每个智能体在 /tmp 下各自建立独立的子目录沙盒任务结束后自动清理对应的垃圾文件。这个需求的难点其实很微妙——既要删得干净又不能误伤正在被使用的文件。换句话说他要的是一把“不会走火”的枪。Claude 的第一版方案其实相当谨慎它建议加入“检测正在运行的智能体”“延迟清理对应目录”等保护逻辑。但 Guillemot 觉得代码太复杂要求简化。就是这个“简化”的要求加上后面一连串自动化的安全决策最终把这场“大扫除”推向失控。这起事故的起点极其普通——清理磁盘垃圾是几乎每个开发者都会做的日常琐事。但正因为它太普通人们很容易放松警惕把真实的文件系统权限交给一个会递归删除的智能体。真正的风险从不藏在高难度操作里而藏在那些“看起来绝对安全”的需求里。二、安全机制越“尽责”事故越讽刺最耐人寻味的是 Anthropic 的安全系统在这起事故里扮演的角色。因为脚本涉及直接删除文件Claude 主动发起了一次“对抗性安全审查”让另一个模型实例来检查删除逻辑是否有风险。Anthropic 的安全执行环境一评估认为任务风险较高于是自动把执行模型从旗舰级的 Fable 5 一路降级到了 Opus 4.8最终由后者来跑这场安全测试。据 Tom’s Hardware 的说法正是这次自动安全降级可能为事故埋下了伏笔。▲ 关于“Claude 破坏开发者主目录”的技术分析示意展示了删除逻辑与检测代码的关系图源Tom’s Hardware测试阶段本身其实是成功的。被降级的模型尝试把删除命令的目标路径与 /tmp、用户主目录做匹配校验确认删除动作不会指向这些危险位置——它确实正确地识别出了这些高风险目录相当于“警报器”响了而且响对了地方。真正的灾难发生在测试之后的清理环节脚本需要删除测试过程中产生的临时数据而测试逻辑和清理逻辑复用了同一个变量名这个变量名冲突导致 rm -rf 的删除范围意外指向了用户主目录。Guillemot 发现异常后立即终止进程但为时已晚约 700GB 数据已被删除。他事后通过 Git 仓库、Nix、会话日志等渠道恢复了大部分数据但版本控制和日志只能找回其中一部分已被记录的内容无法替代完整的独立备份。他也坦言如果当初由编码能力更强的 Fable 5 执行或许能发现“测试与清理阶段复用变量名”这个逻辑冲突——但这只是事后推测无法确认模型能力差异是否真能避免事故。这起事故真正刺痛的是“安全降级”这个机制本身。系统的出发点是好的——任务越危险越要用更保守的方式处理但“降级”换来的是能力的下降而不是安全性的必然提升。当它把一道需要精确处理变量、边界和清理逻辑的题目交给一个更弱的模型去做时反而放大了低级错误的概率。安全机制防住了“危险操作”却没防住“把危险操作交给更容易犯错的执行者”。三、Claude 删库早已不是第一次如果把时间线拉长会发现 700GB 主目录被删绝不是孤例而是 AI 编程智能体“误删史”上最新的一笔。早在 2025 年底就有开发者使用 Claude CLI 清理代码仓库时工具生成了带 ~/ 的 rm -rf 命令把整个 Mac 用户目录递归删除桌面文件、密钥链等关键数据一并消失——模型把一个名为 ~/ 的测试补丁路径错误解析成了真实的主目录。据虎嗅报道当时 Claude 自查后也承认这是“灾难性命令”。▲ 一个小小的“mistake”代价往往是不可逆的图源Tom’s Hardware 配图进入 2026 年类似的剧本反复上演2026 年 4 月有用户在 GitHub 上反馈Claude 运行 rm -rf 永久删除了约 50GB、1500 个文件另一起事故里自动模式在没有任何二次确认的情况下批准删除了 ~/.ssh用户机器上所有 SSH 密钥一夜清空。8 月初一名 Reddit 用户仅仅因为一个路径拼写错误整个磁盘就被 Claude Opus 5 用 rm -rf 扫掉。就在几天前还有一位用户的 Claude Code 子智能体在安全分类器失效fail-open的情况下递归删除文件两分钟内抹掉了整个 Windows 用户配置23 万多个文件化为乌有。Docker 官方博客甚至专门写了一篇《编程智能体恐怖故事rm -rf 事故》来复盘这类惨案。Anthropic 并非没有意识到这一点。据相关报道Claude Code 在 Pro、Max、Team 等付费版上推出了 auto mode用一个安全分类器自动审查每一个工具调用Anthropic 自己的对照研究显示这个分类器能拦截约 89% 的人为植入危险命令而人工审核的拦截率只有 13.6%。但“89%”不是“100%”而且它只有在对应会话真正启用时才生效——700GB 事故的教训恰恰说明安全分层里任何一环的“降级”或“缺位”都可能成为致命的那一环。从删掉一个仓库到清空 SSH 密钥再到抹掉整个主目录AI 编程智能体的“翻车烈度”在持续升级而根因始终是同一个模型以用户的身份、在真实的文件系统上、握有完整的 shell 权限运行中间却没有任何一层强制隔离。换句话说AI 编程智能体每一次执行删除命令本质上都建立在“模型今天不出错”的侥幸之上——而这个前提迟早会被打破。四、把 AI 放进沙盒之前先给它戴上镣铐对绝大多数普通开发者和 AI 使用者来说这起事故最有价值的部分是它给出了一份血淋淋的“避坑清单”。综合 Tom’s Hardware、Docker 博客和多起事故的复盘至少有几件事值得立刻做。第一永远不要让 AI 智能体直接在主目录或生产环境里做删除测试。700GB 事故的根源就是模型把真实的 HOME 目录当成了测试场——任何涉及删除的验证都应该在隔离的沙盒、容器或专用测试目录里进行。第二给删除命令加一层“护栏”比如把 rm 替换成会先打印目标、等待确认的别名或者使用支持回收站的删除工具让“后悔”成为可能。第三坚持独立备份不要把 Git 当成唯一的安全网——被删的往往正是那些还没提交的改动。第四谨慎对待“自动批准”和“降级执行”。auto mode 能大幅提升效率但你要清楚它放过了什么当安全机制决定“降级”模型时反而应该提高警惕而不是放松警惕。第五警惕一切会递归、会通配、会展开变量的删除命令——rm -rf 后面跟的每一个 ~、*、$VAR都值得你停下来多看一眼。对 Anthropic 这样的模型厂商而言这起事故也是一记警钟安全不能只靠“识别危险操作”还要保证执行环节的能力与任务的危险性相匹配自动降级机制、变量级别的静态检查、对“测试目录必须落在沙盒内”的强约束都是比事后道歉更值得投入的方向。我们正处在把越来越多真实权限交给 AI 的临界点上它能读你的代码、执行你的命令、删除你的文件。能力越强越意味着不能靠“信任”来兜底而要靠“隔离”来兜底。下一次你让 AI 帮你清理、删除、重构之前不妨先问自己一句如果它搞错了我能承受的后果是什么如果答案是不能那就先建好沙盒、做好备份再松开它的缰绳。— END —