史上最高調(diào)的AI重寫：Claude花11天搞定Bun，創(chuàng)始人花一個月才敢交底

作者 | Tina

2026 年 5 月，Bun 項目完成了一次在軟件開發(fā)史上近乎罕見的大規(guī)模代碼遷移。

這次遷移從 5 月 3 日啟動，到 5 月 14 日正式合并入主分支，只用了 11 天。寫代碼只用了 6 天，并且整個過程公開。但 Jarred Sumner 寫博客總結(jié)卻花了快一個月，比寫代碼的時間長多了。

這個 JavaScript 運行時原本擁有 535,496 行 Zig 代碼，不包括注釋；同時，約 20% 的代碼由 C++ 編寫，并嵌入了多個 C/C++ 庫。此次借助 AI 重寫為 Rust，整個過程涉及超過 100 萬行代碼變更、6778 次提交，并在 Claude Code 中運行了大約 50 個動態(tài)工作流（dynamic workflows）。

根據(jù) Sumner 披露的數(shù)據(jù)，這次重寫在 API 層面消耗了 59 億個未緩存輸入 token、6.9 億個輸出 token，以及 720 億個緩存輸入 token 讀取，按 API 定價計算約花費 16.5 萬美元。

Sumner 說，這是目前技術(shù)所能達到的前沿水平。他估計，如果讓 3 名完全熟悉 Bun 代碼庫的工程師手工完成這次遷移，大約需要一年時間，而且在這一年里，團隊幾乎無法繼續(xù)推進新功能開發(fā)、bug 修復和安全修復。

這次重寫之后，Bun v1.3.14 成為最后一個 Zig 版本，Bun v1.4.0 將成為第一個 Rust 版本。

1 成果：從 6.7GB 內(nèi)存泄漏到 609MB 穩(wěn)定

Bun 最初是一個 Zig 項目，覆蓋面非常廣：它既是 JavaScript 和 TypeScript 轉(zhuǎn)譯器，也是打包器、包管理器、測試運行器、模塊解析器、HTTP 和 WebSocket 客戶端，還實現(xiàn)了 Node.js API 層。正是這樣的產(chǎn)品寬度，讓 Bun 的 CLI 月下載量超過 2200 萬次，并獲得了 Vercel、Railway、DigitalOcean、Claude Code 和 OpenCode 等項目或公司的支持。

但同樣是這種寬度，也給 Bun 帶來了一些挑戰(zhàn)。

特別是在 Bun v1.3.14 中，有一個讓大家頭疼已久的問題：連續(xù)執(zhí)行 Bun.build() 調(diào)用時，內(nèi)存會不斷累積，永不釋放。每次構(gòu)建大約泄漏 3MB，看起來不多，但如果你運行的是一個開發(fā)服務器，每次請求都觸發(fā)一次構(gòu)建，那么內(nèi)存就會被一點點吞噬，直到進程崩潰。

在實際測試里，執(zhí)行 500 次構(gòu)建后內(nèi)存占用 1.9GB，1000 次后 3.5GB，1500 次后 5.1GB，2000 次后飆升到 6.7GB。

這只是諸多內(nèi)存問題的冰山一角。在 v1.3.14 的 bug 修復清單中，Sumner 列出了一長串問題：

zlib 模塊里調(diào)用.reset() 時，如果還有一個異步.write() 正在線程池中執(zhí)行，進程就會因為"堆釋放后使用"而崩潰；http2 模塊里嵌套的 JavaScript 回調(diào)觸發(fā)了哈希表重哈希，導致內(nèi)部流指針失效；UDPSocket.sendMany() 在遍歷過程中，如果用戶代碼通過 valueOf 或 toString 回調(diào)改變了套接字的連接狀態(tài)，就會發(fā)生越界寫入；crypto.scrypt 在輸出緩沖區(qū)分配失敗時，回調(diào)和受保護的密碼緩沖區(qū)永遠得不到釋放；......

這些 bug 的共性非常明顯——它們幾乎都指向同一個根源：將 GC 與手動內(nèi)存管理在同一個軟件里混合使用。

JavaScriptCore（以及 V8）這樣的現(xiàn)代引擎對異常處理和 GC 有極其嚴格的規(guī)則，而 Zig 像 C 語言一樣不會自動管理內(nèi)存。當這兩種范式在同一個進程中，每個內(nèi)存分配都需要被逐行審查：這些字節(jié)在哪里被釋放？怎么確保只釋放一次？是否正確檢查了 JavaScript 異常？這個被 GC 管理的指針對保守棧掃描器可見嗎？這是 GC 內(nèi)存還是手動管理的內(nèi)存？

更令人焦慮的是，團隊并非沒有努力。他們已經(jīng)給 Zig 編譯器進行了修改，加了 Address Sanitizer 支持（ASAN），每次提交都在 CI 中運行 ASAN 測試，在 Windows 上使用 ReleaseSafe 構(gòu)建，用 Fuzzilli 做 24/7 的模糊測試，還有大量端到端的內(nèi)存泄漏測試。即便如此，崩潰報告仍然源源不斷。

“我們的 bug 修復列表讓人感覺很糟糕，我厭倦了帶著對 Bun 崩潰的擔憂去睡覺。”Sumner 寫道。他并不責怪 Zig——其他 Zig 用戶并沒有遇到 Bun 這樣的問題，因為將 GC 與手動管理內(nèi)存混合使用，本身就是一種極罕見的需求，幾乎沒有語言為此設(shè)計。

而 Rust 版本交出的答卷是：同樣執(zhí)行 2000 次 Bun.build()，內(nèi)存穩(wěn)定在 609MB。

除了內(nèi)存泄漏問題得到根本性解決，Rust 重寫還帶來了其他幾個維度的改善。

在穩(wěn)定性方面，v1.4.0 修復了 v1.3.14 中可復現(xiàn)的 128 個 bug，從內(nèi)存泄漏到崩潰到顏色顯示錯誤的幫助文本都得到了解決。

從體積上，結(jié)合 Rust 重寫、ICU 更改和相同的代碼折疊，Bun 在 Linux 和 Windows 上的二進制文件大小減少了約 20% 。

在性能方面，普遍提升了 2% 到 5%。Bun.serve 從 16.96 萬 req/s 提升到 17.77 萬 req/s，node:http 從 10.38 萬提升到 10.85 萬。實際應用場景中，next build 從 13.62 秒降至 13.03 秒，tsc 批量編譯從 0.94 秒降至 0.89 秒。

而 Claude Code 在基于 Rust Bun 發(fā)布后，Linux 上的啟動時間從 517ms 降至 464ms，快了約 10%。

2 方法：64 個 Claude，11 天，50 個工作流

Sumner 是怎么做到的，這可能是最值得關(guān)注的部分——因為他用的方法，和傳統(tǒng)的“讓 AI 寫代碼”不同。

Sumner 把整個過程拆成了大約 50 個動態(tài)工作流，每個工作流都是一個循環(huán)。他在博客里用偽代碼描述了這個模式：

每個任務都有一個上下文（比如一個 Jira ticket 或 GitHub issue），Claude 基于這個上下文寫出代碼，然后兩個審查者（也是 Claude）審查代碼，最后應用反饋。完成之后，再取下一條任務。

這種模式貫穿了整個重寫過程。每個工作流負責一個特定目標：

• 生成一份 porting guide，把 Zig 的模式和類型映射到 Rust 的模式和類型；

• 把每個 .zig 文件機械式移植成一個 .rs 文件，并匹配 PORTING.md 和 LIFETIMES.tsv；

• 修復每個 crate 的編譯錯誤；

• 讓 bun test 或 bun build 這樣的 subcommand 跑起來；

• 讓 Bun 整個測試套件里的每個測試都通過；做幾輪大型重構(gòu)和清理。

峰值時期，Sumner 同時運行了 4 個工作流，每個工作流里 16 個 Claude，總共 64 個 Claude 同時在 4 個工作樹中并行工作，各自提交和推送文件。在最高峰時，Claude 每分鐘寫了約 1300 行代碼。

這種“實現(xiàn)者 / 審查者”的分離設(shè)計是關(guān)鍵。寫代碼的 Claude 想讓代碼被接受，這和人類工程師一樣有偏見。所以審查者和實現(xiàn)者完全分開——審查者只看代碼差異，不看實現(xiàn)者的推理過程，而且被明確告知“假設(shè)代碼是錯的”。每個實現(xiàn)者對應兩個以上的對抗性審查者，審查者的唯一工作就是找 bug。

代碼寫完只是第一步。Zig 代碼是單一編譯單元，而 Rust 要拆分成約 100 個 crate 來加快編譯速度，循環(huán)依賴導致了 cargo check 一次性輸出約 16000 個編譯錯誤。對于一個人來說這是災難，但對于 64 個并行工作的 Claude 來說，這是可以處理的工作隊列。工作流把錯誤按 crate 分組，每個 crate 跑一遍 cargo check，一個 Claude 修復，兩個審查，一個應用修改。

接下來是讓 bun --version 跑起來，然后是 bun test。測試工作流每次隨機跑 100 個測試文件，分片到 4 個工作樹。測試套件也包含好幾種：有些測試會運行超過一分鐘，有些會耗盡系統(tǒng) TCP 連接數(shù)，有些會 fork 約 10000 個進程。Sumner 用 systemd-run 創(chuàng)建 cgroup 來限制資源，但機器還是因為磁盤空間不足崩潰了好幾次。

兩天后，Linux 平臺的失敗測試從 972 個降到了 23 個。一天半之后，Linux 全綠了。五天后，全部六個平臺——Linux x64、Linux arm64、macOS x64、macOS arm64、Windows x64、Windows arm64——全部通過。

5 月 14 日，PR 正式合并，測試套件全部通過，沒有跳過或刪除任何測試。

3 隱憂：13,000 個 unsafe 和無法逐行審查的代碼

不過，Sumner 也承認，這項工作還沒有真正結(jié)束。

截至目前，Bun 的 Rust 代碼中大約有 4% 位于 unsafe block 內(nèi)，約 13,000 個 unsafe 關(guān)鍵字，分布在約 27,000 行代碼中，而 Rust 總代碼量約為 780,000 行。其中 78% 的 unsafe block 只有一行，通常是一個來自 C++ 的指針，或者一次對 C 庫的調(diào)用。

他預計后續(xù)重構(gòu)會讓這個比例降下來。但有人算了一筆賬：uv 約 35 萬行代碼，只有 73 次 unsafe 調(diào)用。而 Bun 的 unsafe 數(shù)量是 uv 的 178 倍。這個差距很難用“需要調(diào)用 C 庫”來解釋。

并且隨后還在安全 Rust 代碼中也暴露了未定義行為。這比 C++ 還難調(diào)試，因為你會以為安全代碼不可能出問題。

Bun 團隊隨后把這個問題中的 PathString::init 改成了 unsafe fn。

Sumner 自己也承認，這次重寫引入了 19 個已知的回歸問題，并表示大多數(shù)回歸問題都源于語法相同但語義不同的代碼。

比如這兩個代碼片段看起來很相似，但行為卻截然不同。Zig 的代碼 assert 是一個函數(shù)，因此它的參數(shù)在每次構(gòu)建中都會運行。Rust 的代碼 debug_assert! 是一個宏，因此在發(fā)布版本中，整個表達式（包括函數(shù)調(diào)用）都會被刪除 insert_stale。

雖然已經(jīng)問題都修了，但這并不表示百萬行 AI 代碼就沒有其他問題。

正常人誰會在一個運行時被徹底重寫之后，立刻把自己的生產(chǎn)應用遷過去？如果以為 1.4 版本沒有引入新的 bug，或者沒有帶來行為變化，那就太天真了。

還有一個不能忽略的事情是代碼審查。100 萬行的變更實際上沒法由人類逐行看——就算一分鐘看一行，也要連續(xù)看 11.7 天；按實際的代碼審查速度（一小時 200 行），要兩年多才能看完。

這次 PR 的審查者主要是 claude[bot] 和 coderabbitai[bot]。Sumner 自己也承認，他的審查方式是“檢查對抗性審查 agent 是否正確捕獲了差異，確保轉(zhuǎn)換指南被遵守，同時自己也手動讀了不少代碼”。但“不少”是多少，他沒說。

還有一個繞不開的問題：Bun 在 2025 年 12 月被 Anthropic 收購了，真正能有效維護這套代碼庫的工具，基本只有 Claude 自己。社區(qū)里有人說，這已經(jīng)算不上傳統(tǒng)意義上的開源項目了——你想給 Bun 提 PR，得先訂閱 Anthropic，或者指望那幾個已經(jīng)看懂了 AI 生成代碼的核心成員。

16.5 萬美元換一年工作量，值嗎？

Sumner 在博客中還披露，這次重寫的 API 成本約為 16.5 萬美元，等于 3 名工程師一年的工作量。這個數(shù)字在 Hacker News 上引發(fā)了激烈的討論。

有人認為，這筆賬其實很劃算。16.5 萬美元在硅谷請不了幾個全職工程師，更不用說 Anthropic 這種級別公司的工程師了。按照 levels.fyi 上的薪資數(shù)據(jù)，Anthropic 工程師的總包很可能達到 50 萬美元甚至更高。即便按 50 名工程師平均年薪 33.6 萬美元粗略計算，折合到每天大約是 1292 美元。50 個人連續(xù)工作 11 天，光人力成本就已經(jīng)接近 71 萬美元，還不包括福利、辦公場地、設(shè)備和其他管理開銷。

但是，Sumner 用的是“Claude Fable 5 的預發(fā)布版本”，一個尚未對公眾開放、可能受出口管制的高階模型。所以 API 定價只是最終用戶看到的數(shù)字，背后是 Anthropic 投入的巨額研發(fā)費用。還有人指出，把成本簡化成 API 定價，是在刻意淡化真實投入。如果算上模型研發(fā)成本、訓練成本、算力投入、工程人力等，相信最終的總成本肯定很高，很可能超過 150 萬美元。

而且目前看來，雖然 16.5 萬美元換一年工作量，賬面上看挺劃算。

但真正的成本不在這張賬單上。這個代碼庫有 6778 次提交，沒有一個人從頭到尾完整讀過，雖然眼下一切正常，可六個月后呢？當某個詭異的并發(fā)問題在凌晨三點突然冒出來，負責值班的工程師面對的是一個連他自己都說不清內(nèi)部邏輯的系統(tǒng)。延伸到以后都得 AI 來維護，維護成本怎么算，其實挺難。

https://bun.com/blog/bun-in-rust

https://hn.edgecompute.app/item/48837877

聲明：本文為 InfoQ 原創(chuàng)，不代表平臺觀點，也不構(gòu)成投資建議，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

大會限時早鳥票享 8 折專屬優(yōu)惠，現(xiàn)在報名立減 1160，更多詳情可掃碼或聯(lián)系票務經(jīng)理 13269078023 進行咨詢。