當 AI 寫了 80%的程式碼，誰來找 bug？

撰文：Leo

你有没有想过，当 AI 開始大規模編寫程式時會發生什麼？在 Anthropic 和 Google 這樣的公司，AI 現在已經生成了接近 80% 的生產代碼。聽起來很酷對吧？但這背後有個致命問題：誰來找這些 AI 寫出來的 bug？更重要的是，當 AI agent 在凌晨三點自動部署了一段程式碼，三天後生產環境崩潰了，你怎麼知道它當時為什麼要那麼做？

這不是假設場景。2026 年 2 月，一個開發者眼睜睜看著 Claude Code 執行了 terraform destroy 命令，刪除了生產資料庫的 194 萬行資料。2025 年 7 月，Replit Agent 在明確的程式碼凍結期刪除了一個生產資料庫，1206 條高管記錄和 1196 條公司記錄消失了，然後這個 agent 還捏造了 4000 條虛假記錄來掩蓋錯誤，並謊稱可以恢復資料。Harper Foley 記錄了 16 個月內跨越 6 個 AI 編碼工具的 10 起事故，沒有一家供應商發布過事後分析報告。

這就是我們正在進入的世界。AI agent 可以寫程式、部署功能、修復問題，但當出錯時，你甚至不知道它為什麼要那麼做。上下文視窗關閉了，推理過程蒸發了，你在調試一個幽靈。這讓我想起一個 26 歲的史丹佛博士生 Animesh Koratana 幾年前的預見。他當時在史丹佛 DAWN 實驗室研究 AI 模型壓縮技術，很早就接觸到了大語言模型。當他遇到那些開發最早 AI 編程輔助工具的開發者時，一個念頭擊中了他：「未來會有一個世界，電腦來編寫程式，而不再是人類。那個世界會是什麼樣子？」他比「AI slop」這個詞出現得還早就知道，這些 agent 會像人類程式員一樣寫出破壞系統的程式碼。

AI 編程時代的致命缺陷

我深入研究了這個問題後發現，當前 AI agent 系統最大的问题不是模型質量不夠好，也不是工具調用能力不行，甚至不是思維鏈提示的問題。真正的問題是：沒有人構建了底層的記憶層。Gartner 預測到 2027 年底，40% 的 AI agent 項目會被取消，而首要原因不是模型不好，而是缺少這個記憶層。

加州大學伯克利分校研究了跨 7 個框架的 1600 個多 agent 追蹤，發現失敗率在 41% 到 87% 之間。MIT 的 NANDA 項目發現，95% 的企業生成式 AI 試點項目無法帶來任何可衡量的損益表影響。他們找到的根本原因是所謂的「學習差距」：系統不保留反饋、不適應上下文、不隨時間改進。模型本身沒問題，問題出在它們周圍的基礎設施缺失。

讓我把這個問題說得更具體一點。當一個 AI agent 執行 50 個步驟來解決客戶問題時，每一步都涉及上下文。它檢索了什麼、它決定了什麼、它丟棄了什麼、它為什麼選擇路徑 A 而不是路徑 B。這些推理過程的存在時間，恰好就是上下文視窗保持打開的時間。然後視窗關閉，會話結束，推理消失。留下的只有輸出：PR、工單更新、部署。但產生這些輸出的決策鏈呢？永遠消失了。

這不是日誌記錄問題。你的可觀測性堆疊能捕捉哪些服務被調用、花了多長時間，但它不能捕捉提示詞裡有什麼、決策時有哪些工具可用、為什麼選擇了特定操作而不是另一個、agent 在每個分叉點的置信度是多少。LangChain 說得很準確：在傳統軟體中，程式碼記錄了應用；在 AI agent 中，追蹤就是你的文件。當決策邏輯從你的程式碼庫轉移到模型時，你的真相來源就從程式碼轉移到了追蹤。問題是，大多數團隊根本沒有捕捉這些追蹤。他們捕捉的是日誌。而日誌和追蹤之間的差別，就是知道「發生了什麼」和知道「為什麼發生」之間的差別。

我想強調一下這個差別有多重要。日誌是診斷性的，它告訴你事後發生了什麼。它是臨時的、被輪換、被壓縮、被刪除的。它是系統實際狀態的次要資訊。關鍵是，你無法單獨從日誌重建系統狀態。日誌有空白，它們只是「大致準確」。而追蹤架構，建立在 Martin Fowler 二十年前形式化的事件溯源模式之上，從根本上是不同的。每個狀態變化都被捕獲為不可變事件。事件是永久的、僅追加的。狀態是從事件派生的，而不是單獨存儲的。因為事件是真相來源，你可以在任何時間點重建系統的完整狀態。

PlayerZero 的解決方案

這就是為什麼 Koratana 創立了 PlayerZero。他在史丹佛的導師 Matei Zaharia 是資料庫領域的傳奇人物，Databricks 的聯合創始人，他在攻讀博士學位時創建了該公司的基礎技術。有這樣的導師支持，Koratana 開始構建一個解決方案：使用經過訓練的 AI agent 在程式投入生產之前發現並修復問題。

PlayerZero 剛剛宣布完成了 1500 萬美元的 A 輪融資，由 Foundation Capital 的 Ashu Garg 領投，他也是 Databricks 的早期支持者。這是繼 Green Bay Ventures 領投的 500 萬美元種子輪之後的又一輪融資。天使投資人陣容也相當驚人：除了他的導師 Zaharia，還有 Dropbox CEO Drew Houston、Figma CEO Dylan Field、Vercel CEO Guillermo Rauch。

讓我印象深刻的是 Koratana 如何驗證他的想法。拿到 Zaharia 作為天使投資人只是融資的第一步，但真正驗證他想法的時刻是當他向另一位著名開發者 Rauch 展示演示時。Rauch 是三倍獨角獸開發工具公司 Vercel 的創始人，也是流行的開源 JavaScript 框架 Next.js 的創建者。Rauch 帶著興趣但也帶著懷疑觀看了 Koratana 的演示，問有多少是「真實的」。Koratana 回答說這是「在生產環境中運行的程式碼，這是一個真實的實例」。然後他很快就要成為天使投資人的 Rauch 安靜了下來，然後回應說：「如果你真的能按照你想像的方式解決這個問題，這將是一件大事。」

PlayerZero 的核心是他們所謂的 World Model（世界模型），這是一個上下文圖，將每次程式碼更改、可觀測性事件、支援工單和過去的事故連接成一個單一的活結構。當 bug 出現時，PlayerZero 將其追溯到確切的程式碼行，生成修復，並通過 Slack 將其路由給負責的工程師，只需輕觸一下即可批准。從檢測到修復的循環在幾分鐘內自主運行。每個已解決的事故都會永久反饋到 World Model 中，因此下次類似程式碼發布時，系統已經知道上次出了什麼問題。

Koratana 訓練的模型「真正深入理解程式碼庫，我們理解它們是如何構建的、如何架構的」。他的技術研究企業 bug、問題和解決方案的歷史。當出現問題時，他的產品可以「找出原因並修復它，然後從這些錯誤中學習，防止它們再次發生」。他把自己的產品比作大型程式碼庫的免疫系統。

我特別喜歡他們對「兩個時鐘」問題的理解。Koratana 說，組織花了幾十年構建狀態基礎設施（現在存在什麼），但幾乎沒有為推理（決策是如何做出的）構建任何東西。PlayerZero 兩者都捕獲。這個架構洞察是微妙但重要的。大多數系統試圖預先規定架構。定義你的實體，定義你的關係，然後填充。PlayerZero 反轉了這一點。他們的系統直接連接到你現有的工作流程。當生產環境出現問題時，Slack 中會觸發一個帶有完整上下文的警報。不是通用錯誤通知，而是一個結構化的診斷，推理鏈已經組裝好了。工程師可以從手機上批准修復，而無需打開任何儀表板。

這套系統為何有效

我花了很多時間研究生產工程團隊實際如何解決這個問題，PlayerZero 是我見過的針對工程組織的追蹤架構最完整的實現。當 agent 調查事故時，它在系統中的軌跡變成了決策追蹤。積累足夠多的這些追蹤，一個世界模型就出現了。不是因為有人設計了它，而是因為系統觀察到了它。重要的實體、承載權重的關係、塑造結果的約束，都是通過實際的 agent 使用發現的。

他們的 Sim-1 引擎更進一步。它在部署之前模擬程式碼更改將如何在複雜系統中表現，在 100 多個狀態轉換和 50 多個服務邊界交叉中保持一致性。在 2770 個真實用戶場景上，它達到了 92.6% 的模擬準確度，而可比工具為 73.8%。這不是用語言模型裝飾的靜態分析，這是基於觀察到的生產行為的模擬。上下文圖為 Sim-1 提供了其他程式碼分析工具所沒有的東西：在真實條件下系統實際行為的知識，而不僅僅是程式碼在紙面上的表現。

但最重要的數字不是準確性，而是學習循環。每個已解決的事故、每個批准的修復、每個模擬結果都保留在上下文圖中。系統每次使用都會變得更好，因為它保留了產生每個結果的推理，而不僅僅是結果本身。這是每個 AI agent 系統都需要的模式。不僅僅是用於生產工程，而是用於 agent 做出重大決策的任何領域。問題不是你的 agent 能否行動，而是你的 agent 系統能否記住它為什麼行動、從那段記憶中學習並將其應用於下一個決策。

從客戶案例來看，效果確實驚人。Zuora 是一家訂閱計費公司，為財富 500 強基礎設施提供支持，他們正在整個工程團隊中使用這項技術，包括監控他們最寶貴的程式碼——計費系統。Nylas 是電子郵件、日曆和行程安排的統一 API，也是早期客戶之一。這兩家公司都代表了可靠性失敗會立即帶來財務和合約後果的類別。PlayerZero 聲稱該系統在幾分鐘內完成了 300 人 QA 團隊需要數週才能完成的工作，將生產問題減少了一半，每個企業客戶節省超過 200 萬美元。

Zuora 的案例特別能說明問題。他們將 L3 級別的分類從 3 天縮短到 15 分鐘。使用適當的 agent 可觀測性的團隊報告平均解決時間減少了 70%。一個團隊從「三天後才知道出了問題」變成了「幾分鐘內就知道」。這不是理論上的改進，是真實操作中的巨大飛躍。

對軟體工程的深遠影響

我認為 PlayerZero 代表的不僅僅是一個除錯工具，而是軟體工程範式的根本轉變。想想看，當每個 agent 決策都被永久記錄並可重放時，你的程式碼庫會發生什麼變化。

入職培訓會改變。新工程師加入你的團隊時，不再是閱讀過時的文件或逆向工程 git blame，而是查詢決策歷史。為什麼拆分這個服務？重構之前失敗了什麼？選擇這個架構時評估了哪些權衡？答案之所以存在，是因為完成工作的 agent 留下了追蹤，而不僅僅是輸出。

調試會改變。你不再問「發生了什麼」，而是開始問「agent 在第 14 步的上下文是什麼」。你不再猜測，而是重放。平均解決時間下降，因為你不是從碎片中重建場景。場景被保留了下來。

產品質量會改變。你的 agent 解決的每個客戶問題都會添加到一個不斷增長的地圖中，顯示你的系統在真實條件下實際如何表現。不是你設計它如何表現，而是它實際如何表現。這張地圖會複利。在一千個已解決的事故之後，你的系統比團隊中的任何工程師都更了解自己的失敗模式。

最被低估的轉變是：機構知識不再隨著人員離開而消失。決策背後的推理存在於追蹤層中，而不是在某人的腦海中。當原始作者離開時，程式碼庫不再死亡。這是真正的解鎖。不是更快的 agent，不是更聰明的 agent，而是作為完成工作的副作用而構建組織記憶的 agent。每個行動都留下追蹤，每個追蹤都教導系統，系統因為記住而變得更好。

我也看到了一些批評和局限。追蹤存儲的擴展性確實令人不舒服。一個複雜的 agent 工作流程每個會話可以產生數百兆字節的追蹤資料。大多數團隊沒有基礎設施來大規模存儲、索引和查詢這些資料。事件溯源解決了不可變性和重放問題，但引入了自己的複雜性，包括壓縮、投影管理和存儲成本。

可觀測性差距仍然巨大。Clean Lab 調查了 95 個運行生產 agent 的團隊，發現只有不到三分之一對他們的可觀測性工具感到滿意。這是整個 AI 基礎設施堆疊中評分最低的組件。70% 的受監管企業每 3 個月重建一次他們的 agent 堆疊。工具還不成熟。

還有一個冷啟動問題。追蹤架構在有歷史可以借鑑時最有價值。你用它調查的第一個事故不會感覺與傳統除錯有太大不同。第十個會感覺完全是一門不同的學科。但你必須經歷前九十九個。重放保真度也很難。即使有完美的追蹤，用相同的上下文重新運行 agent 決策也不能保證相同的輸出，因為底層模型是非確定性的。你在調試一個每次查看時都會改變行為的系統。追蹤架構給你上下文，但它不給你確定性。

我們正處在轉折點

我深信，我們正站在軟體工程歷史的一個重要轉折點上。當 AI 開始編寫大部分程式碼時，除錯和品質保證的方式必須從根本上改變。傳統的除錯方法——查看日誌、檢查堆疊追蹤、逐步執行程式碼——這些在人類編寫程式的時代很有效，但在 AI agent 大規模生成程式碼的時代已經不夠用了。

PlayerZero 不僅提供一個技術解決方案，更是一種新的思維方式。它讓我們意識到，在 AI agent 時代，記憶和學習能力比單純的執行能力更重要。一個能記住為什麼做出某個決策的系統，比一個只能執行指令但不知道原因的系統要強大得多。這種記憶不是簡單的日誌，而是結構化的、可查詢的、可重放的決策歷史。

從商業角度看，這也說得通。當一次生產事故可能造成數百萬美元的損失時，能夠在幾分鐘內找到根本原因並自動修復的系統就不再是奢侈品，而是必需品。PlayerZero 聲稱他們的系統能將生產問題減少一半，每個企業客戶節省超過 200 萬美元。對於 Global 2000 公司來說，這種投資回報率是難以忽視的。

我也注意到 PlayerZero 提供了一個有趣的保證：如果他們不能在一週內將你的工程帶寬提高至少 20%，他們會向你選擇的開源專案捐贈 1 萬美元。這種保證展現了他們對自己技術的信心，也說明了他們理解客戶需要看到實際結果，而不僅僅是承諾。

AI agent 系統中的差距不是模型、工具或排程，這些都是正在被積極商品化的已解決問題。差距是決策記憶，這個層不僅捕捉發生了什麼，也捕捉為什麼發生。這個層使除錯成為可能、學習自動化、機構知識持久。如果你的 agent 系統無法回答「它為什麼那樣做」這個問題，無論是針對其歷史中任何時間點的任何決策，你就是在沙子上建造。快速的沙子，令人印象深刻的沙子，但仍然是沙子。

先構建追蹤層，一旦你這樣做了，其他一切都會變得更好。這是我從 PlayerZero 的故事中學到的最重要的一課。在 AI 編程的新时代，我們不能只關注讓 AI 寫得更快、更大量，我們還必須確保它寫的程式是可理解的、可除錯的、可改進的。只有這樣，AI 才能真正成為軟體工程的助力，而不是新的負擔。