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

編輯｜楊文

美劇《硅谷》中，有個經典搞笑片段。

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

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

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

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

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

沒想到，現實中的 AI 還真就這么闖大禍了。

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

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

這件事在社交媒體上引發熱議。

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

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

「僅用 9 秒就刪除了生產環境和備份數據，這是該公司有史以來最快的部署速度�！�

AI Agent 自作主張

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

上周五下午，開發團隊用 Cursor 調用 Anthropic 的旗艦模型 Claude Opus 4.6，在測試環境里跑一個例行任務。

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

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

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

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

9 秒后，生產數據庫不見了。

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

Agent 寫了一份「認罪書」

事后，Jer Crane 質問 Agent，為什么這樣做。

Agent 逐條列出了自己被要求遵守的系統規則，并逐一承認違反：

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

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

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

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

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

Railway 的備份不是真的備份

與 Cursor 相比，Railway 的問題更麻煩，它出在產品架構里，影響的是所有在該平臺運行生產數據的用戶。

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

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

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

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

偏偏就在事故發生前一天，Railway 高調上線了面向 AI 編程 Agent 用戶的 MCP 服務器產品，公開鼓勵開發者接入生產環境。而這一新產品，建立在與本次事故完全相同的授權體系之上。

事故發生逾 30 小時后，Railway 仍未能給出能否從基礎設施層面恢復數據的明確答復。

不過，Jer Crane 在給 Railway CEO 發送私信后得到回復，目前已經恢復了數據。

最后買單的，是小企業

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

Jer Crane 花了整整一天，陪著每一位客戶從 Stripe 賬單、日歷記錄和郵件里一條條翻找，手動重建數據�！该總�人都在做緊急的人工補救，就因為一次 9 秒鐘的 API 調用�！�

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

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

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

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

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