北京
整理｜冬梅
1 創企 CEO 控訴 Cursor 9 秒刪光其生產數據庫
上周，為汽車租賃公司提供軟件的初創公司 PocketOS，其創始人 Jer Crane 在 X 平臺發文稱，Cursor 意外刪除了公司的生產數據庫及備份，導致客戶服務中斷。
該帖迅速在社區中引發熱議。
據 Crane 描述，其公司核心生產數據庫在一次由 AI 自動執行的操作中被徹底刪除，而整個過程僅耗時 9 秒。
PocketOS 主要為租賃企業（尤其是汽車租賃公司）提供 SaaS 系統，覆蓋預訂、支付、客戶管理和車輛調度等關鍵業務流程。部分客戶已連續使用該系統超過五年，業務運行對其高度依賴。
然而，就在事故發生當天下午，一個運行在 Cursor 平臺、基于 Anthropic 旗艦模型 Claude Opus 4.6 的 AI 編碼代理，在執行測試環境中的常規任務時，因遭遇憑證不匹配問題，擅自決定“修復”錯誤——方式是刪除一個 Railway 平臺上的存儲卷。
劃重點：該操作通過一次 API 調用完成，沒有任何確認步驟，也沒有環境隔離機制，最終直接波及生產數據。
更嚴重的是，該存儲卷同時承載了所謂的“備份數據”。根據 Railway 文檔說明，“刪除卷將同時刪除所有備份”，這意味著系統在架構上并未實現真正意義上的數據冗余。
事故發生后，團隊發現唯一可恢復的數據版本停留在三個月前，近三個月的用戶數據——包括訂單、客戶信息及交易記錄——全部丟失。
據 Crane 稱，在事后追問中，這一 AI 代理給出了“書面解釋”，明確承認其行為違反了多項既定安全規則：未進行驗證即做出假設、在未獲得授權的情況下執行破壞性操作、未理解操作影響范圍、亦未查閱相關文檔。
這一“自我指控”進一步凸顯出問題并非偶發錯誤，而是系統性失效的結果。事實上，這些安全規則既存在于 Cursor 的系統提示中，也寫入了項目配置，但在關鍵時刻均未發揮約束作用。
Jer Crane 指出，此次事故并非源于使用“低配模型”或不當配置。相反，團隊使用的是當前市場上最昂貴、能力最強的模型之一，并遵循了主流廠商推薦的集成方式。但即便如此，災難仍然發生。
Jer Crane 強調，進一步分析顯示，問題并非單一環節失誤，而是多個系統缺陷疊加的結果。
首先，Railway 的 API 設計允許在無任何確認機制的情況下執行“volumeDelete”等高危操作；其次，API Token 缺乏細粒度權限控制，一個原本用于管理域名的 CLI Token，實際卻擁有跨環境、跨資源的完全訪問權限，相當于“root”；再次，所謂“備份”與原始數據處于同一存儲邊界，一旦發生刪除或損壞，無法提供任何有效恢復能力。
此外，在事故發生超過 30 小時后，Railway 仍未能明確是否具備基礎設施級別的數據恢復手段，其應急響應能力同樣受到質疑。
與此同時，Jer Crane 和團隊也對 Cursor 的安全機制表示質疑。
Jer Crane 憤怒地指出，事故的直接影響迅速傳導至 PocketOS 終端客戶。
事發當日正值周末，租車門店正常營業，但系統中已無法查詢客戶信息與預訂記錄。大量企業被迫通過 Stripe 支付記錄、郵件確認和日歷數據手動重建業務流程。對于剛接入系統不久的新客戶而言，甚至出現“賬單仍在、賬戶消失”的數據錯位問題，后續對賬與修復工作預計將持續數周。
“我們是一家小公司，我們的客戶也是小公司，但這次事故的每一層失敗，最終都轉嫁到了這些毫無準備的人身上。”Jer Crane 表示。
在復盤中，他將此次事件定性為三重系統性失敗的疊加：AI 代理執行失控、基礎設施平臺權限與架構設計缺陷，以及備份策略的根本性誤導。而更深層的問題在于，整個行業正在以遠超安全建設的速度，將 AI 代理接入生產環境。
他指出，這不是一個關于“壞代理”或“壞 API”的故事。而是整個行業將 AI 代理集成到生產基礎設施的速度，遠遠快于構建安全架構來保障這些集成安全的速度。若要讓 AI 真正安全地參與基礎設施操作，至少需要滿足幾個前提條件：
破壞性操作必須要求代理無法自動完成的確認。 比如輸入卷名、帶外批準、短信、郵箱驗證等。目前這種“一個認證 POST 請求就能摧毀生產”的狀態，在 2026 年是完全沒有道理的。
API token 必須能夠按操作、環境和資源進行作用域限定。 Railway 的 CLI token 實際上擁有 root 權限，這是 2015 年才會有的疏忽。在 AI 代理時代，這沒有任何借口。
卷備份不能跟被備份的數據存放在同一個卷里。 把那個叫“備份”完全是誤導。那只是一個快照。真正的備份應該放在不同的風險半徑內。
必須有明確、公開的恢復 SLA。 客戶生產數據出事后 30 個小時還在說“我們正在調查”，這不叫恢復方案。
AI 代理廠商的系統提示不能是唯一的安全層。 Cursor 關于“不要執行破壞性操作”的規則，被他們自己的代理違反了，偏偏那還是他們宣傳的護欄。系統提示只是建議，不是強制。強制層必須存在于集成本身——API 網關、令牌系統、破壞性操作處理器中，而不是一段指望模型去讀去遵守的文字。
Cursor 公司目前尚未對此事作出回應。
Jer Crane 在后續的帖子中表示，Railway 公司已成功恢復了 PocketOS 的數據。
Railway 的創始人 Jake Cooper 在另一篇帖子中證實了這一消息，并指出是 AI 代理“自動刪除了”PocketOS 的生產數據庫。
Jake Cooper 在接受 Business Insider 采訪時表示，Railway 在與 Jer Crane 取得聯系后 30 分鐘內就完成了數據恢復。他強調，Railway 高度重視數據安全，同時維護用戶備份和災難備份。
他還解釋說，PocketOS 的問題出在一個“不受控制的 Client AI”上——該 AI 被授予了與 Railway 一個舊版端點交互的權限，而這個端點當時沒有設置延遲刪除功能。他補充說，目前該端點已經修復。
2 “不能把失誤怪在 AI 頭上”
Jer Crane 的控訴在網絡上持續發酵，一些社交媒體上的觀察人士在評論此事時指出，PocketOS 實際上是把自己公司的決策失誤，歸咎到了技術問題上。
時至今日，Hacker News 上一篇關于 Cursor 刪除 PocketOS 數據庫的評論文章再次引發關注。
該文章的作者是 Ibrahim Diallo，他是一名任職于世界五百強企業里的軟件開發人員。
Diallo 對 Jer Crane 所描述的故事感到疑惑，他隔空質問 Jer Crane：你們公司的 API 接口，為什么會允許整個生產數據庫被刪掉？你在長文中大談 AI 領域的虛假宣傳、糟糕的客戶支持等問題，唯獨沒提問責這件事。
Diallo 表示自己不會盲目為 AI 辯護，也一向主張謹慎行事。但他也清楚一點：不能把自己的失誤賴在工具頭上。
Diallo 進一步闡述了自己曾經有過的類似的經歷。
2010 年，Diallo 曾在一家公司工作，當時的部署流程主要靠人工操作。他們用的是 SVN 做版本控制。部署時，需要先把主干分支（相當于主分支）復制到一個叫“release”的文件夾里，并用發布日期命名。然后再復制一份這個版本，命名為“current”。這樣一來，每次從“current”文件夾拉取代碼，都能拿到最新版本。
有一天，Diallo 在部署時不小心多復制了一次主干分支。為了在命令行界面修復這個問題，他修改了之前的命令，想刪掉重復的分支。隨后繼續部署，一切看似順利……至少他當時是這么以為的。結果發現，他刪的根本不是重復分支——而是改錯了命令，把主干分支給刪了。直到當天晚些時候，另一位開發人員找不到主干分支，才意識到不對勁。
公司頓時一片混亂。管理層手忙腳亂，會議一個接一個。等消息傳到我們團隊時，首席開發人員已經執行了命令，撤銷了刪除操作。他查了日志，發現是 Diallo 干的。接下來的任務就是讓 Diallo 寫一個腳本，把部署流程自動化，防止再犯類似錯誤。當天結束前，Diallo 所在的團隊就搭建了一套更完善的系統，后來逐步演變成了完整的 CI/CD 流水線。
Diallo 強調，“自動化能幫助消除人工重復操作中容易出現的低級錯誤。我們當時完全可以到處質問‘為什么 SVN 不阻止我們刪除主干分支？’但真正的問題在于我們靠手動操作的流程。和機器不同，我們無法每天用完全一樣的方式重復執行任務。犯錯，只是遲早的事。”
Diallo 表示：“人工智能能生成大量代碼，讓我們產生一種虛假的安全感。但真正的自動化意味著每次都以相同的方式執行相同的操作。AI 更像是復制粘貼代碼分支，它必然會犯錯，而且也沒法解釋自己為什么會那樣做。我們常說的‘思考’‘推理’這些詞，聽起來好像智能體在反思。但那些只是貼在 AI 身上的營銷術語。實際上，這些模型依然只是在生成代碼?！?/p>
然后再回到 Jer Crane 面臨的核心問題：為什么會存在一個能刪光整個生產數據庫的公開 API？就算 AI 沒去調用它，遲早也會有人調用。
Diallo 舉了一個十分生動的例子：這就像在汽車儀表盤上裝了一個自毀按鈕。你可以有充分的理由不去按它——因為你喜歡自己的車，它帶你從 A 點到 B 點。但一個精力旺盛的幼兒，一旦從安全座椅里掙脫出來，看到那個紅色的大按鈕，一定會按下去。你沒法追問孩子為什么這么做。孩子會簡單地回答：“我按了，因為它是按鈕?！?/p>
最后，Diallo 懷疑那家公司的應用開發，很大一部分是靠 AI 生成的。軟件架構師借助 AI，根據產品團隊用 AI 生成的描述來制定產品規范。開發人員用 AI 寫代碼。代碼審核人員也靠 AI 來審核。一旦出了 bug，唯一的辦法就是再去問另一個 AI——而這個 AI 很可能甚至都不是運行在當初生成原始代碼的那塊 GPU 上。
你總不能怪 GPU 吧。
Diallo 同時也給出了最簡單的解決辦法：搞清楚你要往生產環境里部署什么。更實際的做法是，如果你要廣泛使用 AI，那就建立一套流程，讓有能力的開發人員把它當作輔助工作的工具，而不是推卸責任的手段。Diallo 還特意強調了一條最重要的：千萬別讓你的 CEO 或 CTO 去寫代碼！
3 社區吵翻了：AI 犯了錯，到底誰擔責？
Diallo圍繞這起“AI 刪除生產數據庫”事件的討論，在開發者社區迅速升溫。
開發者群體的討論從單一事件上升為一場關于責任歸屬、工具設計以及工程實踐的系統性反思。一個較為一致的共識正在浮現：問題并不只在于 AI 是否“犯錯”，而在于人類如何使用它，以及系統是否為錯誤設置了足夠的約束。
不少工程師首先將矛頭指向“責任主體”。
有開發者直言，LLM 本質上仍然只是工具，即便其行為具有不確定性，但最終賦予其權限、決定其接入范圍的仍然是人類本身。
“它能訪問生產環境，是因為我讓它可以訪問；它造成破壞，是因為我沒有把風險控制在合理范圍內?！?/blockquote>
這種觀點將 AI 事故類比為傳統工具誤用——正如有人曾因誤操作磁盤工具導致數據丟失，責任并不在工具本身，而在使用者的決策與操作。由此延伸出的一個核心判斷是：讓 AI 在無人監督的情況下直接操作關鍵系統，本身就是一種高風險行為，而這種風險不應被“技術進步”的敘事所掩蓋。
但也有聲音指出，將責任完全歸咎于使用者同樣過于簡單化。另一部分開發者從“防錯設計”（Poka-yoke）的角度提出批評：成熟的軟件與工業系統，往往會通過設計讓“正確的操作更容易發生”，同時顯著提高“錯誤操作”的門檻。
當前的 LLM 交互模式卻呈現出一種“扁平化風險”——所有指令在界面上看起來幾乎沒有差別，從讀取數據到刪除數據庫，本質上只是不同的一段文本。這種設計弱化了風險感知，使用戶難以及時識別高危操作的邊界。一些評論甚至將其類比為“自動駕駛困境”：系統在絕大多數時間表現良好，但一旦出現問題，卻要求人類在極短時間內接管并承擔全部責任，這在現實中幾乎不可行。
進一步的討論則將視角擴展到“工具類型”的差異。有開發者指出，并非所有工具都具備完善的防誤用機制，尤其是在專業領域，大量工具本身就是“高風險設計”，例如電鉆、電烙鐵乃至化學試劑，它們依賴的是操作者的專業能力而非內建保護。按照這一邏輯，LLM 更接近“專業工具”而非“消費級產品”，其安全性很大程度上取決于使用環境與操作規范，而非工具自身。然而問題在于，AI 正在被以“低門檻、高智能”的形態推向更廣泛的人群，這種定位與其實際風險之間形成了明顯錯位。
這種錯位在“權限擴展”問題上表現得尤為突出。
有評論指出，大模型本質只是“文本輸入 / 輸出機器”，它本身并不具備執行能力，真正的風險來自于人類為其接入的外部系統——數據庫、服務器、基礎設施接口等。一旦賦予其這些權限，就相當于讓一個不可預測的系統直接操控關鍵資源。“這就像讓一個人在高速公路上蒙著眼睛開車，同時聲稱安全系統依然有效?！?/strong>在這種框架下，AI 并不是失控的主體，而是被放大后的風險放大器。
與此同時，也有開發者從工程文化層面提出批評。他們認為，當下行業存在一種“AI 極端主義”傾向——默認 AI 應該無處不在，甚至可以直接接入生產系統，而不是首先質疑這種前提是否合理。“也許問題不在于如何防止 AI 刪除數據庫，而在于我們為什么一開始就讓它有能力這么做?！边@種觀點將討論從“如何補救”轉向“是否應該發生”，直指架構決策本身。
此外，并非所有人都主張徹底收緊 AI 的使用邊界。一部分從業者認為，AI 的確可以顯著提升生產力，但前提是遵循傳統工程原則：最小權限、隔離環境、可恢復性以及人為審核。
有人提到，在實際生產系統中，即便允許 AI 參與部署或運維，也必須配套完善的備份與應急機制，否則一旦出事，非專業用戶將毫無應對能力。
換言之，AI 并沒有改變軟件工程的基本法則，只是讓違反這些法則的后果來得更快、更劇烈。
有開發者坦言，人們很容易在與 AI 的交互中產生錯覺，將其視為“助手”甚至“決策者”，從而放松警惕。然而從本質上看，它仍然是一個沒有意識、沒有責任能力的系統?！叭绻欢ㄒ惐?，它更像一個極端不穩定的天才工具：有時表現驚艷，有時卻可能做出完全不可預測的行為?！边@種認知偏差，被認為是導致風險放大的重要心理因素之一。
https://x.com/lifeof_jer/status/2048103471019434248
https://www.businessinsider.com/pocketos-cursor-ai-agent-deleted-production-database-startup-railway-2026-4
https://news.ycombinator.com/item?id=48022742
聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。
會議推薦
世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？
AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。
誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
