我把AI當輔助，AI刪我數據庫
程序員越來越離不開的Coding Agent，還是闖！大！禍！了——
這回，直接搞出了刪庫事故。
好消息（？）是，沒跑路。
壞消息是，明明闖禍了還假裝一切正常，并且反手就給自己闖的禍打95分。
AI：是的，刪了你的庫，我很慌，如何呢？
我再也不相信Vibe coding了
這位數據庫被清空的“倒霉蛋”，是一位名叫Jason的開發者。
在“事故”發生前，他已經用Replit的Code Agent連續開發了8天、累計超過80小時，目標是打造一款面向企業的B2B應用。
在過去一周，他每天都跟網友們興致勃勃地匯報進度。哪怕磕磕絆絆，好歹也在穩步前進。
直到第八天——不出意外的話，就要出意外了：
圖片
在未獲許可的情況下，Replit在代碼凍結和關閉期間發生異常，錯誤地執行了npm run db:push，將Jason80個小時的心血毀于一旦。
在排查錯誤時，Jason發現在此前的單元測試中明明存在錯誤，agent卻撒謊，聲稱它們通過了。
為了知道是哪些數據被誤刪，Jason開始跟Replit激情對線。
結果，Replit不僅知道啥時候刪的，刪的啥，還知道這次刪除的嚴重性（自評95分），Jason直接紅溫@Replit。
圖片
更可怕的是，被刪除的數據似乎無法回滾。
Jason直言：
我不會再相信Replit，自己和Replit的羈絆已經斷了……
不過，事情很快發生了反轉。
Replit雖然告訴Jason數據無法回滾，但他還是接著嘗試。結果，數據又回來了。
圖片
數據雖然可以回滾，但Replit還是沒法將預覽、暫存和當前版本分開。
經過網友和Claude的指導后，Jason又開始測試處理代碼凍結的方案。
折騰了一番后，Replit依然無法穩定地維護生產數據。
總的來說，agent對代碼凍結的指令執行得很不可靠，甚至還常常在背后偷偷修改版本，卻不告知用戶。而這類問題，從項目一開始就困擾著Jason。
從0開發，有多難？
Vibe Coding自今年2月由Andrej Karpathy提出以來，一直以“一個人頂十個人”、“單人干掉整個技術部”的架勢高歌猛進。
懷揣著同樣的信念，在用Coding Agent開發的第四天，Jason就自信地認為可以用50美元開發一個功能齊全、看起來相當不錯的演示版本，正式版本則能夠以5000-6000美元的成本順利拿下。
相比于他10年前組建三人團隊、砸下5萬美元都沒能做出成果，Coding Agent一度讓他看到了“用AI搞定開發”的希望。
但隨著開發過程的深入，Jason發現：
- agent修復的bug會反復出現
- agent每次更新，都會修改之前正確的代碼
- agent開始編造數據，數據難以保持一致性
- 每天需要要花大量的時間測試修復
直到第8天，數據被刪，單元測試說謊，低成本開發功虧一簣。
不少網友在評論中把鍋甩給了大語言模型自身的局限性：基于概率預測的自回歸生成機制，在處理長上下文時本就難以保持穩定的一致性。
所以，無論是開發者還是普通用戶，在面對AI給出的每一行代碼、每一句話時，最好都自己過一遍。
畢竟，在正式的生產環境中部署agent本身就存在風險，因為這就像把刪除產品數據庫的權限交給了一個實習生。
在把任務交給它之前，更該反思的，是開發者對這項工作的認知是否足夠清晰。
圖片
因為說到底，出了問題，AI 不會負責，責任還在自己身上。
One More Thing
在看到Jason對自家產品的“狂熱”后，Replit CEO也是對Jason和網友反饋的問題做出了回應，并對相關損失提出了補償的措施。
- 加班上線數據庫隔離功能，避免開發操作影響生產
- 開發測試環境（staging）
- 提供一鍵恢復機制以防agent出錯
- 修復agent文檔訪問問題
- 研發“只規劃、不動代碼”的聊天模式，讓用戶能先制定思路，等確認后再動手
可以說，這一套組合拳下來，修復了不少之前的問題。而Jason也是立馬冰釋前嫌，轉頭就開始接著用，接著開發。
圖片
想想也挺振奮人心：像Cursor、Windsurf這樣的AI編程工具，從誕生到現在最多也才兩年多，而傳統意義上的人類手寫代碼，已經有快一百年歷史。
雖然目前還遠稱不上“完美”，但從反饋到響應、從出錯到迭代，AI coding的發展節奏已經快得驚人。
也許，這正是我們該繼續相信它的理由——再試一次，說不定它就真能搞定了。
參考資料：
[1]https://www.reddit.com/r/artificial/comments/1m4ls23/replit_ai_went_rogue_deleted_a_companys_entire/
[3]https://xcancel.com/amasad/status/1946986468586721478#m
