Bun 的 Rust 重寫真正值得追問的，不是「AI 能不能一次產出百萬行程式碼」，而是這批程式碼何時能成為可穩定發布、可長期維護的產品。產碼速度已獲得證明；整體成本、品質與維護效率，仍在接受現實世界的檢驗。
從 11 天重寫到尚未正式發布
獨立開發者 Tom Lockwood 的查核文章指出，Bun 團隊在 2026 年 5 月將 Rust 版本合併進主分支，但截至 7 月 27 日仍沒有新的正式版標籤；同時，由 robobun 建立的待處理 pull request 快速增加。他據此質疑，外界把「合併完成」解讀成「產品重寫完成」，是否過度樂觀。原文可見：https://lockwood.dev/ai/2026/07/27/how-is-the-bun-rewrite-in-rust-going.html
這項質疑有事實基礎，但需要補上一個重要脈絡：Bun 官方文章本身已明言，合併進 main 並不等於版本發布；當時只是決定投入這條路線，信心還不足以正式出貨。官方稱 Bun v1.4.0 才會是第一個 Rust 正式版，而查證時 GitHub Releases 的最新版仍是 5 月發布的 Zig 版 v1.3.14。來源：https://bun.com/blog/bun-in-rust、https://github.com/oven-sh/bun/releases
AI 寫的不是一個補丁，而是一條生產線
根據 Bun 官方說法，創辦人 Jarred Sumner 使用尚未公開的 Claude Fable 5，在 11 天內同時維持約 50 個動態工作流程，尖峰約有 64 個 Claude 實例運作。流程不是單一提示詞，而是先建立 Zig 到 Rust 的移植規則與生命週期表，再由不同代理分別負責實作、兩輪對抗式審查及修正，最後以既有跨平台測試套件作為行為相容性的門檻。
官方列出的合併前成果包括 6,778 次提交、超過 100 萬行新增差異，以及 Debian、macOS、Windows 上各約 5.7 萬至 6 萬項測試全部通過。合併前模型用量按 API 定價約為 16.5 萬美元。然而，這個數字只代表模型推論費用，不能直接視為專案總成本；文章沒有揭露工程師工時、EC2、Buildkite、儲存、重跑測試與合併後維護成本。
為何現在值得注意
來源事實是：Bun 已被 Anthropic 收購，Bun 團隊成員在 Anthropic 任職，重寫又使用 Anthropic 尚未公開的模型。合理推論是，這既是內部「吃自己的狗食」，也是展示 Claude 能否處理大型真實程式庫的示範場。本文觀點則是：它證明了 AI 可以大幅壓縮「機械式移植到測試通過」的時間，但尚不足以證明 AI 可以取代開源維護者。
理由很直接。Sumner 並非旁觀者：他設計移植規則、監看工作流程、人工檢查測試確實執行、閱讀部分新舊程式碼，最後親自決定合併。官方也說，持續模糊測試所產生的修正仍由人類審查。這比較像是一名高度熟悉程式庫的工程師，操作大量平行代理放大產能，而不是無人化維護。
已經產生影響，但證據尚未閉環
不能因為尚無穩定版，就斷言重寫失敗。官方表示，Rust 版本已供 canary 使用，2026 年 6 月 17 日之後的 Claude Code 也採用這個版本，Prisma Compute 公測同樣已部署。官方另宣稱 v1.4 修正 128 個可在 v1.3.14 重現的問題、降低記憶體與二進位大小，部分效能提高 2% 至 5%。但這些效能與穩定性數據目前主要出自 Bun 自己，仍需要正式版、外部基準測試及長期故障資料驗證。
容易忽略的限制
首先，測試全過不等於沒有未覆蓋的錯誤。官方承認移植後發現並修正了 19 項已知退化，且約 4% 的 Rust 程式碼位於 unsafe 區塊。外部貢獻者也曾提出可在安全介面後形成懸空參照的未定義行為案例；該議題目前已關閉並連結修正，但它說明「改用 Rust」不會自動消除由忠實機械移植帶來的生命週期風險。案例：https://github.com/oven-sh/bun/issues/30719
其次，pull request 數量不能直接當成缺陷數。robobun 查詢頁面在本次查證時顯示 2,498 個待處理 PR，但其中可能包含測試加速、CI 調整、新功能、重複或可直接關閉的提案；它們也不必依序執行同一條管線。因此，原文把所有 PR 換算成連續數十天 CI 時間，只能視為提醒審查負荷的示意，不能視為工期預測。公開清單：https://github.com/oven-sh/bun/pulls/robobun
同樣地，原文依每日支出外推接近 80 萬美元，是假設情境，並非已揭露帳目。可以確定的是 16.5 萬美元只涵蓋合併前 API 定價；無法確定的是後續實際模型、CI 與人力支出。兩者不能混為同一項已證實數據。
對台灣軟體團隊的意義
台灣團隊若想複製這個案例，最大的落差未必是模型能力，而是前置資產：成熟且跨平台的測試套件、熟悉舊系統的核心工程師、可承受大量平行運算與失敗重跑的預算，以及清楚的回滾機制。Bun 還使用一般企業當時無法取得的預發布模型，因此 11 天與 16.5 萬美元都不應直接拿來編列本地專案時程。
較務實的做法，是把 AI 大規模重寫視為高吞吐量的遷移工具，而非人力替代方案。決策指標也不該是產生幾行程式碼，而應是每個可發布功能的完整成本、人工審查時數、逃逸缺陷、效能退化、回滾次數，以及原團隊之外的工程師能否理解並維護新程式碼。
後續觀察指標
- Bun v1.4 穩定版何時發布，以及 canary 到正式版之間新增多少修正。
- robobun 待處理 PR 的淨增減、合併率、關閉率與人工審查時間。
unsafe比例、Miri 覆蓋範圍，以及正式版的安全與退化問題數。- 外部使用者能否重現記憶體、效能與穩定性改善。
- Bun 是否揭露包含模型、運算、人力與後續維護在內的總持有成本。
Bun 已證明 AI 能把過去近乎不可行的大型重寫，快速推進到可測試、可試用的階段；它尚未證明的是，這條路比持續重構更便宜、更安全，也更容易維護。真正的終點不是 merge 按鈕，而是穩定版本發布後，缺陷、成本與維護負擔都能持續下降。