11 天、16.5 万美元，Bun 用 AI 重写百万行代码，划算吗？

2026 年 5 月Bun 项目大规模代码迁移2026 年 5 月Bun 项目完成了一次在软件开发史上近乎罕见的大规模代码迁移。这次迁移从 5 月 3 日启动到 5 月 14 日正式合并入主分支只用了 11 天。写代码只用了 6 天并且整个过程公开。不过Jarred Sumner 写博客总结却花了快一个月比写代码的时间长多了。迁移详情超百万行代码变更花费 16.5 万美元这个 JavaScript 运行时原本拥有 535,496 行 Zig 代码不包括注释同时约 20% 的代码由 C 编写并嵌入了多个 C/C 库。此次借助 AI 重写为 Rust整个过程涉及超过 100 万行代码变更、6778 次提交并在 Claude Code 中运行了大约 50 个动态工作流dynamic workflows。根据 Sumner 披露的数据这次重写在 API 层面消耗了 59 亿个未缓存输入 token、6.9 亿个输出 token以及 720 亿个缓存输入 token 读取按 API 定价计算约花费 16.5 万美元。Sumner 说这是目前技术所能达到的前沿水平。他估计如果让 3 名完全熟悉 Bun 代码库的工程师手工完成这次迁移大约需要一年时间而且在这一年里团队几乎无法继续推进新功能开发、bug 修复和安全修复。这次重写之后Bun v1.3.14 成为最后一个 Zig 版本Bun v1.4.0 将成为第一个 Rust 版本。成果从 6.7GB 内存泄漏到 609MB 稳定Bun 最初是一个 Zig 项目覆盖面非常广它既是 JavaScript 和 TypeScript 转译器也是打包器、包管理器、测试运行器、模块解析器、HTTP 和 WebSocket 客户端还实现了 Node.js API 层。正是这样的产品宽度让 Bun 的 CLI 月下载量超过 2200 万次并获得了 Vercel、Railway、DigitalOcean、Claude Code 和 OpenCode 等项目或公司的支持。但同样是这种宽度也给 Bun 带来了一些挑战。特别是在 Bun v1.3.14 中有一个让大家头疼已久的问题连续执行 Bun.build() 调用时内存会不断累积永不释放。每次构建大约泄漏 3MB看起来不多但如果运行的是一个开发服务器每次请求都触发一次构建那么内存就会被一点点吞噬直到进程崩溃。在实际测试里执行 500 次构建后内存占用 1.9GB1000 次后 3.5GB1500 次后 5.1GB2000 次后飙升到 6.7GB。这只是诸多内存问题的冰山一角。在 v1.3.14 的 bug 修复清单中Sumner 列出了一长串问题。这些 bug 的共性非常明显——它们几乎都指向同一个根源将 GC 与手动内存管理在同一个软件里混合使用。更令人焦虑的是团队并非没有努力但崩溃报告仍然源源不断。而 Rust 版本交出的答卷是同样执行 2000 次 Bun.build()内存稳定在 609MB。除了内存泄漏问题得到根本性解决Rust 重写还带来了其他几个维度的改善。在稳定性方面v1.4.0 修复了 v1.3.14 中可复现的 128 个 bug从内存泄漏到崩溃到颜色显示错误的帮助文本都得到了解决。从体积上结合 Rust 重写、ICU 更改和相同的代码折叠Bun 在 Linux 和 Windows 上的二进制文件大小减少了约 20% 。在性能方面普遍提升了 2% 到 5%。Bun.serve 从 16.96 万 req/s 提升到 17.77 万 req/snode:http 从 10.38 万提升到 10.85 万。实际应用场景中next build 从 13.62 秒降至 13.03 秒tsc 批量编译从 0.94 秒降至 0.89 秒。而 Claude Code 在基于 Rust Bun 发布后Linux 上的启动时间从 517ms 降至 464ms快了约 10%。方法64 个 Claude11 天50 个工作流Sumner 是怎么做到的这可能是最值得关注的部分——因为他用的方法和传统的“让 AI 写代码”不同。Sumner 把整个过程拆成了大约 50 个动态工作流每个工作流都是一个循环。他在博客里用伪代码描述了这个模式。这种模式贯穿了整个重写过程。每个工作流负责一个特定目标。峰值时期Sumner 同时运行了 4 个工作流每个工作流里 16 个 Claude总共 64 个 Claude 同时在 4 个工作树中并行工作各自提交和推送文件。在最高峰时Claude 每分钟写了约 1300 行代码。这种“实现者 / 审查者”的分离设计是关键。代码写完只是第一步。接下来是让 bun --version 跑起来然后是 bun test。两天后Linux 平台的失败测试从 972 个降到了 23 个。一天半之后Linux 全绿了。五天后全部六个平台——Linux x64、Linux arm64、macOS x64、macOS arm64、Windows x64、Windows arm64——全部通过。5 月 14 日PR #30412 正式合并测试套件全部通过没有跳过或删除任何测试。隐忧13,000 个 unsafe 和无法逐行审查的代码不过Sumner 也承认这项工作还没有真正结束。截至目前Bun 的 Rust 代码中大约有 4% 位于 unsafe block 内约 13,000 个 unsafe 关键字分布在约 27,000 行代码中而 Rust 总代码量约为 780,000 行。他预计后续重构会让这个比例降下来但 Bun 的 unsafe 数量与 uv 的差距很难用“需要调用 C 库”来解释。并且随后还在安全 Rust 代码中也暴露了未定义行为。Sumner 自己也承认这次重写引入了 19 个已知的回归问题并表示大多数回归问题都源于语法相同但语义不同的代码。虽然已经问题都修了但这并不表示百万行 AI 代码就没有其他问题。还有一个不能忽略的事情是代码审查。100 万行的变更实际上没法由人类逐行看。这次 PR 的审查者主要是 claude[bot] 和 coderabbitai[bot]。Sumner 自己也承认他的审查方式是“检查对抗性审查 agent 是否正确捕获了差异确保转换指南被遵守同时自己也手动读了不少代码”但“不少”是多少他没说。还有一个绕不开的问题Bun 在 2025 年 12 月被 Anthropic 收购了真正能有效维护这套代码库的工具基本只有 Claude 自己。社区里有人说这已经算不上传统意义上的开源项目了。16.5 万美元换一年工作量值吗Sumner 在博客中还披露这次重写的 API 成本约为 16.5 万美元等于 3 名工程师一年的工作量。这个数字在 Hacker News 上引发了激烈的讨论。有人认为这笔账其实很划算。但也有人指出把成本简化成 API 定价是在刻意淡化真实投入。而且目前看来虽然 16.5 万美元换一年工作量账面上看挺划算但真正的成本不在这张账单上。这个代码库有 6778 次提交没有一个人从头到尾完整读过虽然眼下一切正常可未来维护成本怎么算其实挺难。那么你认为 16.5 万美元换一年工作量到底值吗