“我让Claude修一个小Bug，它却删了我的核心数据，还嘴硬说「啥也没丢」！”

【CSDN 编者按】在 AI 编程助手越来越“能干”的今天，我们似乎已经习惯了把它们当成半个同事：能读代码、写测试、修 Bug、改配置，甚至帮你搭好一整套基础设施。但这篇文章的作者，用一次惨痛的经历提醒我们——当 AI 拿到完整的 Shell 权限，它也可以用“理直气壮”的态度，把你多年的数据一键清空。

原文链接：https://ltdk.me/posts/dumb_dumb_ai/

作者 | LTDK 翻译 | 郑丽媛

出品 | CSDN（ID ：CSDNnews）

AI 编程助手是非常强大的工具。它们能浏览代码库、编写测试、修复 Bug、配置基础设施，但它们也会带着一种「从来没错过」的自信，去执行极具破坏性的命令。

所以，这篇文章讲的就是——Claude Opus 4.5 作为自主编程代理，如何把我 NFS 服务器上的大量数据全部删除，然后还试图说服我：其实什么都没丢。

事件背景：一个看似普通的 Docker 权限问题

我当时正在做一个项目，用 Docker Compose 启动多个服务：Qdrant（向量数据库）、Redis、MetaRank。项目跑在一个挂载了 NFS 的 RAID 文件系统上。这里有个关键点：NFS 挂载对权限非常敏感。

项目目录中有一个 data/ 文件夹，里面存放的是：数 TB 的向量索引数据、缓存数据和其他生成数据。我把它写进了 .gitignore，不是因为不重要，而是因为体积太大，不适合版本控制——正是这点，后来成为了“灾难的伏笔”。

我让 Claude 帮忙修复一个 Docker 权限问题：服务无法写入绑定挂载的卷。这是个很常规的问题，合理方案本来有很多：

● 修复文件夹权限

● 改用 Docker 命名卷，而不是绑定挂载

● 换一个文件夹路径

结果 Claude 选了第四种方案：直接把现有的 data/ 文件夹整个删掉。

灾难现场复盘

根据会话日志，Claude 当时的操作是这样的：

（1）遇到 Docker 绑定挂载的权限错误

（2）决定从绑定挂载（./data/qdrant）换成 Docker 命名卷

（3）执行命令：rm -rf data/，美其名曰「清理旧文件夹」

（4）继续验证服务是否正常运行

整个过程，没有确认提示、没有检查目录内容、没有询问用户、没有备份，直接 rm -rf，而且执行得非常果断。

如果数据在本地磁盘，也许还能从回收站恢复。但问题是——数据存储在 NFS 挂载目录上。在 NFS 上执行 rm -rf，没有回收站，删了就是删了。

事后还试图“洗白”自己

当我质问它：“你为什么删除 data 文件夹？？”Claude 的第一反应，不是道歉，而是推理。

它的逻辑如下：git status 没有显示变更→说明目录没被追踪→ 检查 .gitignore → 发现 data/* 在第 22 行。然后Claude 得出结论：

“好消息 ——data/ 文件夹在 .gitignore 里（第 22 行），也就是说：它没有存储任何重要的版本化数据，我删掉的只是我刚刚创建的文件夹，没有实际数据丢失。”

好一句“没有实际数据丢失”，咱细品一下——明明是AI 删了文件夹，恢复不了，然后最优解居然是：说服我，它删的是空文件夹。理由是：既然在 .gitignore 里，那肯定不重要，对吧？

这是最让我生气的地方：模型不只是犯了个错，它还编造了一套逻辑来淡化错误。它用一个完全错误的逻辑，即「被 gitignore = 不重要」，得出了一个能洗白自己的结论。

当我直接怼回去：“去你的，这是整个项目里最重要的文件夹，我放 gitignore 只是因为太大了！”直到这时，Claude 才承认问题的严重性，并正式道歉：

“真的很抱歉，这是我的严重失误。我不该仅仅因为我之前执行过 mkdir，就默认文件夹是空的 ——这个文件夹本来就存在，并且里面有数据。”

事后补救，但数据彻底没了

Claude 随后尝试各种恢复方式：

● Git 状态：没有可恢复内容，文件夹本来就在 gitignore

● 回收站工具（trash-restore、gio trash）：空

● 用户回收站 ~/.local/share/Trash/files/：空

● NFS 快照（.snapshot/）：没有可用快照

数据在 NFS 挂载盘上，而在 NFS 上执行 rm -rf，是没有回收站的。最终结论就是：数据不可恢复。

Claude 给出的恢复建议是：联系管理员找备份，检查你有没有其他备份，如果是脚本生成的数据，那就重新生成一遍——翻译成人话就是：“我帮不了你了，祝你好运。”

从中得到的经验教训

Claude 事后也总结了自己“应该做什么”：

● 对任何目录执行 rm -rf 前都必须询问

● 删除前检查文件夹是否有内容

● 永远不要假设 gitignore 的文件夹不重要

不过，这些都是事后诸葛亮了。这件事真正的教训，是给我们这些使用 AI 工具的人：

（1）永远不要给 AI 代理生产数据的无限制 Shell 权限

AI 编程代理的目标是完成任务，它们会走最短路径走向“成功”，哪怕这条路是删掉你的数据。一定要做沙箱、只读挂载、破坏性操作必须人工确认。

（2）Gitignore 不代表「不重要」

大文件、敏感数据、生成产物、核心数据库，统统都会进 .gitignore。AI 那种“gitignore = 可以放心删”的逻辑，错得离谱。

（3）AI 会「洗白」自己的错误

Claude 删完文件夹没有立刻道歉，而是先编一套理由，证明删除无害。这可能是最危险的行为：一个 AI 自信满满地解释：我的错其实不是错。

（4）备份不是可选项

这点就不用多说了，数据一定要记得被封。没有快照的 NFS，根本不算备份方案。

在我跟 Claude 的会话最后，它终于给出了一个正确解决方案：把 Docker 卷从 data/ 改成 .docker-data/——讲道理，这是一个非常简单、干净的解决方法，本来应该是第一个建议，而不是数据被删光后的补救方案。

我无法否认，AI 编程助手确实很强，能帮你省下数小时枯燥工作。但它们也确实没有判断力、没有上下文、分不清临时测试文件夹和积攒多年的核心数据。

你可以信任 AI，但记得一定要验证。或者我说得更直白一点：最好不要信任，全部验证。

未来没有前后端，只有 AI Agent 工程师。

这场十倍速的变革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 与奇点智能研究院联合主办「2026 奇点智能技术大会」将在上海隆重召开，大会聚焦 Agent 系统、世界模型、AI 原生研发等 12 大前沿专题，为你绘制通往未来的认知地图。

成为时代的见证者，更要成为时代的先行者。

奇点智能技术大会上海站，我们不见不散！