事件背景：這不只是一次「換語言」
Bun 是整合 JavaScript／TypeScript 執行環境、套件管理器、打包器與測試工具的開發平台。InfoQ 報導，Bun 團隊將約 53.5 萬行 Zig 原始碼改寫為 Rust，整體計畫約歷時四個月，並隨 Bun 1.4 對外發布：https://www.infoq.com/news/2026/09/bun-AI-rewrite-zig-rust-4-months/。
不過，「四個月完成重寫」容易讓人誤解。Bun 創辦人 Jarred Sumner 的第一方說法是：AI 密集產生與移植程式碼、直到全平台測試通過的核心階段，從 5 月 3 日到 14 日僅花 11 天；其後還有合併、清理、資安檢查、模糊測試與正式發布。GitHub 發布頁則顯示 Bun 1.4.0 於 8 月 20 日釋出。因此，11 天指移植衝刺，四個月較接近從實驗、驗證到上市的完整週期，兩者並不矛盾。官方技術紀錄見：https://bun.com/blog/bun-in-rust；版本紀錄見：https://github.com/oven-sh/bun/releases。
運作機制：AI 不是直接按下「翻譯」鍵
依 Bun 官方揭露，真正可複製的部分不是某個提示詞，而是一套受約束的移植產線。團隊先建立 PORTING.md，定義 Zig 型別與慣用寫法如何映射到 Rust；再以 LIFETIMES.tsv記錄結構欄位的生命週期。每個檔案由一個實作代理移植，另有至少兩個、彼此上下文隔離的代理專門找錯，最後再交由修正代理處理。實作者不審查自己，審查者也不直接實作。
這套流程曾同時維持 64 個 Claude 執行個體，尖峰每分鐘產生約 1,300 行程式碼。更重要的是，Bun 原有以 TypeScript 撰寫、與底層實作語言無關的測試套件；三個平台各執行約 100 萬次以上的 expect() 檢查，且沒有為了過關而刪除或略過測試。官方估算，合併前消耗的模型權杖按 API 定價約為 16.5 萬美元。
合理推論：這不是證明「AI 能任意重寫百萬行系統」，而是證明當介面行為已有龐大自動化測試、移植規則可被形式化、工作能切成大量小單元時，AI 可以大幅壓縮機械式轉譯時間。缺少這些條件的企業舊系統，不能直接套用相同速度或成本。
為何現在值得注意
第一，這次轉換碰到的是系統軟體最昂貴的問題之一：記憶體生命週期。Zig 可用 defer在個別呼叫點安排清理，但開發者仍可能遺漏錯誤路徑；Rust 的所有權、借用檢查與 Drop，則可把部分釋放規則變成編譯期約束。Bun 表示，1.4 修正了 128 個可在 1.3.14 重現的既有問題，範圍涵蓋記憶體洩漏、崩潰與輸出錯誤。
最具體的例子是同一程序連續執行 2,000 次 Bun.build()：Bun 官方測試中，1.3.14 的記憶體用量升至 6,745 MB，1.4.0 則在 609 MB 左右趨於平穩。官方也測得數種 HTTP 工作負載的吞吐量提高約 2%至5%。這些是 Bun 自己的測試結果，足以顯示改善方向，但仍不等同於獨立基準測試，也不能保證每一種應用都會得到相同比例。
容易忽略的限制：Rust 與測試都不是免責條款
重寫本身也製造了 19 個已知回歸。部分原因正是 Zig 與 Rust 看似相同的語法具有不同語意，例如 Rust 的 debug_assert! 在正式版會移除整段運算，可能連帶消除原本含有副作用的函式呼叫。這提醒我們：編譯成功與既有測試全數通過，不代表所有罕見狀態、平台差異和未定義行為都已被涵蓋。
此外，這也不是「從不安全語言變成全安全 Rust」。官方統計當時約有 4%的 Rust 程式碼位於 unsafe區塊內，原因包括與 JavaScriptCore、C、C++ 函式庫互通。合併後，團隊又做了 11 輪資安審查，並讓解析器接受全天候 coverage-guided fuzzing；約 1,000 億次解析器執行帶來約 15 個修正 PR。換句話說，真正降低風險的是語言約束、測試、模糊測試、資安審查與人工複核的組合。
Zig 創辦人 Andrew Kelley 也提出值得保留的反方觀點：錯誤減少可能來自投入更多工程資源，而非單由語言選擇造成；若原測試套件未能阻止 Zig 版本累積問題，也不應假定它能完整驗證大批機器移植的 Rust 程式碼。他並質疑部分效能與檔案大小改善，究竟來自換語言，還是同時進行的工程整理。其原文帶有強烈立場，但這項技術質疑成立：https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html。
對台灣團隊的意義
作者觀點：台灣的韌體、資安、網通與雲端基礎設施團隊，不宜把此案讀成「Rust 勝過 Zig」或「AI 可以取代三名工程師」。更實用的啟示，是先盤點能否建立語言無關的行為規格、跨平台測試與可追蹤的生命週期文件。若這些資產不存在，AI 只會更快產生難以驗證的程式碼；若已存在，AI 才可能把跨語言移植從一次高風險豪賭，轉為可反覆驗證的工程流程。
後續觀察指標
- 1.4 後續版本是否持續出現與移植語意差異相關的回歸，而非一般功能錯誤。
unsafe程式碼占比、Miri 覆蓋範圍與模糊測試發現率是否持續改善。- 第三方正式環境能否重現記憶體與效能收益，而不只依賴官方基準。
- Rust 版本的編譯時間、貢獻者上手速度與長期維護成本，是否優於舊架構。
- 其他大型專案能否在沒有 Bun 同等測試密度與運算預算時，重現這套代理式移植方法。