2026 年 5 月，Claude 用 11 天将 Bun 的 53.5 万行 Zig 代码完整重写为 Rust，内存从 6.7GB 降至 609MB，API 费用 16.5 万美元。本文拆解其 64 Agent 并行工作流与实现者/审查者分离的工程模式。
2026 年 5 月 14 日，JavaScript 运行时 Bun 的主分支合并了一个让开发者社区沉默的 PR：53.5 万行 Zig 代码，被 Claude 在 11 天内完整重写为 Rust。内存占用从 6.7GB 降到 609MB，API 费用 16.5 万美元。Bun 创始人 Jarred Sumner 花了一个月才写完复盘博客——比 AI 写代码的时间还长。
问题早在 v1.3.14 之前就埋下了。Bun 的架构有一个罕见的设计选择：将 JavaScriptCore 的 GC（垃圾回收）与 Zig 的手动内存管理放在同一个进程里。在 v1.3.14 中，连续调用 Bun.build() 每次泄漏约 3MB——跑 500 次构建内存 1.9GB，2000 次后飙到 6.7GB。
更致命的是那些"堆释放后使用"的崩溃。zlib 模块里 .reset() 和异步 .write() 的竞态条件导致进程直接崩溃；http2 回调触发哈希表重哈希，内部流指针失效；UDPSocket.sendMany() 遍历中用户代码改变了套接字连接状态，发生越界写入。这些 bug 的根因指向同一个问题：GC 与手动内存管理混合使用时，每行代码的内存生命周期都需要逐行审查。
团队不是没努力。改过 Zig 编译器、加了 Address Sanitizer、每次提交跑 CI ASAN、24/7 Fuzzilli 模糊测试——崩溃报告仍然源源不断。Sumner 在博客里写了句话："我厌倦了带着对 Bun 崩溃的担忧去睡觉。"Rust 版本交出的答案是：2000 次构建后内存稳定在 609MB。
如果你以为 Sumner 只是打开 Claude Code 说"把 Zig 重写为 Rust"然后等结果，那就完全理解错了。
他把整个迁移拆成约 50 个动态工作流（dynamic workflows）。每个工作流是一个循环：取一条任务 → Claude 写代码 → 两个审查者 Claude 审查 → 应用反馈 → 取下一条。峰值时 4 个工作流同时跑，每个 16 个 Claude，总共 64 个 Claude 在 4 个工作树中并行提交和推送，最高每分钟约 1300 行代码。这正是 Agentic Coding 从"AI 写代码"到"AI 做项目"的范式转变在真实项目中的极致体现。
这里最关键的工程决策是实现者/审查者分离。写代码的 Claude 有偏见——它想让自己的代码被接受，和人类工程师一样。所以审查者被设计为完全独立：只看代码差异，不看实现者的推理过程，而且被明确告知"假设代码是错的"。每个实现者对应至少两个对抗性审查者，唯一工作就是找 bug。
这个模式在蓝曜炬辉自己的项目中也反复验证过：AIcoding 的难点从来不是"AI 能不能写代码"，而是"谁在审查 AI 写的代码"。没有对抗性审查的 AIcoding 流水线，产出的代码质量会随着迭代次数增加而持续下降。
按 Sumner 的估算，3 名完全熟悉 Bun 代码库的工程师手工完成迁移需要约一年——而且这一年里团队几乎无法推进新功能、bug 修复和安全更新。AI 路线花了 16.5 万美元 API 费用，消耗了 59 亿输入 token、6.9 亿输出 token 和 720 亿缓存 token 读取。
表面看 16.5 万 vs 3 个工程师年薪——AI 完胜。但注意一个容易被忽略的细节：Sumner 本人花了一个月写复盘，比 AI 写代码的 6 天还长。这一个月的"人类消化时间"才是企业落地 AIcoding 时最容易漏算的成本——我们之前算过一笔企业 AIcoding 的真实账，结论和 Bun 案例高度一致：token 账单只是冰山浮在水面上的那一小块。
在实际项目中观察到的规律是：AI 生成代码的速度越快，人类理解、验证、集成的时间占比越高。Claude 一天写完的模块，工程师可能要花三天读 diff、跑测试、补边界 case。这不是 AI 的问题——是软件工程的本质：写代码从来不是瓶颈，理解代码才是。关于如何把 AIcoding 从个人提效推到团队级交付，我们在AIcoding 商业化落地中有更系统的拆解。
Bun 之所以从 Zig 迁移到 Rust，不是因为 Zig 不好——Sumner 明确说不责怪 Zig。问题在于 Zig 在"GC + 手动内存管理混合"这个极窄场景下没有设计，几乎没有语言为这种场景设计。Rust 的所有权系统天然避免了这类问题。企业在选技术栈时如果考虑未来 AI 参与开发，Rust、TypeScript、Go 这些有强类型系统和明确内存模型的语言，Claude 和 Copilot 的表现显著优于动态类型语言——不是因为 AI 偏科，而是因为这些语言的编译器本身就能拦住一大类 bug。
50 个动态工作流 + 实现者/审查者分离——这套方法论不依赖某个特定模型。对企业的启示是：与其等下一个更强的模型发布，不如先把 Agent 协作流程设计好。一个 Claude 写 + 两个 Claude 审，比三个 Claude 一起写效果好得多。对抗性审查的存在不是为了"不信任 AI"，而是因为代码审查的本质就是对抗性的——无论代码是人写的还是 AI 写的。我们在Claude Code 提示词瘦身 80%的实战中也发现，同样的模型，提示词工程和流程设计对最终产出的影响远超模型版本升级。
Bun 重写后二进制体积减少约 20%，Bun.serve 吞吐从 16.96 万 req/s 提升到 17.77 万 req/s，Claude Code 在 Linux 上的启动时间从 517ms 降到 464ms。这些收益不是 AI 写的代码更快——是新语言的内存安全保证和更好的工程结构带来的。AI 帮你写了代码，但可维护性仍然取决于人的架构决策。
Bun 的规模是极端案例——53.5 万行代码全量重写。大多数企业项目的 AIcoding 场景是模块级开发、bug 修复、测试生成，月费通常在几百到几千美元。而且 Claude Code 等工具支持上下文缓存，重复上下文不会重复计费。
需要有深度理解现有代码库的工程师。Sumner 能拆出 50 个工作流是因为他比任何人都了解 Bun 的架构。AI 替代的是"写"，不是"懂"。如果你的团队没有能说清楚"每个模块做什么、为什么这样做"的人，AI 重写的风险极高。
三个条件同时满足时 AI 重写的 ROI 开始显著超过人工：代码库规模超过 10 万行、有明确的目标语言（如 Zig→Rust 这种有清晰映射关系的）、现有语言存在结构性问题（如内存安全、并发模型）。如果只是为了"试试新技术"而重写，那无论用不用 AI 都是亏的。
Bun 案例中，对抗性审查 Agent 是写代码 Agent 数量的两倍。这不是过度谨慎——Zig 代码是单一编译单元，Rust 被拆成约 100 个 crate，第一次 cargo check 输出了约 16000 个编译错误。如果没有审查 Agent 按 crate 分组修复，这个量级对人类团队是灾难性的。结论是：AI 写的代码需要同等级别的审查投入，只是审查本身也可以用 AI 来做。
| 对比维度 | 传统人工（3 人团队） | Claude 工作流（64 Agent） |
|---|---|---|
| 时间 | 约 12 个月 | 11 天（写代码仅 6 天） |
| 经济成本 | 约 90-150 万美元（年薪） | 16.5 万美元（API 费用） |
| 代码审查 | 人工 Review，瓶颈在人 | 对抗性 Agent 审查，2:1 配比 |
| 新功能开发 | 停滞一整年 | 可并行推进 |
| 内存泄漏修复 | 逐行排查，靠 ASAN + 模糊测试 | 语言级内存安全保证（Rust 所有权） |
| 人类消化成本 | 边写边理解 | 写完后集中一个月复盘 |
企业如果正在评估类似的代码迁移项目，蓝曜炬辉可以提供从技术栈评估、Agent 工作流设计到对抗性审查流水线搭建的全流程 AIcoding 工程服务。不是帮你"用 AI 写代码"，而是帮你设计一套让 AI 写出可靠代码的工程体系。
