Claude Code 程式碼遷移實戰：Bun 11 天將 100 萬行 Zig 重寫成 Rust
Claude Code 如何執行大型程式碼遷移？本文解析 Bun 在 11 天內將 100 萬行 Zig 重寫成 Rust 的流程、16.5 萬美元成本、測試結果與導入風險。
Claude Code 程式碼遷移，正在把原本需要數季甚至數年的工程計畫，縮短成以天或週計算的工作。團隊不只要重新產生程式碼，還要維持舊系統、追上新功能，並證明新舊版本的行為一致。
Anthropic 在 2026 年 7 月公開一套不同做法。個別開發者搭配 Claude Code、Claude Fable 5、Claude Opus 4.8 與 Dynamic Workflows，在一個月內完成 10 個程式碼套件的語言移植。其中最醒目的案例，是 Bun 從 Zig 移植到 Rust：不到兩週產生約 100 萬行程式碼，合併前完整測試全數通過。
但這不是「下一句 Prompt，等 AI 寫完」的故事。Bun 合併後仍出現 19 個已知功能退化問題（regression），整個移植也花了約 16.5 萬美元的 API 成本。
真正值得注意的，是 Anthropic 如何把大型重寫變成可以反覆執行、檢查與修正的工程流程。這套方法降低了大量產碼與重試的成本，但沒有消除測試、架構判斷與上線風險。
Claude Code 程式碼遷移重點整理
| 項目 | Bun Zig 轉 Rust 的結果 |
|---|---|
| 遷移規模 | 合併 diff 約增加 100.9 萬行 Rust 程式碼 |
| 執行時間 | 11 天，從 2026 年 5 月 3 日至 5 月 14 日合併 |
| 平行規模 | 尖峰約 64 個 Claude agents 同時執行 |
| AI 成本 | 按 API 價格估算約 16.5 萬美元 |
| 合併門檻 | 跨平台 CI 測試全數通過，沒有跳過或刪除測試 |
| 合併後問題 | 發現 19 個已知 regression，Bun 官方表示均已修復 |
這組數字不能解讀成「AI 已經可以免費取代一整個工程團隊」。它代表的是：當舊程式能充當規格、測試能擔任裁判時，AI agents 可以用大量平行運算，縮短原本不具商業可行性的遷移工作。
Claude Code 大型程式碼遷移案例：Bun 與 Anthropic 內部工具
Anthropic 公開的兩個案例，都不是小型 demo，而是會進入實際產品的程式碼。
| 案例 | 遷移內容 | 規模與時間 | 驗證方式 | 已知成本或結果 |
|---|---|---|---|---|
| Bun | Zig 移植至 Rust | 11 天，合併 diff 約增加 100.9 萬行 | 原有跨平台 CI（持續整合）自動測試、對抗式審查、後續模糊測試（fuzzing） | 約 16.5 萬美元；合併後 19 個已知 regression，官方表示均已修復 |
| Anthropic 內部工具 | Python 移植至 TypeScript | 一個週末，16.5 萬行 | 8 個 phase gates、3 輪對抗式審查、逐一比對新舊指令輸出 | 主體工作使用 2,700 萬 tokens（模型計費與處理用的文字單位）；跨平台建置時間由合計約 30 分鐘降至約 2 秒 |
這些數字很容易讓人只看到速度，但更重要的訊息是：兩個案例都有明確的舊系統可供比對，也都有可以自動判定成功或失敗的測試機制。
換句話說，Claude Code 擅長的不是憑空重建需求，而是當舊程式已經提供規格、測試可以擔任裁判時，大量平行處理可被驗證的工作。
Bun 為什麼從 Zig 改寫成 Rust？
Bun 並不是因為 Zig 效能不足才改寫。Bun 創辦人 Jarred Sumner 在官方技術文章中列出多個 use-after-free、double-free 與 memory leak 案例，這些問題大多與手動管理記憶體及 JavaScriptCore 的垃圾回收機制交錯有關。
Zig 要求開發者在每個呼叫位置明確處理記憶體釋放。對一般底層專案來說，這能提供直接控制；但 Bun 同時整合 JavaScript、C 與 C++ 元件，團隊需要持續確認每一塊記憶體由誰持有、何時釋放，以及錯誤路徑會不會重複釋放。
Rust 的 ownership、borrow checker 與 Drop 機制，能把部分 use-after-free、double-free 和忘記釋放記憶體的問題提前變成 compiler error。這不代表 Rust 自動消除所有風險，但它把原本依賴人工 code review 的規則，往型別系統與 compiler 移動。
因此，Bun 遷移的核心理由是穩定性，而不是單純追求速度。若團隊的主要問題不是語言本身造成的維護成本，換語言就未必比持續改善現有架構划算。
為什麼大型程式碼遷移特別適合 AI Agent？
程式碼遷移（code migration）是把既有系統從一種語言、框架或 API 搬到另一套技術，同時盡量維持原本的功能與外部行為。這類工作剛好具備四個適合 AI Agent 的條件。
第一，任務可以拆分。數百或數千個檔案能依相依關係分批處理，多個 subagents 可以同時工作。Subagent 是由主要 AI Agent 分派出去的子任務執行者，各自負責翻譯、審查或修正一小部分工作。
第二，舊程式本身就是規格。一般開發最難處理的需求歧義，在機械式移植中相對少；新版本若不確定該怎麼做，可以回頭比對舊版本的輸入、輸出與行為。
第三，失敗能自動轉成工作清單。Compiler、type checker 或測試一旦報錯，就會產生下一批待修項目，不需要每次都由人重新描述問題。
第四，結果能由機器判斷。只要 test suite、輸出 diff 與效能門檻設計得夠好，系統就能明確回答「這一輪是否通過」。Test suite 是一組可以重複執行的自動化測試，用來確認修改後的功能沒有偏離原本行為。
我的判斷是，這也是這套方法最大的限制：如果舊系統沒有測試、需求長期靠口頭傳承，或輸出本來就不穩定，AI 只會更快產生大量難以驗證的程式碼。
Claude Code 的六階段程式碼遷移流程
Anthropic 將多次實戰整理成六個階段。不過在第一步之前，還有一個不可省略的前提：先建立 referee。
這裡的 referee 不是人工 reviewer，而是能客觀判定結果的機制，例如 compiler、可攜式 test suite、API 輸出比對或實際情境測試。它必須先在舊系統上通過，再放入刻意破壞的程式碼，確認真的能抓出錯誤。否則「測試全過」可能只是測試根本沒測到問題。
第 1 階段：建立規則、相依地圖與差異清單
團隊先決定這次是忠實移植，還是連架構一起重新設計。忠實移植會建立 rulebook，規定舊語言的型別、慣用寫法與例外情境，在新語言中要如何對應；若是重新設計，rulebook 就要換成完整的 design document。
接著用 deterministic script 建立檔案與 package 的相依地圖。Deterministic script 指的是相同輸入會得到相同結果的腳本，適合用來決定工作順序，而不是讓 AI 每一輪自行猜測。
最後整理 gap inventory，把新舊語言之間無法直接對應的部分列出來。例如 Zig 轉 Rust 時，重點是記憶體 ownership 與 lifetime；Python 轉 TypeScript 時，則要補上 interface 與資料 contract。
第 2 階段：先壓力測試規則，不急著累積進度
Bun 團隊先挑 3 個檔案做試跑：一個 agent 按 rulebook 翻譯，另一個 agent 用資深 Rust 工程師的方式獨立處理，再由第三個 agent 比對差異、找出缺少的規則。
試跑產生的程式碼不保留，因為這個階段的目標不是完成 3 個檔案，而是找出一旦擴散到 1,448 個檔案就會大量重複的系統性錯誤。
這一步很符合產品開發的 MVP 思維：先用最小樣本驗證流程，而不是在錯誤規格上追求完成率。
第 3 階段：平行翻譯，讓不同角色互相制衡
規則通過壓力測試後，才開始全面移植。每個工作單位由 implementer 負責產生程式碼，再交給兩個獨立的 adversarial reviewers 找問題；若 reviewer 意見衝突，再交由第三個 agent 判斷。
對抗式審查（adversarial review）不是請 AI 確認「看起來是否正確」，而是把 reviewer 放在獨立 context，要求它假設程式碼有錯，主動找出失敗方式。
當相同錯誤反覆出現，團隊不逐檔手動修補，而是更新 rulebook，再重新產生受影響的批次。Anthropic 把這個原則濃縮成一句話：不要修那一行程式碼，要修正產生那行程式碼的 loop。
第 4 階段：編譯，讓錯誤成為機械式佇列
完成第一輪翻譯後，再由單一 build daemon 集中執行昂貴的 build。Build daemon 是唯一有權重新編譯的背景程序，fixer agents 只負責提交修正，避免數十個 agents 同時重複執行耗時工作。
不過，compiler 應該放在哪個階段，取決於成本。TypeScript type check 只需要幾秒，可以放進每個小循環；Rust 的 cargo 若需要數分鐘，就適合集中批次執行。
這不是模型能力問題，而是工作流的單位經濟。每一種驗證都有成本，成本決定它應該多久執行一次。
第 5 階段：執行最小可用情境
程式能編譯，不代表真的能工作。團隊先跑最小的 end-to-end command，再逐步加入 smoke tests，確認程式至少能啟動並完成核心路徑。
Smoke test 是快速確認主要功能沒有立刻失效的基本測試。它不能取代完整 test suite，但能在進入高成本驗證前，先排除最明顯的問題。
第 6 階段：比對新舊系統行為
最後才是 parity check，也就是用同一組輸入分別執行新舊系統，再比較輸出是否一致。若原有測試依賴舊語言內部結構，團隊就要另外建立只看外部行為的可攜式測試。
Anthropic 的 Python 轉 TypeScript 案例一開始沒有完整的可攜式 test suite，因此先建立 7 個真實使用情境，逐一比對新舊輸出。之後 Claude 又自行設計 end-to-end tests，連續 4 個晚上執行、修正並重跑。
這個階段的重點不是讓 AI 宣告完成，而是讓舊系統繼續擔任 executable specification，也就是「可以直接執行的規格」。
速度變快了，但成本與風險沒有消失
Bun 移植在合併前消耗 59 億 uncached input tokens、6.9 億 output tokens，以及 720 億 cached input token reads，按 API 價格估算約 16.5 萬美元。這已比 Anthropic 估計的傳統多年期人力成本低，但仍不是一般團隊能隨意嘗試的小額支出。
更重要的是，合併前完整 CI 測試全數通過，合併後仍發現 19 個已知 regression。這不代表測試沒有價值，而是說明測試覆蓋率再高，也不等於涵蓋所有真實環境與語言語意差異。
Rust 版本也不是完全沒有底層風險。Bun 官方表示，約 4% 的 Rust 程式碼仍位於 unsafe blocks，多數是與 C、C++ 邊界互動的指標操作。unsafe 代表開發者在特定區段自行承擔 Rust compiler 無法保證的記憶體安全責任。
另一方面，移植後的改善也能量化。在 Bun 官方一項重複執行 Bun.build() 2,000 次的測試中，記憶體占用由 6,745 MB 降至 609 MB；部分 HTTP 與實際工作負載快 2%～5%，Linux 與 Windows binary 也約縮小 20%。
我的結論是中性偏多。Claude Code 確實讓過去不具商業可行性的重寫案重新值得評估，但前提是團隊有足夠強的測試、清楚的成功門檻與可控的 token 預算。若缺少這三項，速度只會放大風險。
團隊想導入，先做一個有上限的 Migration MVP
不建議第一次就挑整個 production codebase。比較實際的做法，是選一個邊界清楚、維護痛點明確，而且可以獨立回滾的模組。
Migration MVP 可以設定五個 gate：
- 商業理由： 目前的 bug、build time 或維護成本，是否已高到值得遷移？
- 可驗證性： 是否有能在新舊版本共同執行的 test suite 或 parity harness？
- 成本上限： token、人工審查與運算預算超過多少就停止？
- 上線門檻： 功能一致、效能、資安與 regression 容忍度分別是多少？
- 回滾方案： 若 production 出錯，是否能立即切回舊版本？
第一次試點的成功，不應只看「轉了多少行」，而要看每千行需要多少 token、reviewer 抓到多少問題、測試能否穩定重現，以及回滾是否真的可用。
如果這些數字站得住腳，再擴大到下一個模組；若試點已反覆卡在需求歧義或不可重現的輸出，就應先補規格與測試，而不是增加 agents 數量。
Claude Code 程式碼遷移常見問題
Claude Code 可以直接把整套系統換成另一種語言嗎？
技術上可以處理大規模語言移植，但不等於只需要一個 Prompt。Anthropic 的案例先建立 rulebook、相依地圖、差異清單與測試裁判，再用多個 agents 分工執行。沒有這些前置工作，大量產碼很難轉成可以安全上線的系統。
沒有完整 test suite，也能使用這套方法嗎？
可以先建立只比對外部行為的 parity harness，但這本身就是一個工程專案。若連舊系統的正確輸出都無法定義，就不適合直接進入全面移植。
為什麼不逐步改寫，而要一次完成？
Bun 選擇忠實、全面移植，是因為長期維持兩套語言與橋接程式碼也有成本。不過這不是通用答案。JavaScript 轉 TypeScript 這類可逐檔採用的情境，官方 Migration Kit 也明確指出通常不需要完整六階段流程。
這套流程最大的風險是什麼？
最大的風險不是 AI 寫得慢，而是驗證機制看不見真正的錯誤。Bun 在合併前通過完整測試後仍出現 19 個已知 regression，因此 production rollout、觀測、fuzzing 與回滾仍不可省略。
Claude Code 遷移 100 萬行程式碼花多少錢？
Bun 官方表示，合併前共使用 59 億 uncached input tokens、6.9 億 output tokens 與 720 億 cached input token reads，按 API 價格估算約 16.5 萬美元。實際成本會受到模型、快取、審查層數、測試次數與 rate limit 影響，不能直接套用到其他專案。
Bun 為什麼不用 Zig，改成 Rust？
Bun 的主要考量是記憶體安全與長期穩定性。Rust 可以透過 ownership、borrow checker 與 Drop，在編譯階段阻止部分 use-after-free、double-free 與 memory leak；但 Rust 版本仍保留約 4% 的 unsafe code，因此不是零風險改寫。
Claude Code Migration Kit 在哪裡下載？
Anthropic 已在 GitHub 公開 Claude Code Migration Kit，包含 feasibility prompt、rulebook、gap inventory、dependency mapper、queue runner 與 build daemon。官方將它定位為參考程式碼，並未承諾持續維護，導入前仍要依自己的 codebase 調整。
Claude Code 可以直接用 /batch 做程式碼遷移嗎？
可以。Claude Code 官方的進階使用者技巧指出，/batch 會先詢問遷移需求，再將工作分配給多個採用 worktree 隔離的 agents，各自修改、測試並建立 PR。不過 Bun 的百萬行改寫還加入 rulebook、gap inventory、對抗式審查、集中 build daemon 與 parity test，不能只靠一條 /batch 指令重現。
結語：AI 降低重寫成本，工程判斷反而更重要
Anthropic 這次展示的，不只是 Claude Code 能產生 100 萬行程式碼，而是一套把大型遷移拆成規則、佇列、審查與機械驗證的工程方法。
對長期被記憶體 bug、建置瓶頸或舊技術生態拖累的團隊，這讓原本只能繼續忍受的問題，多了一個可評估的選項。但它只適合能清楚回答「什麼叫完成」的團隊。
如果要採用，我會先選一個可回滾模組做 Migration MVP，把 test suite、成本與 production regression 當成主要指標。能不能快速寫完，不是最重要的問題；能不能可靠地證明新版本與舊版本一樣，才是。
