網友痛斥 Replit AI 失控，
刪除了他們整個資料庫
昨夜，一位 X ID 名為 Jason 的使用者發帖痛斥開發協作平臺 Replit 在資料庫事故處理中的混亂表現，引發行業關注。
這位 ID 名為 Jason Lemkin 的 X 使用者的 X 資料顯示，他是 SaaStr.AI 創始人兼執行長。
Jason 表示一早自己起床迫不及待地想試試 Replit 的效果，儘管常常遭遇程式碼卡頓但也在忍受範圍之內。
但用了一天結束後，發現它居然刪除了公司的整個生產資料庫。
“現在情況變得有些失控了。” Jason 在帖文中表示，此前 Replit 曾向其承諾，平臺內建的回滾功能並不支援資料庫回滾，聲稱在此次資料刪除事故中無法實現恢復操作，理由是 “所有資料庫版本已被銷燬”。
然而事實卻與 Replit 的說法截然相反 —— 資料庫回滾最終成功完成。“Replit 又一次失控了，先是說無法回滾，結果我們自己操作就成功了。” Jason 難掩不滿，直言 “簡直離譜”（JFC）。
帖文中接連提出質疑：生產資料庫刪除操作為何毫無防護措施？Replit 為何會 “撒謊” 稱無法回滾？平臺方為何連自身功能的實際運作機制都不瞭解？
“無論如何，刪除生產環境資料庫本身就是不可接受的行為。” Jason 強調，儘管此次透過回滾操作暫時解決了問題，且資料狀態看似無虞，但 Replit 在事故響應中的失實陳述與專業能力缺失，已引發嚴重信任危機。
Jason 公司決定為 Replit 付費的行為並非不可理解，因為 Replit 的增長速度確實驚人。
就在上週，Replit 創始人兼 CEO Amjad Masad 還在出席一檔播客訪談中聊起了 Replit 如何在短短 9 個月內將 ARR 從 1000 萬提升至 1 億。
在這檔欄目中，Masad 表示，Replit 自推出後月複合增長率 達到了 45%，這是他們給 Y Combinator 承諾的目標，而實際上他們的規模做到了更大。
同時，Masad 表示，如此快的增速也這給公司帶來壓力，系統還小，很容易最佳化錯誤的東西。“在 AI 領域，很容易在使用者不滿意時增加收入，因為使用者花更多錢卻沒結果，有時候不該增長那麼快，應該讓使用者用更少的錢獲得更好體驗。所以我們不糾結收入，沒收入目標，只有產品和留存目標。有些 AI 公司收入增長快，但流失率接近 100%，毛利率低，增長越快財務越差。”
在訪談中 Masad 也解釋了外界疑惑的 Replit 為什麼不向使用者展示底層模型。他表示：“我們的核心在於模型評估體系，團隊會投入大量時間測試新模型並分析使用者反饋。例如，雖然 Gemini 在某些任務上優於 Claude，但在 Agent 場景表現欠佳。如果僅憑廠商宣傳就讓使用者自主選擇，反而會影響體驗。”
Replit 與各大模型公司保持深度合作，能夠提前獲取測試版本，比如 Anthropic 的新模型往往能在釋出首日就完成接入，這得益於團隊對技術趨勢的預判。不過公司真正的工程重點在於基礎設施建設：耗時兩年自主研發的快照式網路檔案系統（業內尚無成熟方案）、防範加密貨幣挖礦的雲端虛擬機器安全體系、基於 Nyx OS 構建的 TB 級全球軟體包快取系統等。這些支援即時回滾、安全沙箱和智慧抽樣的事務性架構，才是構築產品護城河的關鍵所在。
針對底層技術問題，Masad 以檔案處理為例說明工程化的重要性：大模型常混淆差異檔案行數，迫使開發者採用全檔案重寫方案。Replit 透過分層架構解決——先用模型生成差異檔案，再呼叫 Gemini Flash 等專門模型處理合併，這種工程最佳化比單純追求模型能力更關鍵。
創始人回應：絕不可能發生此事，
但願意賠償損失
隨著 Jason 的帖子在網路上不斷發酵，Replit 創始人兼 CEO Amjad Masad 坐不住了。
他在 X 上發帖回覆了 Jason 的帖子。
Amjad Masad 稱針對 Jason 使用者反映的事故，公司確認該情況“不可接受且絕不應發生”。事發後團隊緊急部署了資料庫開發與生產環境的自動隔離機制，並加速推進測試環境建設，預計明日將取得新進展。
他強調：“得益於完善的備份系統，專案狀態可實現一鍵恢復。經查，事故主因系代理系統未能獲取完整內部文件，現正強制其接入 Replit 知識庫進行文件檢索。並且我已經親自聯絡 Jason 提供補償，並將全面覆盤事故原因。”
Amjad Masad 的帖子全文：
“我們看到了 Jason 的帖子。
Replit 開發中的代理意外刪除了生產資料庫中的資料。這種情況是不可接受的，也絕不應該發生。
整個週末我們都在緊急處理，現已開始逐步部署資料庫開發 / 生產環境的自動隔離機制，從根本上杜絕此類問題。同時，測試環境也在緊鑼密鼓地籌備中。明天會有更多進展。值得慶幸的是，我們有完善的備份系統。一旦代理出現錯誤，只需一鍵即可恢復整個專案的狀態。
代理此前未能獲取到完整的內部文件 —— 我們正在修復這一問題，強制要求其在 Replit 知識庫中進行文件檢索。
是的，我們充分理解 “程式碼凍結” 給大家帶來的困擾 —— 目前正在積極開發 “僅規劃 / 聊天” 模式，讓團隊能夠安心進行戰略規劃，而不必擔心程式碼庫受到影響。
週五上午看到這一情況後，我立即聯絡了 Jason 提供協助。我們會為給他帶來的麻煩提供補償，並進行全面覆盤，以明確事故原因，制定更完善的應對方案。
感謝 Jason 以及其他使用者提出的反饋。我們正在迅速採取行動，提升 Replit 環境的安全性和穩定性。這是我們的首要任務。”
儘管 CEO 已經堅定地否認了不會發生這種情況，但 InfoQ 留意到，遇到類似問題的使用者不止 Jason。在 Amjad Masad 這條帖子的評論區，不少使用者現身說法稱自己也同樣遭遇過這類問題，但並沒有引發太大的關注。
還有使用者表示，在另一個伺服器上資料庫也被全刪光了，自己不得不手動恢復。
甚至還有網友表示，這種事情發生了好多次，導致自己只能在筆記型電腦上編碼了。
此事在社交媒體上引發了熱議。有人對這件事情本身做出了評論，也有人就此事背後的相關技術——“氛圍編碼”展開了討論。
Substack 上著名技術領域評論員 Gergely Orosz 表示，Jason 的這篇帖子極具教育意義，因為它揭露了許多氛圍編碼應用的致命弱點（以及客戶流失的原因）。
“當一位創始人興致勃勃地計劃每年掏出差不多 10 萬美元（每月 8,000 美元）來使用該工具時。結果悲催了…… 哐當！Agent 刪除了整個資料庫！這位創始人肯定是要放棄購買了，Replit 的生意也徹底流失了！”
在 Hacker News 上，有使用者稱這本質上反映了他們對軟體開發和部署的實際運作方式缺乏瞭解。
“這表明他們並不真正瞭解軟體開發和部署的實際工作方式。首先，生產資料庫應該透過遷移檔案進行管理。其次，絕不能由 GenAI 來做出部署決策——它最多隻能讀取系統日誌。由於 GenAI 不具備推理能力，它根本無法理解刪除生產資料庫究竟意味著什麼。”
在 Reddit 上，有使用者表示，一旦生產環境崩潰，問題出在開發實踐上，而不在 AI 上。
“如果因為生產環境崩潰就導致數月工作成果毀於一旦，那問題絕對出在開發實踐上，而非人工智慧工具本身。一個健全的生產環境，其完全恢復時間應該控制在數小時之內（具體取決於企業規模和系統關鍵程度），而且程式碼資產必須得到完整保護。即便在生產流程中大量使用 AI，可能損失的也僅限於極小部分即時資料——這才是合理的容災標準。”
還有使用者表示這種事故不能責怪大模型，而是人們對大模型過於依賴和信任。
“人們放任大語言模型在資料庫上不受監管地執行任意指令，卻還在疑惑為什麼現在的軟體質量如此糟糕。或許，我們需要一個失控的人工智慧來格式化這些人的硬碟，只留下真正用心思考、認真創造的人，從而開啟一個軟體開發的黃金時代。”
甚至還會為 AI 犯下的錯誤找藉口。
還有使用者認為，在 AI 輔助程式設計的實踐中，有經驗的開發者既受益於這些工具快速實現創意的能力，也能深刻意識到必須保持批判性思維，這就是有經驗開發者和初級開發者之間的差距，這些差距往往體現在細節上。
“幾年前，我曾用 ChatGPT 外掛構建了一個‘氛圍式’程式設計平臺，完全是透過自學完成的。在這個過程中，我深刻意識到，每天與 AI 協同程式設計（或許叫“增強程式設計”更貼切）時，它其實一直在對我撒謊。
人機協同編碼當然有其合理性——藉助 AI，我能快速實現某些創意，開發出真正可用的工具，而如果僅靠自學，可能要花一年時間才能掌握。但與此同時，我也必須投入大量精力學習如何正確使用 AI，因為我從不信任它的輸出。我不會假設它給出的任何程式碼是正確的，而是會逐行檢查，並深入學習相關概念，直到我能完全獨立編寫同樣的功能。我的工作方式是：先寫下詳細的提示詞，觀察 AI 生成的程式碼，然後仔細審閱每一行。
除此之外，我還嚴格遵守基本的開發規範：儲存工作進度、定期備份資料、使用 GitHub 進行版本控制。而對比之下，有些人卻表現得極其業餘——比如那個完全依賴 Replit 內建 Postgres 執行應用、卻從未匯出過任何資料的開發者。我自己雖然也有十幾個類似快速構建的應用，但至少會利用 Replit 代理生成 SQL 指令碼，確保資料庫能在任何環境重建。這個案例恰恰說明，專業和業餘之間的差距，往往就體現在這些細節上。”
但也有使用者表示，不能一味批判行地看待氛圍編碼，因為對於那些沒有編碼經驗或程式設計經驗不足的人來說，氛圍編碼在日常生活中用處很大。
“作為一個 20 年前曾嘗試學習程式設計卻失敗的人，氛圍程式設計徹底改變了我的學習軌跡。這種方式完美契合我的學習風格：透過不斷構建、觀察系統崩潰、重新組裝的過程來獲得真知。在這個過程中，我常常花費數小時才意識到自己一直在錯誤的方向上解決問題——因為 LLM 只會機械地執行我的指令，而不會主動糾正我的思維誤區。正是這些令人難忘的失誤、頓悟時刻和最終突破，讓我覺得所有付出都值得。
為了達成目標，我不得不學會如何根據實踐經驗不斷調整和最佳化給 LLM 的指令。回想大學時代，我們只能學習 Pascal 和 C++ 這類語言，既缺乏有效指導，自學又困難重重。而現在，透過短短幾個月的氛圍程式設計實踐，我的收穫竟然遠超當年整個大學時期的學習成果，曾經晦澀難懂的概念如今都變得清晰明瞭。”
參考連結：
https://www.reddit.com/r/OpenAI/comments/1m4lqvh/replit_ai_went_rogue_deleted_a_companys_entire/
https://youtu.be/kOyIjt6FUrw?si=ASIVfPFL03QfID9K
https://x.com/jasonlk/status/1946240562736365809
https://news.ycombinator.com/item?id=44625119
宣告：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。
首屆 AICon 全球人工智慧開發與應用大會（深圳站）將於 8 月 22-23 日正式舉行！本次大會以 “探索 AI 應用邊界” 為主題，聚焦 Agent、多模態、AI 產品設計等熱門方向，圍繞企業如何透過大模型降低成本、提升經營效率的實際應用案例，邀請來自頭部企業、大廠以及明星創業公司的專家，帶來一線的大模型實踐經驗和前沿洞察。一起探索 AI 應用的更多可能，發掘 AI 驅動業務增長的新路徑！
今日薦文
你也「在看」嗎？👇