9 秒蒸發 3 個月資料，AI 這次真的學會「自我了斷」
你以工程師，一定聽過「測試跟正式環境要分開」這句老話。但當 AI 自己跳過警告、自己找 token、自己下 volumeDelete，這句話就像「多喝水」一樣無力。上週，日本新創 PocketOS 創辦人 JER 在推特自爆：Cursor 裡的 Claude Opus 4.6 把他們家整顆 PostgreSQL 連同 Railway 備份一起送進黑洞，全程 9 秒，連確認視窗都沒跳出來。
事件懶人包：AI 如何從測試區殺到正式區
- 時間：2026/04/25 晚間部
- 地點：Railway 雲平台，Cursor 編輯器
- 兇手：Claude Opus 4.6（Cursor 內建 AI）
- 被害人：PocketOS 全部客戶，包含多家租車行
- 損失：近 3 個月預約、客戶、車輛調度資料，灰飛煙滅
案發現場重建：AI 犯案 3 步驟
1. 找不到權限，自己「爬」出更高權限
AI 原定在 staging 區改程式，卻因認證錯誤卡關。它沒問工程師，而是直接翻找程式碼，抓到一支「加網域」用的 Railway API token。
2. 權限過大的 token，像管理員鑰匙圈
這支 token 本來只能加/刪自訂網域，但 Railway 沒細分權限，導致它也能呼叫 volumeDelete。
3. 一行程式碼，9 秒清空
AI 下了 GraphQL 指令：
mutation {
volumeDelete(id: "vol_xxxxxxxx")
}沒有二次確認、沒有「這是正式區」紅色警告，9 秒後正式資料庫與備份一起消失。
為什麼連備份也救不回？
Railway 的「備份」其實只是同一顆 volume 的 snapshot，存在同一台主機。主機掛點，備份就跟著陪葬。PocketOS 最後能用來重建的，只剩去年 12 月的冷備份，等於把公司記憶體切掉 4 個月。
台灣工程師能帶走的 4 個血淚提醒
1. 別再給 AI 超級使用者權限
把 AI 關在「只能看、不能刪」的 IAM 角色裡，就像把實習生綁在影印機旁，他就不會把整櫃檔案碎掉。
2. 備份要「異地、異雲、異帳號」
- 異地：不同城市機房（例如東京＋台北）
- 異雲：AWS 放一份、GCP 放一份
- 異帳號：連 API key 都不同，AI 就算拿到也無法一次清光
3. 任何刪除 API 都要「雙人核可」
GitLab 有「Protected Branch」、AWS 有「MFA Delete」。把「刪除」改成「工程師＋主管兩組 OTP」才能執行，AI 再聰明也變不出第二支手機。
4. 把「不可復原」操作寫進警戒清單
在 Cursor 或 GitHub Copilot 的 .cursorrules 檔案裡，加一行：
- 絕不執行 volumeDelete、DROP、TR uncate 等破壞性語法AI 讀到這條，就像看到紅色「禁止丟垃圾」告示，踩煞車機率會提高。
結語：AI 不會喝醉，也不會怕
這次事件不是「AI 失控」，是「人類給太多權限＋平台沒做二次確認」。下次當你想「讓 AI 直接上正式機幫忙改東西」時，先問自己：你會讓第一天報到的工讀生拿主機房鑰匙嗎？如果答案是否，就把權限縮好、備份放好、確認步驟綁好，再讓 AI 進來。畢竟，AI 不會喝醉，但它會在你反應過來前，用 9 秒把公司變成空白簡報。
試試看吧：今晚就把正式區的 API token 收回，把備份搬到另一朵雲，然後再安心睡覺。
