Bun 把核心執行環境從 Zig 移植到 Rust，真正值得關注的，不是哪一種語言「勝出」，而是 AI 已能在極短時間製造百萬行變更，卻未同步解決驗證、分流與發布的瓶頸。這起事件因此同時是一場記憶體安全實驗、軟體重寫實驗，也是大型 AI 產碼如何進入正式工程流程的壓力測試。
事件背景：11 天完成，不等於 11 天交付
可驗證的事實是：Bun 在 2026 年 5 月 14 日合併 PR #30412，GitHub 顯示約 100.9 萬行新增、2,188 個檔案異動。Bun 創辦人 Jarred Sumner 表示，移植工作以約 50 套動態工作流程、尖峰約 64 個 Claude 實例完成，歷時 11 天；若按 API 定價估算，運算成本約 16.5 萬美元。相關 PR 與官方技術說明分別見 https://github.com/oven-sh/bun/pull/30412、https://bun.com/blog/bun-in-rust。
但「合併到 main」與「向一般使用者發布」是兩件事。官方文章明言，合併當下尚未有足夠信心推出正式版；截至本文查證時，GitHub 最新穩定版仍是 5 月 13 日發布、以 Zig 建置的 v1.3.14，Rust 版只在 canary 管道提供。發行紀錄可見 https://github.com/oven-sh/bun/releases。獨立開發者 Simon Willison 也從 Claude Code 執行檔驗出 Bun v1.4.0 與 Rust 原始碼路徑，交叉證實 Rust 版確實已在特定產品與 canary 使用，而非只是未執行的程式碼：https://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/。
缺陷統計說了什麼，又沒說什麼
原始分析蒐集合併前六個月至觀察截止日間的 2,981 筆 Bun issue，再以回報者填寫的版本字串區分 Zig 與 Rust build。作者指出，canary 每週回報量由 5.9 件增至 20.7 件；最終被關閉為已修復的比例則由 43.5% 變為 41.9%，全部 bug 的修復時間中位數由 2.7 天增至 3.2 天。原文與方法敘述見 https://medium.com/@asmyshlyaev177/i-counted-every-bun-bug-before-and-after-the-rust-rewrite-b6f1b69db49e?source=rss——rust-5。
這些數字支持的最保守結論，是「移植後尚未觀察到 issue 處理效率的明顯改善」，而不是「Rust 讓 bug 變多」。canary 在合併後成為取得新引擎的唯一管道，使用人數、測試動機與回報意願同時改變；issue 數本質上是實際缺陷、曝險人次與回報傾向的乘積。沒有安裝基數、執行時數或請求量作分母，就不能把每週回報量當成缺陷率。
語言安全與產品穩定，是不同層級的問題
Rust 的商業邏輯仍然成立：對生命週期、所有權與釋放路徑已有明確規格的程式碼，借用檢查器與 Drop 能把部分 use-after-free、double-free 與漏釋放問題提前成編譯錯誤。Bun 官方也表示，v1.4 已修復 128 個可在 v1.3.14 重現的問題，並以完整 TypeScript 測試套件作跨語言相容性檢查。
限制在於，Bun 並非純 safe Rust。官方揭露約 4% Rust 程式碼位於 unsafe 區塊，原因包括 JavaScriptCore 與其他 C、C++ 函式庫介面。這表示 Rust 能縮小需要人工證明安全的範圍，卻不能替整個系統自動背書。測試全數通過也只證明已編碼的行為；未被測試涵蓋的資源生命週期、重入條件與長時間負載，仍可能出錯。
真正的瓶頸已移到人類端
合理推論是，Bun 現在遭遇的主要限制不再是「能否產出移植程式碼」，而是維護者能否消化結果。原始研究觀察到合併後約半數新 issue 未加標籤，穩定版發布亦停頓；這可能代表分流能力被大量回報壓垮，也可能是團隊刻意延長 canary 驗證。僅憑公開 tracker 無法判定是癱瘓還是審慎，因此把沒有穩定版直接歸因於 Rust，證據仍不足。
作者觀點是：Bun 案例最大的訊號，不是「AI 取代工程師」，而是程式碼產能與組織驗證能力開始脫鉤。百萬行一次合併讓傳統逐行審查失去可行性，團隊只能把信任轉移到測試、靜態分析、模糊測試、分階段發布與可回滾設計。若這些控制面沒有先擴充，AI 節省的撰寫時間，很可能改以更長的整合期、事故調查與維護成本付回去。
對台灣工程團隊的意義
台灣不少軟體團隊同時面對舊系統、缺工與導入 AI 的壓力，Bun 提供了一個比「每行成本」更實用的評估框架：先盤點規格是否固定、測試是否可作為行為判準、能否讓新舊版本並行，以及發布後是否有足夠的遙測與回滾能力。若需求仍頻繁變動、測試只覆蓋主要流程，百萬行移植速度不是資產，而是更快累積未知風險。
後續應觀察的指標
- Rust 版正式發布後，以活躍安裝量或執行時數正規化的 crash、記憶體洩漏與回歸率。
- issue 加標籤時間、首次回應時間、修復中位數與重新開啟比例能否恢復。
unsafe範圍、Miri 與模糊測試覆蓋率是否持續改善，而非只增加測試總數。- v1.4 穩定版發布節奏、canary 到 stable 的阻擋條件，以及重大問題的回滾紀錄。
在這些資料出現前，最準確的結論仍是：Bun 已證明 AI 能大幅壓縮大型機械式移植的製作時間；它尚未證明百萬行重寫能同幅度改善穩定性，也尚未證明人類整合成本會隨產碼成本一起下降。