一、一次通过率怎么定义

定义本身只有一句话，难的是口径。

第二行和第三行是最容易各说各话的地方。 把「关掉的 PR」算进分母，这个数会莫名变低； 把「要求补充说明」算成未通过，这个数会莫名变高。 口径不写清，这个指标就只能跟自己比。 跟自己比也够用——它的最好用法就是看趋势。

二、影响它的四个变量

Demo 选的四件事，都是这一章和前面几章讲过的。

四件事全做，一次通过率从两成八抬到接近九成。 而且每多做一件都还有涨幅，没有哪一件是白做的。 这个「没有边际递减」的结论来自模型形式，不来自真实数据。 我用的是一乘法模型：每加一件，剩下的失败空间按比例缩小。 真实世界会有重叠——需求清晰和契约先行有相当一部分是同一件事。 所以这张表能回答的问题是「先做哪件」，不能回答「做了能到多少」。 前者是排序，排序在重叠的情况下依然稳定；后者是绝对值，绝对值一定偏乐观。

三、信息对齐是不是核心

四件事里三件都跟「信息对齐」有关：需求清晰是对齐目标，契约先行是对齐接口， 范围受控是对齐边界。 只有「验证可跑」不是对齐，是「让对方能自己确认」。 这带来一个反直觉的判断：信息对齐不是核心，「可验证」才是。 因为对齐是一个状态，它会随时间衰减——你今天对齐了，两周后新人进来又不对齐了。 而一条能跑的验证脚本不会衰减，它每次跑都给你同一个答案。 所以四件事的顺序应该是：先把验证做成能跑的，再去做对齐。 理由很实际：验证脚本是对齐的载体——你把它写下来，对齐的结果才留得住。 这一章到这里收住。 五篇讲的是同一件事：跨端的活，风险不在写代码，在「两边想的是不是同一件事」。 而这件事只能靠可验证的东西来保证，不能靠开会。

四、本章小结

五节的共同点是「把判断变成能查的东西」。 需求变成六条验收，接口变成一份契约，迁移变成四步检查，发布变成五档比例，效果变成一个比率。 能查，才谈得上交给 Agent 反复执行。

五、动手 Demo：一次通过率：四个变量各值多少

四个变量各开各关，十六种组合，每种跑二百次模拟。 模型是乘法的：每加一件，剩下的失败空间按比例缩小。 这一篇的数全部是模型输出，不是实测—— 系数是我按经验设的，所以只能看排序和量级。这一点在正文里会重复说。

base = 0.28                          # 四件都没做时的基线
g = [0.45, 0.35, 0.30, 0.40]         # 每件事能消掉多少失败空间

for mask in range(16):
    keep = 1.0 - base
    for i in range(4):
        if mask >> i & 1:
            keep *= (1 - g[i])
    p = 1 - keep
    hit = sum(1 for _ in range(200) if random.random() < p)
    print(mask, "%.0f%%" % (p * 100), "%.1f%%" % (hit / 2))

实跑输出：

--------------------------------------------------------------------
一次通过率：四个变量各值多少
--------------------------------------------------------------------

  一次通过率 = 提交一次就通过评审的比例。它比「改了几轮」更接近真实成本。

  ① 先定义
  --------------------------------------------------------------------

  [指标定义]
  | 一次通过率 = 第一次提交就通过的 PR 数 / 总 PR 数
  | 统计口径：不含「评审要求补充说明」这种不算改代码的退回。
  口径不写清，这个数就没法跨团队比。


  ② 四个变量，各两档，十六种组合
  --------------------------------------------------------------------
| 做到几项 | 哪几项 | 模型值 | 二百次模拟 |
|---|---|---:|---:|
| 0 | 都没做 | 28% | 31.0% |
| 1 | 契约先行 | 53% | 50.0% |
| 1 | 范围受控 | 50% | 49.0% |
| 1 | 需求清晰 | 60% | 58.5% |
| 1 | 验证可跑 | 57% | 53.0% |
| 2 | 契约先行、范围受控 | 67% | 76.0% |
| 2 | 契约先行、验证可跑 | 72% | 71.5% |
| 2 | 范围受控、验证可跑 | 70% | 68.0% |
| 2 | 需求清晰、契约先行 | 74% | 74.0% |
| 2 | 需求清晰、范围受控 | 72% | 71.0% |
| 2 | 需求清晰、验证可跑 | 76% | 78.0% |
| 3 | 契约先行、范围受控、验证可跑 | 80% | 81.0% |
| 3 | 需求清晰、契约先行、范围受控 | 82% | 84.5% |
| 3 | 需求清晰、契约先行、验证可跑 | 85% | 83.5% |
| 3 | 需求清晰、范围受控、验证可跑 | 83% | 84.0% |
| 4 | 需求清晰、契约先行、范围受控、验证可跑 | 89% | 92.0% |

  ! 这十六组里的系数是我按经验设的，不是测出来的。能看的是排序和量级，不是绝对值。
  四件事全做，一次通过率从两成八抬到接近九成；而且每多做一件都还有涨幅，没有哪一件是白做的。

  ③ 哪一件抬得最多
  --------------------------------------------------------------------
| 变量 | 单独做能抬多少 | 相对改善 |
|---|---:|---:|
| 需求清晰 | +32 点 | 45% |
| 验证可跑 | +29 点 | 40% |
| 契约先行 | +25 点 | 35% |
| 范围受控 | +22 点 | 30% |

  单做一件，抬得最多的是「需求清晰」和「验证可跑」。
| 变量 | 管的是 |
|---|---|
| 需求清晰 | 做对的事 |
| 契约先行 | 做对的事 |
| 范围受控 | 把事做对 |
| 验证可跑 | 把事做对 |

  前两条管「做对的事」，后两条管「把事做对」。两类的收益差不多，成本差很多——所以从便宜的开始做。
  ! 最便宜的通常是「验证可跑」：写一条能跑的复现脚本，成本十分钟，收益是评审者不用自己搭环境。

  ④ 这个指标怎么用
  --------------------------------------------------------------------
| 用法 | 对不对 |
|---|---|
| 看自己的趋势 | 对，这是它最好的用法 |
| 跨团队比绝对值 | 不对，任务难度不一样 |
| 当考核指标 | 危险，会让人不敢接难题 |

  第三行值得警惕：任何一次通过率被当成绩效，下一季度你看到的数字都会变好，但真实成本不会。

从两成八到八成九，十六行一路往上。 这个表最该看的不是某一行，是「每多做一件都还在涨」这件事—— 说明四件事之间没有哪一件是重复的。 注意「模型值」和「二百次模拟」两列的差别。 模拟值会抖，模型值不会。 两百次里抖个两三点是正常的，别把抖动当趋势。 第三张表那个排序：需求清晰、验证可跑、契约先行、范围受控。 排序本身是有意义的，因为它只依赖相对大小； 而「+32 点」这个绝对值没有意义，它取决于我设的系数。 最后一节的判断值得记住：信息对齐不是核心，「可验证」才是。 因为对齐会衰减，可验证的东西不会。 这也是整本书反复在说的一件事——把判断落成能跑的东西。

30 秒实验

1. 算一下你自己最近二十个 PR 的一次通过率。 低于三成的，对照那四个变量看缺哪个。
2. 把「需求清晰」换成一句可执行的话：下次接需求先写六条验收。 只做这一件，看你的一次通过率有没有动。
3. 挑一个你们反复对齐还反复出错的地方。 把它写成一条能跑的脚本，而不是再开一次会。

常见误区

1. 「一次通过率越高越好，可以当考核。」 当考核就废了。 下一季度数字会变好，但真实成本不会——因为大家开始挑简单的活。
2. 「四个变量的收益可以相加。」 不能。它们之间重叠很大。 模型用的是乘法，不是加法，就是为了避免「四件全做等于百分之一百四」。
3. 「信息对齐是核心，会开够了就行。」 对齐会衰减，会开完两周就散了。 能留下来的是可验证的东西，不是会议纪要。

第 11 章到这里收住。下一章进场景四：PR、Review 与 CI／CD 自动化。 从「无人值守需要什么前提」开始。

• ☐ （本篇完，下一篇 12.1 非交互模式：无人值守的前提条件）

相关笔记

• 渐进式交付：从写完就发到灰度发布
• 需求的结构化拆解：从模糊到精确
• 验证闭环：复现—修复—回归
• 🛠️ Codex快速入门 · 索引