# Bun 用 Workflow 从 Zig 迁到 Rust：11 天百万行实录

**副标题：** 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 B

Bun 在 `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，不是你的默认配置。

---

## 九、与系列前文的衔接

| 前文 | 本文补上 |
|------|---------|
| C01 Skills 九分类 | `PORTING.md` ≈ 领域 Skill；验证类 Skill 是测试门禁 |
| C02 Dynamic Workflows 六模式 | 第一个 **百万行级** 公开落地样本 |
| Agentic Coding Report | 「多 Agent 协同」从报告走进生产 runtime |
| Generated Code / merge 责任 | 不可 review 时代，**测试即法律** |

下一篇自然续篇：**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 万行）因计数方式而异；迁移效果与团队测试成熟度、工程规范强相关，请结合自身仓库判断可复制程度。*

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

Bun 用 Workflow 从 Zig 迁到 Rust：11 天百万行实录

软件研发

编程语言

开发工具

人工智能

Bun团队11天完成百万行Zig到Rust迁移，借助AI工作流实现99.8%测试通过率。采用扇出并行、对抗Review和worktree隔离策略，核心在于移植规则文档+测试门禁。案例展示AI时代工程实践：人类定义规则，Agent执行，测试结果决定合并。

数据结构

编译器

路由

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Bun 用 Workflow 从 Zig 迁到 Rust：11 天百万行实录-腾讯云开发者社区-腾讯云

Bun 用 Workflow 从 Zig 迁到 Rust：11 天百万行实录

Bun 用 Workflow 从 Zig 迁到 Rust：11 天百万行实录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐