11 天完成迁移，Bun 把 AI 重构推到台前
Bun 创建者 Jarred Sumner 宣布，借助一批并行运行的 Claude 智能体，他用 11 天将 Bun 从 Zig 迁移到 Rust，这一结果迅速引发开发者社区关注：一边是大规模软件重构效率被改写，另一边是 Zig 创始人 Andrew Kelley 对代码质量和工程治理的严厉批评。
Bun 是一套 JavaScript 工具链，覆盖运行时、包管理器、打包工具和测试运行器。运行时可以理解为执行 JavaScript 程序的基础环境；工具链则是围绕开发、构建、测试形成的一组工具。Bun 受到部分开发者欢迎，原因在于它试图提供一个速度快、与 Node.js 生态兼容的一站式方案。
从 Zig 到 Rust：速度、内存与漏洞压力
Bun 早期选择 Zig，是因为 Zig 强调性能与底层控制。为了提升启动速度和降低内存占用，Bun 采用了苹果 WebKit 的 JavaScriptCore 引擎，而非更常见的 V8。随着用户规模扩大，Bun 代码中的问题不断暴露。Sumner 承认，Bun 的架构混合了垃圾回收和应用驱动的内存管理，而 Zig 并非为这类任务量身设计；相比之下，Rust 在自动化内存管理方面更适合此次改造。
原文提到，Anthropic 于 2025 年 12 月收购 Bun，并基于 Bun 构建其核心状态机。在此之前，名为 RoboBun 的 Claude Bot 已经在 Bun 代码库中承担大量维护工作，包括修复 Bug 和处理测试失败，并成为合并 PR 数最多的贡献者。
此次迁移的关键数据包括：
- 迁移耗时：11 天；
- 并行 Claude Code 工作流：约 50 个；
- 峰值产出：每分钟约 1300 行代码；
- 最终生成：超过 100 万行 Rust 代码；
- 按 API 定价估算成本：约 16.5 万美元；
- 测试规模：Bun 自身超过 100 万条断言，宣称在所有支持平台 100% 通过，未跳过或删除测试。
支持者看到效率，批评者质疑“没人把关”
在支持者看来，这次迁移展示了 AI 对软件工程边界的改变。Sumner 认为，如果由小型工程师团队手动重写 50 万行 Zig 代码，可能需要整整一年，并导致 Bug 修复、安全修复和功能开发停滞。HashiCorp 联合创始人 Mitchell Hashimoto 也在 X 平台表示，以工程师薪资水平衡量，Claude 在 11 天内完成的里程碑几乎不可能由人工团队达成。
但 Kelley 的态度截然相反。他强调，问题并不只是 Zig 与 Rust 的功能差异，也不只是是否使用 AI，而是两个项目的价值观不同。在他看来，Bun 长期激进发布新功能，积累了大量技术债务，错误处理和工程实践并不可靠。Kelley 的核心质疑是：如果测试套件没能发现 Zig 版本中的所有缺陷，又凭什么相信它能发现 100 万行未经充分人工审查的 Rust 代码中的问题？
这场争议还涉及 AI 生成代码能否回馈开源社区。Bun 团队曾维护一个 Zig 分支，据称调试编译速度提升四倍，但 Zig 项目以“不接受基于 AI 的贡献”为由拒绝相关改动。Kelley 认为，大语言模型生成的提交大量涌入，其中不少质量堪忧，如果缺乏工程监督，未来会带来更多隐患。
AI 编程进入“重构可行、治理更难”的阶段
这起事件的行业意义不在于简单证明 Rust 优于 Zig，或 AI 能取代程序员，而在于它揭示了软件工程的新矛盾：AI 已经能让过去成本过高、周期过长的大规模重构变得可执行，但代码可维护性、责任归属和审查机制并不会自动随之解决。
测试套件是质量保障的重要手段，但测试只能覆盖被设计出来的场景，无法天然替代架构评审、安全审计和长期维护经验。对普通技术团队而言，Bun 的案例更像一次压力测试：AI 可以显著降低迁移门槛，尤其适合机械性、重复性、可验证的代码转换；但越是核心基础设施，越需要明确哪些代码经过人工审查、哪些风险由测试覆盖、哪些决策由维护者负责。
接下来，AI 辅助开发很可能继续深入运行时、编译器、基础库等底层项目，但开源社区也会更重视贡献来源、审查标准和可追溯性。Bun 的迁移也许会成为标志性案例：它证明 AI 重构已经足够快，也提醒业界，快并不等于工程上已经足够稳。