Bun 的创建者 Jarred Sumner 近日宣布 ，这款集 JavaScript/TypeScript 运行时、打包工具和包管理器于一体的工具已经从 Zig 重写为 Rust。这次重写主要是通过 Rust 的借用检查器消除反复出现的内存安全漏洞。
这项在人工智能辅助下进行的重写工作历时 4 个月便完成并发布，而非原先预计的一年。这一举措最初是作为概念验证项目启动的，Sumner 总结了背后的动机： 在错误路径中，有很大比例的 Bug […]属于“释放后使用”、“双重释放”以及“忘记释放”的情况。
在安全的 Rust 语言中，这些都会被编译器识别为错误，并且通过 Drop 实现了类似 RAII 的自动清理。与代码风格指南相比，编译器错误能提供更好的反馈机制。
从历史经验来看，重写是一个糟糕的主意。 […] Bun 共有 535496 行 Zig 代码。
如果用另一种语言重写，需要花费掉一个小型工程师团队整整一年的时间。这意味着在一年的时间里，漏洞修复、安全修复或功能开发都将被迫暂停。
幸运的是，Bun 自身的测试套件是用 TypeScript 编写的，这意味着它不依赖于运行时的编程语言。如果我花一周时间测试 Anthropic 的新模型能否用 Rust 重写 Bun，会怎样呢？
起初，我并不指望它能成功。但几天后，测试套件的通过比例大幅上升，我发现新生成的 Rust 代码与原始的 Zig 代码库高度吻合。
我的看法也从“这值得一试”转变为“我要把这个合并进去”。 Sumner 执行了一次自动化的“一次性”移植，整个重写过程中的大部分工作都是利用了 Claude Fable 5 的预发布版本，通过约 50 个动态工作流进行协调。
Zig 代码被转译为 Rust（或许可以使用 unsafe Rust 并稍后进行重构），并使用当前包含超过一百万条断言的庞大测试套件进行了验证。移植指南可以帮助 Claude 将 Zig 的模式和类型映射到 Rust 的模式和类型。
通过对抗性的智能代理代码审查，可以在进入最终移植阶段之前进一步检测问题。每次出现错误后，他都通过优化实现流程（而非手动修复实现产物，例如代码）来改进实现循环。
持续的流程改进揭示了一些有用的规律。规划阶段对于成功的迁移至关重要，非常有必要通过这个阶段预见并缓解一些关键的挑战。
PORTING.md（描述了从 Zig 到 Rust 的映射）和 LIFETIMES.tsv 文件（描述了代码库中每个结构体字段的生命周期）是这次移植的关键成功因素。随后，实现者代理将利用这些文件将 Zig 文件转换为 Rust 代码。
实现者代理将面临两个对抗性审查代理，它们在单独的上下文窗口中运行，仅能访问文件差异，其唯一任务就是发现错误和行为偏差。 Sumner 强调说： 实现者不负责审查。
审查者不负责实现。审查者代理提出的建议和发现的问题由修复代理处理。
在很大程度上，实现过程的效率得益于实现任务的并行化。但这需要解决共享代码库的并发更新问题，以及计算资源有限的饥饿问题。
最终，这项工作被分配到四个工作区分片中，每个分片运行 16 个代理，并行运行的 Claude 实例总共有 64 个。在最快情况下，系统每分钟生成约 1300 行代码，每小时最多提交 695 次。
要使整个测试套件全部通过，需要耗费价值 16.5 万美元的 Token——这与 Sumner 对人工工程工作量的估算形成了鲜明的对比： 合并前，这消耗了 59 亿个未缓存的输入 Token、6.9 亿个输出 Token，以及 720 亿次缓存输入令牌读取——按 API 定价计算，费用约为 16.5 万美元。如果靠人工，我认为需要 3 名完全熟悉这个代码库的工程师耗时约一年的时间才能完成。
当 100 多万行代码最终通过了测试套件后，我们进行了进一步的测试和验证，发现了更多问题。移植过程中的机械操作引入了 19 个微妙的语义回归，其根源在于 Zig 和 Rust 之间的语法相似性。
Claude Code Security 进行的 11 轮安全审查修复了多个安全问题。他们对 Bun 中的每个解析器进行了 7x24 小时不间断地覆盖率引导式模糊测试，其间共产生了 15 个 PR。
据 Bun 团队称，通过 Rust 重写实现的 Bun v1.4.0 不仅修复了 v1.3.14 中长期存在的 128 个 Bug，还带来了显著的性能收益。原生内存泄漏问题已经得到解决。
在进程内打包测试中连续执行 2000 次 Bun.build() 操作时，内存占用在 Rust 环境中稳定维持在 609 MB，而非像之前那样攀升至超过 6.7 GB。 HTTP 吞吐量提高了 2% 至 5%。
Bun v1.4.0 最终于 2026 年 8 月发布 。 Zig 语言创建者 Andrew Kelley 发表了一篇尖锐的批评文章，题目为“ 我对 Bun 用 Rust 重写的看法 ”，其中包含以下评论： 这里体现了一种二分法：为了避免 Bug，你必须在“风格指南”和编程语言特性之间做出选择。
这种障眼法将读者的注意力从消除 Bug 的主要途径上转移开，即投入工程资源来解决这个问题。 [……] 主张将所有 100 万行未经审查的代码直接发布出去的理由是，测试套件足够完善，能够捕获所有问题。
那么，为什么你说你的 Zig 代码中存在这么多令人头疼的 Bug 呢？那个“测试套件足以捕获所有问题”的说法去哪儿了？
它不足以捕获 Zig 代码中的 Bug，却足以捕获 100 万行未经审查的粗制滥造的 Rust 代码中的 Bug？与此同时，用户 vitaminCPP 指出，超过 100 万行机器转译代码的整合，使 Bun 成为一个关键的行业预警风向标，用以检验由大型语言模型（LLM）生成的庞大代码库在软件工程生命周期中是否仍然能够保持可维护性。
建议开发者阅读 全文 ，其中包含深入的技术解析以及相应的插图和图表。 Bun 于 2025 年 12 月被 Anthropic 收购 。
原文链接： /ai-market-guide/