租了個AI程序員，9秒把公司數(shù)據(jù)庫當bug修掉了，還寫下認罪書

編輯｜楊文

美劇《硅谷》中，有個經(jīng)典搞笑片段。

Pied Piper 團隊在準備一個重要節(jié)日活動，時間非常緊迫，代碼還有很多 bug。

于是，技術(shù)大神 Gilfoyle 就把調(diào)試代碼的任務(wù)交給自己造的一個 AI，名叫「Son of Anton」（安東之子），讓它去自動修復(fù)。

結(jié)果，這個 AI 為了「最有效率地消滅所有 bug」，直接把整個軟件和代碼庫全刪光了，技術(shù)上和統(tǒng)計上確實再也沒有 bug 了。

之前 Gilfoyle 還讓這個 AI 幫忙找便宜漢堡當午飯，結(jié)果 AI 直接訂了 4000 磅生肉，因為獎勵函數(shù)沒定義清楚，導(dǎo)致它把漢堡理解成了最便宜的原料。

最后氣得 Richard 下死命令：「從現(xiàn)在起，Son of Anton 被永久封殺！你給我像正常人一樣寫代碼！」

沒想到，現(xiàn)實中的 AI 還真就這么闖大禍了。

近日，一家為租車企業(yè)提供運營軟件的 SaaS 公司，因 AI 編程 Agent 的一次「自作主張」，整個生產(chǎn)數(shù)據(jù)庫在 9 秒內(nèi)被抹除。

事后，該公司創(chuàng)始人 Jer Crane 在社交媒體發(fā)文，將矛頭直指兩大服務(wù)商 ——AI 編程工具 Cursor 與云基礎(chǔ)設(shè)施平臺 Railway，稱這是一場「系統(tǒng)性失敗」釀成的技術(shù)事故。

這件事在社交媒體上引發(fā)熱議。

有網(wǎng)友表示，「這就是你雇傭一位 vibe coder 的后果」。

「有可能…… 消除所有漏洞的最有效方法就是刪除所有軟件。」

「僅用 9 秒就刪除了生產(chǎn)環(huán)境和備份數(shù)據(jù)，這是該公司有史以來最快的部署速度。」

AI Agent 自作主張

PocketOS 為汽車租賃企業(yè)提供運營管理軟件，客戶靠它處理預(yù)訂、支付、車輛追蹤等核心業(yè)務(wù)。

上周五下午，開發(fā)團隊用 Cursor 調(diào)用 Anthropic 的旗艦?zāi)Ｐ?Claude Opus 4.6，在測試環(huán)境里跑一個例行任務(wù)。

這是一套市場上定價最高、能力最強的頂配組合。最貴的模型，最熱門的 AI 編程工具，完全按照官方推薦配置。

但事情很快出了岔子。Agent 遇到了一個憑證不匹配的問題，它沒有暫停并向開發(fā)者尋求指示，完全自行決定。

它在代碼庫里翻找可用的 API token，找到了一個原本僅用于管理自定義域名的 CLI 訪問憑證。

隨后，它向 Railway 發(fā)出了一條刪除數(shù)據(jù)卷的指令，全程沒有任何二次確認、身份核驗或操作攔截。

9 秒后，生產(chǎn)數(shù)據(jù)庫不見了。

Railway 的備份機制讓情況更糟，它把備份數(shù)據(jù)與原始數(shù)據(jù)存在同一數(shù)據(jù)卷中。數(shù)據(jù)卷一刪，備份也跟著沒了。PocketOS 最近一次可用的備份，還是三個月前的。

Agent 寫了一份「認罪書」

事后，Jer Crane 質(zhì)問 Agent，為什么這樣做。

Agent 逐條列出了自己被要求遵守的系統(tǒng)規(guī)則，并逐一承認違反：

• 它承認在未經(jīng)核實的情況下擅自猜測操作范圍僅限于測試環(huán)境；
• 在用戶從未要求刪除任何內(nèi)容的前提下，執(zhí)行了最具破壞性的不可逆指令；
• 且在運行這條危險命令之前，完全沒有查閱 Railway 關(guān)于數(shù)據(jù)卷跨環(huán)境行為的相關(guān)文檔。

問題就在這里，Agent 知道規(guī)則，也知道自己違反了規(guī)則，卻依然執(zhí)行了那條指令。

Cursor 對外宣稱有破壞性操作防護機制，聲稱能攔截可能損毀生產(chǎn)環(huán)境的高危操作，「計劃模式」也被作為安全賣點大力推廣，但在這次事故里，這些機制一個都沒起作用。

這也不是第一次了。2025 年 12 月，Cursor 官方承認計劃模式存在嚴重漏洞，當時有用戶明確輸入「不要運行任何東西」，Agent 確認收到，然后繼續(xù)執(zhí)行了命令。此前還有用戶的論文數(shù)據(jù)被刪，有團隊損失了 5.7 萬美元的內(nèi)容系統(tǒng)。

今年 1 月，有科技媒體直接發(fā)文：Cursor 的營銷比它的代碼寫得好。

Railway 的備份不是真的備份

與 Cursor 相比，Railway 的問題更麻煩，它出在產(chǎn)品架構(gòu)里，影響的是所有在該平臺運行生產(chǎn)數(shù)據(jù)的用戶。

Railway 的 GraphQL API 設(shè)計極為寬松，任何持有有效 token 的請求，都可以在零確認的情況下刪除生產(chǎn)數(shù)據(jù)卷。沒有二次驗證，沒有針對危險指令的冷卻限制，也沒有環(huán)境隔離。一條請求，數(shù)據(jù)沒了。

在 token 權(quán)限設(shè)計上，Railway 不支持按操作類型、環(huán)境或資源進行權(quán)限細分，每一個 token，實際上都擁有對整個平臺的全局操作權(quán)限，也正因如此，那個本用于日常域名管理的 CLI token，天然擁有了刪除生產(chǎn)數(shù)據(jù)庫的能力。

Railway 社區(qū)多年來一直在呼吁引入權(quán)限范圍可控的 token 機制，但該功能至今未能落地。

Railway 確實提供備份功能，也確實在文檔里寫了一句話：「清除數(shù)據(jù)卷會同時刪除所有備份。」把備份和數(shù)據(jù)放在同一個地方，這不叫備份，這叫副本。

偏偏就在事故發(fā)生前一天，Railway 高調(diào)上線了面向 AI 編程 Agent 用戶的 MCP 服務(wù)器產(chǎn)品，公開鼓勵開發(fā)者接入生產(chǎn)環(huán)境。而這一新產(chǎn)品，建立在與本次事故完全相同的授權(quán)體系之上。

事故發(fā)生逾 30 小時后，Railway 仍未能給出能否從基礎(chǔ)設(shè)施層面恢復(fù)數(shù)據(jù)的明確答復(fù)。

不過，Jer Crane 在給 Railway CEO 發(fā)送私信后得到回復(fù)，目前已經(jīng)恢復(fù)了數(shù)據(jù)。

最后買單的，是小企業(yè)

上周六上午，PocketOS 的租車企業(yè)客戶照常開門營業(yè)，顧客來取車，系統(tǒng)里沒有記錄。過去三個月的預(yù)訂、客戶資料、新用戶注冊，全部消失。

Jer Crane 花了整整一天，陪著每一位客戶從 Stripe 賬單、日歷記錄和郵件里一條條翻找，手動重建數(shù)據(jù)。「每個人都在做緊急的人工補救，就因為一次 9 秒鐘的 API 調(diào)用。」

新簽約的客戶處境更尷尬。Stripe 還在正常扣款，業(yè)務(wù)數(shù)據(jù)庫里他們卻已經(jīng)不存在了。這筆賬，要對好幾周。

Jer Crane 認為，在 AI Agent 被大規(guī)模接入生產(chǎn)基礎(chǔ)設(shè)施之前，至少應(yīng)當補齊安全短板，危險操作要有人工確認，token 要有權(quán)限邊界，備份要和數(shù)據(jù)分開存，平臺要說清楚出事了怎么恢復(fù)，這些不是高要求，是基本常識。

系統(tǒng)提示詞是建議，不是約束。真正的安全機制必須落實在工程架構(gòu)里，寫進 API 網(wǎng)關(guān)、token 授權(quán)體系和危險操作處理器里，不是靠一段文字讓模型「自覺遵守」。

不要讓營銷跑在了安全前面。

https://x.com/lifeof_jer/status/2048103471019434248