# 吞吐量改变合并理念（Throughput Changes Merge Philosophy）

> 六大核心概念之一（概念 5，编号见 [00-overview.md](00-overview.md)）。

## 原文要点

当 Codex 的吞吐量远超人类注意力时，传统的工程规范变得不再有效。

核心转变：**纠错成本低，等待成本高。**

## 具体变化

### PR 生命周期缩短

- 1,500 个 PR / 5 个月 / 3 人 = 人均每天 3.5 个 PR
- PR 不再是需要精雕细琢的大作，而是快速流动的小变更
- 扩展到 7 人后吞吐量仍在增长（说明瓶颈不在人数）

### 合并门控最小化

- 尽量减少阻塞合并的门
- 测试偶发失败 → 后续重跑解决，不无限期阻塞
- 在低吞吐量环境中这是不负责任的；在高吞吐量环境中这通常是正确的

### 智能体审查智能体

- 人类可以审核 PR，但**不是必须的**
- 随着时间推移，几乎所有审核都调整为智能体对智能体
- Ralph Wiggum 循环：Codex 本地审核 → 请求额外智能体审查 → 对反馈做出响应 → 循环直到所有审核通过

## 来自其他文章的补充

### HumanLayer — 优化迭代速度而非首次成功率

实战结论：
- ❌ 每次改动跑全量测试
- ✅ 优化迭代速度，快速发现和修复问题
- ✅ 便宜模型（Sonnet/Haiku）做子任务，贵模型（Opus）做编排

### LangChain — Ralph Loop 机制

长时间自主执行需要：
1. 文件系统 + git 追踪持久化工作
2. **Ralph Loop** 拦截退出，在新上下文窗口中重注入原始提示词
3. 规划 + 自我验证分解目标为步骤

### Martin Fowler — 技术栈收敛假说

当编码从手写转向引导生成时，开发者偏好作为选型标准的重要性下降。组织可能基于 harness 的质量和"AI 友好度"来选择技术栈 → 技术栈趋向收敛。

### OpenAI Symphony — 吞吐量从 PR 级跃迁到 ticket 级

Symphony（[references/articles.md #16](../references/articles.md#article-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、结构检查）来保证基本质量，否则就不是"快速迭代"而是"快速腐烂"。