Bun 从 Zig 重写为 Rust：一次由编码代理推动的大规模迁移
Bun 作者 Jarred Sumner 近日详细介绍了将 Bun 从 Zig 重写为 Rust 的过程。这次迁移并不是简单的语言偏好变化，而是围绕内存安全、测试可信度和大规模 AI 辅助工程展开的一次实践。
为什么从 Zig 转向 Rust
Sumner 在文章前半部分肯定了 Zig 对 Bun 早期发展的作用。他提到，Bun 能走到今天离不开 Zig，但项目的 bug 列表中有大量与内存管理相关的问题，例如 use-after-free、double-free，以及错误路径中忘记释放内存。
在他的描述中，Bun 面临的难点并不是 Zig 本身有问题，而是将垃圾回收与手动内存管理混合使用，是一种并不常见、也很少有语言专门为之设计的需求。
选择 Rust 的核心原因，是安全 Rust 能把这类内存问题转化为编译期错误，并通过类似 RAII 的 Drop 机制提供自动清理能力。
大规模重写为什么这次可行
传统软件工程经验通常反对“停下来从头重写”大型系统。Joel Spolsky 早在 2000 年就曾强调过这一点。但这次 Bun 的迁移显示，前沿模型驱动的编码代理正在改变这类决策的成本结构。
这次重写能够推进，一个关键条件是 Bun 的测试套件使用 TypeScript 编写，因此可以作为与实现语言无关的一致性测试套件。也就是说，无论底层实现是 Zig 还是 Rust，只要行为符合测试，就能为迁移提供相对稳定的判断标准。
Sumner 起初并不确信这会成功。但几天后，较高比例的测试开始通过，新的 Rust 代码也与原 Zig 代码库保持了较高对应关系。他的判断从“值得试试”转为“准备合并”。
如何审查百万行级 AI 生成代码
这次迁移涉及超过百万行新增代码。Sumner 提到，合并这类代码不能依赖逐行人工审查，而需要一套流程：
- 使用语言无关的测试套件，其中包含大量断言；
- 引入对抗式代码评审；
- 当出现问题时，优先修复生成代码的流程，而不是手工修补单个代码片段；
- 在多数时间里监控工作流，阅读输出，发现问题后再提示 Claude 修改循环流程。
这种做法更像是审查和改进“代码生成系统”，而不是只审查最终产物。
已在 Claude Code 中运行
Rust 版本的 Bun 已经在 Claude Code 中运行近一个月。Claude Code v2.1.181 及之后版本使用了 Rust 移植版 Bun。根据 Sumner 的说法，Linux 上启动速度提升了 10%，除此之外几乎没有人注意到变化。
这反而是迁移成功的信号：对用户来说，底层实现变化没有带来明显扰动。
成本与意义
迁移合并前消耗了 59 亿未缓存输入 token、6.9 亿输出 token，以及 720 亿缓存输入 token 读取。按 API 价格估算，成本约为 16.5 万美元。
这次案例的价值不只在于 Bun 选择了 Rust，也在于它展示了一种新的大规模工程迁移模式：用一致性测试作为约束，用并行编码代理完成初始迁移，用对抗式评审和流程修正建立合并信心。
对于社区而言，它提供了一个值得观察的样本：当测试边界足够清晰、行为一致性可验证时，过去被认为风险极高的大规模重写，可能会在 AI 辅助工程中获得新的可行路径。