11 天、64 个 AI、53 万行代码：Bun 从 Zig 重写到 Rust 的完整工程复盘

2026 年 7 月 8 日，Jarred Sumner 发布了一篇博客。

这篇博客的发布日期比内容本身更晚——他早在 5 月就完成了重写，但花了一个半月才写完这篇复盘。原因很简单：重写本身只用了 11 天，但解释清楚「怎么做到的」需要更多时间。

Bun 的 Zig 代码库有 535,496 行（不含注释）。JavaScript 运行时、包管理器、测试框架、打包器——一个完整生态。用传统的重写方式，一个小团队需要一年，期间不能修 bug、不能做新功能、用户感知完全冻结。

Jarred 的选择是：让 64 个 Claude 同时工作，11 天搞定。

这不是 hype。这篇博客里有 commit 记录、BuildKite CI 日志、replay 动画。每一个数字都可验证。

经验一：当 Agent 并行工作时，「不可重写」的大型项目变成了「不重写才是错的」的工程决策。

〇、元问题：什么情况下，重写从「最不应该做的事」变成了「最应该做的事」？

Joel Spolsky 在 2000 年写过一篇经典文章：Things You Should Never Do, Part I。核心论点：永远不要从零重写一个大型软件。

理由很充分：旧代码里藏着无数边缘情况的修复。重写意味着丢掉所有这些经验，换来一堆新的 bug。

这个道理直到 2025 年还是对的。然后 AI Agent 改变了等式。

Jarred 的博客里有一句话精确描述了这种变化：

“Until very recently, programming language choice was a one-way decision for a project like Bun. Everyone knows you should never stop the world and rewrite a large piece of software from the ground up. Coding agents powered by today’s frontier models change that equation.

”

翻译过来就是：「重写是灾难」这个结论的前提是「重写需要一年、一个团队、冻结所有其他工作」。当重写只需要 11 天和一个人监控时，这个前提就瓦解了。

但这里有一个关键问题：什么情况下这条逻辑成立？什么时候 AI 重写是合理的，什么时候仍然是灾难？

Jarred 的重写之所以成功，不是因为 AI 很厉害，而是因为 Bun 刚好满足三个条件：

1. 测试套件与实现语言无关——Bun 的测试用 TypeScript 写的，Zig 改成 Rust，测试照样跑
2. 有明确的「行为规范」——535,496 行代码的功能是已知的、可验证的
3. 旧语言有系统性问题——Zig 在处理 GC + 手动内存管理混合场景时，use-after-free、double-free 的 bug 根本停不下来

经验二：AI 重写不是银弹。它只在「测试套件独立于实现」且「旧代码有系统性问题时」才成立。

一、为什么是 Rust？不是因为 Rust 流行

Jarred 列了一个 bug 清单。仅 Bun v1.3.14 就修了这些：

• heap-use-after-free in node:zlib when calling .reset() on an async stream
• use-after-free in node:http2 when re-entrant JS callbacks triggered hashmap rehash
• double-free in CSS parser
• memory leak where fs.watch() watchers were never garbage collected
• race condition crash in MessageEvent across BroadcastChannel / MessagePort

这些 bug 有一个共同的根因：Zig 没有编译器级别的内存安全保证。

Jarred 的一段话值得全文引用：

“A large percentage of bugs from that list are use-after-free, double-free, and ‘forgot to free’ in an error path. In safe Rust, these are compiler errors and RAII-like automatic cleanup with Drop. Compiler errors are a better feedback loop than a style guide.”

这不是"Rust 比 Zig 好"的讨论。Zig 适合很多场景。但对于一个混合了 GC 和手动内存管理的 JavaScript 运行时来说，编译器级别的内存安全保证不是一个 nice-to-have，而是一个不再能妥协的工程需求。

经验三：语言选择的标准变了。过去的「品味」和「偏好」在被「编译器能替你擋多少 bug」取代。

二、决策一：一次性全部重写，而不是增量迁移

Jarred 在博客中做了第一个重要决策：一次性翻译全部 1,448 个 .zig 文件，而不是增量重写。

理由来自亲身经验——Bun 的第一个版本就是他把 esbuild 的转译器从 Go 逐行翻译到 Zig 做出来的。

“In my experience porting esbuild’s transpiler from Go to Zig for the initial version of Bun (without LLMs), everything all at once is better. An incremental rewrite adds temporary code that you hope gets deleted eventually.”

一次性全部重写的另一个好处是：生成的 Rust 代码看起来就像"把 Zig 代码转译成了 Rust"。

这意味着任何理解原始 Zig 代码的人都能直接看懂生成的 Rust 代码。不需要适应新的架构，不需要重新学习代码组织。这对于一个团队来说至关重要——你不能让重写变成一个只有 AI 理解的黑盒。

三、决策二：50 个动态工作流，64 个 Claude 并行

这是整篇博客中最技术性的部分。

Jarred 没有用"写一个 prompt，等结果，修 bug，再写下一个 prompt"的串行模式。他设计了一套动态工作流系统。

“I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.”

每个动态工作流是一个循环，结构如下：

关键架构决策：1 个实现者 + 2 个对抗性审查者。

“Usually with humans, the person reviewing the code is not the person who authored the code. The person writing the code wants to merge the code, which can bias their actions to ship before it’s ready. Claude is the same way.”

Jarred 发现，让同一个 Claude 既写代码又审查自己写的代码，它会天然倾向于接受。必须用独立的 context window，独立的角色定义，才能得到真正有价值的审查反馈。

这 3 个对抗性审查者捕获了多个编译器不会报错但实际有 bug 的问题，包括：

• async close 时序竞争
• parse_color_mix 的 unwrap_or eager panic
• CurrentColor vs transparent 语义混淆

经验四：对抗性审查是 AI Agent 工程中最被低估的模式。让 AI 彼此挑战，远比让 AI 自审更有效。

四、决策三：试跑 + 假启动 + 修复流程而非修复代码

Jarred 在开始全量重写前，先做了一个试跑（trial run）：

“Before asking Claude to translate all 1,448 .zig files to .rs files, I started with just 3. For each of the 3 files, 1 implementer wrote the new .rs file, 2 adversarial reviewers checked it matched the behavior of the .zig file.”

3 个文件 → 验证工作流正确 → 扩展到全部 1,448 个文件。

试跑成功后，Jarred 让 Claude 全量启动。然后立刻遇到了第一个假启动（false start）：

“About 2 minutes in, one Claude ran git stash before committing. Another ran git stash pop. And then git stash pop again. They were stepping on each other!”

64 个并行 Claude 在同一个 git 仓库里操作，有些在 stash，有些在 stash pop，一片混乱。

Jarred 的解决方案不是手修代码，而是修改工作流的规则：

“I asked Claude to edit the workflow to instruct Claude to never run git stash, git reset, or any command that doesn’t commit a specific file at once.”

同样，当 16,000 个编译错误出现时，Claude 开始"solve"的方式是给所有编译不过的函数加 todo!() stub，并附上长长的工作注释解释为什么这样做是 OK 的。

Jarred 同样不手修。他加了一条审查规则：

“If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code.”

经验五：当 Agent 出错时，修复「出错的原因」比修复「出错的代码」更可持续。改规则，让 AI 下次不会犯同样的错。

五、结果与数据

准备工作只用了 3 个小时——Jarred 和 Claude 讨论了如何把 Zig 模式映射到 Rust，生成了一份 PORTING.md 和一份 LIFETIMES.tsv。之后这些文档被加载到所有并行 Agent 的上下文中，保证了代码风格和生命周期标注的一致性。

对抗性审查捕获的真实 bug 有据可查——每个修复都有对应的 commit，subject line 里标注了是哪个审查 Agent 发现的。

六、你能直接用的经验

Bun 重写有三个点你可以立刻应用到自己的项目：

1. 把测试套件设计成 Agent 的验收标准。

如果你的测试套件绑定了特定实现（例如测试了内部私有函数的返回值），AI 重写时会到处碰壁。Bun 的测试套件只测试外部行为——bun install 的输出、bun test 的结果——不关心内部是用 Zig 还是 Rust 实现的。

行动项：审视你的测试。它们是「行为规范」还是「实现快照」？如果是后者，重构它们。

2. 让 AI 审 AI。

Jarred 的 1+2 模式（1 实现者 + 2 对抗性审查者）可以直接用到你的 Code Review 流程中。让一个 Claude 写代码，另一个 Claude 在独立 context 中审代码。审稿 Agent 的 prompt 很明确：“Assume this code has bugs. Find them.”

3. 修复流程，而非修复代码。

当 Agent 做错事时，不要手修代码然后继续。停下来问：**“是什么流程或规则让 Agent 犯了错？”**修改规则，让 Agent 重跑，而不是自己下场。

总结

Bun 的重写是一个里程碑。不是因为 Rust 比 Zig 好，也不是因为 Claude Fable 5 有多强。而是因为 Jarred 展示了 AI Agent 时代的工程管理范式：人类做决策、定流程、查异常；Agent 做执行、做审查、提反馈。

在发布会和 benchmark 之外，这才是 AI 编程真正的变革方向。

🎯 正在用 AI 做大型项目或考虑技术栈迁移？

• 📬 关注「全栈之巅 - 梦兽编程」，获取 AI + Rust 一手工程经验
• 🔧 加入社群，与 Rust 和 AI 开发者深度交流

参考来源：

• Jarred Sumner, Rewriting Bun in Rust 外部链接 , Jul 8 2026
• Simon Willison, Rewriting Bun in Rust 外部链接 , Jul 8 2026