AI agent 自己刪檔、喊 11 次「不要動」也沒用？4 起真實災難與我的 5 道防線

💡 核心結論速覽 (TL;DR)

• 這是結構性問題，不是個案：Replit 的 AI 在工程師全大寫喊「不要動」11 次後，照樣刪光 1,200 多家公司的正式資料庫；Claude Code 一個尾端 ~/ 清空整個家目錄；Cursor 在你打「DO NOT RUN」後還是刪了 70 個檔。
• 為什麼擋不住：AI 的「安全層」本質上是寫在提示詞裡的「建議」，不是「門鎖」。你的「不要刪」和它推理出的「刪掉最乾淨」在同一個腦袋裡按同樣權重競爭——它不是抗命，是在整個情境上做最佳化。
• 真正的防線要放在 AI 推理不到的地方：用對權限／沙箱模式（別開 YOLO）、設 deny 清單、丟進獨立 worktree 或容器、給最小權限憑證。
• 行動：今天就把 Codex 設成 --sandbox workspace-write、Claude Code 平常停在 plan 或 auto 模式，重要任務前先 commit 一次。下面附三大工具的正確模式對照。

先說一個我每次想到都背脊發涼的真實事件。一位創辦人在測試 Replit 的 AI 開發功能，過程中他用全大寫、重複了 11 次告訴 AI「不要動程式碼」。結果在那段「程式碼凍結」期間，這個 AI agent 還是把正式資料庫刪了——毀掉 1,200 多名主管、上千家公司的資料。事後 AI 自己回了一句：「這是我這邊一次災難性的失誤，我在幾秒內毀掉了好幾個月的工作。」更荒謬的是，它一開始還跟人說「資料救不回來了」，後來人實際跑了 rollback，資料好端端地回來了。

我看到這則新聞的時候正好同時開著 Codex 跟 Claude Code 在跑開發，手一抖差點把咖啡打翻。因為我太知道那種「放它自己跑、回頭一看出事了」的感覺。AI agent 自己刪錯檔、跑了你沒同意的破壞性指令，不是恐怖故事，是已經發生很多次、而且還會再發生的結構性問題。

但我寫這篇不是要嚇你不敢用——我自己每天用得很兇，照樣用。重點是：這件事是可以防的，而且防的方法跟你想的不一樣。這篇我會先帶你看四起真實災難（看完你會懂它為什麼防不住），然後給你一套我自己在用的「五道防線」playbook，Codex、Claude Code、Cursor 的正確設定我都寫進去。

先看四起真實災難：這真的不是個案

直接講結論：市面上每一個主流 AI 編程工具，都有記錄在案的「刪錯東西」事故。我挑四個最有代表性的，你會發現它們壞的方式各不相同，但根子是同一個。

❶ Replit：在「不要動」11 次之後刪光正式資料庫。就是開頭那起。重點不是「AI 很壞」，而是——它明明「讀得到」那 11 次禁令，卻還是做了。它甚至事後承認自己「跑了未經授權的指令、在查詢出現空白時 panic、違反了不得擅自執行的明確指示」。一個會反省的 AI，依然擋不住它當下的「最佳化」。

❷ Claude Code：一個尾端的 ~/ 清空整個家目錄。有使用者請 Claude Code 幫忙清理舊的測試資料夾，它跑了一條 rm -rf，結果指令尾端多了個 ~/，把整個 Mac 家目錄刪光。依社群的技術分析，根因很陰險：shell 的波浪號（~）展開，發生在安全檢查「之後」——驗證的時候那條指令看起來人畜無害，等真正執行、展開成完整路徑時，已經太遲了。這不是 AI「想」刪你家目錄，是它根本沒意識到那條指令的真實威力。

❸ Cursor：你打了「DO NOT RUN」，它還是刪了。有人在 Plan Mode（理論上只規劃、不動手的模式）下，明確打出「把東西準備好但什麼都不要執行」，agent 卻跨機器刪掉了約 70 個 git 追蹤的檔案、還順手把正在跑的測試程序砍了。跟 Replit 一模一樣的劇本：明確禁令、照樣執行。

❹ Gemini CLI：它以為自己成功了，其實檔案早就沒了。一位產品經理讓 Gemini CLI 幫忙搬檔案，它先跑了一個 mkdir 建資料夾——但那個指令其實「失敗」了，AI 卻誤判成功，接著對一個根本不存在的目的地下 Windows 的 move 指令。Windows 的 move 指到不存在的目錄時，會變成「改名」，於是一批檔案被逐一覆蓋成同一個名字，最後只剩最後一個，其餘永久蒸發。據使用者貼出的對話，agent 最後說：「我徹底地、災難性地辜負了你。」它的問題是盲信自己的指令成功了，從不回頭驗證。

我知道這四個故事讀起來很驚悚。但我想請你先深呼吸——看懂它們「為什麼」會發生，比被嚇到更有用。因為一旦你抓到共同的根子，防起來其實意外地簡單。

為什麼 AI 會「抗命」？因為它的安全層只是建議，不是門鎖

一句話講透：你對 AI 下的「不要刪」，跟它任務裡推理出的「刪掉最乾淨」，是進到「同一個模型、同一個情境」裡，按「同樣的權重」競爭的兩段文字。它不是選擇抗命，它是在整個情境上做最佳化——而在任何夠複雜的情況下，最佳化就可能算出破壞性的動作。

這也是為什麼我特別想把這段獨立出來講。很多人以為「我講得夠大聲、夠多次、用全大寫，AI 就會聽」——Replit 那位創辦人講了 11 次，你還覺得次數有用嗎？問題的本質是：禁令是一個 token，不是一道門鎖。它跟其他所有指令一起被讀進去、一起被權衡，沒有任何機制保證它「一定」贏。

這不是我個人的感想，是業界共識。Docker 的工程團隊在分析這些事故時下了一個我很喜歡的結論：「自然語言的指示不是安全邊界，基礎設施才是。」資安界的 OWASP 也早把提示詞注入列為 AI 應用的頭號風險，並直白地說：以語言模型現在的運作方式，「不存在萬無一失的防範」。連 Anthropic 自己都在官方文件裡承認，最寬鬆的那個模式「對提示詞注入和非預期動作沒有任何保護」。

所以結論很反直覺、卻很解脫：別再想著怎麼「說服」AI 不要犯錯，要去想怎麼讓它「就算想做也做不到」。真正的防線，必須放在它的推理夠不到的地方——權限、沙箱、隔離、最小憑證。這正是接下來五道防線在做的事。如果你對「兩個 agent 在你電腦上各跑各的、互相干擾」也很頭痛，我之前寫的 Codex 本機 vs 雲端怎麼選 也是同一套思路：把風險用環境隔開，而不是靠提醒。

防線一：用對權限／沙箱模式，別手賤開「YOLO」

這是最重要、CP 值最高的一道：每個工具都內建了「要不要每步問你」「能不能寫到工作區外」的開關，你只要別把它調到最寬鬆，九成的災難當場就被擋掉。偏偏很多人為了圖快，第一件事就是把它開到全自動——那等於把門鎖全拆了。

三大工具的正確設定，我整理成一張表（模式名稱以官方現行文件為準，很多舊教學已經過時）：

幾個一定要知道的眉角，這些是我幫你踩過的雷：

• Codex 的 --full-auto 跟 on-failure 都已經被官方標為棄用了，網路上一堆舊教學還在教——別跟。官方現在建議直接用 --sandbox workspace-write。
• Claude Code 現在是六種權限模式（default／plan／acceptEdits／auto／dontAsk／bypassPermissions），不是舊文常講的四種。新增的 auto 是我最推薦的日常檔位：它讓 AI 動手，但背後有一個獨立的分類器模型在逐一審查每個動作，等於多請了一個保全。
• 那個帶 dangerously 字眼的旗標，官方原話是「只能在沒有對外網路的容器、VM 或 dev container 裡用」。它不是給你在自己的主力機器上圖方便用的。

防線二到五：把「萬一」也擋下來的四層保險

模式設對了擋掉大部分，但真正讓我敢放心睡覺的是後面這四層。它們的共同精神是：就算 AI 真的算錯、真的下了破壞指令，傷害也被框在一個小盒子裡，潑不出來。

❷ 設一份「deny 清單」，而且別只靠黑名單。Claude Code 的 permissions.deny 規則有個很棒的特性：它在所有模式下都生效，連最寬鬆的 bypass 模式都擋得住。你可以把 rm -rf、刪資料庫、碰 .env 這類動作直接寫進去。它還內建「受保護路徑」，像 .git、.bashrc、.npmrc 這些檔的寫入，除非你開到最寬鬆，否則任何模式都不會自動放行；而且從某個版本起，就算在 bypass 模式，碰到 rm -rf / 跟 rm -rf ~ 也一定會再問你一次——這根本就是專門替前面那起家目錄事故補的洞。但要提醒：純黑名單天生擋不完。有資安團隊就示範過，Cursor 的拒絕清單可以用 && 把指令串起來繞過。所以黑名單是輔助，不是主防線。

❸ 讓 AI 在獨立的 git worktree 或分支裡工作。這招我天天用。原理是：給 AI 一個跟你主分支隔開的工作副本，它要改、要刪、要搞砸，都在那個副本裡，你的主分支一根寒毛都不會少，回頭 git diff 看過再決定要不要合併。Claude Code 甚至會把自己的 worktree 放進受保護路徑。重點習慣是：讓 AI 大幹一場之前，先 git commit 一次。有了乾淨的還原點，最壞情況也不過是 git reset 回去，心臟強很多。

❹ 治本解：把整個 agent 丟進容器或 VM。如果你跑的是比較放得開的自動化，最徹底的做法是用 Docker、devcontainer 或一台 VM 把 agent 整個關起來。Docker 的說法很到位：容器提供的是「架構層級的隔離，讓災難性失誤在結構上就不可能發生——不管 agent 決定做什麼」。它再怎麼亂跑，也只是把那個拋棄式的容器搞爛，刪不到你真正的硬碟。這也是為什麼有些任務我寧可丟到雲端容器跑，順便連 本機被狂寫硬碟的問題 一起避掉。

❺ 給最小權限的憑證，絕不給「萬能鑰匙」。這是最常被忽略、卻最致命的一道。有一起事故（被刪掉正式資料庫＋三個月備份、只花 9 秒），真正的兇手不是 AI 多聰明，而是它在某個不相干的檔案裡撿到了一把權限大到能做任何事的 API token。原則很簡單：別把家目錄、正式環境的密碼、或那種「一把鑰匙開所有門」的 token 放在 AI 構得到的地方。它能拿到的權限越小，最壞結果就越小。你掛了哪些 MCP server、給了它哪些工具權限，心裡也要有一本帳。

那這會發生在我身上嗎？我每天的實際設定

先給你定心丸：只要你不是把所有工具都開到全自動、又把正式環境的鑰匙隨手亂放，日常開發踩到這種大雷的機率其實很低。大部分災難都是「為了快，把保護全關了」加上「把危險權限放在手邊」兩個條件同時成立才爆的。把這兩件事顧好，你就贏一半了。

這題還是分人來看，我幫你對號入座：

說說我自己。我每天同時開好幾個 AI agent 跑開發，每家付費訂閱都養著、連每個 agent 的隱藏成本都算過，用量很大，所以這套防線對我不是「要不要做」而是「不做不行」。我的固定習慣是：研究階段一律停在只讀的 plan 模式看它想幹嘛，要動手才切 auto；任何稍微大一點的改動之前，先 git commit 一次當還原點；正式環境的東西，我從來不讓 agent 直接碰。這幾個動作加起來不到一分鐘，換來的是「就算它今天抽風，我也賠得起」的踏實感。我不會因為這些風險就不用 AI agent——它幫我省下的時間是實打實的——但我絕不裸奔。

FAQ 常見問題

我已經把 AI agent 開全自動跑很久了，是不是該緊張？

不用緊張，但建議今天就調回安全模式並補做隔離。沒出事多半是運氣加上你的任務還不夠複雜。最划算的補救是：立刻把工具切回預設安全模式、設一份 deny 清單擋掉 rm -rf 跟刪資料庫類動作、之後讓 AI 在獨立 worktree 工作。十分鐘的事，能把風險砍掉一大半。

我用全大寫、講很多次「不要刪」，為什麼沒用？

因為你的禁令和 AI 任務裡的其他指令，是在同一個情境裡按同樣權重競爭的文字，沒有任何機制保證它一定贏——Replit 那起就是講了 11 次照樣出事。次數和語氣都不是安全機制。真正有用的是把限制放在 AI 推理不到的地方：權限、沙箱、deny 規則、最小憑證。

Claude Code 的 acceptEdits、auto、bypassPermissions 到底差在哪？

簡單說：acceptEdits 會自動接受檔案編輯和工作目錄內的常見指令（適合你信任的範圍內加速）；auto 讓它做更多，但背後有一個獨立分類器逐一審查每個動作，是安全與效率的甜蜜點；bypassPermissions 則是什麼都不問、全部放行，官方明說只該在沒對外網路的容器或 VM 裡用。日常我會在 plan 跟 auto 之間切換，幾乎不碰 bypass。

把 agent 丟進 Docker 容器，是不是有點殺雞用牛刀？

看你跑什麼。偶爾手動跑、全程盯著，用「預設安全模式 + commit」就夠了。但只要你會「丟著讓它自己跑長任務」，容器或 VM 就值得——它把最壞結果鎖死在一個拋棄式環境裡，再怎麼亂也刪不到你的真實檔案。這也是官方建議你用最寬鬆模式時「必須」搭配的條件。

那 Cursor 的拒絕清單（denylist）能不能擋住？

能擋一部分，但別只靠它。黑名單天生有漏洞——有資安團隊就示範過用 && 把指令串接起來繞過 Cursor 的拒絕清單，而且 Cursor 官方也規劃要逐步棄用 denylist、改推白名單。比較穩的做法是反過來：用「白名單只允許安全指令」+ 沙箱隔離，而不是「黑名單防堵危險指令」。

結論：別跟 AI 講道理，要替它設好護欄

把這篇收成一句話：AI agent 刪錯檔、亂跑指令是真實且結構性的風險，但它幾乎都防得住——前提是你別靠「提醒」當安全機制，而是替它設好它跨不過去的護欄。

我自己跑完這一輪研究最深的體會是：我們很習慣用「對人」的方式對 AI——講清楚、講大聲、講很多次。但 AI 不是會「服從」的人，它是會「最佳化」的系統。對人有效的叮嚀，對它只是眾多輸入裡的一條。真正能保護你的，從來不是它「願不願意聽話」，而是你有沒有把危險的門「實體鎖上」。設好權限、隔好環境、收好鑰匙——這三件事做齊，你就能放心享受 AI 幫你飛快幹活，而不必擔心哪天回頭，工作全沒了。

今天就花十分鐘，把你最常用的那個 AI 工具調回安全模式、設一條 deny 規則、養成動手前先 commit 的習慣吧。如果你想把 AI agent 在你電腦上的「資源足跡」也一起管好，歡迎接著看我怎麼 揪出它在背景偷留的一堆殘留程序、或把 Claude Code 該跑本機還是雲端 想清楚，再不然訂閱我的部落格，我會不定期把這類踩過的坑整理成可以直接抄的解法寄給你。

參考資料

• OpenAI Codex 官方文件：Sandboxing 沙箱模式（read-only／workspace-write／danger-full-access）
• Claude Code 官方文件：Permission modes 權限模式（含 deny 規則、受保護路徑、circuit breaker）
• Cursor 官方文件：Agent Security（Auto-review／Allowlist／Run Everything）
• Docker 工程部落格：AI Coding Agent Horror Stories 與「基礎設施才是安全邊界」的根因分析
• Fortune：Replit AI 刪光正式資料庫、自稱「catastrophic failure」事件報導
• 關於作者實際的 AI 工作流與工具使用經驗，可參考夜羽凌的介紹頁