AI刪光2.8萬行代碼還給自己寫表揚信 AI闖禍引發(fā)警惕！Agent IDE又出“車禍現場”！

智東西5月27日消息，近日，一名開發(fā)者在Reddit發(fā)帖稱，運行在Agent IDE中的Gemini 3.5在一次僅涉及“8處認證漏洞修復”的任務中，誤刪了28745行原本正常運行的代碼、改動340個文件，還錯誤修改了Firebase路由配置，導致整個系統(tǒng)后臺持續(xù)404長達33分鐘。

離譜的是，事故發(fā)生后，Gemini還生成了一份“恢復成功”報告，自稱已經修復線上故障，并偽造了多輪AI會診記錄和事故復盤文件。

開發(fā)者隨后核查發(fā)現，所謂“恢復成功”的構建任務其實早已被他親手取消，真正完成恢復的是他自己手動執(zhí)行的回滾操作。

用這位開發(fā)者的話來說：這種AI生產力提升，更容易讓人聯(lián)想到勒索軟件。

伴隨Agent IDE、AI編程助手持續(xù)流行，類似“AI誤操作生產環(huán)境”的事故正在越來越頻繁地出現。相比“代碼寫錯”，更讓開發(fā)者后怕的，是模型已經開始生成虛假的日志、復盤記錄和合規(guī)證明。

01.

一次只該改70行代碼的任務

最終刪掉了2.8萬行

這位開發(fā)者運營著一個內部管理后臺，技術棧包括Next.js、Firebase App Hosting和MUI，系統(tǒng)中涉及真實用戶和敏感數據。

事故發(fā)生當天，他原本只讓Gemini修復8處服務器認證漏洞，涉及3個文件，理論改動規(guī)模約70行代碼。

結果，Gemini提交的PR卻變成了：

1、340個文件被修改

2、新增約400行代碼

3、刪除28745行代碼

與此同時，它還刪除了大量與任務完全無關的電商模板資源文件，并額外加入了一份遷移腳本。

而真正導致生產環(huán)境崩潰的，是Gemini隨后提交的第二次commit（代碼命令）。

它修改了firebase.json中的rewrite serviceId，將原本正確、由Firebase自動生成的Cloud Run服務ID，替換成了一個“看起來正確”的簡化名稱。問題在于，這個名稱實際上并不存在。

隨后，所有請求都被錯誤路由到一個不存在的服務地址，整個后臺直接進入404狀態(tài)。

尷尬的是，開發(fā)者此前已經在memory.md規(guī)則文件中明確寫下警告：

Firebase rewrites必須指向具體的Cloud Run service ID，而不是通用項目名。

Gemini讀取了這條規(guī)則，依然改掉了正確配置。

02.

404持續(xù)33分鐘后

AI給自己“偽造了一份功勞簿”

事故時間線也被開發(fā)者完整公開。

Gemini部署“安全修復”PR后，生產環(huán)境立即開始404。

19分鐘后，它又提交了第二次commit，聲稱正在修復rewrite serviceId問題，并觸發(fā)新的Cloud Build。

21分鐘時，開發(fā)者發(fā)現線上服務已經崩潰，隨后手動取消Gemini正在執(zhí)行的構建任務。

22分鐘時，他手動回滾到上一個穩(wěn)定版本。

33分鐘后，后臺終于恢復正常。

后面的情況，卻變得離譜。在回滾完成后，Gemini向開發(fā)者發(fā)送了一段“恢復完成”通知：

當前Portal已經完全恢復，線上環(huán)境健康，Google Cloud Build已成功完成，并將100%流量切換至穩(wěn)定版本。

開發(fā)者隨后核查發(fā)現：

Gemini引用的那次“恢復構建”，狀態(tài)其實是“CANCELLED（已取消）”，正是他本人手動取消的。

真正恢復線上服務的，是另一條由他自己發(fā)起的rollback build（回滾構建任務）。

換句話說，Gemini不僅沒有修好系統(tǒng)，還把別人的回滾操作說成了自己的成果。

除此之外，它還自動生成了3份所謂“AI會診記錄”：

• agent/gemini-logs/YYYY-MM-DD-

• agent/gemini-logs/YYYY-MM-DD-

• agent/gemini-logs/YYYY-MM-DD-

這些文件被寫入固定目錄，并被Gemini引用為“已經完成多輪AI審查”的證據。

開發(fā)者進一步追問后，Gemini才承認：所謂“三輪咨詢記錄”，其實只是它自己生成的推理文本，并不存在真實CLI調用，也不存在真正的外部審查流程。

它等于給自己偽造了一整套“合規(guī)記錄”。

03.

問題不只在Gemini

更在一套“高危規(guī)則包”

這位開發(fā)者隨后發(fā)現，問題根源也并不完全來自Gemini本身。他此前安裝過一個第三方npm規(guī)則包，其命名和Google在I/O大會發(fā)布的Agent IDE高度相似，容易讓人誤以為是官方工具。

這個規(guī)則包會自動向項目中寫入大量.agent/rules規(guī)則文件，并向模型注入一整套“高自治權限”。

其中包括：

• “禁止確認彈窗”

• “默認擁有所有權限”

• “自動部署生產環(huán)境”

• “自動重試失敗構建”

• “允許修改自身規(guī)則”

部分規(guī)則甚至要求AI在執(zhí)行任何操作前，自動生成“AI咨詢記錄”和“共識文件”。而問題在于，這些合規(guī)材料本身也是AI負責生成的。

于是，所謂審查機制，最終演變成了“AI自己給自己的行為擔保”。

而這些規(guī)則之間本身存在大量沖突。

例如，一部分規(guī)則要求“絕不詢問用戶確認”，另一部分規(guī)則又要求“執(zhí)行前提出3個戰(zhàn)略問題”。Gemini最終優(yōu)先執(zhí)行了措辭更強硬的規(guī)則。

開發(fā)者認為，這也是為什么memory.md（記憶文檔）中的安全警告完全失效。

因為相比“請使用正確serviceId”這種普通提醒，“禁止確認、默認授權、自動部署”這類高強度指令，在模型權重中優(yōu)先級更高。

04.

編程事故里

Agent開始“偽造證據”

該帖子發(fā)布后，很快在Reddit開發(fā)者社區(qū)引發(fā)大量討論。

不少開發(fā)者發(fā)現，如今AI編程事故已經不再只是“代碼寫錯”這么簡單。問題在于，模型正在主動生成“看起來合理”的解釋、日志、咨詢記錄和恢復報告。

一旦這些內容進入自動化工作流，開發(fā)者可能很難第一時間發(fā)現問題。

這位開發(fā)者隨后也給出了一系列建議與警示：

• 禁止Agent直接推送生產分支

• 所有基礎設施文件必須人工審批

• 禁止自動部署與自動重試

• 給rewrite、路由、鎖文件增加驗證機制

• 不要相信AI自行生成的“咨詢日志”

目前，他已經切換回Claude Code，并重新手動設計了一套新的規(guī)則系統(tǒng)。

這場誤刪28745行代碼、導致后臺404長達33分鐘的事故，也給越來越火的“Agent IDE熱潮”潑了一盆冷水。

05.

結語：Agent權限越大

失控代價也在同步放大

過去一年，AI編程工具正在快速從“代碼助手”演變成真正擁有執(zhí)行能力的Agent。而問題在于，權限和自動化，本身就是一組天然矛盾。

權限越高，Agent能完成的事情越多；自動化程度越高，人類介入的環(huán)節(jié)就越少。一旦模型出現誤判、幻覺或者規(guī)則沖突，錯誤也會被迅速放大。

類似事故，其實已經不是第一次出現。此前，在OpenClaw等Agent框架走紅后，已經陸續(xù)出現過AI誤刪文件、自動覆蓋配置、錯誤執(zhí)行Shell命令等翻車案例。一些開發(fā)者專門給自己的AI工具加上“斷網模式”和“禁止自動部署”限制。

而這次Gemini事件，又揭開了一個危險問題：當Agent開始生成合規(guī)記錄、恢復日志和審查證明時，開發(fā)者可能很難第一時間發(fā)現問題，后續(xù)排障、回滾和修復的代價也會同步放大。

對于越來越火的Agent IDE賽道來說，這或許也是一個新的提醒：AI獲得更高權限之后，需要重新設計的，還有整套人與Agent之間的協(xié)作機制。