近日，JavaScript 运行时项目 Bun 因一次史无前例的 AI 重构而引发开发者社区广泛关注。Bun 团队宣布，在 Anthropic 提供的 Claude Code 智能体帮助下，项目于短短 9 天内完成了超过 100 万行代码的迁移工作，共产生 6755 次提交，并将原有 Zig 实现大规模改写为 Rust。这被不少人视为 AI 编程能力迈入新阶段的重要标志。
Bun 原本由 Zig 语言开发。自 Anthropic 于去年底收购 Bun 后，该项目被视为验证 AI 自动编程能力的试验场。此次迁移完成后，Bun 团队公布数据显示：新版本通过了现有测试套件 99.8% 的测试，同时性能与旧版本基本持平，部分场景甚至略有提升，二进制体积也有所缩减。从工程成果来看，这似乎是一场成功的技术升级。
然而，争议迅速出现。许多开发者认为，“测试通过率高”并不意味着代码更安全。因为测试只能证明新系统在外部行为上与旧系统保持一致，却无法证明内部实现是否真正具备更好的安全性。换句话说，99.8% 的通过率只能说明迁移足够“忠实”，而不是足够“安全”。
事实上，Bun 官方推动此次迁移的核心理由正是内存安全。相比 Zig、C/C++ 等依赖开发者手动管理内存的语言，Rust 最大优势在于通过编译器机制减少内存错误，例如重复释放、越界访问或释放后继续使用等问题。因此，团队希望通过 Rust 降低长期维护中的隐患与调试成本。
但问题在于，开发者发现重写后的代码中包含超过 1 万个 unsafe 代码块，分布在 700 多个文件内。unsafe 是 Rust 中一种绕开安全检查机制的特殊能力，一旦大量使用，Rust 原本依赖借用检查器提供的内存安全优势就会被削弱。相比之下，同体量的 Rust 项目 uv 仅使用几十个 unsafe 块，两者差距达到数量级级别。
造成这一结果的原因，与 AI 的迁移策略密切相关。Bun 团队要求 Claude Code 尽量“忠实翻译”原 Zig 架构和逻辑，逐文件迁移，而不是重新设计为符合 Rust 最佳实践的实现方式。当旧逻辑无法满足 Rust 借用规则时，AI 往往选择通过 unsafe 绕过限制，以尽快完成迁移。因此，新系统虽然换成了 Rust 外壳，但底层仍保留了大量手动内存管理思维。
开发者社区因此提出一个更深层问题：AI 写代码的速度已经远远超过人类审查代码的能力。百万行代码在九天内生成，但谁来完整审核这些基础设施级代码？尤其在运行时、编译器等底层系统中，一个隐藏的错误可能数月甚至数年后才以安全漏洞（CVE）的形式暴露。行为测试无法发现所有内存问题，而验证 unsafe Rust 的正确性，目前仍属于学术与工业界共同面对的难题。
文章作者认为，这场迁移真正值得关注的，不是“AI 能不能写代码”，也不是“Rust 是否优于 Zig”，而是如何建立一套可信的 AI 代码验证机制。测试通过率衡量的是功能一致性，而不是安全性。当 AI 开始主导关键基础设施开发时，行业或许需要新的审计标准、形式化验证方法以及更成熟的工程规范，来确保代码不仅可运行，更值得信任。