Cockroach Labs：五個月把 bug 當病人、把編碼智能體當醫療團隊

四月的一個週三傍晚到週五下午，Cockroach Labs 用來把資料庫遷移到 CockroachDB 的工具 MOLT，獲得了從 IBM Db2 遷移的能力。Db2 是最早的商用關聯式資料庫之一，SQL 方言豐富，型別系統複雜，還有原生的線路協定。要在 MOLT 中支援它，需要一個新的結構轉換器、一條新的 Fetch 路徑（把資料列取出並載入 CockroachDB）、一條新的 Verify 路徑（載入後比對資料）、一份內建的 ANTLR 語法、一個供 CI 使用的 Docker 映像檔，外加一萬多行測試夾具。2024 年為 MOLT 增加 Oracle 支援時，同等工作耗時 9 個月，約花費 16 萬美元的工程成本。這一次的 Db2 不到兩天完成，沒有任何人手寫一行程式碼，token 帳單是 4172 美元：速度快了 164 倍，成本低了 38 倍。

這個結果的起點只是一個 GitHub issue，裡面描述了需求。隨後，一個規劃智能體讀完它，判斷任務太大，不能一次處理，於是把它拆成十五個子 issue，並畫出明確的依賴圖：先打地基，再做型別系統，然後是列迭代器，接著是 Fetch、Verify、Convert，最後是 CI 和測試資料。其中兩個子 issue 在各自的工作評估裡又被判定為過大，於是被再次拆分。在推進過程中，智能體還針對自己的工作另外提交了約十幾個 issue，內容包括測試夾具的缺口、一個型別對應的缺陷，以及一處隔離級別的修復。值得注意的是，這些問題不是人發現的，而是流水線自己發現、自己登記、自己排進佇列的。把工作拆開並讓依賴顯式化，是這套系統能夠在兩天內完成大塊頭任務的第一個關鍵。

Cockroach Labs 為這條流水線選了一個有意思的組織隱喻：教學醫院。每個 bug 被當作一位病人，每個編碼智能體則是醫療團隊中的一個角色。分診護士負責接收和初篩，判斷問題是什麼、有多大、該交給誰；住院醫師（Fellow）負責動手治療，也就是寫出修復；複核主治醫師（Review Attending）負責嚴格評審，把關品質；出院護士負責收尾，確保合併前的各項檢查和記錄都已完成。這個比喻的價值不在於可愛，而在於它把軟體工程裡本來就存在、但常被省略的分工與制衡，用一套人人熟悉的醫療流程重新固定下來。寫程式的人不能自己批准自己的程式，這一點在醫院裡是常識，在智能體流水線裡卻需要刻意設計。 更重要的是幾條硬性紀律。第一，寫程式之前必須先做計畫，並且計畫本身要經過評審，也就是在花費 token 生成大量程式碼之前，先讓錯誤的方向被攔下來。第二，嚴格的測試覆蓋是合併的前提，而不是事後補充。第三，要有細緻的記錄，每個決定、每次修改都留下痕跡，這既是醫療病歷的做法，也是事後追查回退原因的唯一依據。第四，在合併之前設有安全護欄。這些規則看上去樸素，但它們恰好針對的是智能體最容易出問題的地方：目標理解偏差、過度自信，以及沒有人對產出負責。 衡量這套流水線是否可靠，最有說服力的是回退次數。在五個月裡，這條流水線處理了超過一百萬行程式碼，只發生了 7 次回退。這個數字說明，自主產出和企業級的可靠性並不必然衝突，前提是把可靠性當作系統結構的一部分，而不是寄望於單個模型足夠聰明。同樣的機制也支撐了 Migration Assistant 這類功能：當複雜的資料庫遷移要由智能體來建構和維護時，規劃評審、測試覆蓋和完整記錄，就是避免昂貴迴歸的主要手段。需要說明的是，原文給出的是 Cockroach Labs 自己的經驗數字，Oracle 九個月與 16 萬美元的對比也是公司自己的估算，讀者應把它們看作一個有力的案例，而不是普遍適用的基準。

從成本結構看，這個案例還有一層容易被忽略的含義。Oracle 專案的 16 萬美元是工程時間，Db2 專案的 4172 美元是 token 帳單，兩者的計價單位不同，但都指向同一件事：當程式碼的生產成本大幅下降，真正昂貴的東西就變成了判斷。哪些需求值得做，任務該怎麼拆，哪個結果可以放行，這些判斷仍然需要被明確地寫下來並交給有權限的角色。教學醫院的比喻之所以有效，正是因為醫院早已習慣在高風險環境中，把判斷權分配給不同的人，並要求每一步都有記錄可查。軟體團隊過去靠個人經驗和口頭默契完成的事，現在必須變成流程，因為執行者已經換成了不會疲勞、也不會主動提出疑問的智能體。把隱性的工程常識顯式化，也許是這類系統帶給團隊的最大副產品。

對於產業而言，這篇文章的意義在於換了一個問題。過去人們常問：哪個模型寫程式最強？這個案例提示我們，更有價值的問題是：如何組織一群智能體，讓它們像醫療團隊那樣分工、互審、留痕，並在出錯時有明確的責任鏈？當成本從九個月降到兩天、從十六萬美元降到四千多美元，瓶頸就從編碼本身轉移到了需求描述、任務拆解和驗收這些環節。團隊如果想複製這樣的結果，應當先投資於拆解能力、評審流程和測試基礎設施，而不是只追逐更強的模型。