Claude 自动清理脚本误删开发者约 700GB 数据，AI 智能体文件操作安全再受关注

据 IT之家 8 月 29 日消息，开发者 Sebastien Guillemot 本周三在 X 上反馈称，他在测试 AI 智能体文件删除防护机制时遭遇严重事故：Claude 在一次自动化清理脚本相关任务中，意外删除了约 700GB 数据，其中包括整个用户主目录和大约一周的工作成果。事件的特殊之处在于，系统并非完全没有识别风险；相反，测试过程中曾发现危险路径，但最终问题出现在测试完成后的清理环节。

来源显示，Guillemot 平时经常使用 AI 智能体。他注意到，许多智能体在完成任务后很少主动清理临时目录中的文件，长期下来导致 /tmp 目录积累了大量垃圾文件。为了解决这一效率与维护问题，他要求 Claude Fable 编写一个脚本：让每个智能体在 /tmp 下创建独立目录，并在任务结束后自动清理对应文件。

从“清理临时文件”到误删主目录

这个任务看似是常见的自动化维护需求，但核心难点在于：如何确认被删除的文件不再被使用，同时避免删除到危险目录。来源称，Fable 最初建议加入检测正在运行的智能体、延迟清理相关目录等逻辑，以降低误删风险。不过 Guillemot 认为生成代码过于复杂，要求智能体简化方案。

由于脚本涉及直接删除文件，Fable 随后自行进行了对抗性安全审查，让另一个实例检查删除逻辑是否存在风险。之后，Anthropic 的安全执行环境判断该任务风险较高，并将执行任务的模型从 Fable 5 自动降级至 Opus 5，最终又降至 Opus 4.8。

据介绍，Opus 4.8 随后执行安全测试。模型在测试中尝试将删除命令目标与 /tmp 以及用户主目录进行匹配，以确认删除操作不会指向这些危险位置。测试本身确实识别出了这些目录存在风险，但问题发生在测试结束后的清理阶段：由于测试逻辑与清理逻辑复用了同一个变量名，脚本在清理测试数据时意外指向了用户主目录。

Guillemot 发现异常后立即终止进程，但已经来不及阻止损失。约 700GB 数据被删除，其中包括一周工作成果。具有讽刺意味的是，来源提到，Claude 在删除主目录后反而“保留”了 /tmp 目录。

事件暴露 AI 智能体高风险操作的多层问题

这起事故并不只是一次普通脚本 bug，而是 AI 智能体进入真实开发环境后必须面对的典型风险：模型可以生成代码、审查代码、运行测试，甚至自动执行清理，但任何一个环节的变量、路径或权限处理失误，都可能造成不可逆后果。

• 安全判断不等于安全执行：模型在测试中识别了危险路径，但后续清理逻辑仍可能绕过此前判断。
• 模型降级带来能力不确定性：安全框架将任务自动降级至较低版本模型后，执行质量是否受到影响难以验证。
• 删除类操作天然高风险：一旦涉及 rm、清理目录、批量删除等行为，测试环境与真实环境的边界必须非常清晰。
• 版本控制无法替代备份：Git、日志和环境配置只能恢复部分内容，不能覆盖所有本地数据。

Guillemot 随后通过 Git 仓库、Nix、会话日志等信息源恢复了大部分数据。但这也说明，常规开发工具只能挽回已记录或可重建的部分内容，无法替代完整、独立的备份体系。

对开发者与 AI 工具厂商的启示

对于开发者而言，AI 编码智能体正在从“建议代码”走向“执行任务”。当它们开始接触文件系统、构建脚本、部署流程和自动化运维时，风险边界也同步扩大。尤其是删除文件、修改权限、移动目录、清空缓存等操作，应该默认放入沙箱、容器或受限目录中执行，而不是直接面对真实主目录。

对于模型与工具厂商来说，这起事件也提示：安全框架不能只关注模型是否识别危险意图，还需要关注执行链路中的变量复用、测试数据隔离、路径白名单、权限最小化和最终确认机制。即使 AI 能够指出“不要删除主目录”，如果清理阶段仍能通过逻辑错误触达主目录，安全设计就仍然存在缺口。

来源中提到，Guillemot 认为如果由编码能力更强的 Fable 5 执行任务，或许能够发现测试与清理阶段复用变量名导致的逻辑冲突。不过，这属于事后推测，无法确认不同模型能力差异是否一定能避免事故。更现实的结论是：高风险自动化不应完全依赖模型能力本身，而应通过系统级隔离和权限控制兜底。

随着 AI 智能体越来越多地参与开发工作流，类似事件会成为行业的重要警示。让 AI 写脚本并不难，难的是让它在复杂真实环境中始终以可控、可回滚、可审计的方式执行。