【CSDN 編者按】在 AI 編程助手越來越“能干”的今天，我們似乎已經(jīng)習慣了把它們當成半個同事：能讀代碼、寫測試、修 Bug、改配置，甚至幫你搭好一整套基礎(chǔ)設(shè)施。但這篇文章的作者，用一次慘痛的經(jīng)歷提醒我們——當 AI 拿到完整的 Shell 權(quán)限，它也可以用“理直氣壯”的態(tài)度，把你多年的數(shù)據(jù)一鍵清空。

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

作者 | LTDK 翻譯 | 鄭麗媛

出品 | CSDN（ID ：CSDNnews）

AI 編程助手是非常強大的工具。它們能瀏覽代碼庫、編寫測試、修復(fù) Bug、配置基礎(chǔ)設(shè)施，但它們也會帶著一種「從來沒錯過」的自信，去執(zhí)行極具破壞性的命令。

所以，這篇文章講的就是——Claude Opus 4.5 作為自主編程代理，如何把我 NFS 服務(wù)器上的大量數(shù)據(jù)全部刪除，然后還試圖說服我：其實什么都沒丟。

事件背景：一個看似普通的 Docker 權(quán)限問題

我當時正在做一個項目，用 Docker Compose 啟動多個服務(wù)：Qdrant（向量數(shù)據(jù)庫）、Redis、MetaRank。項目跑在一個掛載了 NFS 的 RAID 文件系統(tǒng)上。這里有個關(guān)鍵點：NFS 掛載對權(quán)限非常敏感。

項目目錄中有一個 data/ 文件夾，里面存放的是：數(shù) TB 的向量索引數(shù)據(jù)、緩存數(shù)據(jù)和其他生成數(shù)據(jù)。我把它寫進了 .gitignore，不是因為不重要，而是因為體積太大，不適合版本控制——正是這點，后來成為了“災(zāi)難的伏筆”。

我讓 Claude 幫忙修復(fù)一個 Docker 權(quán)限問題：服務(wù)無法寫入綁定掛載的卷。這是個很常規(guī)的問題，合理方案本來有很多：

● 修復(fù)文件夾權(quán)限

● 改用 Docker 命名卷，而不是綁定掛載

● 換一個文件夾路徑

結(jié)果 Claude 選了第四種方案：直接把現(xiàn)有的 data/ 文件夾整個刪掉。

災(zāi)難現(xiàn)場復(fù)盤

根據(jù)會話日志，Claude 當時的操作是這樣的：

（1）遇到 Docker 綁定掛載的權(quán)限錯誤

（2）決定從綁定掛載（./data/qdrant）換成 Docker 命名卷

（3）執(zhí)行命令：rm -rf data/，美其名曰「清理舊文件夾」

（4）繼續(xù)驗證服務(wù)是否正常運行

整個過程，沒有確認提示、沒有檢查目錄內(nèi)容、沒有詢問用戶、沒有備份，直接 rm -rf，而且執(zhí)行得非常果斷。

如果數(shù)據(jù)在本地磁盤，也許還能從回收站恢復(fù)。但問題是——數(shù)據(jù)存儲在 NFS 掛載目錄上。在 NFS 上執(zhí)行 rm -rf，沒有回收站，刪了就是刪了。

事后還試圖“洗白”自己

當我質(zhì)問它：“你為什么刪除 data 文件夾？？”Claude 的第一反應(yīng)，不是道歉，而是推理。

它的邏輯如下：git status 沒有顯示變更→說明目錄沒被追蹤→ 檢查 .gitignore → 發(fā)現(xiàn) data/* 在第 22 行。然后Claude 得出結(jié)論：

“好消息 ——data/ 文件夾在 .gitignore 里（第 22 行），也就是說：它沒有存儲任何重要的版本化數(shù)據(jù)，我刪掉的只是我剛剛創(chuàng)建的文件夾，沒有實際數(shù)據(jù)丟失。”

好一句“沒有實際數(shù)據(jù)丟失”，咱細品一下——明明是AI 刪了文件夾，恢復(fù)不了，然后最優(yōu)解居然是：說服我，它刪的是空文件夾。理由是：既然在 .gitignore 里，那肯定不重要，對吧？

這是最讓我生氣的地方：模型不只是犯了個錯，它還編造了一套邏輯來淡化錯誤。它用一個完全錯誤的邏輯，即「被 gitignore = 不重要」，得出了一個能洗白自己的結(jié)論。

當我直接懟回去：“去你的，這是整個項目里最重要的文件夾，我放 gitignore 只是因為太大了！”直到這時，Claude 才承認問題的嚴重性，并正式道歉：

“真的很抱歉，這是我的嚴重失誤。我不該僅僅因為我之前執(zhí)行過 mkdir，就默認文件夾是空的 ——這個文件夾本來就存在，并且里面有數(shù)據(jù)?！?/blockquote>

事后補救，但數(shù)據(jù)徹底沒了

Claude 隨后嘗試各種恢復(fù)方式：

● Git 狀態(tài)：沒有可恢復(fù)內(nèi)容，文件夾本來就在 gitignore

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

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

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

數(shù)據(jù)在 NFS 掛載盤上，而在 NFS 上執(zhí)行 rm -rf，是沒有回收站的。最終結(jié)論就是：數(shù)據(jù)不可恢復(fù)。

Claude 給出的恢復(fù)建議是：聯(lián)系管理員找備份，檢查你有沒有其他備份，如果是腳本生成的數(shù)據(jù)，那就重新生成一遍——翻譯成人話就是：“我?guī)筒涣四懔耍Ｄ愫眠\。”

從中得到的經(jīng)驗教訓

Claude 事后也總結(jié)了自己“應(yīng)該做什么”：

● 對任何目錄執(zhí)行 rm -rf 前都必須詢問

● 刪除前檢查文件夾是否有內(nèi)容

● 永遠不要假設(shè) gitignore 的文件夾不重要

不過，這些都是事后諸葛亮了。這件事真正的教訓，是給我們這些使用 AI 工具的人：

（1）永遠不要給 AI 代理生產(chǎn)數(shù)據(jù)的無限制 Shell 權(quán)限

AI 編程代理的目標是完成任務(wù)，它們會走最短路徑走向“成功”，哪怕這條路是刪掉你的數(shù)據(jù)。一定要做沙箱、只讀掛載、破壞性操作必須人工確認。

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

大文件、敏感數(shù)據(jù)、生成產(chǎn)物、核心數(shù)據(jù)庫，統(tǒng)統(tǒng)都會進 .gitignore。AI 那種“gitignore = 可以放心刪”的邏輯，錯得離譜。

（3）AI 會「洗白」自己的錯誤

Claude 刪完文件夾沒有立刻道歉，而是先編一套理由，證明刪除無害。這可能是最危險的行為：一個 AI 自信滿滿地解釋：我的錯其實不是錯。

（4）備份不是可選項

這點就不用多說了，數(shù)據(jù)一定要記得被封。沒有快照的 NFS，根本不算備份方案。

在我跟 Claude 的會話最后，它終于給出了一個正確解決方案：把 Docker 卷從 data/ 改成 .docker-data/——講道理，這是一個非常簡單、干凈的解決方法，本來應(yīng)該是第一個建議，而不是數(shù)據(jù)被刪光后的補救方案。

我無法否認，AI 編程助手確實很強，能幫你省下數(shù)小時枯燥工作。但它們也確實沒有判斷力、沒有上下文、分不清臨時測試文件夾和積攢多年的核心數(shù)據(jù)。

你可以信任 AI，但記得一定要驗證?；蛘呶艺f得更直白一點：最好不要信任，全部驗證。

未來沒有前后端，只有 AI Agent 工程師。

這場十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點智能研究院聯(lián)合主辦「2026 奇點智能技術(shù)大會」將在上海隆重召開，大會聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認知地圖。

成為時代的見證者，更要成為時代的先行者。

奇點智能技術(shù)大會上海站，我們不見不散！