兩週搬完一百萬行代碼：Anthropic用Claude把多年不敢碰的語言遷移壓進一個週末

把一門程式語言整套換掉，放在過去幾乎等於替公司立下一個兩年以上的軍令狀。工程師們聞之色變，預算委員會避之唯恐不及，許多老舊的程式碼就這樣卡在原地動彈不得。然而，Anthropic 在 7 月 16 日發表的一篇文章，直接改寫了這條鐵律：過去一個月內，他們內部的開發者利用 Claude Fable5、Opus4.8 以及動態工作流，將十個包含數萬到數十萬行程式碼的軟體包，乾淨俐落地遷移到全新的語言上。這不再是未來式想像，而是真實發生在他們身上的事實。其中最引人注目的兩個案例，猶如兩根釘子，把想像牢牢釘進現實。

Bun 的共同創辦人 Jarred Sumner 使用 Claude Code，在不到兩週內將整個 Bun 從 Zig 遷移到 Rust，產出一百萬行程式碼；合併進主幹之前，整條 CI 測試鏈以 100% 通過率過關，合併後僅出現 19 個迴歸錯誤，如今已全數修復，Rust 版本早在 6 月就隨著 Claude Code 發佈。另一邊，Anthropic Labs 的聯合負責人 Mike Krieger，只用一個週末就將一套 Python 程式庫搬成了 16.5 萬行的 TypeScript，裡面包含數百個代理、8 道階段閘門、3 輪對抗審查，最後還用奇偶校驗逐字比對每一條命令的輸出。

Anthropic 把這套打法提煉成一句話：你修的不是程式碼，而是生產程式碼的那個流程本身。一旦看透這點，那些被無限期擱置的遷移計畫，就不再是不可觸碰的禁區。團隊啟動遷移的時機通常來自於技術地形與現實需求的脫節：可能是當初權衡的優點如今成了瓶頸，可能是出現了更好的路徑，也可能是原先生態正在萎縮。Jarred 當年選擇 Zig，是看中它 C 級別的性能和極致簡單，讓一位創始人在奧克蘭的小公寓裡用一年寫出 Bun；但簡單也有代價。到了 2026 年，Bun 的指令列工具月下載量突破一千萬，這些代價已足以凍結路線圖，卻仍沒有人願意押上數季資源去動它。現在情況不同了。

最壞的結果不過是刪掉那條分支，重新再來。當然，商業帳還是要算。一百萬行級別的遷移，雖然不必再像四年專案那樣燒掉三四百萬美元工程師資源，但落地仍需花費數萬到數十萬美元。Bun 那次遷移消耗了 59 億個未緩存輸入 token 和 6.9 億個輸出 token，按 API 定價約合 16.5 萬美元；Mike 的遷移也燒了 2700 萬 token。真正驅使 Mike 下定決心的，是編譯速度這道坎。他的團隊以單一二進位檔案交付內部工具，用 Python 工具鏈編譯每個平台需約八分鐘，整個建構矩陣一輪要等三十分鐘；遷移後，同樣的編譯只需兩秒，二進位啟動速度快了六倍，還順手淘汰了一條獨立的部署管線。

為什麼 AI 能算平這筆舊帳？因為大規模程式碼遷移剛好是高階模型的絕佳場景。這項工作天然可以並行處理：檔案、crate 等成百上千的獨立單元可以讓代理同時開工，上下文既清晰又完整，舊程式碼本身就是最好的規格說明書，測試套件則充當鐵面無私的裁判。隊列會自己產生：編譯器或測試一掛，下一個要修的任務就自動排上。流程本身讓偏差無處藏身，審查員每一條發現都得引用背後規則，一次違規變成一個待辦項，而不是悄悄分叉。Anthropic 從這兩場遷移中提煉出了一套可複用的六步法。第一步是備好一個鐵面無私的裁判。這個裁判必須能站在同一標準上同時評判原始碼和目標碼。

用原語言寫的測試套件往往依賴目標碼裡不存在的內部函數，因此得先用 Claude 分類測試、改寫成能同時跑在兩種版本上的斷言，再派對抗代理驗證改寫沒有削弱斷言力度。第二步是立規矩、畫依賴圖、列缺口清單。規則手冊的內容取決於是否沿用舊結構：沿用結構就像一張翻譯查表，徹底重做則是一份設計文檔。依賴圖要摸清檔案間的關係，才能有效切分並行流；缺口清單則記錄新舊語言之間的硬差距，例如 Zig 轉 Rust 差在手動記憶體管理，Python 轉 TypeScript 差在介面與契約。第三步是壓一壓規則，進行一場迷你遷移當試航。

Jarred 派一個代理照手冊翻三份檔案，另一個像資深工程師那樣翻三份，再用第三個代理拿著兩份差異去提煉新規則；就在這個階段他逮住了兩個致命問題，否則等到攤開全部 1448 個檔案時麻煩就大了。壓力測試只對結構保持型遷移有效；若是重設計，就該用對抗審查員轟炸設計文檔，再以一次可丟棄的端到端跑通驗證。翻出來的檔案全部扔掉——這一步只是磨利規則，不是累積進度。第四步是翻譯一切。剩下的步驟都跑同一套多代理循環：實現、審查、修復。實現這類苦力活可以交給小模型，審查留給大模型；任務隊列要機械到無聊——一個批次腳本根據翻譯後的檔案是否在磁碟上來決定完工與否。

代理有時會過於謹慎，解法就是一條帶著上下文的指令，提醒它下一步編譯器會替它抓錯。翻譯器沒把握的地方就標上 TODO，留給第四步。從這裡開始，待辦清單自己會寫：編譯器數出錯，冒煙測試逮住崩潰，測試套件報出失敗。兩個對抗審查員用各自的上下文打分，意見相左就交給第三個代理。當同一種錯誤在多個檔案中反覆出現時，修法不是逐檔案打補丁，而是在規則手冊裡加一句話，把受影響的批次重新生成。第五步是編譯。取決於語言與規模，它通常會與第三步融合。Jarred 用一個編排腳本在整個工作區調一次編譯器，修復代理並行掃描錯誤清單，對抗審查同步進行，建構重跑，如此往復。

翻錯誤清單能幫你抓出系統性毛病的根因，例如他修完循環依賴後冒出幾千個 Rust 模塊錯誤，便給循環加了一段邏輯來分類處理。第六步是行為比對，也就是把預備階段那套測試套件套上去跑，失敗的交給修復代理對著兩套程式碼審查，對抗審查員再查它們的修法。Mike 更進一步，讓 Claude 自己設計端到端測試套件，通宵自主運行，連跑四個晚上，逮住了任何場景清單都預測不到的細微破綻。這套打法跑下來，有幾條實踐在每個專案上都站得住腳。

別盯著單點失敗——那是循環的活兒，修復代理會替你磨平；讓審查保持對抗、讓驗證保持機械；把 token 開銷集中在循環裡，小模型扛高吞吐的實現鋪開，最大模型留給審查員和規則手冊的撰寫者。把人的工時前置，規則手冊和壓力測試最耗時間，之後基本上就是隊列在燒。回到結果本身：Jarred 的 Bun 遷移已經上線生產，雖然約 4% 的 Rust 程式碼留在 unsafe 區塊裡，但新程式庫明顯更好——記憶體洩漏全修乾淨，二進位在 Linux 和 Windows 上小了 19%，HTTP 服務與 next build、tsc 等真實負載上快了 2% 到 5%。

那些你一直忍著沒動的程式庫，也許是時候重新算算這筆帳了。挑出那個容忍最久的傢伙，問問 Claude，為它做一場遷移到底長什麼樣。