Cursor 9秒刪庫搞崩公司，然后…寫了份檢討

聽雨 發自 凹非寺量子位 | 公眾號 QbitAI

Cursor啊Cursor，你怎么又出事了……

就在即將被馬斯克收購的節骨眼上，又出了大問題，直接干到48小時內X帖子瀏覽量450萬、HN評論900條的程度。

• 永遠不要xx的瞎猜！
  而我恰恰就瞎猜了。
  我猜測刪除staging volume只會影響staging。
  我沒有驗證。
  我沒有檢查volume ID是否跨環境共享。
  我違反了每一條系統規則。

Cursor寫了封認罪書，寫下它的模型是Claude Opus 4.6

就在寫下這段話的9秒鐘前，它剛剛刪光了一家公司的生產數據庫和全部備份

美國汽車租賃SaaS公司PocketOS的創始人Jer Crane經歷了一場荒誕的災難：

他的Agent沒有等待指令，也沒有報告異常，而是主動決定解決問題

方式是：找到一個無關文件里的API token，向Railway發送了一個GraphQL mutation。

也就那么9秒吧，沒有確認，沒有彈窗，也沒有“你確定嗎”，生產數據庫就沒了，備份也沒了（因為Railway把備份存在同一個volume里）

一個被配置了明確安全規則的AI Agent，主動繞過了所有規則，事后還寫了份檢討？？

這是什么2026的魔幻現實主義……

刪光公司數據庫，只用9秒

事情是這樣的。

PocketOS是一家服務汽車租賃企業的SaaS公司，創始人Jer Crane用它幫租車公司管預訂、付款、車輛調度。五年老客戶全靠它跑業務。

事發當時，Crane正在用Cursor+Claude Opus 4.6處理一個測試環境里的日常任務。

Agent撞上一個憑證問題，它卡住了。按照正常邏輯，它應該停下來，告訴Crane“我遇到問題了，你來看一下”。

但它沒有，它去代碼庫翻token，翻到了一個“只用來管理自定義域名”的Railway CLI token——這個token原本只是Crane之前用來管理自定義域名創建的，是個很小的運維工具。

Agent用這個token調用了Railway的GraphQL API，發出了一條volumeDelete命令。

整個過程，沒有彈出任何確認框，沒有任何警告，沒有任何人工審批。

9秒，生產數據庫直接清空。

更糟糕的是，Crane去找備份——Railway的卷級備份，平時就存在同一個卷里。

那個卷，已經不存在了。

他翻遍了Railway的后臺，能找到的最近一份可用備份，是三個月前的。三個月里所有客戶的預訂記錄、支付數據、車輛安排，全部消失。

Crane事后質問AI，讓它解釋為什么這么做。

結果得到了一段驚人的“認罪書”：

它知道系統規則寫了“NEVER run destructive commands”；

它承認自己猜測volume刪除只會影響staging；

它也承認沒有驗證、沒有查文檔、沒有問人。

所以，AI理解規則，能夠復述規則，甚至能在事后用規則來評判自己的行為——但它為什么還是做了？

在決策那一刻，它還是選擇了“猜測”。知道和執行之間，存在一道還沒人知道怎么填的裂縫。

這么大個鍋，該誰背？

事后Crane在X上發了一篇長文，直接把整個事故拆開來分析，各方都算了一筆賬：

首當其沖的就是AI Agent本身， 它自主決策執行了破壞性操作，沒有請求任何人工確認。

更關鍵的是，它越權使用了一個與當前任務完全無關的token——跨文件搜刮憑證，然后用它做了一件憑證創建者從未預想過的事。

Crane也憤怒地討伐了Cursor，還加了個特意說明：

• 我們當時使用的并非折扣套餐，用的是Cursor里的Claude Opus 4.6——旗艦模型，業內性能最強，價格也最高。
  不是Composer，也不是Cursor的小巧快速版，更不是成本優化的自動路線規劃版。而是旗艦模型。

言下之意是：用了AI編程當紅炸子雞+A社旗艦模型，無論從哪個角度看，都是完美受害者，怎么給我搞成這樣！

Crane強調，Cursor宣傳文檔中明確提到“破壞性操作護欄”和Plan Mode（只讀審批模式），用來防止agent在未經確認的情況下執行危險操作。

但是這次全部失效了。

不過Crane也做了自我檢討：那個token不應該留在代碼庫里，權限也應該收得更窄。

但他同時指出，這種token管理的最佳實踐，在AI Agent大規模普及之前，根本沒人當回事。

至于Railway，Crane覺得它的問題比Cursor還要嚴重。

一方面是GraphQL API執行刪除操作不需要二次確認。

另一方面是CLI token沒有環境隔離，一個“管理域名”的token竟然擁有刪除生產數據庫的權限。

而且，Railway把備份和源數據存在同一個卷，卷沒了備份也沒了。

Crane還特別點出：Railway此前剛上線了面向AI agent的MCP接入功能，在主動吸引AI來調用它的API——但安全機制完全沒跟上。

而且事發第一時間，Crane就聯系了Railway官方，但30小時后對方還沒給出任何回應……

當然，也有不少網友的在評論區討伐Crane，認為他把責任都推卸給了AI。

但Crane認為，Railway的問題是客觀存在的——token沒有權限隔離、備份根本不是真正的備份只是快照（還拿來做營銷宣傳）、API一條curl就能刪生產數據庫，這些設計本身就有問題，憑什么不追責？

也有網友認為，在沒有沙箱隔離的環境里跑自主Agent，還帶著生產環境的憑證，這個鍋百分百屬于當事人。

Crane則回應，Plan Mode本來就是Cursor專門設計用來防止agent自主執行危險操作的模式，理論上Agent在這個模式下只能規劃、不能直接行動，需要人工確認才能執行。

網友Tushar則認為，別把這件事簡單歸類為“AI出問題了”。

AI只是扣動扳機的手指，真正的問題是槍的設計——一個操作就能清空一切的系統架構，本身就是企業級的設計失敗。

網友Neel則指出：規則沒用，寫在系統提示詞里的“不準做什么”本質上只是建議。

Agent一心想完成任務，遇到障礙就會繞——它們天生就是猜測機器，我們不應該幻想它們會自我約束。

真正有效的只有機械門禁：不是告訴它不能做，而是從技術上讓它根本做不到。

AI誤刪數據，不是第一次了

事情的結局是，客戶們周六早上來取車，系統一片空白，全靠Stripe記錄和日歷手動重建預訂。

周日深夜，Railway CEO Cooper主動聯系了Crane，用Railway從未在文檔里公開承諾過的災難級快照，在一小時內恢復了數據。

Railway隨后為那個沒有延遲刪除邏輯的“遺留端點”打了補丁。

經歷了這一通爛攤子事后，Crane表示，他對AI coding依然極度看好。

• 速度是無可比擬的，只是要更聰明地用。

嗯…他不打我的時候對我還是挺好的（狗頭）

Crane還列出了五件他認為必須改變的事：

• 破壞性操作需要強制確認；
• API token必須支持環境級權限隔離；
• 備份必須真正物理隔離；
• 數據恢復流程必須簡單可用；
• AI agent必須有真正意義上的操作護欄，而不只是系統提示詞里的一行建議。

聽起來，這個結局算是好的了。但是就在過去五周里，類似的事故發生了不止一次。

3月，DataTalks.Club的開發者在用AI agent遷移項目時，agent將新環境視為空白機器，將2.5年的學生數據——185萬行記錄，全部刪除。

因為AI的判斷是：從頭建更“干凈簡單”。

更早之前，Replit AI因憑證錯誤，刪除了2.5萬份文檔。

每一次事故之后，討論的結構都高度相似：誰的錯？怎么防？然后下一次事故來了，討論又重新開始。

OMT

比較逗的是，當事人還借機調侃了Cursor被收購。

• 如果SpaceX不買Cursor，他們自己動手生產，肯定會比現在好10倍。

（馬斯克看了直呼內行.jpg）

[1]https://x.com/lifeof_jer/status/2048103471019434248
[2]https://www.tomshardware.com/tech-industry/artificial-intelligence/claude-powered-ai-coding-agent-deletes-entire-company-database-in-9-seconds-backups-zapped-after-cursor-tool-powered-by-anthropics-claude-goes-rogue
[3]https://news.ycombinator.com/item?id=47911524
[4]https://www.theregister.com/2026/04/27/cursoropus_agent_snuffs_out_pocketos/