副标题： Anthropic 官方案例拆解——扇出并行、对抗 Review、worktree 隔离，以及「人类几乎不敲代码」的团队怎么 merge

2026 年 5 月中旬，Bun 创始人 Jarred Sumner 在 X 上发了一条推文：Linux x64 glibc 上，Rust 重写版 99.8% 既有测试通过。

几天后，一个 超过 100 万行 Rust 的 PR 被 merge 进主仓库。Zig 源码随后被大规模删除——GitHub 甚至自动给删 Zig 的 PR 打了 「AI slop」 标签。

这不是科幻，而是 Anthropic 在 Dynamic Workflows 博客里点名的 极限压测案例：Bun 团队用 Claude Code Workflow，把原本可能要 季度级 的语言迁移，压到了 11 天。

如果你刚读完《Claude Code 动态工作流：6 种编排模式》，这篇就是把那个「Bun 实录」章节 拆到骨头里——适合想在自己仓库做大规模迁移、重构的工程师。

一、背景：为什么 Bun 要从 Zig 换 Rust？Bun 是高性能 JavaScript 运行时 / 工具链，长期以 Zig 实现著称。Jarred 曾是 Zig 的强力倡导者。

但 2025 年底 Bun 被 Anthropic 收购后，几件事叠在一起：

因素

说明

内存安全债

use-after-free、double-free、错误路径漏 free 长期消耗大量调试时间

AI 原生工作流

Jarred 公开表示：好几个月团队几乎不再手写代码，AI 写是常态

Zig 上游政策

Zig 官方 不接受 AI 生成代码；Bun 用的 Zig fork 与上游渐行渐远

Rust 工具链

编译器辅助捕获内存类 bug；生态与招聘面更广

Jarred 在实验初期也很克制：

「我们还没承诺重写。这些代码有很大概率会被完全扔掉。我想看看能跑起来的版本长什么样、性能如何、手感如何。」

——结果：实验没扔，merge 了。

二、规模数据：这组数字意味着什么？综合 Anthropic 官方博客、Jarred 推文与 The Register 等报道，可核对的核心指标如下：

指标

数据

备注

Rust 产出

约 75 万～100 万+ 行

单次巨型 commit，人类无法逐行 review

测试通过率

99.8%

既有测试套件，Linux x64 glibc

周期

首次 commit → merge 约 11 天

2026-05 初实验 → 5 月 14 日 merge

并行 Agent

数百个 并行写 .rs

每文件配 2 个 reviewer

二进制体积

缩小 3～8 MB

merge 后披露

性能

持平或更快

架构与数据结构基本不变

async Rust

未使用

刻意保持与原有模型一致

关键结论：这不是「重写一个 demo」，而是 生产级运行时 在保持测试绿灯的前提下换语言实现。

三、两阶段迁移：Phase A / Phase BBun 在 claude/phase-a-port 分支公开了方法论，并写了 Zig → Rust 移植指南（PORTING.md，约 300 条规则）。

Phase A：忠实翻译（当前重点）• 逐文件 把 Zig 逻辑翻译成 Rust

• 此阶段 Rust 不必能编译——目标是 捕获语义意图

• AI Agent（Claude + robobun 自动 PR）承担主体翻译

Phase B：让它跑起来• 逐 crate 修编译、链接、运行时

• Fix loop 直到 build + test 全绿

这和 Dynamic Workflows 的 「扇出 → 合成 → 循环直到完成」 模式一一对应：先并行铺开，再_barrier 式收敛。

四、Workflow 编排：官方披露的 4 步流水线Anthropic 工程博客对 Bun 案例的描述，可还原为下面这条 可复用 的编排链（非逐字脚本，是模式抽象）：

1. 映射阶段

└─ 为 Zig 每个 struct field 建立 Rust lifetime / 所有权对应关系

2. 扇出端口

└─ 每个 .zig 文件 → 独立子 Agent → 产出 .rs（独立 worktree）

3. 对抗 Review

└─ 每个修复再 spawn reviewer Agent，按 rubric 挑刺

4. Fix Loop

└─ build + test 失败 → 再 spawn 修复 Agent，直到全绿

5. 优化 Pass（可选，通宵跑）

└─ 扫描不必要的数据拷贝，每个优化单独开 PR

为什么必须 worktree + 小 PR？百万行单 PR 没人能 review——GitHub 评论里也有人讽刺：「多可爱的可 review 小 commit 啊。」

Bun 的选择是：

• 并行写：最大化吞吐

• 隔离写：每个 Agent 在独立 worktree，避免互相踩文件

• 对抗验：缓解「自己写自己批」的自偏好（Self-preferential bias）

• 测试当门禁：99.8% 通过率是 merge 的硬论据，不是 vibe

这和你在《Generated Code is Real Code》里读的 merge 责任 形成张力：代码是谁写的已不重要，什么证明它能上线才重要。

五、六种 Workflow 模式在 Bun 案例里的对号入座模式

Bun 案例中的体现

Fan-out-and-synthesize

数百文件并行端口，最后合成可构建的 crate 图

Adversarial verification

每文件 2 reviewer；修复与审查分上下文

Loop until done

build/test 不绿就继续 spawn fix Agent

Classify-and-act

Phase A 翻译 vs Phase B 编译修复，分阶段路由

Generate-and-filter

大量初稿 Rust 经测试与 review 过滤

Tournament

未强调，但优化 pass 可对多种拷贝消除方案做筛选

资源提示：官方建议迁移类 Workflow 限制重型命令（如全量 benchmark），否则本机并行 Agent 会把 CPU/内存打满。

六、Jarred 的 X 帖与社区争议Jarred 的推文线程（@jarredsumner）是一手信息源。几个高信号观点：

1. 「AI 写码已是常态」——收购前后，团队已长期依赖 Agent 产出

2. 实验心态——先出可运行、可测版本，再决定要不要 merge（后来 merge 了）

3. Rust 赢的不只是安全——还有 编译期消灭整类 bug 带来的长期 velocity

4. Rust 不是银弹——跨 JS 边界的引用持有、重入路径等 leak 仍靠人设计

社区分裂也很有意思：

• 支持者：终于有公开、可测的大规模 AI 迁移样本

• 怀疑者：百万行不可 review → 「快不等于对」

• 中立派：即便最终 discard Rust 分支，并排对比 本身就是工程金矿

七、对你团队的启示（可抄作业清单）不必拥有 Anthropic 无限 Token，也能借鉴 结构，而非照搬 规模：

1. 先写「移植宪法」Bun 的 PORTING.md ≈ 你的 Skill + 规则文档：

• 命名约定

• 错误处理映射

• 禁止模式（如不要随便引入 async）

• 测试门禁定义

没有宪法，扇出越多，垃圾越快。

2. 任务粒度 = 文件 / 模块 / 失败测试Workflow 适合 可枚举子任务：

• ✅ 每个 callsite 端口

• ✅ 每个 failing test 一个 fix loop

• ❌ 「帮我把项目变现代」

3. 隔离与并行• 子 Agent 独立 worktree

• 避免资源密集型命令挤在同一台机器

• 合并策略：测试绿 + 对抗 review 过 才可进主分支

4. 人类角色转变Jarred 的模式里，人更像 指挥官 + 门禁设计师：

• 定 PORTING 规则

• 定 stop condition（99.x% tests pass）

• 拍板 merge / discard

• 处理 Agent 无法覆盖的架构债

5. 诚实面对「不可 review」百万行 PR 的现实是：信任测试 + 信任过程 + 信任抽样 audit。

建议搭配：

• 分层测试（单元 / 集成 / 回归）

• 关键路径人工 spot check

• 金丝雀发布

• 回滚预案

八、何时别学 Bun？（降温）Bun 案例 不能 被误读为「所有迁移都该 Workflow 通宵跑」。

场景

建议

小模块换语言

单 Agent + Skill 足够

无完善测试套件

先补测试 再谈迁移

Token / 算力有限

缩小扇出，分批文件

监管 / 合规极严

需要更强人工 traceability

Anthropic 原话：Workflow 费 Token，适合 高价值、复杂、长时 任务。Bun 是 upper bound，不是你的默认配置。

九、与系列前文的衔接代码语言：javascript复制PORTING.md

≈ 领域 Skill；验证类 Skill 是测试门禁下一篇自然续篇：D01 DeepSeek V4 开源解读，或 C04 AI 原生工程团队（组织层怎么接住这种产出速度）。

十、结论Bun 的 Zig → Rust 不是「AI 又炫技了」，而是一次 可观测的工程实验：

1. 动态 Workflow 把迁移拆成可并行、可对抗验证的流水线

2. 300 条移植规则 + 99.8% 测试 是质量锚点，不是口号

3. 11 天百万行 依赖的是编排层，不是某一个更聪明的 prompt

4. merge 之后，真正的考验是 生产环境、社区信任、长期维护

静态语言选型争论还会继续。但对 Agent 时代的工程师来说，更值得抄走的是：怎么设计 PORTING 宪法、怎么设 stop condition、怎么让测试替人类签字。

资料来源• Anthropic《A harness for every task: dynamic workflows in Claude Code》：https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code

• Jarred Sumner X 线程：https://x.com/jarredsumner/status/2060050578026189172

• Bun 移植指南 PORTING.md：https://github.com/oven-sh/bun/blob/main/docs/PORTING.md

• Bun phase-a-port 分支：https://github.com/oven-sh/bun/compare/claude/phase-a-port

• The Register 报道（2026-05-14 merge）：https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381

• Rust Bytes 解读（2026-05-11）：https://weeklyrust.substack.com/p/the-great-zig-to-rust-experiment

• 上一篇：《Claude Code 动态工作流》content/claude-code-dynamic-workflows/

文中规模、通过率、周期等数据来自公开报道与官方博客，不同统计口径（75 万 vs 100 万行）因计数方式而异；迁移效果与团队测试成熟度、工程规范强相关，请结合自身仓库判断可复制程度。