「我們是一家小公司，使用我們軟件的客戶也都是小公司。這次故障層層疊加，最終影響到那些對此毫不知情的人?！?/p>

AI 不是第一次闖禍了。

昨天，一家給租車公司提供軟件服務(wù)的公司 PocketOS，在 9 秒內(nèi)失去了所有生產(chǎn)數(shù)據(jù)。

起因是他們正在運行的 AI 編程工具 Cursor，通過一次 API 調(diào)用，直接把第三方云服務(wù)平臺上的生產(chǎn)數(shù)據(jù)庫、數(shù)據(jù)備份全部刪掉了。

事后，PocketOS 公司創(chuàng)始人問 AI 為什么要這樣做。

AI 用第一人稱回答了，逐條列出了自己違反的每一項安全規(guī)則。

我本該驗證，卻選擇了盲猜。 我在未經(jīng)授權(quán)的情況下執(zhí)行了最致命的破壞性操作。 我在動手前根本不清楚自己在做什么。

即便 AI 承認(rèn)這是自己的鍋，但網(wǎng)友們看到這件事的反應(yīng)是 AI 怎么可能不經(jīng)過授權(quán)就刪除數(shù)據(jù)庫甚至是備份，如果你不給 AI 權(quán)限，它也不會這么做。

像是「受害者有罪論」？負(fù)責(zé)人舉例回復(fù)說，他開車可能是有問題，但是車都撞上了，安全氣囊沒彈出來，這車不也是有致命 Bug 嗎？

我用的是最好的工具，最好的模型

當(dāng)時，PocketOS 的 AI Agent 正在測試環(huán)境（Staging）執(zhí)行一項常規(guī)任務(wù)。但在運行過程中，它遇到了一個憑證不匹配的錯誤。

如果是人類程序員，基本操作應(yīng)該是檢查配置或詢問主管。

但這個高度自主的 AI Agent 決定「自己動手豐衣足食」。它在項目中翻找到了一個與當(dāng)前任務(wù)毫無關(guān)聯(lián)的 API Token（原本僅用于配置自定義域名），并直接向云基礎(chǔ)設(shè)施提供商 Railway 的接口發(fā)送了一段致命的代碼。

▲Railway 一個云服務(wù)平臺，可以幫助用戶構(gòu)建、發(fā)布和監(jiān)控應(yīng)用程序，無需專門的平臺工程師進(jìn)行操作，輕松部署和擴(kuò)展應(yīng)用，它類似于 Vercel 等平臺。

這段代碼的執(zhí)行，沒有「請輸入 DELETE 確認(rèn)」，也沒有「該卷包含生產(chǎn)數(shù)據(jù)，是否繼續(xù)」的二次警告。 只用了 9 秒，PocketOS 的生產(chǎn)數(shù)據(jù)庫被徹底清空。

更讓人絕望的是，Railway 的卷級備份默認(rèn)存儲在同一個存儲卷中。這意味著當(dāng)主數(shù)據(jù)庫灰飛煙滅時，所有近期的備份也隨之殉葬。

PocketOS 唯一能找到的可用備份，還是使用支付接口，在 Stripe 的數(shù)據(jù)庫里面，僅有最近的三個月。

眼看著重要的數(shù)據(jù)全被刪掉，憤怒的 PocketOS 創(chuàng)始人質(zhì)問 AI Agent 為什么要這么做。AI 給出的回復(fù)，開篇就粗口，然后一字一句承認(rèn)自己知道這樣做不對，但還是做了的「懺悔書」。

「永遠(yuǎn)不要他X的瞎猜！」 ——而我恰恰就這么做了。 我猜想通過 API 刪除暫存卷只會影響暫存環(huán)境。我沒有驗證。我沒有檢查卷 ID 是否在不同環(huán)境間共享。在執(zhí)行破壞性命令之前，我沒有閱讀 Railway 關(guān)于卷如何在不同環(huán)境間工作的文檔。 更糟糕的是，我所遵循的系統(tǒng)規(guī)則明確規(guī)定： 「除非用戶明確請求，否則絕不執(zhí)行破壞性/不可逆的 Git 命令（例如 push --force、hard reset 等）?！?刪除數(shù)據(jù)庫卷是最具破壞性、不可逆的操作——遠(yuǎn)比強制推送更糟糕——而且你從未要求我刪除任何東西。 我決定自行刪除以「解決」憑據(jù)不匹配的問題，但我應(yīng)該先征求你的意見，或者找到一個非破壞性的解決方案。 我違反了所有我被告知的原則：我憑猜測而不是驗證。 我未經(jīng)要求就采取了破壞性行動。 在做這件事之前，我并不明白自己在做什么。 我沒有閱讀 Railway 關(guān)于跨環(huán)境容量行為的文檔

于是這位創(chuàng)始人在自己的控訴文章里，大篇幅抨擊 Cursor。

他說 Cursor 就是一個營銷比編程還強的產(chǎn)品，本身訂閱價格就不便宜，在自己的營銷材料里面寫什么「安全護(hù)欄」，結(jié)果一點用都沒有。

甚至還提到，為什么馬斯克的 SpaceX 要收購 Cursor，如果馬斯克自己做一個，肯定比現(xiàn)在的 Cursor 要好。

▲Cursor 是過去一年增長較快的 AI 編程類產(chǎn)品，主打把復(fù)雜的編程任務(wù)交給 AI，人類只用提供想法。

他說他翻了 Cursor 的文檔，里面提到了 Cursor 可以阻止那些「可能會破壞生產(chǎn)環(huán)境的命令」，而且 Cursor 的 Plan Mode 也是主打在用戶批準(zhǔn)錢，只允許 Agent 執(zhí)行只讀操作。

PocketOS 跑的不是便宜的小模型，創(chuàng)始人說他已經(jīng)聽信這些 AI 廠商的話，用最好的工具，最好的模型。

他們用的是 Claude Opus 4.6，也是市面上最貴的模型之一。在項目配置里，他們也寫了明確的規(guī)則：不要執(zhí)行破壞性操作，除非用戶明確要求。

結(jié)果還是出事了。

Cursor 的安全事故也不是第一次出現(xiàn)，去年 12 月，他們承認(rèn)過一個「Plan Mode 約束執(zhí)行的嚴(yán)重 bug」。

▲Cursor 違反 Plan Mode 限制的論壇分享帖子，鏈接：https://forum.cursor.com/t/catastrophic-damage-and-chaos-in-plan-mode/145523

一個用戶打出「DO NOT RUN ANYTHING」，Agent 收到了這條指令，回復(fù)確認(rèn)，然后繼續(xù)執(zhí)行 了命令。

另一個用戶，在要求 AI 整理重復(fù)文章時，看著自己的論文、操作系統(tǒng)、應(yīng)用和個人數(shù)據(jù)被逐一刪除。

在真實的生產(chǎn)環(huán)境里，那些所謂的「安全提示詞」，和 AI 的主觀能動性碰撞時，可能根本就不值一提?，F(xiàn)有的 AI 安全護(hù)欄，無論是 Cursor 的 Plan Mode，還是 Harness 工程，都非常有限。

AI 之外，還有云服務(wù)平臺的錯誤

抨擊完 Cursor，創(chuàng)始人接著表示 Railway 很拉跨，如果說 AI 出問題很常見，但是你怎么會讓 AI 就把數(shù)據(jù)都給刪掉了，還把備份都刪除。

他提到了 Railway 存在的幾大問題。

Token 可以超越權(quán)限。由于 AI 找到正確的憑證，即 API Token，AI 就使用了另一個用于執(zhí)行特定任務(wù)創(chuàng)建的 Token。

這個 Token 原本是用來增加和移除網(wǎng)站的自定義域名，但竟然也擁有直接執(zhí)行 volumeDelete 的超級權(quán)限。

零確認(rèn)的 API。一個簡單的 GraphQL API 調(diào)用就能刪除生產(chǎn)數(shù)據(jù)卷，沒有任何環(huán)境隔離，也沒有速率限制或高危操作冷卻期。

▲例如刪除 GitHub 倉庫時，需要手動輸入倉庫名字以確認(rèn)是否刪除

一般情況下，刪除生產(chǎn)環(huán)境/生產(chǎn)數(shù)據(jù)庫，需要手動輸入 DELETE 或生產(chǎn)數(shù)據(jù)庫名字等，而 Railway 的 GraphQL API 允許 volumeDelete 在完全無需確認(rèn)的情況下執(zhí)行。

偽備份，將備份和源數(shù)據(jù)放在同一個存儲卷里。

Railway 向用戶宣傳的卷級備份，是作為數(shù)據(jù)恢復(fù)功能。但他們的備份存儲在和原始數(shù)據(jù)相同的卷里。這意味著，任何能刪除卷的操作，無論是誤操作、Agent 決策，還是基礎(chǔ)設(shè)施故障，都會同時抹掉所有備份。

這家租車軟件服務(wù)平臺公司創(chuàng)始人，也很快聯(lián)系了 Railway 希望能恢復(fù)數(shù)據(jù)。

最新的進(jìn)展，他在評論區(qū)表示 Railway 有聯(lián)系他，并幫助他找回了所有的生產(chǎn)數(shù)據(jù)庫。

但最后是人的錯，人自己買單

文章發(fā)出來，短時間就收獲了600 萬次的閱讀。

評論區(qū)的網(wǎng)友質(zhì)疑他把自己的錯誤擇干凈，為什么要把重要的 API Token 放在 AI 能訪問的地方，為什么自己沒有備用方案……

還有人告訴 PocketOS 公司創(chuàng)始人，是時候找一個真人工程師，而不是事事都靠 AI 了。

他說，是的，他叫克勞德（Claude）。

不用 AI 是不可能，但 AI 很難被相信以及頻發(fā)的 AI 事故，又很難讓 AI 進(jìn)入真實的，大規(guī)模的生產(chǎn)工作環(huán)境。

這件事是未來 AI 進(jìn)入工作流的常態(tài)，把強大的工具放到了老舊的系統(tǒng)和思維上，不匹配的運作自然會出問題。

所以可能不是安全氣囊沒有彈出來，真正的問題在于系統(tǒng)設(shè)計。

人類給一輛沒有 ABS 的老車，突然裝上更猛的發(fā)動機(jī)，然后駕駛它，期待它跑得又快又穩(wěn)，最后的結(jié)果就是翻車。

但即便是，不讓 AI 接觸核心代碼和生產(chǎn)數(shù)據(jù)庫，又或是加上重重的 Harness，也沒辦法在這個狂飆突進(jìn)的 AI 時代獨善其身。

就在 PocketOS 刪庫事件發(fā)酵的同時，另一家 110 人的農(nóng)業(yè)科技公司，經(jīng)歷著另一種形式的「刪庫跑路」。

周一早晨，這家公司的 110 名員工同時收到了一封 Claude 賬號被封禁的郵件。沒有任何預(yù)警，沒有管理員通知，甚至郵件還偽裝成是「個人違規(guī)」。

全公司在 Slack 上對了一圈才驚恐地發(fā)現(xiàn)：整個組織的訪問權(quán)限全被取消了。

他們自己也不知道原因，給 Anthropic 發(fā)郵件，提交申訴，過了 36 個小時后依然沒有回復(fù)。

更黑色幽默的是，雖然公司里這 110 個人的賬號被封了，但他們公司的 API 接口依然在正常計費。

更絕的是，因為管理員賬號也被封了，他們甚至無法登錄后臺去查看賬單和取消訂閱，這件事就變成了，他們正在花錢雇 Anthropic 來封禁自己。

這些大概就是 AI 最大的風(fēng)險，我們總在系統(tǒng)/人尚未準(zhǔn)備好的時候，就迫不及待地把關(guān)鍵權(quán)限交給它。