首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Bun 11 天 Zig 迁 Rust:Workflow 实录

Bun 11 天 Zig 迁 Rust:Workflow 实录

作者头像
阿特拉斯
发布2026-06-25 13:49:12
发布2026-06-25 13:49:12
1310
举报

副标题: 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,不是你的默认配置。


九、与系列前文的衔接

代码语言: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 万行)因计数方式而异;迁移效果与团队测试成熟度、工程规范强相关,请结合自身仓库判断可复制程度。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-06-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 超级AI技术 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、背景:为什么 Bun 要从 Zig 换 Rust?
  • 二、规模数据:这组数字意味着什么?
  • 三、两阶段迁移:Phase A / Phase B
    • Phase A:忠实翻译(当前重点)
    • Phase B:让它跑起来
  • 四、Workflow 编排:官方披露的 4 步流水线
    • 为什么必须 worktree + 小 PR?
  • 五、六种 Workflow 模式在 Bun 案例里的对号入座
  • 六、Jarred 的 X 帖与社区争议
  • 七、对你团队的启示(可抄作业清单)
    • 1. 先写「移植宪法」
    • 2. 任务粒度 = 文件 / 模块 / 失败测试
    • 3. 隔离与并行
    • 4. 人类角色转变
    • 5. 诚实面对「不可 review」
  • 八、何时别学 Bun?(降温)
  • 九、与系列前文的衔接
  • 十、结论
  • 资料来源
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档