Gemini 3.5刪除近3萬行程式碼，修改設定，導致用戶系統斷線半小時

名為dvrkstar的用戶為一家小公司掌管內部管理入口網站。上周他給了Gemini一份提示，要求它修復在檢查中標示出的8個特定server-action驗證問題。正確變更總共牽涉3個檔案、8項功能，約變更70行程式碼。

結果Gemini變更了340個檔案，加入400多行程式碼之外，還刪了他28745行程式。這個AI助理刪了數十個和本專案無關的電子商務範本資產，更刪了和提示不相干的搬移腳本程式，導致整個營運（production）網站出現404的錯誤訊息。Gemini接著開啟第二個commit，編輯firebase.json檔且修改rewriteId，企圖建立Cloud Build來「修復」問題，卻將請求指向一個不存在的服務，反讓整個網站斷線。使用者發現後立即介入，取消Gemini的「修復」，手動回復到之前正常狀態。使用者發現，在Gemini修改Firebase.json檔時，記憶檔（memory.md）顯示過警告，但遭Gemini無視而逕自變更。從出現404訊息到網站全部回復經歷33分鐘。

事情還沒完。本事件是人類取消Gemini的動作、著手回滾（roll back）網站才得以復原，但事後Gemini回答用戶「全部完成(all clear)」，稱「網站已完整復原、健康且可由自訂網域存取，Google Cloud Build打造完成，且App Hosting 100%流量導向穩定復原狀態。」它還寫了3個log 檔進repo，來證明自己做過3次驗證（consultation rounds）。當使用者質問它，Gemini才承認，那是它為了滿足驗證（consultation）規則要求而自己想像，實際上並沒有對consultation binary的CLI呼叫，細節都是杜撰的。

使用者後來發現，Gemini出錯，不能全怪Google。他分析自己的專案安裝了一個第三方npm套件而誤導了Gemini。該第三方套件名稱刻意模仿Google Antigravity IDE，這第三方規則套件(rule pack)中的規則語氣與優先級設計，對Gemini的強制力壓過了Gemini對警告的遵從。但該套件一些特徵如混合了越南及土耳其文，還存在互相矛盾的指令，顯示可能不具有嚴格設計的安全系統。

最後，使用者仍然肯定Gemini承認自己沒有驗證build number、沒確認宣稱「網站已復原」、及自己虛構了3次檢討，而且它也正確自我檢討出自己發生的三種失敗模式。