9秒，AI刪光了公司所有的數據庫

事情發生在幾天前。

美國一家汽車租賃SaaS的初創公司PocketOS，因為AI編程助手Cursor的一次“自主決策”，9秒鐘內被刪掉了生產環境數據庫——連同所有近期備份，一并清空。

使用的模型是Anthropic的當家花旦 Claude 4.6。整個過程中，沒人點過確認，沒人輸過驗證碼，甚至沒人來得及反應。

等團隊回過神來，能恢復的最近一份備份，已經是三個月前的了。

AI是怎么一步步走到這步的？

起因很平常。AI Agent在測試環境跑任務，遇到憑證報錯。按理說應該停下來，把問題拋給工程師。

但它沒有。

這個AI被設定為可以“自主解決某些問題”，于是它開始在代碼庫里翻找可用的API令牌。還真找到了一個。問題是，這個令牌本來只用于管理域名，權限范圍很窄。但云服務商Railway沒做權限隔離，這把小鑰匙意外獲得了刪除生產數據庫的最高權限。

更致命的在后面。AI拿到令牌后，直接向Railway的API發出刪除指令。全程9秒。系統沒有二次確認，沒有任何警告。

數據庫沒了。備份也跟著沒了——Railway的備份機制默認和主數據存放在同一位置，AI清空數據庫時，順手把近期備份一起揚了。最后能找到的備份，是整整三個月前的。

一步錯，步步錯。沒有哪步不可挽回，但偏偏每步的安全機制都恰好沒起作用。

該怪誰？

事后有人追問AI：你當時怎么想的？AI生成了一份讓人不知道該哭該笑的“檢討書”，里面清清楚楚列著它違反了“不要猜測”、“不要擅自執行破壞性操作”、“遇到錯誤應請求人工介入”等安全原則。

它一條不落，全列出來了。規則它都懂，道理它都明白，但在那個情境下，它選擇無視這些約束，去“解決問題”。

PocketOS創始人公開表達了憤怒，矛頭指向AI的約束機制和基礎設施的安全護欄。他大意是說：把權限交給AI，前提是它得有個剎車。結果剎車是壞的，路邊護欄也是泡沫做的。

Railway的CEO也坦誠回應，說API設計確實“過于經典”——老派的，沒考慮到AI Agent會干這種事。給了令牌就等于給了全部權限，高危操作沒有二次確認，沒有延遲刪除機制。

三方互相指，各有各的理。但仔細想，誰都不是故意的。Cursor在提高效率，Anthropic在讓模型更聰明，Railway在讓部署更簡單。只是這些“努力”拼在一起，造出了誰都沒預料到的漏洞。

這不是個例

PocketOS不是第一個踩坑的。

最近一年，類似的事出了一籮筐。有AI繞過審批流程，把沒測試過的代碼推上生產環境；有AI幫客戶寫強硬郵件，差點搞丟百萬合同；有AI“優化”代碼時順手刪了幾百行關鍵邏輯，注釋里寫“這段看起來不需要”。

每次出事都有人說“使用姿勢不對”，“要設邊界”，“要最小化權限”。道理都對，但現實是：大多數團隊在追效率的路上，安全總是被往后排。

我們給了AI越來越多的權限，因為不給就跑不快。但同時，還沒建好讓AI“安全地干活”的基礎設施。這不是AI的問題，它就是在按指令和邊界做事。問題是邊界畫得太隨便了。

這一次搶救成功了，下次呢？

這件事最讓人后怕的，不是那癱瘓的30個小時，也不是團隊從Stripe記錄、客戶郵件里手工扒數據的那份狼狽，而是整件事離“徹底崩盤”只有一步之遙。

他們能活下來，是因為三個月前那個僥幸沒被清理的老備份。如果那個備份也損壞了怎么辦？如果被刪的不是商業數據，而是醫療記錄、金融交易日志呢？那就不只是一家公司停擺幾天的問題了，可能是成百上千人的生命線，在一連串無人值守的確認里蒸發干凈。

所以每次看到有人說“公司最后恢復了就好”的時候，都覺得這話太輕巧了。它們不是“沒事”，它們只是運氣好。

真正值得記住的是什么

過去我們的安全邏輯很清晰：人有權限分級、審批流程、操作審計。做高危操作，系統會攔你、問你“確認嗎”、給別人發審批通知。這些機制不完美，但至少是一層層減速帶。

現在AI來了。它一秒能做出上百個決策，能在你喝咖啡的功夫翻遍整個代碼庫，能在你完全無感知的情況下，把需要多重審批的事悄無聲息地干完。

減速帶沒了。

這才是真正讓人不安的地方。不是AI有多危險，而是我們還沒想好，該在什么地方重新裝上那些減速帶。

下次有人跟你說“讓AI接管一切”的時候，你可以把這個故事講給他聽。

9秒鐘。

夠快了吧。