Anthropic 如何使用 Claude Code 進行大規模程式碼遷移

Anthropic 如何使用 Claude Code 進行大規模程式碼遷移 程式碼遷移（即將生產環境的程式碼庫移植到新語言的專案）在最近之前，都還是需要耗時數年的工程。 但在過去一個月裡，Anthropic 的獨立開發者們僅使用 Claude Fable 5、Claude Opus 4.8 與動態工作流程，就遷移了 10 個包含數萬到數十萬行程式碼的程式庫。 Bun 的共同創辦人兼 Anthropic 技術團隊成員 Jarred Sumner（@jarredsumner）使用 Claude Code 將 Bun 從 Zig 遷移到 Rust。在不到兩週的時間內，就產出了 100 萬行的程式碼，並且在合併前，CI 中 Bun 現有的測試套件通過率達到 100%。合併後浮現了 19 個回歸問題，且全都獲得修復。這個 Rust 版本已於 6 月份在 Claude Code 內部上線。 Anthropic Labs 共同負責人 Mike Krieger（@mikeyk）在一個週末內，將一個 Python 程式碼庫遷移成了 165,000 行的 TypeScript。這其中包含了數百個 Agent、八個階段檢查點（phase gates）、三輪對抗式審查，以及最後的差異比對（diff）檢查，用來比對每個指令的輸出與原版 Python 是否一致。 Claude Code 的新功能徹底改變了這些長期擱置專案的成本效益計算。以下是我們現在採用的六步驟流程，這些經驗都是從上述遷移實踐中學到的。 核心見解在於：你不用去修復程式碼，而是去修復產生程式碼的流程（迴圈）。 --- 為什麼以及何時該遷移語言 團隊之所以發起遷移，是因為最初建構時的環境與當前專案的現狀有所落差。要么是過去已知的取捨變成了瓶頸、出現了更好的方法，要么是原本的生態系正在萎縮。 舉例來說，Jarred 當初選擇 Zig 是因為它兼具 C 語言等級的效能與極致的簡潔性，非常適合身為獨行創辦人的他在「LLM 出現前，在奧克蘭一間狹窄的公寓裡花一年時間寫出 Bun」。這種簡潔性伴隨著已知的取捨，他曾在這裡寫下相關心得。 Bun 的 CLI 每月下載量已超過 1,000 萬次，並在 Claude Code 內部被廣泛使用。 就在上個季度，這些取捨還不足以構成凍結產品藍圖並投入資源進行數季專案的正當理由。你可能會維護兩套平行的程式碼庫數季甚至數年，而如果最終成果只有 90% 的相容度，帶給你的麻煩反而比剛開始時更大。 現在，最壞的情況就是把這個分支刪掉重來。 當然，仍然需要具備合理的商業價值。雖然百萬行等級的遷移不再需要耗費四年專案、價值 300 萬到 400 萬美元的工程資源，但執行起來仍然需要花費數萬到數十萬美元不等的成本。以 Bun 的遷移為例，它消耗了 59 億個未快取的輸入 token 和 6.9 億個輸出 token — 按照 API 定價大約是 165,000 美元。Mike 移植專案的主要部分則消耗了 2,700 萬個 token。 展開畫面重點畫面為 GitHub 上的 Pull Request 頁面，標題為「Rewrite Bun in Rust #30412」。 頂部顯示該 PR 已由 Jarred-Sumner 於 5 月 14 日合併 6755 個 commit，從 claude/phase-a-port 合併至 main。 右上方顯示檔案變更統計：+1,009,257 -4,024。 下方顯示 Commit 68a34bf 的詳細資訊，由 dylan-conway 於 5 月 13 日提交（已驗證），標題為：test: revert proc.exited change in spawn.test.ts, keep isDebug iteration count。 程式碼差異對照（diff）檔案為 test/js/bun/spawn/spawn.test.ts，變更內容如下： 刪除（紅色）： // Wait for the child to exit before reading stdout. Using a real // signal (process exit) instead of a fixed timer keeps this // deterministic: it exercises "stdout is fully readable after the // child has exited" without depending on timing. await proc.exited; 新增（綠色）： await Bun.sleep(1); 後續程式碼： const out = await proc.stdout.text(); expect(out).not.toBe(""); } 然而，遷移的理由已不再需要生死攸關。只要有changelog 中累積了一年的記憶體錯誤修復，或是遇到某個長期的瓶頸，現在就足以成為發起遷移的理由。 編譯步驟就是促成 Mike 專案的契機。他的團隊所維護的內部工具是以單一二進位檔（binary）的形式發佈給使用者。使用 Python 工具鏈來產生這個二進位檔，每個平台大約需要 8 分鐘，在每次發佈的建構矩陣（build matrix）中總共需要等待 30 分鐘。遷移之後，同樣的編譯現在大約只需要兩秒鐘，二進位檔的啟動速度快了 6 倍，團隊也因此能夠除役一套獨立的部署管道。 --- 為什麼 AI 改變了程式碼遷移的數學公式 Fable 和 Opus 4.8 特別擅長透過子 Agent 來委派、指揮與驗證平行的工作串流，同時能找出通往既定目標的多條路徑。 大型程式碼遷移之所以是這些先進模型的絕佳應用場景，原因在於： 工作具備平行性。工作可以分散在數千個獨立單位（例如檔案和 crate）中同時執行，因此 Agent 可以同步工作，而不必互相等待。 context 清晰且全面。舊程式碼是模型的絕佳規格說明書。 具備內建的裁判。許多大型程式碼庫都包含測試套件，Agent 可以用來驗證它們的工作成果。 佇列會自動產生。當編譯或測試執行失敗時，該失敗項目就會變成 Agent 下一個要修復的任務。 它們需要一致性與邊界案例處理：審查者會引述每個發現背後的規則，因此違規事項會變成佇列項目，而不是默默存在的程式碼分歧。 --- 大規模程式碼遷移的六個步驟 如需更多細節，你可以閱讀 Jarred 的部落格。 先決條件 在開始遷移專案之前，首要條件是建立一個強而有力的裁判機制，否則你將無法界定結束條件或衡量成功與否。 要建立這個裁判機制： 將現有的測試分類。使用 Claude 來識別哪些測試可以表達為外部呼叫，哪些則依賴無法移植的內部實作。 為了可移植性而重寫。將面向外部的測試轉換為可以針對原始版本和移植版本同時執行的斷言（assertions）。使用對抗式 Agent 來驗證重寫後的測試沒有削弱斷言的嚴格性。 驗證裁判機制。針對原始程式碼執行它，以確認能夠通過。然後針對故意破壞的程式碼執行它，以確認會失敗 — 一個抓不出破壞的裁判根本不能算是裁判。 這基本上遵循了 Jarred 的方法論，並在每個階段進行審查與把關。Mike 採用了類似的整體結構與迴圈工作流程，但他以端到端的方式執行了整個遷移，根據結果修正規則與工作流程，然後再次執行 — 每次都丟棄輸出結果，直到第三次執行才採用。 展開畫面重點- 標題列：One engineer, outside the loop (reads outputs, edits the loop, gates phases — "prompting Claude to edit the loop to fix things") 顏色圖例：teal = does the work, coral = checks it, amber = shared documents Step 1 · create the map and the rules (output: trusted map + rules) - Rulebook authors: each decision once (teal) - Dependency mappers: order the work (teal) - Gap inventory: trace the control flow (teal) - Rule auditors: one mistake class each (coral) - Skeptic reviewers ×2: attack each entry (coral) - Joint audit: inventory +…