Bun 創辦人以 Claude Code 於 11 天內完成 53 萬行 Zig→Rust 重寫，並以大規模測試、對抗式審查與多工作區並行流程，將高風險重構轉化為可驗證的工程實作。
Bun 創辦人 Jarred Sumner 以 AI 輔助開發工具 Claude Code，將 Bun 內部超過 53 萬行程式從 Zig 改寫為 Rust，整個專案在 11 天內完成，並產生 6,778 次 Git 提交，最高峰有 64 支 Claude 同時協作。[1][2][9]
這次重寫並非單純追求速度，而是要解決大型底層系統長期累積的記憶體管理問題。Bun 原本以 Zig 開發，隨著規模擴大，記憶體洩漏、重複釋放與越界讀寫等問題反覆出現，因此團隊改以 Rust 的記憶體安全機制作為重寫目標。[1]
更關鍵的是，這是一個原本被認為成本過高的工程。Jarred Sumner 估算，若採傳統方式，需要 3 位熟悉 Bun 的資深工程師投入一年，還可能迫使團隊暫停漏洞修補、新功能與相容性工作；AI 工具成熟後，這個原本難以啟動的計畫才真正落地。[1][3]
從工程方法看，這次成功的核心不是「讓 AI 直接改完整個專案」，而是先建立可重複、可驗證、可分工的流程。Jarred Sumner 先花 3 小時與 Claude 整理 Zig 轉 Rust 的規則，釐清資料型別、記憶體管理與錯誤處理原則，再挑 3 個檔案試跑，確認流程可行後才擴大到全量重寫。[1]
之後，他設計了 50 套 AI 工作流程，分別處理程式改寫、編譯、除錯、測試與程式碼審查等任務，並刻意將實作與審查分離。審查 Agent 只看修改內容，不看推理過程，且被要求預設程式有錯，藉此降低 AI 自我背書的風險，攔下記憶體過早釋放、時間格式錯誤與 Rust 函式行為差異等問題。[1]
在規模化階段，團隊把專案拆成 4 個獨立 Git worktree，每個 worktree 同時啟用 16 支 Claude，形成最高 64 支 Claude 並行作業的結構。這種設計把大型重寫拆解為高頻率、小步驟、可回滾的工作流，讓 AI 產出能持續被編譯與審查，而不是一次性生成大量不可控程式。[1][2]
驗證層面同樣重要。Rust 版 Bun 直接沿用原本以 TypeScript 撰寫的自動測試，以相同行為標準比對 Zig 版與 Rust 版的一致性。首次完整測試有 972 個測試檔失敗，但兩天後降到 23 個；最終驗證涵蓋 4,174 個測試檔、6 萬多個測試案例與約 139 萬次結果檢查，且未刪除或跳過任何測試。[1]
結果顯示，AI 不是取代工程驗證，而是把驗證節奏推到更高頻率。它能加速重寫，但真正決定專案是否可上線的，仍是編譯、測試、回歸修正與人工審查共同構成的控制迴圈。[1][5]
效能與維運面也出現可量化成果。Linux x64 測試中，HTTP 伺服器每秒請求量增加 4.8%，Next.js 建置速度提升 4.5%；Claude Code 在 Linux 上的啟動時間由 517 毫秒降至 464 毫秒。記憶體方面，舊版連續執行 2,000 次建置後升至 6,745MB，Rust 版則維持約 609MB，Windows 與 Linux 執行檔也縮小 20%。[1]
不過，重寫並未消除所有風險。來源指出，目前仍有 19 項已知功能退步，約 4% 的 Rust 程式碼仍使用 unsafe 來串接 JavaScriptCore 等 C、C++ 函式庫，代表關鍵邊界仍需人工確認安全性。[1]
這起案例的影響不只在 Bun 本身，而是直接改寫了大型系統重構的成本認知。過去，許多企業明知核心系統需要重寫，卻因人力、時間與機會成本過高，只能持續在舊架構上修修補補；Bun 的案例顯示，AI Coding 可能把這類「想做但做不起」的專案，推向可執行範圍。[1][3]
對開發流程而言，這代表重構不再只是語言遷移，而是「流程工程」的競賽。誰能建立更好的規則、測試、審查與並行機制，誰就更可能把 AI 的產能轉化為可交付成果。這也是為什麼 Bun 案例中，測試與審查機制比單純的模型能力更重要。[1][5]
對資安團隊而言，這個案例也提醒兩個現實。第一，AI 能快速擴大變更量，若缺乏安全基線，弱點也會被等比放大；第二，即便 Rust 降低記憶體錯誤風險，unsafe、第三方函式庫與跨語言邊界仍可能保留攻擊面，因此不能把「改用 Rust」誤解為「安全問題自動消失」。[1]
此外，該專案耗費約 16.5 萬美元的 API 成本，顯示未來大型重寫的主要門檻，可能從「工程師是否做得到」轉變為「算力、流程管理與品質控管是否跟得上」。這會影響企業如何評估技術債、重構排程與供應商依賴。[1][3][5]
若企業要把類似 AI Coding 模式導入核心系統，首先應建立可機器驗證的安全基線，包括單元測試、整合測試、回歸測試與行為一致性檢查，並要求任何大規模改寫都必須維持既有測試覆蓋率，不得任意跳過失敗案例。[1]
其次，應採取「實作與審查分離」原則。負責產生程式碼的 Agent 不應同時負責最終驗證，審查流程也不應只看推理過程，而要以變更內容、編譯結果與測試輸出為依據，以降低模型自我確認偏誤。[1]
第三，對於涉及 unsafe、C/C++ 函式庫或跨語言介面的程式碼，必須進行額外人工審查與記憶體安全測試。Rust 的優勢主要來自編譯器可檢查的安全範圍，一旦進入 unsafe 邊界，風險控制就不能只依賴語言本身。[1]
第四，應以小範圍試點驗證工作流，再逐步擴大。Bun 先從 3 個檔案試跑，再拆成 50 套流程與多 worktree 並行，顯示大型重寫最忌諱一次全量鋪開；對企業而言，先驗證流程、再擴張範圍，能有效降低失敗成本。[1]
第五，資安與維運團隊需同步監控功能退步、效能變化與檔案體積改動，因為重寫完成不代表專案已成熟上線。像 Bun 仍存在已知功能退步與 residual unsafe 區段，說明後續重構、補測與安全驗證仍是必要工作。[1]
5步驟修補清單
參考資料