以AI速度合併
Bun專案使用AI將核心程式碼從Zig重寫為Rust,引發了關於AI生成程式碼、記憶體安全和測試可靠性的廣泛討論。文章分析了三個不同視角的爭議,並指出測試用例透過並不等同於程式碼驗證,強調了更強驗證標準的重要性。
2026年5月,JavaScript執行時Bun(內建於Claude Code)將其核心程式碼從Zig重寫為Rust,涉及約100萬行程式碼、6502次提交。Bun創始人Jarred Sumner坦言“我們已有數月未親手編寫程式碼”。媒體以“AI速度合併”報道此事,但兩個月後,Bun、Zig創始人以及資深開發者分別發文,揭示了這場重寫背後的複雜真相。
Bun官方解釋稱,重寫源於記憶體安全問題。混合JavaScript垃圾回收引擎與手動記憶體管理的Zig導致每週出現多次釋放後使用(use-after-free)等錯誤。Rust的編譯器可將此類問題轉化為編譯錯誤。然而,Zig創始人Andrew Kelley反駁道,問題不在於語言本身。他指出Bun的Zig程式碼長期存在“堆疊上的駭客”問題,且雙方關係早已破裂——Anthropic收購後,Bun停止了對Zig軟體基金會的每年6萬美元捐款,並忽視會議邀請。Kelley直言,當得知重寫時,“我們欣喜若狂”。
資深開發者Ray Myers則從營銷角度分析,認為管理層選擇了既能修復記憶體錯誤又能展示AI能力的方案。他指出,Bun的論證文章缺少利弊分析、編譯速度等關鍵內容。
三方爭議的核心矛盾在於測試覆蓋率的有效性。Bun聲稱透過了6萬項測試(138萬個斷言),但Kelley質問:如果測試套件足夠驗證100萬行AI生成的Rust程式碼,為何Zig版本仍存在大量錯誤?Myers也從外部指出,生成重寫程式碼的模型無法捕獲釋放後使用錯誤。最終,Bun承認重寫後存在19個已知迴歸錯誤,每個都是忠實翻譯但在新語言中語義不同的問題,例如Zig的assert在除錯和釋出版本中行為一致,而Rust的debug_assert!在釋出版本中會消除表示式。
Bun的重寫流程堪稱嚴謹:先編寫埠指南和生命週期表,然後使用多Claude架構進行程式碼生成和對抗性審查。最高峰時64個Claude並行執行11天,耗資16.5萬美元。儘管如此,仍未能避免這些語義錯誤。
相比之下,Ladybird瀏覽器在2月使用類似AI工具將JavaScript引擎前端從C++重寫為Rust時,採用了更強的標準:要求新舊管道的輸出位元組一致。透過52,898個test262測試和12,461個迴歸測試的零差異比較,以及即時網頁鎖步瀏覽,成功避免了類似迴歸問題。
這場爭論的最終教訓是:生成程式碼的成本已大幅下降,但驗證的差距仍是全部工作。Bun將合併標準定為測試透過,但測試僅能驗證已知行為,而重寫錯誤恰恰隱藏於未知行為中。更可靠的方法是定義和執行“行為一致”標準,透過輸出差異檢測和鎖步測試來確保新程式碼準確模擬舊程式碼的所有行為。
“AI速度合併”確實是現實,但它轉移了真正的焦點:生成幾乎免費,但驗證仍是全部工作。未來,當組織考慮讓AI代理重寫關鍵系統時,應採用更強的合併標準,並將人工審查作為最後防線。