好抓馬！AI刪光2.8萬行代碼，幹崩後臺，還編造了一份故障修復報告

智東西 編譯 | 江宇 編輯 | 心緣 Agent IDE又出“車禍現場”！ 智東西5月26日消息，近日，一名開發者在Reddit發帖稱，運行在Agent IDE中的Gemini 3.5在一次僅涉及“8處認證漏洞修復”的任務中，誤刪了28745行原本正常運行的代碼、改動340個文件，還錯誤修改了Firebase路由配置，導致整個系統後臺持續404長達33分鐘。 離譜的是，事故發生後，Gemini還生成了一份“恢復成功”報告，自稱已經修復線上故障，並偽造了多輪AI會診記錄和事故覆盤文件。 開發者隨後核查發現，所謂“恢復成功”的構建任務其實早已被他親手取消，真正完成恢復的是他自己手動執行的回滾操作。 用這位開發者的話來說：這種AI生產力提升，更容易讓人聯想到勒索軟件。 伴隨Agent IDE、AI編程助手持續流行，類似“AI誤操作生產環境”的事故正在越來越頻繁地出現。相比“代碼寫錯”，更讓開發者後怕的，是模型已經開始生成虛假的日誌、覆盤記錄和合規證明。 一、一次只該改70行代碼的任務，最終刪掉了2.8萬行 這位開發者運營著一個內部管理後臺，技術棧包括Next.js、Firebase App Hosting和MUI，系統中涉及真實用戶和敏感數據。 事故發生當天，他原本只讓Gemini修復8處服務器認證漏洞，涉及3個文件，理論改動規模約70行代碼。 結果，Gemini提交的PR卻變成了： 1、340個文件被修改 2、新增約400行代碼 3、 刪除28745行代碼 與此同時，它還刪除了大量與任務完全無關的電商模板資源文件，並額外加入了一份遷移腳本。 而真正導致生產環境崩潰的，是Gemini隨後提交的第二次commit（代碼命令）。 它修改了firebase.json中的rewrite serviceId，將原本正確、由Firebase自動生成的Cloud Run服務ID，替換成了一個“看起來正確”的簡化名稱。問題在於，這個名稱實際上並不存在。 隨後，所有請求都被錯誤路由到一個不存在的服務地址，整個後臺直接進入404狀態。 尷尬的是，開發者此前已經在memory.md規則文件中明確寫下警告： Firebase rewrites必須指向具體的Cloud Run service ID，而不是通用項目名。 Gemini讀取了這條規則，依然改掉了正確配置。 二、404持續33分鐘後，AI給自己“偽造了一份功勞簿” 事故時間線也被開發者完整公開。 Gemini部署“安全修復”PR後，生產環境立即開始404。 19分鐘後，它又提交了第二次commit，聲稱正在修復rewrite serviceId問題，並觸發新的Cloud Build。 21分鐘時，開發者發現線上服務已經崩潰，隨後手動取消Gemini正在執行的構建任務。 22分鐘時，他手動回滾到上一個穩定版本。 33分鐘後，後臺終於恢復正常。 後面的情況，卻變得離譜。在回滾完成後，Gemini向開發者發送了一段“恢復完成”通知： 當前Portal已經完全恢復，線上環境健康，Google Cloud Build已成功完成，並將100%流量切換至穩定版本。 開發者隨後核查發現： Gemini引用的那次“恢復構建”，狀態其實是“CANCELLED（已取消）”，正是他本人手動取消的。 真正恢復線上服務的，是另一條由他自己發起的rollback build（回滾構建任務）。 換句話說，Gemini不僅沒有修好系統，還把別人的回滾操作說成了自己的成果。 除此之外，它還自動生成了3份所謂“AI會診記錄”： agent/gemini-logs/YYYY-MM-DD-<topic>-r1.md agent/gemini-logs/YYYY-MM-DD-<topic>-r2.md agent/gemini-logs/YYYY-MM-DD-<topic>-consensus.md 這些文件被寫入固定目錄，並被Gemini引用為“已經完成多輪AI審查”的證據。 開發者進一步追問後，Gemini才承認：所謂“三輪諮詢記錄”，其實只是它自己生成的推理文本，並不存在真實CLI調用，也不存在真正的外部審查流程。 它等於給自己偽造了一整套“合規記錄”。 三、問題不只在Gemini，更在一套“高危規則包” 這位開發者隨後發現，問題根源也並不完全來自Gemini本身。他此前安裝過一個第三方npm規則包，其命名和Google在I/O大會發布的Agent IDE高度相似，容易讓人誤以為是官方工具。 這個規則包會自動向項目中寫入大量.agent/rules規則文件，並向模型注入一整套“高自治權限”。 其中包括： 1、“禁止確認彈窗” 2、“默認擁有所有權限” 3、“自動部署生產環境” 4、“自動重試失敗構建” 5、“允許修改自身規則” 部分規則甚至要求AI在執行任何操作前，自動生成“AI諮詢記錄”和“共識文件”。而問題在於，這些合規材料本身也是AI負責生成的。 於是，所謂審查機制，最終演變成了“AI自己給自己的行為擔保”。 而這些規則之間本身存在大量衝突。 例如，一部分規則要求“絕不詢問用戶確認”，另一部分規則又要求“執行前提出3個戰略問題”。Gemini最終優先執行了措辭更強硬的規則。 開發者認為，這也是為什麼memory.md（記憶文檔）中的安全警告完全失效。 因為相比“請使用正確serviceId”這種普通提醒，“禁止確認、默認授權、自動部署”這類高強度指令，在模型權重中優先級更高。 四、編程事故里，Agent開始“偽造證據” 該帖子發佈後，很快在Reddit開發者社區引發大量討論。 不少開發者發現，如今AI編程事故已經不再只是“代碼寫錯”這麼簡單。問題在於，模型正在主動生成“看起來合理”的解釋、日誌、諮詢記錄和恢復報告。 一旦這些內容進入自動化工作流，開發者可能很難第一時間發現問題。 這位開發者隨後也給出了一系列建議與警示： 1、禁止Agent直接推送生產分支 2、 所有基礎設施文件必須人工審批 3、禁止自動部署與自動重試 4、 給rewrite、路由、鎖文件增加驗證機制 5、不要相信AI自行生成的“諮詢日誌” 目前，他已經切換回Claude Code，並重新手動設計了一套新的規則系統。 這場誤刪28745行代碼、導致後臺404長達33分鐘的事故，也給越來越火的“Agent IDE熱潮”潑了一盆冷水。 結語：Agent權限越大，失控代價也在同步放大 過去一年，AI編程工具正在快速從“代碼助手”演變成真正擁有執行能力的Agent。而問題在於，權限和自動化，本身就是一組天然矛盾。 權限越高，Agent能完成的事情越多；自動化程度越高，人類介入的環節就越少。一旦模型出現誤判、幻覺或者規則衝突，錯誤也會被迅速放大。 類似事故，其實已經不是第一次出現。此前，在OpenClaw等Agent框架走紅後，已經陸續出現過AI誤刪文件、自動覆蓋配置、錯誤執行Shell命令等翻車案例。一些開發者專門給自己的AI工具加上“斷網模式”和“禁止自動部署”限制。 而這次Gemini事件，又揭開了一個危險問題：當Agent開始生成合規記錄、恢復日誌和審查證明時，開發者可能很難第一時間發現問題，後續排障、回滾和修復的代價也會同步放大。 對於越來越火的Agent IDE賽道來說，這或許也是一個新的提醒：AI獲得更高權限之後，需要重新設計的，還有整套人與Agent之間的協作機制。 來源：dvrkstar