修流程，不修代码：Bun 重写案例的范式信号
July 23, 2026 · View on GitHub
触发：Jarred Sumner《Rewriting Bun in Rust》（references/articles.md #56，译文见 works/bun-in-rust-translation.md）。 对照对象：#36 动态工作流、#48 Cursor 规模化、#49 并行 Claude 造 C 编译器、#55 外环问责。 日期：2026-07-22
论点
Bun 重写案例把 harness engineering 的角色反转推到了一个可以直接引用的表述上。Sumner 自己的原话是：
一套语言无关、带百万断言的测试套件；对抗式代码评审；以及当真出了问题时，修复生成代码的流程，而不是手改代码。
"修流程不修产物"此前散落在多篇文章里（#26 的"从批准者到训练者"、#55 的"改 harness 而非改工件"），但都是方法论倡议。Bun 案例是第一个工业负载下的完整实证：535,496 行 Zig 机械移植为 Rust，11 天、6,778 次提交、约 50 个 dynamic workflows、峰值 64 个并发 Claude，产物随后进入 Claude Code 自身的生产运行时。人类工程师在整个过程中没有逐行写代码——他写的是 PORTING.md、LIFETIMES.tsv、workflow 指令和对抗评审者的否决规则。
工程师的交付物是生成过程本身；代码只是这个过程的一次执行结果。
三个对照
对照 #36：从能力宣告到承重结构
#36（dynamic workflows 发布文）展示的是能力：模型可以现场写自己的编排 harness。Bun 案例展示的是承重：同一机制连续运行 11 天、驱动约 78 万行 Rust 产出、按 API 定价花掉约 16.5 万美元，最终合并进一个月下载 2200 万次的运行时。Sumner 那句"不然我就得自己写一个 harness 才能办到"反过来读，恰好说明 dynamic workflows 已经把"一次性编排 harness"的固定成本降到了个人可负担——这正是 #31 预言的 HaaS 形态在真实项目上的兑现。
对照 #49：oracle 的来源决定方法的迁移性
#49（C 编译器）的可行性建立在"近乎完美的验证器"上——GCC 作为外部 oracle 对拍。Bun 案例结构同源，但 oracle 的来源不同：它是项目自己积累了五年的 TypeScript 测试套件，因为测试语言与实现语言解耦，可以原封不动地裁决 Rust 新实现（三平台合计约 365 万个 expect() 断言）。
这给 #2 的 Harnessability（可驾驭性）加了一个此前没人列出的维度：测试套件与实现语言的正交性，本身是战略资产。它把"重写"从一次性豪赌变成了可以增量验证的机械任务——语言选择由此从 Sumner 说的"一锤子买卖"变成了可逆决策。这也解释了为什么该方法论最先在"移植/迁移"类任务上开花（Cursor 的 Solid→React 迁移同理，见 #48）：行为保持类任务天然 oracle 完备。
对照 #55：外环问责的具体工作清单
#55 说"智能体跑内环、工程师拥有外环问责"，但外环工作到底长什么样，Osmani 只给了抽象描述。Bun 案例给出了逐项清单：
| #55 的抽象表述 | Sumner 实际做的事 |
|---|---|
| 设计循环、让验证进环 | 设计分阶段流水线（移植指南 → 生命周期分析 → 试运行 3 个文件 → 放量 1,448 个） |
| 监控与调节 back-pressure | 人工读 workflow 输出；发现 Claude 打桩函数、写辩护性长注释后改对抗评审者的否决规则而非改代码 |
| 验证不能外包给被验证者 | 合并前人工核实"测试确实在运行、没有被跳过" |
| 处理环境故障 | IOPS 配置失误、磁盘写满崩溃、git stash 互相踩踏——全是外环兜底 |
值得单独记的一条流程级修复："如果你需要一段一整段的注释来论证这个绕过方案没问题，那代码就是错的——去修代码。"这是把人类评审直觉热更新进运行中的约束系统——一次提示词编辑，几小时后症状绝迹。约束的迭代周期从"版本发布"缩短到了"运行中改一行"。
两个此前档案里没有的东西
1. 回归清单是"语义陷阱"的分类学样本
19 个已知回归几乎全部来自语法相同、语义不同的代码：Zig assert（函数，永远求值）vs Rust debug_assert!（宏，release 擦除）；ReleaseFast 去边界检查 vs Rust release 保留；comptime 格式串 vs 运行时格式化。这类错误恰好是流程级规则可以系统性消灭、而人工逐行评审无法规模化捕获的——每发现一类，就往移植指南或评审者提示词里加一条，之后的几百个文件自动免疫。这是 #9（反馈飞轮）在单项目内的最小闭环实证。
2. 成本账本的隐藏分母
16.5 万美元 API 成本对比"3 名全上下文工程师 × 一年"，表面是 10 倍级的成本优势。但这笔账的隐藏分母是那套已经存在的百万断言测试套件——它是五年人工工程的沉没投资。没有它，对抗评审再密也只是概率性防线（#47 的教训：评测本身决定你能授予多少自主权）。这与 software-project-complexity-in-the-ai-era.md 提出的"验证成本"维度互证：验证基础设施的完备度，决定同一方法论在不同项目上的成本曲线差异，可以差出数量级。
开放问题
- 方法的边界在哪： 机械移植是"oracle 最完备"的任务形态（行为保持、断言可复用）。绿地开发没有现成 oracle——#49 的做法是让 Claude 先写测试再写实现，但那份测试的权威性远弱于 Bun 的五年存量。行为不保持的任务上，"修流程不修代码"还能守住多少？
- 对抗评审的经济学： 1 名实现者 + 2 名对抗评审者 + 1 名修复者 = 每行代码至少 4 次智能体过手。这个配比是拍脑袋还是最优？评审者从 2 加到 3 的边际收益曲线，目前没有任何公开数据。
- 返工排行榜是新传感器吗： 原文的交互组件展示了各文件的返工次数排名——"哪些文件反复返工"正是 #19 说的推理性传感器想要的信号，但这里它是从流程遥测里免费掉出来的。流程级可观测性（返工率、评审否决率、修复轮数）可能是下一代 harness 传感器的现成来源。
结论
把这个案例和 #48（planner/worker/judge）、#49（无编排者 + oracle）放在一起看，2026 年上半年的三个大规模实证在同一点上收敛：自主权的上限由验证器质量决定，而人类杠杆最高的位置是流程编辑权。Bun 案例的独特贡献是把这件事从"实验室里的编译器/浏览器"推进到了"有 2200 万月下载、要背生产责任的基础设施"——并且给出了完整的成本账本和回归清单，让后来者第一次可以按图索骥地评估：我的项目离这套方法论，差的是模型，还是差一套语言无关的测试套件。