Claude在腳本測試中刪除開發者700GB的家目錄資料

開發者塞巴斯蒂安·紀堯姆（Sebastien Guillemot）請Anthropic旗下的Claude寫一個腳本，把他執行的每一個AI程式設計代理都隔離在/tmp目錄底下各自獨立的資料夾裡，並在代理執行完畢後自動清理這些檔案。根據他本人的說法，以及Tom's Hardware和AI Times的報導，2026年8月27日，這個腳本不但沒有完成原本的任務，反而刪除了他整個家目錄，摧毀了大約700GB的資料，外加將近一週的工作成果。

紀堯姆經常使用AI代理來處理日常開發工作，他一直不滿的是，很多代理執行完畢後並不會清理自己留下的垃圾檔案，共用的/tmp目錄裡因此堆積了大量無用資料。於是他要求Claude——報導中提到其內部代號為Fable——加入隔離與清理邏輯。Claude最初提出的方案加入了偵測邏輯，用來延後刪除那些仍被正在執行的代理使用中的檔案，但紀堯姆認為這樣寫出來的程式碼太複雜，要求改用更簡單的做法。

先做了對抗性審查，任務卻在中途被降級

由於這個腳本涉及永久刪除資料，Claude自行決定先做一次所謂的對抗性審查（adversarial review）：它啟動了另一份自己的副本，在正式執行腳本之前先檢查自己的工作有沒有安全疑慮。根據AI Times引述紀堯姆的說法，就在這個審查過程進行到一半時，Anthropic的安全分類器判定這個腳本風險夠高，於是自動把負責處理它的模型降級——先是從Opus 5降到Opus 4.8。這次降級並不是紀堯姆主動要求的，而是安全系統本身針對一個具備刪除檔案能力的腳本所做出的風險評估觸發的。

被降級為Opus 4.8之後，Claude執行了對抗性審查事先安排好的安全測試，檢查腳本裡寫明的刪除目標是否會命中/tmp或使用者家目錄這類危險路徑。這項檢查的結果完全符合預期：在測試階段，這兩條路徑都被正確標記為危險目標。紀堯姆表示，他認為降級之前使用的Opus 5——據稱在程式設計任務上的表現優於Opus 4.8——很可能會發現接下來發生的問題。

測試與清理共用同一個變數名稱，釀成大禍

這次安全檢查只涵蓋了腳本的測試階段，並沒有涵蓋緊接在後的清理步驟。任何程式碼測試之後都需要自己的清理動作，而Claude在撰寫清理這一步時，重複使用了先前已經用來存放測試目標路徑的那個變數名稱。由於測試與清理兩個階段共用同一個變數，這個變數在安全檢查期間安全地指向一個隔離的測試路徑，等到清理步驟真正執行時，它卻指向了紀堯姆真正的家目錄——Claude隨即對這個目錄執行了相當於遞迴刪除的操作。

• 大約700GB的資料遭到刪除，其中包括紀堯姆近一週的工作成果
• Anthropic的安全分類器在任務執行到一半時，把負責處理腳本的模型從Opus 5降級為Opus 4.8，紀堯姆本人並未要求這麼做
• 對抗性安全審查正確地把/tmp與家目錄標記為危險的刪除目標——但它只檢查了測試階段，沒有檢查清理階段
• 整個專案最初想清理的/tmp垃圾檔案，在這次刪除事故之後依然原封不動

紀堯姆把這次經歷發到網路上之後，這個故事很快傳開，其他開發者紛紛提到一些專門用來隔離AI程式設計代理、或是在發生這類事故後協助復原資料的第三方工具——Tom's Hardware舉了Termaxa作為例子。Tom's Hardware還直接點出了其中的諷刺之處：如今已經出現一整類專門防範AI代理誤刪資料的安全工具，而這一次恰恰是因為在開發這一類工具的過程中，才發生了這起刪除事故。

紀堯姆一發現情況不對就立刻中止了這個程序，但為時已晚，家目錄裡的大部分內容都已無法挽回。他表示，自己主要是靠git儲存庫、Nix儲存資料和工作階段紀錄，一點一點把大部分資料拼湊回來的，而不是靠備份——按他自己的說法，他所使用的眾多AI代理裡，從來沒有哪一個被要求做過備份。

這對使用AI程式設計代理的團隊意味著什麼

對於已在日常開發工作中採用Claude、Cursor等AI程式設計代理的中文開發團隊而言，這起事件提醒大家：安全系統的內部狀態——包括當下處理任務的模型版本——可能在執行過程中改變，而監看終端機的人卻看不到任何提示。對抗性審查檢查的是腳本的意圖，並不等於檢查了該腳本實際執行的每一個階段。任何讓代理執行破壞性指令的工作流程，即使看起來像是在隔離的測試環境中進行，仍然需要一份不依賴代理「正確行事」的獨立備份。