概念 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 友好度”来选择技术栈 → 技术栈趋向收敛。

关键洞察

这个概念的本质是一个经济学问题：

传统模式：人力贵 + 吞吐量低 → 每个 PR 都要精心审查 → 阻塞门多
Harness 模式：智能体便宜 + 吞吐量高 → 快速迭代修复 → 阻塞门少

前提条件：必须有足够的背压机制（测试、lint、结构检查）来保证基本质量，否则就不是”快速迭代”而是”快速腐烂”。