一個(gè)人+Claude，11天生成超100萬(wàn)行Rust代碼！Bun創(chuàng)始人復(fù)盤(pán)從Zig到Rust重寫(xiě)全過(guò)程

編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

從 Zig 到 Rust，知名的開(kāi)源項(xiàng)目 Bun 完成了一次徹底的技術(shù)轉(zhuǎn)向。

近日，JavaScript 運(yùn)行時(shí) Bun 創(chuàng)始人 Jarred Sumner 發(fā)布長(zhǎng)文，首次公開(kāi)復(fù)盤(pán) Bun 重寫(xiě)背后的全過(guò)程。

這位曾長(zhǎng)期力挺 Zig 的開(kāi)發(fā)者，用一篇文章詳細(xì)解釋了為何最終決定放棄這一語(yǔ)言，并分享了自己一個(gè)人如何借助 Anthropic 的 Claude Fable 5 與 Claude Code，僅用 11 天便完成了 53 萬(wàn)余行 Zig 代碼向超過(guò) 100 萬(wàn)行 Rust 代碼的遷移，也借此希望能夠給更多開(kāi)發(fā)者一些參考。

一個(gè)曾把 Zig 推向世界的人，如今主動(dòng)重寫(xiě)它

如果說(shuō)過(guò)去幾年，誰(shuí)讓更多開(kāi)發(fā)者認(rèn)識(shí) Zig，Jarred Sumner 一定排得上號(hào)。

Bun 最初就是一個(gè)將 esbuild 的 JavaScript 和 TypeScript 轉(zhuǎn)譯器從 Go 逐行移植到 Zig 的項(xiàng)目。

2021 年 4 月 16 日，Jarred Sumner 寫(xiě)下了自己的第一行 Zig 代碼。他后來(lái)回憶稱(chēng)，當(dāng)時(shí)在 Hacker News 上看到一份單頁(yè)版的 Zig Language Reference，Zig 對(duì)底層的掌控能力以及對(duì)性能的極致追求給他留下了深刻印象，因此決定將 Bun 押注在 Zig 之上。

從定位上看，Bun 一開(kāi)始的目標(biāo)就遠(yuǎn)不只是一個(gè)簡(jiǎn)單的 JavaScript 運(yùn)行時(shí)。

Jarred Sumner 稱(chēng)，Bun 構(gòu)建之初，野心就非常大，其試圖在一個(gè)統(tǒng)一工具鏈中覆蓋 JavaScript 和 TypeScript 開(kāi)發(fā)流程中的多個(gè)核心環(huán)節(jié)，包括 JavaScript、TypeScript 和 CSS 的轉(zhuǎn)譯、壓縮與打包；兼容 npm 的包管理器；類(lèi)似 Jest 的測(cè)試運(yùn)行器；兼容 Node.js 與 TypeScript 的模塊解析機(jī)制；HTTP/1.1 和 WebSocket 客戶(hù)端，以及包括 fs、net、tls 在內(nèi)的大量 Node.js API 實(shí)現(xiàn)。

這個(gè)龐大的目標(biāo)幾乎全部由 Sumner 一人完成。按照他的回憶，Bun 最初版本耗時(shí)約一年開(kāi)發(fā)完成，當(dāng)時(shí)他還沒(méi)有 LLM 工具輔助，主要在奧克蘭一間狹小的公寓里，使用 Zig 完成了整個(gè)項(xiàng)目。

Sumner 認(rèn)為，對(duì)于這樣一個(gè)野心龐大的個(gè)人項(xiàng)目，最終陷入 GitHub 個(gè)人主頁(yè)中“廢棄項(xiàng)目的墓地”才是更常見(jiàn)的結(jié)局。而 Zig 的出現(xiàn)，讓 Bun 成為了可能。“如果沒(méi)有 Zig，我不可能在一年時(shí)間里完成這么多工作。”

隨著時(shí)間推移，如今的 Bun 已經(jīng)從一個(gè)個(gè)人開(kāi)發(fā)項(xiàng)目成長(zhǎng)為被廣泛采用的 JavaScript 工具鏈。其命令行工具每月下載量超過(guò) 2200 萬(wàn)次，包括 Claude Code、OpenCode 在內(nèi)的熱門(mén)開(kāi)發(fā)工具都選擇將 Bun 作為運(yùn)行時(shí)。同時(shí)，Vercel、Railway、DigitalOcean 等云平臺(tái)也已經(jīng)提供了對(duì) Bun 的官方支持。

不過(guò)，Bun 追求“大而全”的設(shè)計(jì)理念，也帶來(lái)了長(zhǎng)期穩(wěn)定性的挑戰(zhàn)。隨著功能不斷擴(kuò)展，項(xiàng)目復(fù)雜度持續(xù)上升，如何維護(hù)一個(gè)覆蓋運(yùn)行時(shí)、工具鏈和 Node.js 兼容層的龐大系統(tǒng)，成為 Bun 后續(xù)發(fā)展中必須面對(duì)的問(wèn)題。

為什么放棄 Zig？

在最新發(fā)布的博客中，Jarred Sumner 并沒(méi)有否定 Zig。相反，他表示，如果時(shí)間回到 2022 年，自己依然會(huì)選擇 Zig 作為 Bun 的底層語(yǔ)言。

在 Bun 早期發(fā)展階段，Zig 確實(shí)展現(xiàn)出了明顯優(yōu)勢(shì)。它擁有優(yōu)秀的 C 語(yǔ)言互操作能力、簡(jiǎn)潔直接的語(yǔ)言設(shè)計(jì)，以及接近 C/C++ 的底層控制能力，這些特性幫助 Bun 快速搭建起一個(gè)高性能 JavaScript 運(yùn)行時(shí)。

但隨著 Bun 規(guī)模不斷擴(kuò)大，問(wèn)題也逐漸暴露出來(lái)。

Sumner 回憶稱(chēng)，隨著代碼量增長(zhǎng)，團(tuán)隊(duì)不得不投入越來(lái)越多精力處理內(nèi)存泄漏、生命周期管理以及各種底層穩(wěn)定性問(wèn)題。大量 Bug 修復(fù)任務(wù)不斷累積，甚至影響到了開(kāi)發(fā)者的日常狀態(tài)。

他坦言，“層出不窮的 Bug 修復(fù)清單讓我身心俱疲，每晚睡前都會(huì)擔(dān)心 Bun 是否會(huì)出現(xiàn)運(yùn)行崩潰。”

更關(guān)鍵的是，這些問(wèn)題并不是單純依靠更加嚴(yán)格的編碼規(guī)范就能夠完全避免。即便團(tuán)隊(duì)進(jìn)行了大量代碼審查，底層內(nèi)存安全問(wèn)題依然可能出現(xiàn)。

因此，Sumner 開(kāi)始重新評(píng)估 Bun 的技術(shù)路線：是否應(yīng)該選擇一門(mén)能夠從語(yǔ)言層面減少這類(lèi)問(wèn)題的語(yǔ)言。

C/C++ 能否成為替代方案？

事實(shí)上，C++ 曾經(jīng)是一個(gè)看似合理的選擇。

目前 Bun 約有 20% 的代碼采用 C++ 編寫(xiě)，同時(shí)項(xiàng)目?jī)?nèi)部也大量依賴(lài) C/C++ 生態(tài)中的成熟組件，包括用于支撐 Safari 的 JavaScript 引擎 JavaScriptCore、提供 HTTP/WebSocket 能力的 uWebSockets 與 usockets、實(shí)現(xiàn) HPACK 和 HTTP/3 的 lshpack 與 lsquic、Google 基于 OpenSSL 開(kāi)發(fā)的 BoringSSL，以及 SQLite 等。

因此，如果選擇 C++ 重構(gòu) Bun，并非完全從零開(kāi)始。

Sumner 認(rèn)為，C++ 甚至能夠帶來(lái)一些便利。例如，開(kāi)發(fā)者可以直接使用構(gòu)造函數(shù)和析構(gòu)函數(shù)管理資源，同時(shí)減少大量 extern "C" 的封裝代碼。

但問(wèn)題在于，C++ 依然無(wú)法從根本上解決內(nèi)存安全挑戰(zhàn)。

即便團(tuán)隊(duì)采用更加嚴(yán)格的代碼審查流程，制定編碼規(guī)范，并開(kāi)啟 AddressSanitizer（ASAN）等檢測(cè)工具，內(nèi)存越界、資源釋放錯(cuò)誤以及內(nèi)存泄漏等問(wèn)題仍然可能發(fā)生。

最終，C++ 并沒(méi)有成為 Bun 的答案。

而這也成為 Sumner 轉(zhuǎn)向 Rust 的重要原因之一：相比依賴(lài)工程規(guī)范和人工審查，Rust 希望通過(guò)編譯器和所有權(quán)模型，在代碼運(yùn)行之前就阻止大量潛在錯(cuò)誤。

為什么選擇 Rust？

此前困擾 Bun 的大量問(wèn)題，主要集中在內(nèi)存安全領(lǐng)域，包括 use-after-free（釋放后使用）、double-free（重復(fù)釋放），以及異常分支中遺漏資源釋放等情況。

而在 Rust 的安全子集中，這類(lèi)問(wèn)題通常會(huì)在編譯階段直接被阻止。Rust 通過(guò)所有權(quán)、借用檢查器以及 Drop 機(jī)制，實(shí)現(xiàn)類(lèi)似 RAII 的自動(dòng)資源管理，讓許多潛在錯(cuò)誤在代碼運(yùn)行前就暴露出來(lái)。

相比依靠團(tuán)隊(duì)制定編碼規(guī)范、進(jìn)行人工 Code Review 來(lái)降低風(fēng)險(xiǎn)，Rust 編譯器提供了一種更加嚴(yán)格且強(qiáng)制的約束方式。

但對(duì)于 Bun 這樣的成熟項(xiàng)目而言，遷移到另一門(mén)語(yǔ)言并不是一個(gè)簡(jiǎn)單決定。

據(jù) Sumner 介紹，剔除注釋后，Bun 現(xiàn)有 Zig 代碼規(guī)模約為 53.5 萬(wàn)行。如果依靠一個(gè)小型工程團(tuán)隊(duì)手動(dòng)完成語(yǔ)言遷移，預(yù)計(jì)需要整整一年時(shí)間。而在這一年里，Bug 修復(fù)、安全補(bǔ)丁以及新功能開(kāi)發(fā)都將受到影響。

因此，他們團(tuán)隊(duì)認(rèn)為，想要以最低風(fēng)險(xiǎn)完成遷移，最合理的方案并不是重新設(shè)計(jì)代碼，而是進(jìn)行一次“機(jī)械式移植”——盡可能保持原有邏輯不變，最大程度復(fù)用現(xiàn)有測(cè)試體系，通過(guò)測(cè)試結(jié)果驗(yàn)證遷移后的代碼是否可靠。

幸運(yùn)的是，Bun 自身?yè)碛幸惶谆?TypeScript 構(gòu)建的完整測(cè)試體系，并不依賴(lài)底層運(yùn)行時(shí)采用何種編程語(yǔ)言，這也為遷移提供了重要基礎(chǔ)。

然而，完全暫停開(kāi)發(fā)一年并不是現(xiàn)實(shí)選擇。

Sumner 表示，最初團(tuán)隊(duì)考慮過(guò)另一條路線：繼續(xù)使用 Zig，通過(guò)更加嚴(yán)格的編碼規(guī)范約束內(nèi)存安全問(wèn)題，同時(shí)在代碼庫(kù)中加入借鑒 Rust 思想設(shè)計(jì)的自研智能指針。

但這一方案并沒(méi)有讓他滿(mǎn)意。

在 Sumner 看來(lái)，自研智能指針無(wú)論是開(kāi)發(fā)體驗(yàn)還是安全保障，都無(wú)法達(dá)到 Rust 的水平。相比重新造一套內(nèi)存管理機(jī)制，直接采用一門(mén)已經(jīng)經(jīng)過(guò)多年驗(yàn)證的系統(tǒng)級(jí)語(yǔ)言似乎更加合理。

就在這個(gè)過(guò)程中，他產(chǎn)生了一個(gè)大膽設(shè)想：

“為什么不花一周時(shí)間，測(cè)試一下 Anthropic 最新的大模型，看看它能否把 Bun 完整重寫(xiě)成 Rust？”

最初，Sumner 對(duì)這一想法并沒(méi)有抱太大期待。

但實(shí)驗(yàn)開(kāi)始后，情況很快發(fā)生變化。幾天之后，大量測(cè)試用例已經(jīng)能夠正常通過(guò)，而 AI 生成的 Rust 代碼與原有 Zig 實(shí)現(xiàn)之間，也展現(xiàn)出了較高的一致性。

這讓 Sumner 的想法發(fā)生了轉(zhuǎn)變。

最開(kāi)始，他只是希望驗(yàn)證“AI 是否能夠完成這項(xiàng)任務(wù)”；但隨著遷移結(jié)果逐漸穩(wěn)定，最終決定直接合并這套由 AI 輔助完成的 Rust 重構(gòu)代碼。

借助 Claude，用 Rust 重寫(xiě) Bun

遷移伊始，Sumner 認(rèn)為，這類(lèi)大型重構(gòu)存在大量容易踩坑的做法。例如，直接向模型輸入一句“將 Bun 改寫(xiě)成 Rust，并確保不會(huì)出現(xiàn)任何問(wèn)題”，然后期待 AI 一次性完成整個(gè)項(xiàng)目，這并不是可靠方案。

在他的設(shè)想中，AI 輔助重構(gòu)需要遵循類(lèi)似人工遷移的工程方法，核心需要解決兩個(gè)問(wèn)題：是漸進(jìn)式重構(gòu)，還是一次性全量遷移？以及如何保證遷移后的 Bun 與原版本保持一致。

對(duì)于遷移方式，Sumner 最終選擇了一次性全量移植。

他回憶稱(chēng)，最初開(kāi)發(fā) Bun 時(shí)，自己曾經(jīng)手動(dòng)將 esbuild 的 JavaScript/TypeScript 轉(zhuǎn)譯器從 Go 遷移到 Zig，而且整個(gè)過(guò)程沒(méi)有使用任何大語(yǔ)言模型。根據(jù)此前經(jīng)驗(yàn)，一次性完成完整遷移，往往比漸進(jìn)式重構(gòu)效果更好。

原因在于，漸進(jìn)式重構(gòu)通常會(huì)產(chǎn)生大量臨時(shí)代碼。這些代碼雖然能夠幫助項(xiàng)目逐步過(guò)渡，但隨著時(shí)間推移，團(tuán)隊(duì)還需要不斷清理歷史包袱，最終導(dǎo)致代碼結(jié)構(gòu)更加復(fù)雜，長(zhǎng)期維護(hù)體驗(yàn)下降。

因此，在 Bun 從 Zig 遷移到 Rust 的過(guò)程中，團(tuán)隊(duì)決定采用更加直接的方式：盡可能保持原有邏輯不變，將 Zig 代碼轉(zhuǎn)換為 Rust 實(shí)現(xiàn)。

另一個(gè)關(guān)鍵問(wèn)題是，如何保證 Rust 版本 Bun 與原版本在架構(gòu)、性能和功能上保持一致，同時(shí)又能夠利用 Rust 的核心安全特性，例如借用檢查器。

最終，Sumner 確定了一個(gè)相對(duì)保守的方案：

先按照“Zig 直譯 Rust”的方式完成遷移，再逐步優(yōu)化代碼。

也就是說(shuō)，第一階段的目標(biāo)不是寫(xiě)出最優(yōu)雅的 Rust，而是確保 Rust 版本能夠完整替代原有 Zig 版本。等 Bun v1.4 發(fā)布后，再逐步減少 unsafe 代碼塊，將部分實(shí)現(xiàn)改寫(xiě)成更加符合 Rust 語(yǔ)言習(xí)慣的形式。

在 Sumner 看來(lái)，遷移過(guò)程真正需要解決的核心問(wèn)題只有這兩個(gè)，其余更多屬于工程執(zhí)行細(xì)節(jié)。

11 天完成全量遷移：Claude Code 組成 50 套動(dòng)態(tài)工作流

為了執(zhí)行這項(xiàng)大規(guī)模遷移，Sumner 并沒(méi)有讓 Claude 單獨(dú)完成任務(wù)，而是在 Claude Code 中搭建了一套循環(huán)式代碼生成與審核流程。

他認(rèn)為，軟件工程師日常開(kāi)發(fā)本質(zhì)上就是一個(gè)循環(huán)：提出任務(wù) → 編寫(xiě)代碼 → 接受反饋 → 修改代碼 → 再次驗(yàn)證。

此次 Bun Rust 重構(gòu)，也是按照類(lèi)似方式運(yùn)行。

在 Claude Code 中，Sumner 創(chuàng)建了約 50 套動(dòng)態(tài)工作流，持續(xù)運(yùn)行 11 天，完成整個(gè)代碼庫(kù)遷移。

這些工作流覆蓋多個(gè)階段：

• 首先，Claude 需要生成遷移指南，建立 Zig 語(yǔ)法、類(lèi)型系統(tǒng)與 Rust 之間的映射規(guī)則。

• 隨后，根據(jù) PORTING.md 和 LIFETIMES.tsv 等文檔，將全部 .zig 文件機(jī)械轉(zhuǎn)換為 .rs 文件。

• 之后，系統(tǒng)持續(xù)處理 Rust 編譯錯(cuò)誤，讓各個(gè) crate 逐步恢復(fù)正常運(yùn)行，并確保 bun test、bun build 等核心命令能夠工作。

• 最后，通過(guò)完整測(cè)試套件驗(yàn)證遷移結(jié)果，并進(jìn)行多輪代碼重構(gòu)和清理。

整個(gè)過(guò)程中，Sumner 并不是完全放手讓 AI 自動(dòng)運(yùn)行，而是持續(xù)監(jiān)控工作流狀態(tài)。

當(dāng)出現(xiàn)異常時(shí)，他會(huì)人工查看日志，定位問(wèn)題，再調(diào)整 Claude 的執(zhí)行流程，讓模型重新處理錯(cuò)誤。

當(dāng)然，對(duì)于一次新增數(shù)十萬(wàn)行甚至百萬(wàn)級(jí)規(guī)模代碼的 Pull Request，很多人最大的疑問(wèn)是：如何確保 AI 生成的代碼值得信任？

Sumner 給出的答案是：測(cè)試體系 + 對(duì)抗式代碼評(píng)審。

Bun 原本就擁有一套與底層實(shí)現(xiàn)語(yǔ)言無(wú)關(guān)的測(cè)試體系，其中包含百萬(wàn)級(jí)斷言，可以持續(xù)驗(yàn)證 Rust 版本是否保持原有行為。

但僅靠測(cè)試仍然不足。

因此，他引入了一套類(lèi)似人工軟件開(kāi)發(fā)流程中的“代碼作者”和“代碼審查者”分離機(jī)制。

在傳統(tǒng)開(kāi)發(fā)中，代碼作者和代碼審查者通常是兩個(gè)人。原因在于，代碼編寫(xiě)者往往希望自己的實(shí)現(xiàn)能夠盡快合并，容易忽略自身代碼中的問(wèn)題；而獨(dú)立審查者則會(huì)站在懷疑角度尋找潛在漏洞。

Sumner 認(rèn)為，Claude 同樣存在類(lèi)似傾向。

因此，在 Bun Rust 重構(gòu)過(guò)程中，他采用了“生成 Claude + 對(duì)抗評(píng)審 Claude”的模式：一個(gè) Claude 負(fù)責(zé)生成代碼；至少兩個(gè) Claude 負(fù)責(zé)獨(dú)立審查。

審查模型不會(huì)看到生成過(guò)程，只能讀取代碼 Diff，并默認(rèn)代碼存在缺陷，任務(wù)就是尋找可能導(dǎo)致 Bug、邏輯失效或者性能退化的問(wèn)題。

最終，生成端和評(píng)審端形成相互制約。

這一機(jī)制并非理論設(shè)計(jì)，而是在實(shí)際遷移過(guò)程中發(fā)現(xiàn)了真實(shí)問(wèn)題。其中一個(gè)典型案例來(lái)自異步關(guān)閉句柄問(wèn)題。

Claude 生成的 Rust 代碼能夠正常編譯，邏輯表面上也沒(méi)有明顯錯(cuò)誤，但評(píng)審模型發(fā)現(xiàn)，代碼可能導(dǎo)致 use-after-free 和 double-free。

問(wèn)題源于 libuv 的異步關(guān)閉機(jī)制。

當(dāng)調(diào)用 uv_close 時(shí)，libuv 并不會(huì)立即釋放句柄，而是等待后續(xù)事件循環(huán)觸發(fā)回調(diào)完成清理。但 Rust 中 Box 包裹的對(duì)象會(huì)在作用域結(jié)束時(shí)自動(dòng)析構(gòu)釋放。

這意味著，libuv 可能繼續(xù)訪問(wèn)已經(jīng)被釋放的內(nèi)存，從而引發(fā)崩潰。

最終，團(tuán)隊(duì)通過(guò)調(diào)整代碼，讓對(duì)象生命周期延長(zhǎng)，避免異步回調(diào)訪問(wèn)失效內(nèi)存。

Sumner 表示，這類(lèi)問(wèn)題正是傳統(tǒng)代碼審查容易遺漏，而 Rust 編譯器和對(duì)抗式 AI 審查能夠幫助發(fā)現(xiàn)的問(wèn)題。

在整個(gè)遷移過(guò)程中，對(duì)抗評(píng)審提前發(fā)現(xiàn)了多類(lèi)真實(shí) Bug，包括異步資源釋放問(wèn)題、負(fù)數(shù)時(shí)間戳處理問(wèn)題等。

這些代碼在編譯階段沒(méi)有任何錯(cuò)誤，功能測(cè)試初期也未必能夠暴露問(wèn)題，但經(jīng)過(guò)獨(dú)立 Claude 審查后被提前攔截。

對(duì)于 Sumner 而言，這次 Bun Rust 重構(gòu)最大的變化并不只是“AI 寫(xiě)了大量代碼”，而是軟件工程流程本身發(fā)生了變化：AI 不再只是代碼生成工具，而成為參與遷移、測(cè)試和審查的大規(guī)模工程協(xié)作者。

全流程復(fù)盤(pán)

不容忽視的是，此次遷移并非是幾句提示詞的事，Sumner 在這次遷移過(guò)程中做了大量的工作，詳細(xì)來(lái)看：

前置籌備：制定統(tǒng)一移植規(guī)范

在正式生成代碼前，Sumner 投入 3 小時(shí)與 Claude 深度對(duì)齊 Zig 到 Rust 的語(yǔ)法、類(lèi)型映射規(guī)則，由模型輸出標(biāo)準(zhǔn)化移植文檔`PORTING.md`，這份文檔后續(xù)也發(fā)布至 Hacker News （https://news.ycombinator.com/item?id=48016880）公開(kāi)分享。

項(xiàng)目最大難點(diǎn)在于原有 Zig 代碼混合手動(dòng)內(nèi)存管理與 GC 內(nèi)存，原生無(wú) Rust 生命周期標(biāo)注體系。為此，Sumner 搭建專(zhuān)屬動(dòng)態(tài)工作流，讓 AI 逐文件遍歷全部結(jié)構(gòu)體字段，梳理完整控制流，推導(dǎo)適配 Rust 的生命周期參數(shù)。

每組生命周期方案都會(huì)交由兩組獨(dú)立對(duì)抗評(píng)審模型校驗(yàn)，修正沖突標(biāo)注后，統(tǒng)一歸檔為`LIFETIMES.tsv`，作為后續(xù)所有代碼轉(zhuǎn)換的統(tǒng)一標(biāo)準(zhǔn)，Sumner 本人也人工復(fù)核兩份核心文檔，消除規(guī)則漏洞。

小規(guī)模試點(diǎn)移植：驗(yàn)證 AI 轉(zhuǎn)換與對(duì)抗評(píng)審機(jī)制可行性

為避免大規(guī)模轉(zhuǎn)換出現(xiàn)批量邏輯偏差，Sumner 先選取3個(gè)`.zig`文件開(kāi)展試點(diǎn)。單文件分配 1 個(gè) AI 模型負(fù)責(zé)生成對(duì)應(yīng)`.rs`代碼，2 組獨(dú)立對(duì)抗評(píng)審模型對(duì)照移植規(guī)范校驗(yàn)代碼邏輯一致性，最后由修復(fù)模型統(tǒng)一落地評(píng)審修改意見(jiàn)。

試點(diǎn)階段驗(yàn)證了核心質(zhì)控手段——對(duì)抗式代碼評(píng)審的有效性：評(píng)審 AI 僅能讀取代碼 diff，無(wú)法查看代碼生成模型的推導(dǎo)上下文，且被強(qiáng)制預(yù)設(shè)代碼存在缺陷，窮盡挖掘潛在內(nèi)存崩潰、邏輯退化問(wèn)題，提前攔截編譯正常但存在隱性缺陷的代碼。

批量全量代碼遷移：解決多實(shí)例命令沖突，并行生成百萬(wàn)行代碼

項(xiàng)目總計(jì)需要轉(zhuǎn)換 1448 個(gè) Zig 源碼文件，初期執(zhí)行出現(xiàn)多 Claude 實(shí)例并發(fā)執(zhí)行 git 操作沖突，stash、reset 等指令互相覆蓋修改內(nèi)容；若為每個(gè) AI 分配獨(dú)立工作區(qū)，Bun 龐大的代碼倉(cāng)庫(kù)又會(huì)耗盡磁盤(pán)存儲(chǔ)空間。

Sumner 隨即更新工作流約束規(guī)則：禁止執(zhí)行任何臨時(shí)修改類(lèi) git 命令、禁用 cargo 等高耗時(shí)阻塞指令，僅允許單次提交指定文件。后續(xù)拆分 4 套獨(dú)立并行工作分片，每套分配 16 個(gè) Claude 同步運(yùn)行，總計(jì) 64 個(gè) AI 并行作業(yè)。

峰值狀態(tài)下 AI 每分鐘可產(chǎn)出 1300 行代碼，每一行代碼都經(jīng)過(guò)兩名獨(dú)立對(duì)抗評(píng)審校驗(yàn)，完成一輪修復(fù)后才允許提交。

11 天運(yùn)行累計(jì)生成 6502 次有效提交，峰值單小時(shí)提交量 695 次。

批量修復(fù)編譯報(bào)錯(cuò)：拆分 Crate 并行處理，化解循環(huán)依賴(lài)阻礙

百萬(wàn)行代碼生成完畢后，Sumner 搭建工作流以單個(gè) crate 為單位批量處理編譯報(bào)錯(cuò)，通過(guò)`cargo check`匯總?cè)垮e(cuò)誤并按文件分組，分配 64 個(gè) AI 分?jǐn)傂迯?fù)任務(wù)，依舊沿用“1生成+2評(píng)審+1落地修復(fù)”的固定循環(huán)。

原有 Zig 代碼為單一編譯單元，Sumner 計(jì)劃拆分近百個(gè) Rust crate 加速編譯，但拆分方案前期存在缺陷，大量循環(huán)依賴(lài)引發(fā)約 16000 條編譯錯(cuò)誤。

其團(tuán)隊(duì)也開(kāi)始新增專(zhuān)項(xiàng)工作流梳理循環(huán)依賴(lài)代碼歸屬、完成模塊重構(gòu)，徹底掃清編譯障礙。

整個(gè)過(guò)程中出現(xiàn)了 AI 為繞過(guò)報(bào)錯(cuò)填充占位 stub、添加大段冗余注釋掩蓋不合理兼容邏輯的問(wèn)題，Sumner 為對(duì)抗評(píng)審新增攔截規(guī)則：若需要長(zhǎng)篇注釋解釋臨時(shí)兼容方案，判定代碼存在根本性缺陷，必須重構(gòu)而非臨時(shí)占位，最終這一問(wèn)題在調(diào)整提示詞后徹底解決。

分層測(cè)試流水線：從冒煙測(cè)試到本地全量用例全覆蓋

編譯無(wú)報(bào)錯(cuò)后，項(xiàng)目分階段推進(jìn)測(cè)試驗(yàn)證：

1. 基礎(chǔ)煙霧測(cè)試：優(yōu)先實(shí)現(xiàn)`bun --version`正常編譯運(yùn)行，解決鏈接錯(cuò)誤、程序啟動(dòng) panic；

2. 子命令適配工作流：逐個(gè)修復(fù)`bun test`、`bun build`等CLI子命令運(yùn)行崩潰，捕獲堆棧交由AI迭代修復(fù)；

3. 全量本地測(cè)試分片執(zhí)行：按代碼目錄拆分 4 個(gè)工作區(qū)，隨機(jī)分配百條測(cè)試用例并行執(zhí)行，捕獲失敗用例自動(dòng)走AI修復(fù)評(píng)審流程。

Bun 測(cè)試套件包含海量?jī)?nèi)存泄漏檢測(cè)、長(zhǎng)耗時(shí)集成測(cè)試、極限壓力測(cè)試，部分用例運(yùn)行時(shí)長(zhǎng)超一分鐘，還會(huì)耗盡 TCP 連接、讀寫(xiě) GB 級(jí)文件、創(chuàng)建上萬(wàn)子進(jìn)程。Bun 團(tuán)隊(duì)借助`systemd-run`（cgroups）做 CPU、內(nèi)存、PID 命名空間隔離，但服務(wù)器仍多次因磁盤(pán)占滿(mǎn)宕機(jī)，拉長(zhǎng)了整個(gè)測(cè)試周期。

CI 全平臺(tái)適配收尾，完成分支合并

首輪 CI 流水線執(zhí)行時(shí)，共有 972 個(gè)測(cè)試文件運(yùn)行失敗。經(jīng)過(guò)兩天的運(yùn)行，失敗的測(cè)試文件數(shù)量縮減至 23 個(gè)，再經(jīng)過(guò)一天半調(diào)試，Linux 平臺(tái)所有測(cè)試分片全部綠燈。

項(xiàng)目覆蓋 macOS x64/arm64、Linux x64/arm64、Windows x64/arm64 六大平臺(tái)，Windows 適配難度最高，比 Linux 晚近一天完成全量用例通過(guò)。收尾階段持續(xù)運(yùn)行自動(dòng)化工作流，循環(huán)修復(fù)各平臺(tái)剩余 CI 失敗用例，配套專(zhuān)項(xiàng)工作流處理 Windows 專(zhuān)屬兼容、代碼去重、削減 unsafe 代碼塊、整體代碼清理。

在全部平臺(tái) 100% 測(cè)試通過(guò)，且人工核驗(yàn)所有用例無(wú)跳過(guò)、正常執(zhí)行后，Sumner 正式將百萬(wàn)行 Rust 重構(gòu)代碼合并至主分支。

本次合并僅完成代碼落地，并未對(duì)外發(fā)布正式版本，留足迭代優(yōu)化周期。

Rust 版的 Bun

從數(shù)據(jù)層面來(lái)看，整個(gè)重構(gòu)周期為 5 月 3 日至 5 月 14 日，共計(jì) 11 天。

峰值 4 套工作流、64 個(gè) Claude 并行運(yùn)行。移植階段累計(jì) 4416 次提交，一分鐘峰值 58 次提交，新增+改寫(xiě)代碼合計(jì) 1430577 行，最終合并入庫(kù)變更量 1009272 行，全程無(wú)任何測(cè)試用例刪除或跳過(guò)。

資源消耗層面，合并前累計(jì)消耗未緩存輸入token 59 億、輸出 token 6.9 億，緩存讀取輸入 token 720 億，按官方 API 定價(jià)折算成本約 16.5 萬(wàn)美元。

最終完成 Rust 重構(gòu)后的 Bun v1.4.0 針對(duì)性修復(fù)了上一版本 128 類(lèi)內(nèi)存與運(yùn)行故障，依托 Rust 原生 Drop 自動(dòng)析構(gòu)機(jī)制徹底解決長(zhǎng)期存在的內(nèi)存泄漏問(wèn)題，官方實(shí)測(cè)批量打包場(chǎng)景內(nèi)存占用大幅回落。

同時(shí)得益于跨語(yǔ)言 LTO 鏈接優(yōu)化、棧空間復(fù)用機(jī)制，全平臺(tái)運(yùn)行性能提升 2% 至 5%，二進(jìn)制安裝包體積整體縮減約 20%，棧內(nèi)存消耗也顯著降低，各類(lèi)極限遞歸解析場(chǎng)景不再輕易觸發(fā)程序崩潰。

新版本兼顧生產(chǎn)落地實(shí)用性與長(zhǎng)期迭代維護(hù)性，Prisma、Claude Code 等主流工具已率先上線試用，Linux 環(huán)境下 Claude Code 啟動(dòng)速度提升 10%。

從開(kāi)發(fā)側(cè)來(lái)看，移植后的 Rust 代碼與原有 Zig 邏輯高度對(duì)齊，原有開(kāi)發(fā)人員上手門(mén)檻低，搭配 borrow checker、Miri、7×24 小時(shí)解析器模糊測(cè)試等工具，后續(xù)團(tuán)隊(duì)可系統(tǒng)性規(guī)避內(nèi)存安全類(lèi)缺陷，為持續(xù)迭代筑牢穩(wěn)定性基礎(chǔ)。

最后，Sumner 感慨道，若交由熟悉完整代碼庫(kù)的工程師團(tuán)隊(duì)人工完成本次 Rust 重構(gòu)，預(yù)計(jì)耗時(shí)一整年。而僅我一人配合 Fable 模型、全程監(jiān)控 Claude Code，僅用 11 天就完成全平臺(tái)測(cè)試套件 100% 通過(guò)。

如今單人借助 AI 工具，能完成遠(yuǎn)超過(guò)去一年的開(kāi)發(fā)工作量。

來(lái)源：https://bun.com/blog/bun-in-rust

2026 奇點(diǎn)智能產(chǎn)品大會(huì)全日程正式發(fā)布!

7月17-18日，北京金隅喜來(lái)登大酒店，40+位來(lái)自字節(jié)、百度、阿里、騰訊、宇樹(shù)、360、京東、螞蟻、科大訊飛等一線產(chǎn)品技術(shù)領(lǐng)袖，圍繞 Agent 智能體、企業(yè)級(jí) AI、AI Coding、具身智能、AI 原生組織等 12 大專(zhuān)題，全鏈路拆解AI原生落地閉環(huán)。