事件背景:史上最大规模AI代码重写
2026年7月15日,全栈JavaScript工具包Bun宣布完成了一项极具争议的技术重构。作为去年被Anthropic收购的项目,Bun团队宣布花费了相当于16.5万美元的资源,利用64个并发的Claude Agent(智能体),在短短11天内将其整个代码库从Zig语言重写为Rust语言。这一举动通常被视为初创公司在市场压力下做出的绝望之举,但Bun的情况似乎有所不同。这次涉及百万行代码的重写不仅修复了128个遗留Bug,还将二进制文件体积缩小了20%,整体性能提升了几个百分点。更重要的是,自6月以来,新的Rust代码库已稳定支撑Claude Code的运行,且未引发任何用户侧的异常。
"Last week, Bun... announced that they spent the equivalent of $165,000 running 64 parallel clot agents to refactor their entire codebase from Zigg to Rust in just 11 days."
尽管结果看似成功,但社区反应两极分化。Zig语言的创始人Andrew Kelly公开回应,认为Bun提供的基准测试数据具有误导性。他进一步指出,Zig团队实际上对Bun的离开感到轻松,因为Bun的代码库长期以来被Zig内部用作“如何不写Zig”的反面教材。此外,Kelly还批评Bun创始人Jared在LLM(大语言模型)出现之前就已经在产出低质量代码。这场技术迁移不仅是一次代码库的变更,更演变成了一场关于技术选型、AI辅助编程有效性以及开发者声誉的公开辩论。
重写动机:内存管理的噩梦与AI适配困境
Bun决定进行这次重写,根源在于其原始语言Zig带来的内存管理困境。Zig是一种低级语言,要求开发者手动管理内存,而Bun嵌入了JavaScript Core(Safari的垃圾回收引擎)。这导致Bun的对象一半由垃圾回收器管理,另一半由手动管理的Zig内存持有,两者之间需要频繁管理指针。这种混合模式导致代码库结构混乱,充满了因内存读取已释放区域、重复释放内存或内存泄漏引发的Bug。
"Half of Bun's objects were owned by the garbage collector, while the other half lived in manually managed Zig memory, and the two had to constantly manage pointers to each other, which led to a codebase that looked like it had an explosive diarrhea parasite."
具体的内存问题包括开发服务器每次重建时泄漏3MB内存,这仅仅是因为单个错误路径忘记清理资源。然而,更深层的驱动力来自Anthropic收购后的战略调整。Anthropic希望未来大部分代码由Claude生成,但Zig语言以反AI友好著称。Zig团队拒绝LLM生成的拉取请求,甚至会在安全报告中关闭承认AI发现Bug的提交。此外,由于互联网上Zig代码极少且语言尚未稳定(1.0版本前存在破坏性更新),模型在生成Zig代码时的表现远不如在成熟语言上。因此,Jared决定通过迁移到Rust来同时解决内存安全和AI适配问题,利用Rust的借用检查器将内存管理错误转化为编译时错误。
执行过程:AI驱动的重写工作流
Bun的重写过程极具创新性,主要依赖AI代理的并行工作流。首先,Claude花费数小时研究代码库,生成了一份详细的迁移指南。接着,团队运行了一个工作流,追踪每个结构体字段的生命周期,并将其整理成电子表格,从而将多年的“部落知识”(即谁在何时释放什么内存)文档化。随后,团队利用分布在四个Git工作树中的64个并行Claude Agent,对1448个文件进行了重构。
"From there, they used 64 parallel CLA agents across four git workrelate all, 1448 files, at one point cranking out 1300 lines of Rust per minute."
为了保持代码质量,团队引入了对抗性审查机制。每个代码实现者都配有两个独立的Claude Agent作为审查者,这些审查者被设定为假设代码是错误的,并专门负责寻找漏洞。整个重写过程在11天内完成,产生了652次提交。如果按市场价计算,这笔算力成本约为16.5万美元(尽管Bun拥有自己的代币,可能降低了实际成本)。最终,Bun的整个测试套件在所有平台上均通过,不仅解决了内存泄漏问题,还实现了二进制文件的显著缩小。
性能数据与基准测试对比
Bun团队公布的重写成果包含多项具体的性能指标和代码量数据。以下是重写前后的关键数据对比,这些数据构成了Bun主张重写成功的主要依据,也是后续争议的核心焦点。
| 指标类别 | 重写前 (Zig) | 重写后 (Rust) | 变化/备注 |
|---|---|---|---|
| 代码行数 | 535,000 行 | 1,000,000+ 行 (估算) | 涉及百万行级别的迁移 |
| 重写耗时 | N/A | 11 天 | 极短的重写周期 |
| 并发Agent数 | N/A | 64 个 | 并行处理 |
| 算力成本 | N/A | 等效 $165,000 | 若按市场价计算 |
| 遗留Bug修复 | 128 个已知Bug | 0 (修复后) | 修复了长期存在的内存问题 |
| 二进制体积 | 基准值 | 缩小 20% | 显著减少 |
| 整体性能 | 基准值 | 提升数个百分比 | 小幅提升 |
| 代码生成速度 | N/A | 1,300 行/分钟 | 峰值生成速度 |
| 提交次数 | N/A | 652 次 | 11天内的版本控制记录 |
"The port fixed 128 long-standing bugs. The dev servers memory leak issues resolved, but binaries got 20% smaller."
这些数据表明,重写在代码稳定性和二进制效率上取得了显著进展。特别是修复128个Bug和解决内存泄漏,直接解决了Zig版本中最为头疼的运行时错误问题。二进制体积缩小20%则意味着部署和分发效率的提升。然而,Andrew Kelly对这些数据的解读提出了质疑,他认为性能增益主要来自于链接时优化(LTO),而Zig本身一直支持LTO,并非Rust独有。此外,他批评Bun忽略了编译时间这一关键指标,暗示Zig在编译速度上可能仍占优势。
争议焦点:Zig创始人的反击与技术质疑
Zig创始人Andrew Kelly的回应不仅包含技术质疑,还带有强烈的情感色彩。他指出,Zig团队多年来一直看着Bun“羞辱”他们的语言,Bun的代码库被内部用作反面教材。Kelly还针对Jared个人进行了攻击,指出Jared18岁辍学接受Peter Thiel的投资,追求创业荣耀,这导致其带有“初学者能量”(beginner energy),且管理风格不佳。
"According to him, the Zigg team spent years watching Bun embarrassed their language with a codebase they privately used as the example of how not to write Zigg."
在技术层面,Kelly的核心论点包括: 1. 性能增益来源存疑:Bun的性能提升主要归功于链接时优化(LTO),这是Zig早已支持的特性,而非Rust的专属优势。 2. 二进制体积无关性:二进制文件缩小20%与迁移到Rust无直接因果关系。 3. 编译时间被隐瞒:Bun未公布编译时间数据,而Zig在编译速度上通常优于Rust。
"He argues the performance gains mostly came from link time optimization which Zig has supported the whole time that the binary size reduction had nothing to do with Rust and that Jared conveniently left out any reference to compile times which Zigg almost certainly wins."
这些质疑揭示了重写评估中的常见陷阱:选择性展示数据。虽然Bun在运行效率和内存安全上取得了进步,但在开发体验(如编译速度)和特定优化技术(LTO)的归属上,双方存在根本分歧。Kelly的反击虽然情绪化,但也指出了技术迁移中容易被忽视的隐性成本。
结论与启示:AI辅助重写的未来
这场“离婚”没有明确的赢家。Zig失去了其最著名的用户,Kelly失去了冷静,而Jared则被公开贴上“初学者”标签。然而,Bun的重写案例为软件行业提供了一个重要的参考:AI辅助代码重写已成为可能,且效率惊人。通过结合LLM的代码理解能力、并行代理的生成速度以及对抗性审查的质量控制,团队能够在极短时间内完成大规模重构。
"But if you're looking to rewrite your own codebase in Rust or just write better code in general, then you need to know about Code Rabbit..."
对于开发者而言,这一案例强调了代码审查在AI辅助编程中的重要性。Bun采用的“实现者+对抗性审查者”模式,有效缓解了AI生成代码可能带来的质量风险。尽管存在争议,但Bun的成功表明,在解决特定技术债务(如内存管理)和适配新工具链(如AI生成)时,激进的重写策略并非不可行。未来,随着AI能力的提升,类似的代码迁移可能会变得更加普遍,但如何平衡性能、开发体验和社区关系,仍是每个团队需要面对的复杂问题。
"Writing thousands of lines of code with AI feels great until you have to review all that unholy slop by hand."
最终,Bun的重写不仅是一次技术升级,更是一次关于技术主权和AI角色的实验。它证明了AI可以加速重构,但也提醒我们,技术决策背后的社区关系和长期维护成本,往往比代码本身的性能数据更为复杂。