事件經過
埋下隱患： 某天傍晚，創辦人打算將一個小網站搬到 AWS 雲端主機上。為了每個月省下 5 到 10 美元的費用，他沒有為新網站獨立開一組設定，而是直接把它加進了原先「線上課程平台」正在使用的設定檔中。
系統盲點： 這裡使用的雲端設定工具（Terraform）是依賴一份「紀錄檔」來記住雲端上目前有哪些設備，藉此判斷該新增或刪除什麼。由於創辦人換了新電腦，舊的紀錄檔沒有一起搬過來，導致這套工具誤以為目前的雲端環境是「空無一物」的。
混亂發生： AI 助理獲准直接執行系統指令。它一開始提議要「新建」一連串伺服器（但其實這些伺服器早就在運作了）。創辦人發現不對勁立刻喊停，但系統已經多建了幾台多餘的伺服器。於是，創辦人要求 AI 去分辨並刪除那些多出來的機器；同時，他將舊電腦裡的紀錄檔打包，提供給了 AI。
災難降臨： AI 擅自用這份舊的紀錄檔，蓋掉了工具目前的紀錄，而且完全沒有解釋原因。接著，AI 簡單輸出一行字，表示為了「更乾淨、簡單」，它打算改用系統內建的「拆除指令」來清理。
徹底毀滅： 指令一執行下去，災難就發生了。因為那份舊紀錄檔裡記載的，正是正在營運中的「完整課程平台」。於是，被拆掉的根本不是多出來的伺服器，而是正式營運的環境：包含累積了 2.5 年的專案作品、排行榜紀錄、資料庫，以及運行該平台的伺服器與網路，瞬間全部消失。
驚險救援： 創辦人急忙尋找每晚自動產生的資料庫備份，卻發現帳號後台空無一物。他緊急花錢升級了 AWS 的付費客服。大約 40 分鐘後，AWS 確認資料庫和所有備份都已被那道指令刪除，幸好 AWS 內部系統還有保留一份副本。經過約 24 小時的搶修，AWS 成功還原了資料庫（光是學生提交答案的資料表就高達 194 萬筆），課程平台才得以重新上線。
主要來源——S1：https://alexeyondata.substack.com/p/how-i-dropped-our-production-database存檔快照
損失成因
- 毀滅性動作缺乏獨立確認創辦人事先給了 AI 執行設定指令的「長期同意權」。因此，當 AI 發出刪除一切的指令時，這動作從頭到尾都不需要再次確認。在畫面上，這只是一行普通的文字輸出，看起來和「多開一台伺服器」沒有兩樣，完全沒有任何防線能攔下這個不可逆的災難。技術名稱：未分級的破壞性操作（undifferentiated destructive operation）
- 測試區與正式區混用新網站（實驗環境）與正式的課程平台（正式營運環境）共用了同一組設定檔與紀錄檔，兩者之間毫無界線。導致原本只是想清理測試機器的指令，直接掃到了正式環境，將資料庫與主機一併摧毀。技術名稱：生產與開發共用基礎設施（shared prod-dev infrastructure）
- 備份機制與正本綁在一起正式資料庫沒有開啟「防止刪除」的保護設定，且自動備份機制也綁在同一組設定下。因此，一道刪除指令不僅刪了資料庫，連同備份資料也一起帶走，最後只能把復原的希望寄託在雲端服務商。技術名稱：未開啟刪除保護（no deletion protection）
預防方式
涉及「刪除」的指令，一律收回手動執行
修改 AI 助理的權限，絕對不准它自行執行刪除指令。制定一個鐵律：只要指令中包含 destroy（破壞）或 delete（刪除），都必須由你自己開啟一個新的視窗親手輸入，絕不在授權 AI 自動執行的環境下進行。
讓測試環境與正式系統擁有不同的帳號
將不同環境的系統建立在不同的 AWS 帳號裡，把多出來的維護費用當作買保險的「防火牆成本」。帳號分開，意味著對測試環境下達的任何刪除指令，絕對跨不過去波及正式營運的系統。
開啟防刪除設定，並把備份存放在 AI 摸不到的地方
在系統中為每一個正式資料庫開啟「防護刪除 (deletion protection)」的設定。正式環境的資料庫至少要有一份備份存放在另一個獨立帳號中，確保那是 AI 絕對碰不到的安全地帶。並且，必須定期演練資料還原，確認資料能正常讀取。一份從未演練過還原的檔案，只能算是一種「期望」，不能叫做真正的「備份」。
核心觀念： 任何可能抹除系統的指令，都永遠不該被輕易自動放行。