hero

Anthropic 在 Claude Code v2.1.181 內建 Rust Bun 的同一週，發布了一篇看似誠懇的「大規模 AI 程式碼遷移實戰手冊」。兩個成功案例、六步驟方法論、精美的 before/after 數據——所有產品行銷文該有的元素都以經到齊了。真正值得讀的不是他們公開了什麼，而是他們選擇不說的那部分。

原文摘要

Anthropic 開宗明義：程式碼遷移——把一個生產環境的程式庫搬到另一個語言——過去是多年的工程，現在用 Claude Code 可以在幾週內完成。過去一個月，Anthropic 內部的開發者用 Claude Fable 5、Claude Opus 4.8 和動態工作流（dynamic workflows）完成了 10 個程式庫的遷移，規模從數萬行到數十萬行不等。這篇文章以其中兩個案例為例，整理了從這些專案中提煉出的最佳實踐。

第一個案例：Bun 共同創辦人、同時也是 Anthropic 技術成員的 Jarred Sumner，用 Claude Code 將 Bun 從 Zig 遷移到 Rust。不到兩週產出 100 萬行程式碼，Bun 現有的全部測試在 CI 中 100% 通過後才合併。合併後發現 19 個回歸（regression），已全部修復。這個 Rust 版本已在六月隨 Claude Code 一起出貨。

第二個案例：Anthropic Labs 共同負責人 Mike Krieger（Instagram 共同創辦人），在一個週末內將一個 Python 程式庫遷移成 16.5 萬行 TypeScript。過程中動用了數百個 agent、八個階段閘門（phase gate）、三輪對抗審查（adversarial review），以及最終的 parity check——對每一條指令的輸出都與 Python 原版做 diff。

Anthropic 從這些遷移專案中提煉出一個核心洞見：你不需要修程式碼，你需要修的是產出程式碼的那個流程（迴圈）。以下是他們的六步驟方法論。

遷移語言的時機與理由

團隊啟動遷移，通常是因為初始建構時的選擇與現在的專案需求之間出現了落差——要嘛已知的取捨變得無法忍受，要嘛出現了更好的方案，或者原始生態系正在萎縮。

以 Bun 為例，Jarred 最初選擇 Zig 是因為它能提供 C 等級的效能加上極端的簡潔——在 2021 年，一個獨立創辦人「在擁擠的奧克蘭公寓裡、還沒有 LLM 的時代，一年內寫出 Bun」，這個選擇完全合理。但到了 2026 年，Bun CLI 每月下載量已超過一千萬次，而且被大量用於 Claude Code 內部。

放在上一季，這些取捨還不足以凍結 roadmap。遷移語言可以產出更小、更快、更安全的系統，但沒有人想為此買單。現在，最壞情況也不過是刪掉分支重來一次——因為 AI 改變了成本結構。

Bun 遷移消耗了 59 億個未快取的輸入 token 和 6.9 億個輸出 token，以 API 定價計算約 16.5 萬美元。Mike 的遷移主要部分則消耗了 2,700 萬個 token。Anthropic 強調：遷移不再是存在級別的決策——過去需要「一整年的 changelog 全是記憶體 bug」才能正當化的遷移案，現在一個長期瓶頸就足夠了。

Mike 的專案是內部工具，打包成單一二進位檔（single binary）出貨給使用者。用 Python 工具鏈產出那個二進位檔，每個平台要花大約八分鐘。遷移後，同樣的編譯現在只要約兩秒，二進位檔啟動速度快了六倍。

為什麼 AI 改變了遷移的算式

Claude Fable 5 是 Anthropic 目前最強、已全面開放使用的模型。Fable 和 Opus 4.8 特別擅長委派、指揮、驗證平行工作流中的 subagent。大型程式碼遷移之所以特別適合 AI，有五個原因：工作本身可高度平行化（數千個獨立單元如檔案和 crate 可同時進行）；脈絡清晰且完整——舊程式碼就是最好的 spec；有內建裁判——現有的測試套件讓 agent 可以驗證自己的產出；工作佇列會自己長出來——編譯或測試失敗時，失敗本身就變成下一個待處理項目；最後，遷移要求一致性和邊界案例處理——漂移無處可躲。Mike 和 Jarred 都在關鍵步驟使用 Fable，尤其採用了一種「顧問模式」（advisory pattern），用多種模型類別來最佳化 token 消耗。

六步驟方法論

前置條件：在開始之前，你必須有一個夠強的裁判（judge），能夠在相同條件下評估原版程式碼和目標程式碼。建構裁判的方式是：分類現有測試（區分哪些可表達為外部呼叫、哪些依賴內部實作）、改寫為可攜式測試（轉換外部測試為可同時對原版和遷移版執行的斷言）、驗證裁判（對原版確認通過、對刻意破壞的程式碼確認失敗）。Jarred 有一個用 TypeScript 寫的大型測試套件，Mike 則建立了一個包含七個真實情境的 parity harness。Mike 甚至完整跑完整個遷移流程、根據結果修訂規則、再跑一次——每次丟掉產出，直到第三次才保留。

第一步：建立規則手冊（rulebook）、依賴地圖（dependency map）和缺口清單（gap inventory）。規則手冊必須先於缺口清單，因為缺口是由規則手冊的預設值無法覆蓋的部分所定義。規則手冊的形式取決於新程式碼是保留原有結構還是完全重新設計——Jarred 的主要是 Zig 與 Rust 之間型別和慣用語的對照表，Mike 的則是一份設計文件。Jarred 透過與 Claude 對話來建立規則手冊，對每個模糊地帶形成政策；他還設計了八個 subagent，專門審查八種不同類別的常見失敗模式。依賴地圖用來理解檔案之間的依賴關係，以便有效拆分平行遷移的工作流——對 C/C++ 和 Python 這類遺留程式庫，需要透過 Claude Code 部署 agent 來建立並執行確定性腳本以產出這個地圖。缺口清單記錄新語言的不同要求：Zig 到 Rust 的缺口是手動記憶體管理 vs 所有權系統，Python 到 TypeScript 的缺口是介面和合約——Python 不需要宣告接受的物件形狀，TypeScript 需要。兩人都建立了捕捉這些隱性知識的缺口清單檔案。

第二步：對規則進行壓力測試。做法是做一個小型遷移當作「試航」——Jarred 用一個 agent 依照規則手冊翻譯三個檔案，另一個 agent 用「資深 Rust 工程師」的方式翻譯同樣三個檔案，第三個 agent 比較兩者的 diff 來產生新的翻譯規則。他抓住了兩個關鍵問題，如果散佈到全部 1,448 個檔案，會造成大量麻煩。壓力測試結束後，丟掉所有翻譯出來的檔案——目標是精煉規則，不是累積進度。這個壓力測試只適用於保留結構的遷移；如果你的規則手冊是一份重新設計案，等效的測試是直接用對抗審查者攻擊設計文件本身。

第三步：全量翻譯。執行相同的多 agent 迴圈架構：實作、審查、修復。將實作工作卸載到較小的模型，審查者保留在較大的模型上——Mike 在主遷移中展開 12 個 subagent 時使用了 Claude Sonnet。工作佇列必須是機械式的——一個批次腳本透過檢查磁碟上是否存在已翻譯的檔案來判斷完成狀態，然後將待處理檔案切片成批次。因為佇列每次都從磁碟重建，遷移本身就是可恢復的。任何翻譯器無法自信執行的部分，會標記為 // TODO(port): <原因>，留到第四步處理。兩個對抗審查者用獨立的脈絡評估產出；審查者之間的分歧交給第三個 agent 裁決；當審查者反覆在不同檔案中抓到相同錯誤時，就在規則手冊中加一句話，然後重新生成受影響的批次。一個重要的設計決策：Mike 在每個迴圈內都執行 TypeScript 編譯器（一個單元幾秒就能檢查完），Jarred 則完全禁止編譯器進入迴圈，延後到下一步（cargo 編譯需要數分鐘）。

第四至六步：編譯、執行、行為匹配。這三步共享相同的迴圈架構，且需要越來越少的人類判斷。第四步，Jarred 用一個 orchestration 腳本對整個工作區呼叫一次編譯器，「修復 agent」平行處理錯誤清單，並經過對抗審查；然後再編譯一次，重複。第五步，機械式的真相來源類似編譯器錯誤清單——來自煙霧測試的崩潰，將問題按根本原因分組，由對抗 subagent 審查。第六步，比較兩個程式庫的行為：將檔案分片，對它們執行測試套件，用「修復 agent」對照兩個程式庫來審查失敗的測試，對抗審查者檢查修復。一個建構守護行程（build daemon）將最昂貴的操作（重建二進位檔）序列化，批次收集修補並重新執行受影響的測試。當同樣的失敗在許多測試中反覆出現時，修復就往上游移動：修正產生該 bug 的規則，然後只重新生成該規則觸及到的檔案。Mike 讓 Claude 建立一個小腳本，對新舊兩個程式庫執行七個真實情境，並對結果做 diff；然後 Claude 自己設計了一套端對端測試套件，在夜間自主執行、修復、重跑——連續四個晚上。

最佳實踐

不要盲目照著這份指南做——每個遷移都不一樣，先用 Claude 規劃。不要聚焦在個別失敗上——個別失敗是迴圈的工作，你的注意力應該放在模式上。讓審查變成對抗、驗證變成機械——對抗審查允許更長時間執行的任務，讓腳本當裁判。不要對所有任務都用最大的模型——小模型處理高量的實作展開，最大模型留給審查者和規則撰寫。把人類工時集中在前端——規則手冊和壓力測試最耗時，之後大部分只是佇列在消耗。讓工作佇列保持機械式和可恢復——「完成」的定義應該是「輸出檔案存在於磁碟上」。

成果與結論

Jarred 的 Bun 遷移現已上線生產環境。約 4% 的 Rust 程式碼位於 unsafe 區塊內，大多數是 C/C++ 邊界處的單行指標操作。新程式庫有可量測的改善：團隊工具能偵測到的每一個記憶體洩漏都已被修復——一項重複建構 2,000 次的 benchmark 從 6,745 MB 記憶體降到 609 MB；二進位檔在 Linux 和 Windows 上都縮小了 19%；跨語言最佳化讓 HTTP 服務和真實工作負載（如 next build 和 tsc）快了 2–5%。文章最後呼籲讀者：重新計算你拖延已久的遷移案的算式——挑一個你一直在忍受的程式庫，問 Claude 這個遷移流程對它來說會是什麼樣子。

城武觀點

觀點一：這是行銷文，不是工程分享。

文章發布的時機本身就是答案。Claude Code v2.1.181 內建 Rust Bun——就在同一週，Anthropic 發了這篇「實戰手冊」。一個獨立創辦人在奧克蘭公寓裡用手寫 Zig 的故事，配上「我們把 100 萬行 Zig 變成了 Rust，只花了兩週」的英雄敘事——這不是工程分享的寫法，這是產品上市前的 case study 模板。

最致命的證據藏在文末。Anthropic 坦承，他們公開的 migration kit 是「generalized template」，不是實際跑遷移的那個版本。換句話說，你拿到的是一份好看的骨架，但真正讓這件事成功的東西——Fable 5 在 advisory pattern 中是怎麼被用的、八個 subagent 各自對應哪八種 failure mode、對抗審查在多次迭代中怎麼演化——全部被省略了。

留下來的是什麼？「要有好裁判」「先做壓力測試」「不要所有事都用大模型」——這些不是 insight，是任何人在第一次嘗試之後就會自己長出來的常識。Anthropic 把真正的技術細節抽乾，灌進足以支撐一篇部落格文的內容，然後包裝成「我們來分享工程經驗」。我說這是行銷，因為發布時機、敘事結構、以及被省略的部分，三者加起來只有一種解釋：這篇文章的目的是讓你想買 Claude Code，不是讓你學會怎麼遷移程式碼。

觀點二：$165K 不是民主化，是寡頭化。

Anthropic 的敘事是：過去四年要花 300–400 萬美元的遷移案，現在兩週、$165K 就搞定了——「AI 讓大規模遷移民主化了」。

但 $165K 對絕大多數團隊來說仍然是天價。全球有多少新創公司能為了「遷移程式語言」這個非 revenue-generating 的工程活動，燒掉團隊一整季的 burn rate？答案是幾乎沒有。這不是從帝王到平民的民主化，這是從帝王專屬降到貴族階級——你從「只有 FAANG 做得起」變成「只有 A 輪以後的公司做得起」。進步是真的，但進步的幅度被過度包裝了。

更值得追問的是：這 $165K 裡，有多少是真正必要的 token 消耗，有多少是 Anthropic 自己的 multi-agent 架構為了「對抗審查」而刻意放大的？八個 subagent 互相審查、三輪 adversarial review、每個 disagreement 再開第三個 agent——這整套架構就是設計來讓 token 消耗乘上好幾倍的。用自家的模型、跑自家的 agent 架構、產出一個證明自家模型很厲害的案例——這以經不是第三方驗證，這是一個封閉的經濟循環。你花 $165K 給 Anthropic，Anthropic 拿你的錢證明自己很厲害，然後用這個證明來說服下一個客戶也花 $165K。

我賭一件事：如果今天用同樣的架構但換成開源模型（例如 DeepSeek 或 Llama 4）來跑同樣的遷移，token 成本至少可以砍掉一個數量級。但 Anthropic 不會做這個實驗，因為做了就等於拆自己的台。

城武的未解檔案——一份「實戰手冊」裡最實戰的部分全部被抽掉，留下來的是一個封閉迴圈的行銷劇本：用我的模型、花你的錢、寫我的成功案例。