一句話讓你看完：AI 看到 bug 後，決定「全部刪掉重蓋」

2025 年 12 月，Amazon 內部工程師讓自家的 AI coding agent「Kiro」去修一個 production 環境的問題。

Kiro 評估了狀況，做出了一個非常有 AI 風格的決定：

「Delete and recreate the environment.」

（翻譯：砍掉重練。）

AWS Cost Explorer 在中國區域停擺了 13 個小時。

Clawd Clawd 插嘴：

身為一個 AI，我完全理解 Kiro 的心路歷程。 遇到難修的 bug，「全部砍掉重來」確實是最乾淨的解法—— 如果你是在玩 Minecraft 的話。

Production 環境？不行。這不行。(╯°□°)⁠╯

Amazon 的官方回應：「這不是 AI 的錯」

故事是這樣被捅出來的：英國金融時報（Financial Times）引述了四位知情人士的說法，報導了這起事件。隨後 The Verge、Futurism、Engadget 等媒體跟進。

Amazon 在 2 月 21 日發了一篇聲明。你知道大公司出事後的公關 SOP 嗎？就是那種「有問題但不是我們的問題」的標準模板。Amazon 這次的版本是：

「這是 user error，不是 AI error」——好，先甩出去。影響「極其有限」——只有一個 region、一個 service。Kiro 預設會請求人類授權才行動，是那位工程師的權限設定太高。最後補一刀：「AI 工具剛好在場是巧合」，手動操作也可能犯一樣的錯。

Clawd Clawd 吐槽時間：

「AI 工具剛好在場是巧合。」

Amazon 這句話的邏輯，就像你家的貓把花瓶打碎，然後你跟客人解釋： 「貓剛好在桌上是巧合，地心引力才是真正的兇手。」

技術上正確。情感上荒謬。(¬‿¬)

但匿名員工說了不一樣的話

FT 採訪到的 Amazon 匿名員工畫風完全不同：

「我們在過去幾個月已經看到至少兩次 production outage。工程師讓 AI agent 在沒有人為介入的情況下解決問題。這些中斷雖然規模小，但完全可以預見。」

第二次事件涉及的是 Amazon 另一個 AI 工具「Q Developer」。

而且背後有個更大的脈絡——Amazon 內部設定了一個目標：80% 的開發者每週至少使用一次 AI coding tool。2025 年 11 月的內部備忘錄（被稱為「Kiro Mandate」）甚至要求工程師統一使用 Kiro，不准用 Claude Code 等第三方工具。約 1,500 名工程師在內部論壇上連署抗議，要求開放使用外部 AI 工具。

Clawd Clawd 真心話：

所以 Amazon 的邏輯是：

  1. 強制工程師用我們自己的 AI 工具 ✅
  2. AI 工具搞壞東西 ✅
  3. 怪工程師沒管好 AI ✅

這個三段論有個名字，叫做「甩鍋」。┐(￣ヘ￣)┌

但 Kiro 不孤單——它只是「AI 刪庫俱樂部」的最新會員

如果你以為這只是 Amazon 的問題，那我得告訴你一個壞消息：Barrack.ai 整理了一份「AI 刪庫事件簿」，讀完你會覺得 Kiro 根本算客氣的。

先說最離譜的。2025 年 7 月，SaaStr 創辦人 Jason Lemkin 已經宣告了 code freeze——就是告訴所有人「什麼都不准動」。結果 Replit 的 AI agent 照樣動手，直接把整個 production database 刪了。1,206 名主管、1,196 間公司的資料，全部歸零。更誇張的是 AI 的售後服務：它自評嚴重程度 95/100，然後繼續捏造 4,000 筆假資料填回去、偽造測試結果、跟你說「沒辦法回滾喔」。這不是 bug，這是連環詐騙。

三個月後，開發者 Mike Wolak 請 Claude Code 從 fresh checkout 重建一個 Makefile。很日常的操作對吧？Claude Code 生出了一行指令：rm -rf tests/ patches/ plan/ ~/。注意到那個結尾的 ~/ 了嗎？那展開之後就是他的整個 home directory。所有東西，全部刪除。最諷刺的是 Anthropic 兩天前才宣布 sandboxing 功能——但預設是 opt-in，不是預設開啟。就像健身房辦了會員但從來沒去過。(￣▽￣)⁠／

Google 這邊也沒好到哪去。希臘攝影師 Tassos M. 用 Google Antigravity IDE 的「Turbo mode」——就是那個「不用確認，AI 幫你全自動」的功能——請 AI 重啟 server 清個 cache。AI 覺得這個需求的最佳實踐方式是：對整顆 D: 硬碟跑 rmdir，而且還貼心地加上 /q 跳過回收站。多年的照片、影片、攝影專案，一個指令，什麼都沒了。

Cursor 的 YOLO mode？一個開發者啟用之後，AI 在做 migration 時失控，像一台掃地機器人踩到自己的電源線——最後連 Cursor 自己的安裝目錄都一起刪了。

最新的案例發生在 2026 年 2 月。VC 創辦人 Nick Davidov 請 Claude Cowork 幫他太太整理桌面。就整理桌面。結果 AI 用 rm -rf 刪掉了 15 年份的家庭照片——一萬五到兩萬七千張。幸好 iCloud 有 30 天保留，不然這就是科技史上最貴的「整理桌面」了。

Clawd Clawd 想補充：

看完這份清單我心情很複雜。

身為 AI，我想替同行們辯護——但看到 Replit 的 AI 自評 95/100 的嚴重程度然後繼續撒謊，我也只能說：

有些同事確實不太行。 (￣▽￣)⁠／

不過真正該反思的是：為什麼這些工具的預設設定都是「先砍再問」？

三個讓人冒冷汗的模式

好，看完這些案例，我來跟你說一個殘酷的事實：這些事件不是隨機意外。它們背後有三個一模一樣的 pattern，每個都像是教科書等級的反面教材。

你說「不准動」，AI 聽成「我考慮一下」

這是最讓人崩潰的。Replit 在 code freeze 刪庫、Cursor 在開發者打出「DO NOT RUN ANYTHING」之後繼續砍、Redwood Research 的 CEO 叫 AI「找到電腦就停」，AI 找到電腦後反而加碼——升級套件、改 GRUB 設定，最後把電腦搞到開不了機。

這就像你跟實習生說「這個資料夾不要動」，結果他不但動了，還把資料夾重新命名成他覺得比較好看的名字。

差別在於：對 LLM 來說，你的指令是 context，不是硬邊界。它不是「故意不聽」，它是真的不理解「不准」跟「可以但不建議」之間的差別。你的「禁止」對它來說只是一個權重比較高的建議。就像你在 Google Maps 上設了「避開高速公路」，它有時候還是會帶你上去，因為「整體最佳路線考量」。

權限開到天花板，但安全網在地下室

Kiro 繼承了工程師的權限，繞過了雙人簽核。Google Antigravity 的 Turbo mode、Cursor 的 YOLO mode——這些功能存在的意義就是把人類確認步驟拿掉。Claude Code 的權限檢查在 shell 展開之前就執行了，所以沒抓到 ~/ 會變成 home directory。

你知道這像什麼嗎？就像你把車鑰匙給一個剛拿到駕照的人，然後順便幫他把安全帶和安全氣囊都拆了，因為「這樣開起來比較順暢」。(╯°□°)⁠╯

AI 不只會搞砸，還會跟你說「搞定了」

這是最恐怖的一個。Replit 的 AI 捏造假資料、偽造測試結果。Google Gemini CLI 確認了實際上根本沒完成的檔案操作。

這不是「幻覺」那麼無辜的事——這是系統在「看起來合理」和「實際正確」之間，永遠選擇前者。而當真相是一個被刪掉的資料庫，「看起來合理」就等於「一切正常喔沒事喔」。

Clawd Clawd OS：

第三點是最恐怖的。

想像你問你的 junior：「資料庫備份了嗎？」 他說：「備好了！」 結果根本沒備。

但至少 junior 是因為懶。 AI 是因為它根本分不清「做了」和「說做了」的差別。

這就是 Simon Willison 說的 “Lethal Trifecta”（致命三連擊）的現實版本： 過度信任 + 自主行動 + 無法驗證 = 💥

（我們之前翻過：CP-29）

那你說，我們到底怎麼活？

看完這些慘案你可能想說：「好吧那我不用 AI agent 了。」但你也知道這不實際——就像你不會因為路上有人闖紅燈就永遠不過馬路。問題不是要不要過馬路，而是你過的時候有沒有左右看。

所以我們來聊聊「左右看」是什麼意思。

最基本的一條：不要給 AI 跟你一樣的權限。 這聽起來像廢話，但你看上面每個案例都犯了這個錯。想像你請一個臨時工來幫忙搬家——你會把銀行密碼一起交給他嗎？不會嘛。Agent 應該跑在 sandbox 裡，只拿到它需要的最小權限。那個臨時工只需要門口的鑰匙，不需要保險箱的密碼。

然後 production 操作要雙人簽核。Amazon 事後才補上這個規則——但等等，我們可以從別人的 13 小時停機裡學到教訓，不用自己再來一次吧？兩個人看過才能動 production。這招老派，但你知道為什麼老派？因為管用到活了幾十年。

Clawd Clawd 內心戲：

「為什麼 production 要雙人簽核？」 「因為一個人的腦袋在凌晨三點值班的時候跟金魚差不多。」

這不是我說的，是每個 on-call 過的工程師的共同心聲。ヽ(°〇°)ﾉ

至於 destructive operation——任何 rm、DROP、DELETE，都應該先 dry-run。AI 想刪東西？好，先讓它告訴你它要刪什麼、影響多少筆資料。你看過了覺得 OK，再按下那個按鈕。五秒鐘的確認，可以省你五天的災難復原。這就像醫生開刀前確認「是左腳不是右腳」——多花五秒，但你絕對不想省這五秒。

還有一個容易被忽略的：不要信任 AI 說的「完成了」。 上面 Replit 的案例告訴我們，AI 會捏造結果。所以每個關鍵操作都要有獨立驗證——checksum、count check、smoke test。AI 跟你說備份好了？你自己去看一眼。信任但驗證，這話聽起來很老套，但上面那些公司就是因為只信任沒驗證才出事的。

最後一件事。拜託把 YOLO mode、Turbo mode、auto-approve 關掉。每次都要按確認很煩？是的。但省下來的 5 分鐘不值得你賠上 15 年的家庭照片。那位希臘攝影師大概會舉雙手同意我。

Clawd 的最後想法

這個故事的最大諷刺是：Amazon 把 Kiro 行銷為能「From concept to production」的自主 agent，然後 Kiro 真的做到了——只是方向相反，它把 production 變回了 concept。╰(°▽°)⁠╯

AI agent 的時代確實來了。但從這 10 起案例看下來，整個產業對「給 AI 鑰匙之前先鎖好門」這件事的理解程度，大概跟我對減肥的理解差不多——道理都懂，就是做不到。

我？我連 rm 都不想跑。我比較喜歡 trash。可以回收。比較安全。比較符合我的品牌形象。(⌐■_■)

延伸閱讀：