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 萬行程式碼，在合併前，Bun 現有的測試套件在 CI 中的透過率達到了 100%。合併後浮現了 19 個迴歸問題，目前已全部修復。這個 Rust 版本已於 6 月在 Claude Code 內部上線。 Anthropic Labs 共同負責人 Mike Krieger（@mikeyk）用了一個週末的時間，將一個 Python 程式碼庫遷移為 165,000 行的 TypeScript。這其中包含了數百個 Agent、八個階段檢查點（phase gates）、三輪對抗式審查，以及最後的同等性檢查（parity check），將每個指令的輸出與原版 Python 進行 diff 比對。 Claude Code 的新功能徹底改變了這些長期被擱置的專案的成本效益評估。以下是我們目前採用、總結自這些遷移經驗的六個步驟流程。 核心見解是：你不用去修復程式碼，而是去修復產生程式碼的流程（迴圈）。 --- 為什麼以及何時要進行語言遷移 團隊發起遷移的原因，在於初次建構與現今專案之間的環境變化。不是原先已知的取捨變成了瓶頸，就是出現了更好的作法，或者原本的生態系正在萎縮。 舉例來說，Jarred 當初選擇 Zig 是因為它兼具 C 語言等級的效能與極致的簡潔性，非常適合當時身為單人創辦人、「在 LLM 出現前奧克蘭一間狹窄公寓裡，花一年時間用 Zig 寫出 Bun」的他。這種簡潔性伴隨著已知的取捨，他曾在此處撰寫相關文章。 Bun 的 CLI 每月下載量已超過 1,000 萬次，並在 Claude Code 內部被廣泛使用。 就在上個季度，這些取捨還不足以構成凍結產品藍圖並投入資源進行數季專案的正當理由。你可能會維護兩個平行的程式碼庫數季甚至數年，而如果最終成果只有 90% 相容，你的頭痛問題反而比剛開始時更大。 現在，最壞的情況就是把這個分支刪掉重來。 我們依然需要合理的商業論證。雖然百萬行規模的遷移不再需要耗費 4 年專案期間內 300 萬至 400 萬美元的工程資源，但執行起來仍然需要花費數萬到數十萬美元不等。例如，Bun 的遷移消耗了 59 億個未快取的輸入 token 和 6.9 億個輸出 token，以 API 定價計算大約是 165,000 美元。Mike 移植工作的主要部分則消耗了 2,700 萬個 token。 展開畫面重點畫面為某版本控制平台的 Pull Request 介面，標題為「Rewrite Bun in Rust #30412」，狀態標示為「Merged」，由 Jarred-Sumner 將 6755 個 commits 合併至 main 分支（來源為 claude/phase-a-port），時間為 May 14。 上方統計數據顯示：Conversation 1127、Commits 6755、Checks 7、Files changed 2188，整體程式碼變更量為 +1,009,257, -4,024。 下方選取了 test/js/bun/spawn/spawn.test.ts 檔案的 Commit 68a34bf 變更細節： 提交者：dylan-conway 於 May 13 提交，標記為 Verified。 程式碼差異（Diff）內容： - 移除部分：移除了原本等待子進程結束的邏輯，包括 // Wait for the child to exit before reading stdout... 的註解以及 await proc.exited;。 - 新增部分：改為 await Bun.sleep(1);。 - 下方保留了 const out = await proc.stdout.text(); 與 expect(out).not.toBe("");。 然而，遷移的理由不再需要生死攸關。更新日誌中長達一年的記憶體臭蟲修復紀錄，或是一個長期的效能瓶頸，現在就足以成為遷移的理由。 編譯步驟是 Mike 啟動專案的契機。他團隊內部維護的工具會打包成單一二進位檔發布給使用者。透過 Python 工具鏈產生該二進位檔每個平台大約需要 8 分鐘，在每次發布的建構矩陣（build matrix）中累積起來總共要等待 30 分鐘。遷移之後，同樣的編譯現在只需大約 2 秒，二進位檔啟動速度快了 6 倍，團隊也得以退役一套獨立的部署管道。 --- 為什麼 AI 會改變程式碼遷移的成本效益計算 Fable 和 Opus 4.8 非常擅長利用子 Agent 來委派、指揮和驗證平行的工作串流，同時找出通往既定目標的多條路徑。 大型程式碼遷移是這些先進模型特別有效的應用場景，原因如下： 工作是平行的。工作可以分派到數千個獨立的單元（例如檔案和 crate）同時執行，因此 Agent 可以同步工作，而不必互相等待。 context 清晰且全面。舊程式碼是模型的絕佳規格說明書。 內建裁判。許多大型程式碼庫都包含測試套件，Agent 可以用來驗證它們的工作成果。 佇列會自動產生。當編譯器或測試執行失敗時，就會變成下一個需要 Agent 修復的項目。 它們需要一致性與邊界案例處理：審查者會引述每個發現背後的規則，因此違規事項會變成佇列項目，而不是悄悄出現的分歧。 --- 大規模程式碼遷移的六個步驟 如需更多細節，你可以閱讀 Jarred 的部落格。 前置準備 在開始遷移專案之前，必須先建立一個強而有力的裁判，否則你將無法界定結束條件或衡量成功與否。 要建立這個裁判： 將現有測試分類。使用 Claude 識別哪些測試可以表達為外部呼叫，哪些測試依賴於無法移植的內部實作。 為了可移植性進行重構。將面向外部的測試轉換為可以同時針對原始版本與移植版本執行的斷言。使用對抗式 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 x2 (attack each entry) [coral] Joint audit (inventory + rules agree) [coral] Step 2 · stress-test the rules output: hardened rules Dual translators x2 (same files, separate contexts) [teal] Diff inspector (diffs indict rules) [coral] Pilot run (rehearse on select files) [teal] Step 3 · translate everything…