近日，开源界一个技术事件在开发者社群引发持续热议。一个名为Bun的JavaScript运行时项目，在短短9天内完成了超过100万行代码的重写，累计提交达6755次，几乎全部由AI编程工具Claude Code完成。这一"史上最大AI重构"项目，在测试通过率高达99.8%的前提下，却引发了关于AI生成代码安全性的深度追问。

事件背景需要追溯到去年12月。AI公司Anthropic收购了Bun项目。收购后不久，Bun团队启动了一个雄心勃勃的迁移计划——将项目从Zig语言重写为Rust。Zig需要开发者自行管理内存，而Rust因其内置的内存安全机制，近年来在系统级开发领域备受青睐。

项目启动仅9天后，超过100万行Rust代码和6755次提交被合并进主分支。Bun团队宣称，新版本通过了现有测试套件99.8%的测试。这一成绩迅速在Hacker News等平台刷屏，被许多人视为AI编程进入新阶段的重要标志。

然而，测试通过率接近满分，是否就意味着代码真的更安全了？一位名叫dreamreal的开发者在Hacker News上发表长文，从另一个角度重新审视这场备受追捧的AI重构实验。他的观点将讨论焦点从"AI能不能写代码"，转向一个更核心也更棘手的问题：当AI生成代码的速度远超人类审查速度时，我们该如何证明这些代码值得信任？

关键发现来自代码审查。尽管测试通过率高达99.8%，但审查人员发现，迁移后的代码中分布在700多个文件里的unsafe代码块超过一万个。这意味着，原本宣称是为了提升内存安全性而进行的重构，实际上并未真正消除内存风险。

作为对比，另一个体量相当的Rust项目uv，整个项目仅有73个unsafe块。两者相差两个数量级。而这一结果，恰恰源于Bun团队采用的迁移策略——要求AI尽可能"忠实"地移植Zig代码，保持相同的架构和数据结构。

但一个依赖手动内存管理的实现，在被"忠实移植"之后，并不会自动变成内存安全的代码。它只是变成了一份披着Rust外衣的手动内存管理实现。每当原始Zig代码中的逻辑无法通过Rust借用检查器验证时，迁移过程就会使用unsafe来绕过限制。

开发者Todd Smith指出，团队完全可以提前设置约束，例如明确规定"禁止使用unsafe"，通过Git的pre-commit hook在提交前强制检查。在这样的限制下，大语言模型理论上会寻找其他实现方式，逐步引入真正的内存安全机制。

测试通过率高与大量unsafe代码并存，并非矛盾。两者实际上描述的是同一件事——这次迁移足够"忠实"，但"忠实还原"并不能自动实现迁移之初承诺的安全性目标。测试套件只能证明新实现与旧实现对外暴露的接口行为一致，无法证明底层实现是否真正安全。

最自然的辩护理由或许是：这还只是早期阶段，后续还有更多PR，随着逐步重建成符合Rust惯用写法的代码，unsafe数量自然会下降。但问题在于，验证Rust中一段unsafe代码是否真正安全，本身就是一件极其困难的事情。Amazon曾联合Rust基金会发起专门项目，验证Rust标准库中的unsafe代码。

即便是Rust标准库本身，在过去这些年里也出现过二十多个可以追溯到unsafe代码的CVE漏洞。尽管这些代码已经接受了数十年专家级别的审查，问题依然存在。

Bun团队目前主要依赖测试套件获得信心。但如果旧实现本身是一套依赖手动内存管理的系统，而新实现只是对它进行了忠实翻译，那么测试全部变绿所证明的，仅仅是迁移工作完成得很好。除此之外，它完全无法告诉你：这套系统是否真正安全。

真正值得关注的，是代码生成能力正在指数级扩张，而代码验证能力却远远没有跟上。这种不对称，才是整个事件真正值得关注的地方。Bun可能只是迄今为止规模最大、曝光度最高的案例而已。

这一事件为整个AI编程领域提出了一个警示：当评估AI生成的代码时，不能仅看测试通过率或性能指标，更需要审视代码的内在质量与安全性。行为一致性和内存安全性，是两个完全不同的维度。