Bun 1.4：從 Zig 到 Rust 的 AI 驅動重寫引發爭議

2026 年 5 月，Bun 團隊做了一件軟體行業多年來私下討論的事：他們用六天時間，藉助 AI 代理，將整個執行時從 Zig 重寫為 Rust。這可能是公開的最大的 AI 驅動程式碼庫遷移，涉及近百萬行程式碼。

資料：約 57 萬行 Zig 程式碼變成了約 68 萬行 Rust 程式碼（不含 AI 生成的註釋）；現有測試套件中 99.8% 一次性透過；生成的 Rust 程式碼包含 13,044 個 unsafe 塊（手寫 Rust 專案平均約 73 個），999 多處靜態可變狀態，262 處 ManuallyDrop 和 81 處 mem::forget。最大的檔案（JS 解析器 p.rs）有 9,765 行。

實現方式：重寫使用 Anthropic 的 Claude Code 和“動態工作流”系統，數百至數千個 AI 代理並行工作。管道流程如下：Claude 代理並行將檔案從 Zig 翻譯為 Rust；每個檔案有“對抗性審查員”（另一個 AI）查詢錯誤；構建和測試反饋迴圈自動修正；Bun 的建立者 Jarred Sumner 提供高層監督。由於 Bun 歸 Anthropic 所有，團隊擁有無限計算資源。

轉用 Rust 的原因：記憶體安全（Bun 因段錯誤積累聲譽）；編譯器速度（Bun 維護的 Zig 分支編譯快 4 倍，但維護負擔重）；AI 適配性——Rust 的編譯器能立即捕獲錯誤並提供精確位置和修復路徑，其他系統語言無法提供同樣質量的反饋迴圈。

程式碼質量爭議：雖然 99.8% 的測試透過率令人印象深刻，但程式碼質量粗糙。Reddit 使用者發現程式碼中存在“999 處靜態可變狀態”，並稱其為“全域性可變的義大利麵條式程式碼”。AI 甚至新增了註釋，承認程式碼不安全，但計劃在“第二階段”清理。批評者指出，在 13,000 多個 unsafe 塊且無人審查程式碼的情況下，“第二階段”可能永遠不會到來。

社群反應：r/rust 和 r/programming 板塊討論激烈。一些開發者認為這是對 Rust 語言的濫用，另一些則視其為工程突破。部分 Bun 使用者反饋新版本出現奇怪掛起和行為異常，但也有使用者（如 Prisma Compute）報告記憶體使用降低和連線池更穩定。

行業意義：這次重寫表明語言遷移不再需要多年時間；瓶頸正在從程式碼編寫轉向可維護性和安全性；Rust 因其編譯器的“安燈拉繩”可能成為 AI 生成系統程式碼的預設語言；信任成為核心問題——程式碼透過測試但無人閱讀。

結論：Bun 1.4 同時是一個工程實驗、Anthropic 的營銷策略、對 AI 生成程式碼的壓力測試和改進執行時的真誠嘗試。AI 在一週內翻譯百萬行系統程式碼的事實已經改變了軟體工程的規則，而社群是否準備好迎接這一變化仍是未知數。