AI 代理让“永不重写”成为历史：Bun 从 Zig 到 Rust 的 11 天奇迹

如果你关注 AI 在软件开发中的实际应用，最近 Bun 创始人的一篇博客可能会颠覆你的一些固有认知。Jarred Sumner 详细记录了他们如何利用 AI 编码代理，在仅仅 11 天内将 Bun 的核心从 Zig 语言迁移到了 Rust。这不仅仅是又一次技术选型的胜利，更揭示了软件工程中一个深层范式转移：“永不重写”的戒律正在被 AI 打破。

起因：为什么非要重写？

Bun 是一个用 Zig 编写的 JavaScript 运行时，以高性能著称。但 Zig 手动管理内存的特性，让 Bun 长期饱受 use-after-free、double-free 等内存 bug 的折磨。Sumner 坦言，他厌倦了每天担心崩溃的日子。虽然 Zig 本身很优秀，但将垃圾回收（GC）与手动内存管理混合使用的场景极罕见，几乎没有语言为此专门设计。直到最近，编程语言的选择对于 Bun 这样的项目来说都是一个单向门——一旦选定，几乎不可能回头。

拆解：AI 如何让“不可能”变成“可能”？

传统智慧告诉我们，永远不要停下来从零重写一个大型软件。Joel Spolsky 早在 2000 年就为此写过经典文章。但 Sumner 指出，前沿模型驱动的编码代理改变了这个等式。

具体来说，Bun 团队有一个用 TypeScript 编写的测试套件，与语言无关。这个测试套件成了完美的“一致性要求”：它定义了 Bun 应该表现的行为，而不关心底层是 Zig 还是 Rust。Sumner 构建了一个代理工具链，让 AI 自动将 Zig 代码移植到 Rust，然后运行测试来看是否通过。一开始他也没抱期望，但几天后，极高比例的测试通过了，而且新 Rust 代码与原始 Zig 代码高度匹配。他的看法从“值得一试”迅速转变为“我要合入主线”。

但这不是简单的代码生成。Sumner 描述了复杂的代理工程实践：动态工作流（AI 自主决定做什么）、试运行（不断调整提示和循环）、以及“对抗性审查”——他会手动阅读输出、发现错误，然后提示 Claude 修改循环逻辑来修复问题。最终他面对的是一个 +100 万行的 PR，审查的自信正是来自于那套可验证的测试。

趋势洞察：编程语言不再是单行道

这件事最深远的影响可能在于，它揭示了一个趋势：在 AI 代理的辅助下，编程语言的选择正在从单向门变成旋转门。Sumner 在博客中强调，“直到最近，编程语言的选择对类似 Bun 的项目来说还是一个单向决定。”但现在，如果你有完善的测试套件，AI 可以帮你完成大规模的语言迁移。这意味着团队可以更灵活地根据项目现阶段的需求选择语言，甚至在将来切换。

这背后是 AI 代理工程能力的成熟。我们早已习惯用 AI 写小函数或小脚本，但 Bun 的案例展示了 AI 可以参与架构级别的重构——只要你能提供明确的目标和验证手段。

实用价值：你能从中学到什么？

对于普通开发者，Bun 的故事并非要你马上去重写自己的项目，而是提供了一种新的思维模式：

1. 测试套件是你给 AI 的“要求说明书”。高质量、语言无关的测试，是让 AI 帮你安全重构的基础。
2. 代理工程不是魔法，是迭代过程。Sumner 花了大量时间监控、调整、审查，就像训练一个初级工程师。
3. 从小实验开始。Bun 团队最初只是尝试一个更早的模型，发现可行才加大投入。你可以在非关键模块上先试验。

反常识：AI 不是取代程序员，而是改变决策逻辑

很多人以为 AI 会让编程变成“一句话生成整个应用”。但 Bun 的案例告诉我们，真正革命性的改变在于：AI 让我们敢于做以前不敢做的技术决策。重写不再等同于自杀，因为成本和风险被 AI 大幅降低了。这可能会鼓励更多团队创新，而不是永远被历史代码绑住。

当然，这要求团队拥有强大的工程纪律和测试文化。AI 只是一个杠杆，它放大的永远是你的能力，而不是弥补你的混乱。

原文地址: Rewriting Bun in Rust