11 天 53 万行：Bun 的 AI 驱动 Rust 重写，和那些没人告诉你的坑
2026 年 5 月，Bun 创始人 Jarred Sumner 用 64 个 AI agent 在 11 天内将 53.5 万行 Zig 代码重写为 Rust。本文复盘整个过程：方法论、数字成果，以及三个没人会主动告诉你的翻车点。
11 天 53 万行：Bun 的 AI 驱动 Rust 重写，和那些没人告诉你的坑
2026 年 5 月 3 日到 5 月 14 日，JavaScript 运行时 Bun 完成了一次软件工程史上几乎找不到先例的代码迁移：53.5 万行 Zig，11 天内全部重写为 Rust。写代码用了 6 天，创始人 Jarred Sumner 写复盘博客花了一个月——比写代码还长。这背后藏着的，才是 AIcoding 真正的门槛。
为什么非要重写：不是 Zig 的错
Bun 的起点很野。2021 年，Sumner 在 Hacker News 上看到 Zig 的单页语言参考后押注了它。一年内，他在奥克兰公寓里独自写出了 Bun 初始版本——一个集转译器、打包器、包管理器、测试运行器、HTTP 客户端、Node.js API 层于一体的庞然大物。如今 CLI 月下载量超 2200 万，被 Claude Code 和 OpenCode 选为运行时。
问题出在内存管理。Bun 同时跑着 JavaScriptCore 的垃圾回收和 Zig 的手动内存管理，两种范式在同一个进程里打架。结果：每次 Bun.build() 泄漏约 3MB，执行 2000 次后内存飙到 6.7GB。崩溃报告塞满 use-after-free、double-free、越界写入——全是 GC 与手动管理混合才会触发的罕见 bug。
团队不是没努力。他们给 Zig 编译器加了 ASAN，每次提交跑 ASAN 测试，Windows 用 ReleaseSafe 构建，Fuzzilli 24/7 模糊测试。但崩溃报告依然不断。Sumner 原话：「我厌倦了带着对 Bun 崩溃的担忧去睡觉。」这不是 Zig 的问题——其他 Zig 用户没遇到这些——而是把 GC 和手动管理塞进同一进程这种极端需求，几乎没有语言为此设计。
怎么做到的：64 个 AI Agent，50 个工作流
Sumner 的方法和「让 AI 写代码」完全不是一回事。他把整个重写拆成约 50 个动态工作流，每个工作流是一个循环：AI 读任务上下文 → 写代码 → 两个审查者（也是 AI）审查 → 应用反馈 → 取下一张工单。这种模式本质上是 Agentic Coding 的一次极限实践——AI 不再只是补全代码，而是承担了完整的工程角色。
关键设计是「实现者与审查者彻底分离」。写代码的 agent 想让自己的代码被接受——和人类工程师一样有偏见。所以审查者只看 diff，不看实现者的推理过程，且被明确告知「假设代码是错的」。每个实现者对应两个以上对抗性审查者，审查者唯一工作就是找 bug。
峰值时期，Sumner 同时运行 4 个工作流，每工作流 16 个 agent——总共 64 个 AI 在 4 个工作树中并行，各自提交和推送。最高峰每分钟约 1300 行代码。整个过程涉及超 100 万行变更、6778 次提交。
数字说话：$16.5 万换来了什么
| 指标 | 重写前（Zig v1.3.14） | 重写后（Rust v1.4.0） |
|---|---|---|
| 2000 次构建内存占用 | 6.7 GB（持续增长） | 609 MB（稳定） |
| 可复现 bug 数 | — | 修复 128 个 |
| 二进制体积（Linux/Windows） | — | 减少约 20% |
| Bun.serve QPS | 16.96 万 req/s | 17.77 万 req/s |
| next build 耗时 | 13.62 秒 | 13.03 秒 |
| Claude Code 启动（Linux） | 517ms | 464ms（快 10%） |
API 费用：59 亿未缓存输入 token、6.9 亿输出 token、720 亿缓存输入读取，按公开定价约 $16.5 万美元。如果让 3 名完全熟悉代码库的工程师手工完成，Sumner 估计需要约一年——且这一年里团队几乎无法推进新功能。$16.5 万买回了一年的工程带宽。关于 AIcoding 的成本结构，我们在 AI 写代码半年的真实账本 里有更系统的拆解。
同期，Anthropic 的 AIcoding 生态正在闭环。Claude Code v2.1.206 于 2026 年 7 月 10 日发布，新增 /doctor 检查——分析项目文件并建议删除模型可从代码库自行推导的冗余内容，后台 agent 更新后自动升级无需手动干预。Bun 本身在 2025 年 12 月被 Anthropic 收购，Rust 重写大量使用了 Fable 5 预发布版。AI 写代码 → AI 审查代码 → AI 运行在 Bun 上 → Bun 用 AI 重写自身——这个闭环的深度，是目前所有 AIcoding 工具中最完整的。
三个翻车点：AI 写代码容易，写对代码很难
第一个坑：编译错误不是 bug，是海啸。Zig 是单一编译单元，但 Rust 要拆成约 100 个 crate 加速编译。循环依赖导致 cargo check 一次性输出约 16000 个编译错误。对一个人是灾难，对 64 个 agent 是可处理的工作队列——但不是自动的。工作流需要按 crate 分组错误、分配优先级、处理依赖链，这本身就是一套工程。
第二个坑：AI 写的移植代码「看起来对」但语义全错。Zig 到 Rust 不是语法替换。Zig 的 comptime 泛型、手动内存分配模式、与 JS 引擎 GC 的交互协议，在 Rust 里需要完全不同的表达。模型生成的初版代码经常「编译通过但逻辑错误」——比如在 unsafe 块里照搬 Zig 的指针算术，绕过了生命周期检查。对抗性审查在这里救了命：两个审查 agent 不看实现者的推理过程，只从不同角度交叉验证 diff。
第三个坑：不是所有代码都适合让 AI 写。Sumner 明确说，像 LIFETIMES.tsv 这种定义 Rust 生命周期映射的参考文件必须人工编写——它定义了「这个 Zig 指针在 Rust 里对应什么生命周期标注」，是整个移植的骨架。AI 在这个层面的判断力仍然不够。另一个例子是 PORTING.md，它规定了 Zig 模式到 Rust 模式的映射规则，同样需要人工设计。Sumner 的角色从「写代码的人」变成了「给 AI 写规范的人」。关于如何让 AI 输出更精准、减少无用 token 消耗，提示词瘦身 80% 的实战方法 有更详细的展开。
对企业技术决策者的启示
Bun 这次重写不是一个「AI 替代程序员」的故事，而是一个「AI 改变工程分工」的案例——2026 年中 AI 编程正在经历的三个转向 也印证了同样的趋势。几个可直接参考的结论：
- $16.5 万 vs 一年工程带宽：对于任何有大规模代码迁移需求的企业，ROI 已经不需要犹豫。但前提是你有能定义 PORTING.md 和 LIFETIMES.tsv 的人——AI 省的是执行层，不是架构层。
- 对抗性审查是当前 AIcoding 的必备环节：不要让同一个模型既写代码又审查。两个以上审查者、不看实现者推理过程、假设代码是错的——这套模式可直接复用。
- 动态工作流比「一个 prompt 搞定」有效得多：Bun 的重写不是一次对话完成，而是 50 个工作流，每个有明确目标和完成标准。企业落地 AIcoding 时应设计工作流模板，而非期待模型靠一个 prompt 出奇迹。
- 选 AIcoding 工具看生态闭环，不是单点 benchmark：Anthropic 正在构建从模型到运行时的完整链路。Meta 的 Muse Spark 1.1（2026 年 7 月 9 日发布，定价 $1.25/$4.25 per M tokens）也在追这个方向，但生态深度还有差距。
蓝曜炬辉在服务企业 AIcoding 转型时反复验证的结论：工具选型的关键不是模型 benchmark 分数，而是你的团队能不能围绕它建立工作流。Bun 这次重写把这一点推到了极致——工具、审查机制、任务拆分、规范文档，缺任何一环都会翻车。
常见问题
Bun 为什么从 Zig 迁移到 Rust，而不是其他语言？
核心原因是内存安全。Bun 需要同时运行 JS 引擎的 GC 和手动内存管理，Zig 在此组合下频繁出现 use-after-free 和泄漏。Rust 的所有权系统在编译期就阻止了这类问题，重写后 2000 次构建内存稳定在 609MB。此外，被 Anthropic 收购后与 Fable 生态的技术栈对齐也是考量。
64 个 AI agent 并行，费用真的只有 $16.5 万？
这是按 API 定价计算的直接 token 成本。Sumner 披露：59 亿未缓存输入 token、6.9 亿输出 token、720 亿缓存输入读取。实际成本因 Anthropic 内部定价可能更低。但即使按公开价格，对比 3 名资深工程师一年薪资，ROI 仍是碾压级。
中小企业能用这套方法论吗？
可以，核心可复用三要素：① 写一份明确的移植/开发规范（类似 PORTING.md）；② 实现者与审查者分离，审查者 ≥ 2；③ 按工作流拆分任务，每个有明确完成标准。不需要 64 个 agent——2-4 个的工作流对中小规模代码库足够。蓝曜炬辉在多个客户项目中验证了模式的可迁移性。
AIcoding 工具这么多，该怎么选？
看团队瓶颈在哪。瓶颈在代码审查和架构决策 → Claude Code 的对抗性审查 + 动态工作流更合适。瓶颈在单开发者效率 → Cursor/Copilot 的 inline 补全更好。Meta Spark 1.1 差异化在 agentic workload——适合需要跨多个外部工具编排的复杂自动化。没有银弹，先搞清楚瓶颈再选工具。