11天，16.5万美元API费用，53万行Zig代码变成100万行Rust代码——Claude Fable 5完成了一次史无前例的AI驱动重写。
如果你只看这个数字，结论很清晰：AI已经可以大规模替代软件工程师了。但如果你看完整个故事——Zig创始人Andrew Kelley的公开炮轰、技术社区的分裂、2.7万行unsafe代码的遗留——你会得到一个完全不同的结论。
Bun的Rust重写不是AI取代程序员的证据，而是AI时代软件工程新困境的预演：当代码的生成速度超过人类的理解速度，我们实际上是在积累技术债，而不是消除它。
一、一个惊人的实验
Bun是一个高性能JavaScript/TypeScript运行时，旨在替代Node.js。它的核心卖点是极速——启动速度、依赖安装、测试运行都远超竞品。Bun最初用Zig语言编写，每月CLI下载量超过2200万次，Claude Code、OpenCode等工具都依赖它作为运行时。
2025年12月，Anthropic收购了Bun，创始团队加入Anthropic。随后，Bun团队面临一个严峻问题：Zig版本的Bun存在大量内存安全bug——use-after-free、double-free、错误路径中忘记释放内存。这些问题在Zig中只能靠编码规范约束，而在Rust中通过借用检查器和Drop机制会直接变成编译错误。
同时，Zig上游社区对LLM生成代码采取零容忍政策，Bun团队重度依赖AI辅助开发，继续使用Zig意味着必须长期维护自己的编译器分支。
于是，今年5月，Bun创始人Jarred Sumner做了一个疯狂的决定：用Anthropic尚未公开发布的Claude Fable 5，在11天内将53万行Zig代码重写为Rust。整个过程消耗了约16.5万美元的API费用，使用了50个动态工作流在Claude Code中持续运行。
Jarred在博客中详细描述了方法论：先与Claude讨论生成PORTING.md映射文档，然后用对抗性审查——一个Claude写代码，两个Claude在独立上下文窗口中找bug。最终，百万行Rust代码通过了Bun原有的TypeScript测试套件。
从账面上看，这是一次惊人的效率展示：传统方式需要一整年的人力重写，AI将其压缩到了11天，成本约为传统方式的十分之一。
二、两个世界的正面碰撞
但Zig创始人Andrew Kelley不这么看。他在博客中进行了毫不留情的回击，核心论点有三个：
第一，问题不在语言，在人。 Kelley指出，Bun的bug根源不是Zig的缺陷，而是Jarred糟糕的工程习惯——"hacks on top of hacks"、滥用断言、从不花时间消除技术债。早在AI出现之前，Jarred就在写"垃圾代码"。Zig团队检查Bun代码库时感到"极其恐惧"。
第二，测试套件的逻辑漏洞。 Bun官方声称百万行未审查的AI代码"因为有测试用例所以是安全的"。Kelley反问：如果测试真的这么完备，为什么Zig版本没能抓出那些bug？测试套件不足以发现Zig代码的bug，却足以发现百万行未审查AI代码的bug？
第三，AI代码的长期风险。 新代码库中残留了高达2.7万行unsafe代码块。Kelley担忧，未来人类开发者在维护、阅读和修改这坨庞大的AI生成物时，耗费的认知成本和排错成本，最终可能超过今天省下的前置开发成本。
这场争论迅速在技术社区分裂成两派：一派认为Kelley在捍卫纯粹的工程质量，展现了Linus Torvalds式的作风；另一派则认为他公开攻击曾经的重要用户和赞助者，缺乏职业素养。
但如果我们只停留在"谁对谁错"的层面，就错过了这场争论真正的价值。
三、AI时代的软件工程：理解速度与生成速度的鸿沟
剥开"Zig vs Rust"的表层，这场争论暴露了一个核心问题：AI时代，代码的生成速度正在以指数级增长，但人类理解代码的速度几乎没有变化。
让我把这个框架说清楚：
传统软件工程中，代码的生成速度和理解速度是基本匹配的。一个工程师写100行代码，另一个工程师可以花差不多的时间去理解它。代码审查之所以可行，是因为审查速度大致等于编写速度。
但AI打破了这种平衡。Claude Fable 5在11天内生成了100万行代码。假设一个资深工程师每天能认真审查200行代码（这已经是乐观估计），审查完这100万行需要5000个工作日——大约20年。
这不是一个技术问题，这是一个信任问题。
Jarred用对抗性审查（两个Claude互相审查）来弥补这个鸿沟。但对抗性审查本质上是用AI验证AI——一个闭环。它检查的是"代码是否通过测试"，而不是"代码是否被人类理解"。Kelley的质疑正是针对这一点：测试通过不等于代码正确，更不等于代码可维护。
2.7万行unsafe代码就是最好的证据。这些代码在Rust中绕过了借用检查器，保留了Zig版本中所有手动内存管理的复杂性。AI机械翻译了代码，但并没有消除技术债——它只是换了一种语言来存放同样的技术债。
四、推演：这个框架不只适用于Bun
"理解速度跟不上生成速度"这个困境，在AI时代的软件工程中无处不在：
在代码补全场景中， Copilot让开发者写代码的速度提升了50%以上，但代码审查的时间并没有减少。结果就是：更多代码被合并，更少代码被真正理解。
在代码迁移场景中， 不只是Bun在做语言迁移。越来越多的团队用AI将遗留系统从COBOL、Perl迁移到现代语言。迁移本身是机械的，但迁移后的代码是否保留了业务逻辑的细微之处？没有人真正知道。
在文档生成场景中， AI可以瞬间生成API文档、架构说明、代码注释。但这些文档是否准确？当代码被修改时，AI生成的文档会不会变成"漂亮的谎言"？
这些场景的共同特征是：AI让"写"变得极其便宜，但"理解"的成本没有降低。 如果你只关注"写"的效率，你实际上是在用AI加速积累技术债。
五、落在行动上
对于正在使用AI辅助开发的团队，Bun事件提供了几个具体的行动指南：
如果你是技术决策者： 不要用"AI能写多少代码"来衡量AI的价值。用"AI帮团队理解了多少代码"来衡量。如果AI只负责写，不负责解释，你的技术债正在以AI的速度增长。
如果你是架构师： 区分"翻译"和"重构"。AI擅长翻译——把一种语言逐行映射到另一种语言。但真正的工程价值在于重构——消除技术债、改进架构、提升可维护性。如果AI只做翻译，你只是换了一种语言积累同样的技术债。
如果你是开发者： 不要假设AI生成的代码"大概是对的"。对于关键路径（安全、并发、内存管理），人类理解仍然是不可替代的保险。2.7万行unsafe代码不是Rust的问题，是"没有人真正理解这些代码"的问题。
如果你是AI工具开发者： 对抗性审查是好的方向，但不充分。真正的突破不是让AI写更多代码，而是让AI帮助人类更快地理解代码——自动生成架构图、标注边界条件、追踪数据流。降低理解成本，比降低生成成本更有价值。
Bun的Rust重写最终会走向何方？也许几个月后，Bun的稳定性确实大幅提升，Jarred的方法被证明是正确的。也许几年后，2.7万行unsafe代码变成了一座无法维护的技术债火山。
但无论结果如何，这场争论已经为AI时代的软件工程画下了一个坐标：一端是AI的效率奇迹，另一端是人类理解的不可替代性。真正的工程智慧，不是选择哪一端，而是知道在什么时候、在什么位置，站在坐标的哪个点上。