[AI 影響] Bun用AI在11天內完成Rust重寫的啟示

 [AI 影響] Bun用AI在11天內完成Rust重寫的啟示

摘要 : Bun以AI協作流程在11天內將53萬行Zig重寫為Rust，效能提升且更安全。

內容:

最近開源社群出現一個很受矚目的案例：JavaScript工具 Bun，將原本53萬行的 Zig 程式碼，在11天內重寫成超過100萬行的 Rust 程式碼。Bun本身是很流行的 JavaScript 執行與開發工具，能處理執行、安裝依賴、打包與編譯，每月下載量超過2000萬次。這種規模的重寫，過去通常需要一個小團隊投入約一年的時間。

這件事特別值得注意，不只是因為速度快，更因為它證明了大型程式碼庫的重構，未來可以在AI協助下變得可行。過去多數人即使會用AI寫功能，也很少接觸幾十萬、幾百萬行程式碼的重構，因為時間與成本太高；而 Bun 這次提供了一個實際樣本。

在重寫策略上，作者沒有選擇增量替換，而是採取一次性全量重寫。原因是增量重寫雖然看似穩妥，但在中短期內會造成雙語言或雙系統並存，維護成本反而更高。此外，這次重寫並不是先大幅改造設計，而是先盡量保持原有邏輯不變，將 Zig 程式碼直接翻譯為 Rust，等到正式上線後再逐步調整成更符合 Rust 習慣的寫法。

真正關鍵的，是作者採用了 loop engineering 的方式：先明確任務邊界，再讓 AI 在邊界內反覆循環執行。整個流程分成寫程式碼、評審程式碼、修復問題三個環節，並以約50個並行工作流持續跑了11天。作者主要負責監控流程，若發現問題，就去修改整個 loop，而不是手動修某一段程式碼，因為調整流程才能避免後續任務重複犯同樣錯誤。

在品質控制上，作者用了對抗式評審：讓獨立上下文中的另一個 AI 專門審查剛產生的程式碼，且預設立場是「這段程式碼可能是錯的，請找出問題」。這種做法模仿人類工程中的程式碼評審機制，讓實作者與評審者角色分離，避免同一個模型在同一脈絡裡傾向為自己辯護。這也帶來實務啟發：AI寫完程式碼後，應另外開新上下文，只提供改動內容，要求它從反方角度找錯，往往比自我檢查更有效。

最終結果是，Rust版本不僅通過全部測試，還帶來記憶體安全，從根本上減少 use-after-free 這類問題。作者形容這次上線是「boring is good」—— Rust版安靜、穩定地上線，幾乎沒人察覺。這個案例也說明，當多個 AI agent 能持續並行工作時，人的角色並沒有消失，而是從親自寫程式轉向設計、監控與優化整個系統流程；這或許正是 loop engineering 真正的價值。