概念 5：吞吐量改变合并理念
原文要点
当 Codex 的吞吐量远超人类注意力时，传统的工程规范变得不再有效。
核心转变：纠错成本低，等待成本高。
具体变化
PR 生命周期缩短
- 1,500 个 PR / 5 个月 / 3 人 = 人均每天 3.5 个 PR
- PR 不再是需要精雕细琢的大作，而是快速流动的小变更
- 扩展到 7 人后吞吐量仍在增长（说明瓶颈不在人数）
合并门控最小化
- 尽量减少阻塞合并的门
- 测试偶发失败 → 后续重跑解决，不无限期阻塞
- 在低吞吐量环境中这是不负责任的；在高吞吐量环境中这通常是正确的
智能体审查智能体
- 人类可以审核 PR，但不是必须的
- 随着时间推移，几乎所有审核都调整为智能体对智能体
- Ralph Wiggum 循环：Codex 本地审核 → 请求额外智能体审查 → 对反馈做出响应 → 循环直到所有审核通过
来自其他文章的补充
HumanLayer — 优化迭代速度而非首次成功率
实战结论：
- ❌ 每次改动跑全量测试
- ✅ 优化迭代速度，快速发现和修复问题
- ✅ 便宜模型（Sonnet/Haiku）做子任务，贵模型（Opus）做编排
LangChain — Ralph Loop 机制
长时间自主执行需要：
- 文件系统 + git 追踪持久化工作
- Ralph Loop 拦截退出，在新上下文窗口中重注入原始提示词
- 规划 + 自我验证分解目标为步骤
Martin Fowler — 技术栈收敛假说
当编码从手写转向引导生成时，开发者偏好作为选型标准的重要性下降。组织可能基于 harness 的质量和"AI 友好度"来选择技术栈 → 技术栈趋向收敛。
OpenAI Symphony — 吞吐量从 PR 级跃迁到 ticket 级
Symphony（references/articles.md #16）把吞吐量哲学抽象到更高一层：从"PR 流转速度"到"ticket 流转速度"。差别在哪——
| 层级 | 单位 | 人类介入点 |
|---|---|---|
| OpenAI 原文 | 1 PR | 提示+审查 |
| Symphony | 1 ticket（可产出 0..N 个 PR） | 提交 ticket + 审查 review packet |
数据点：部分团队前三周已落地 PR 数量 +500%。原因不是 PR 写得更快，而是人类不再为每个 PR 付注意力成本——一个 ticket 内的多次重试、PR 拆分、CI 重跑全由编排器代劳。
前提对齐： Symphony 的工作方式仍然依赖原文要求的所有"背压机制"（CI、lint、测试），并加上"可推送到 ticket 状态机的工作流"（WORKFLOW.md）。原文的吞吐量哲学是必要条件，Symphony 是它的充分应用。
关键洞察
这个概念的本质是一个经济学问题：
传统模式：人力贵 + 吞吐量低 → 每个 PR 都要精心审查 → 阻塞门多
Harness 模式：智能体便宜 + 吞吐量高 → 快速迭代修复 → 阻塞门少
前提条件：必须有足够的背压机制（测试、lint、结构检查）来保证基本质量，否则就不是"快速迭代"而是"快速腐烂"。