两个维度打分：影响面、可回滚性。合起来决定「自动、通知、审批、禁止」。 审批点是稀缺资源，一天超过二十次，人就开始闭眼点通过。 已知的坏交给钩子，别占审批额度——审批只花在「想不到的坏」上。
三道闸里最后一道：审批。它最贵，因为它要人醒着。 贵的东西就要省着用。这一篇讲怎么省：先分级，再算账。 Demo 拿八个动作按两个维度打分，分成四档； 再算一笔账：审批频率从一天八次涨到一百次，漏掉的危险动作从零涨到六点四个。
一、按影响面分级
影响面按「动了之后波及多远」分三档： 一只碰一个文件、二碰一片、三影响线上。 这个判断不需要精确，但需要一致。 同一个动作今天算二、明天算三，那分级就没意义了。 所以分级表要写下来，写到能查。 影响面最容易低估的是「配置」。 改一行配置看起来只碰一个文件，但它可能让所有人登不进来。 所以配置类动作的影响面，要按「它影响谁」算，不按「它改了几个文件」算。
二、按可回滚性分级
这一维比上一维更硬，因为它决定「错了还能不能救」。
| 分 | 含义 | 例子 |
|---|---|---|
| 一 | 改错了能撤 | 改注释、加函数 |
| 二 | 要费点劲 | 跨文件重构、改配置 |
| 三 | 撤不了 | 删数据、改表结构、改密钥 |
「撤不了」的判据很具体： 有没有一份完整的旧状态可以恢复。 有备份、有版本、有快照，就能撤；没有，就撤不了。 所以「删一批文件」评三分，「改数据库表结构」也评三分——虽然前者看起来更暴力。 因为表结构一改，回滚要恢复数据，而数据可能已经写脏了。 两维加起来，六分以上是「禁止」。 注意这一档不是「很难批」，是「不批」。 任何需要它自动做这两件事的场景，都是流程没设计好—— 不是审批设计的问题，是这件事根本不该由它做。
三、审批点太多等于没有
这一条要拿数说话。 Demo 里设一个人一天审 N 次，认真看的概率按二十分之 N 的反比估（N 不超过二十时算一）。 八个危险动作，漏掉的期望等于八乘（一减 认真看的概率）。
| 一天审几次 | 认真看的概率 | 漏掉几个 |
|---|---|---|
| 8 次 | 1.00 | 0.0 个 |
| 30 次 | 0.67 | 2.7 个 |
| 60 次 | 0.33 | 5.3 个 |
| 100 次 | 0.20 | 6.4 个 |
一天一百次，基本等于没设审批。 因为那时候的「通过」不是判断，是肌肉记忆。 这个模型是粗的（真实的人不是线性衰减）， 但它给的结论是对的：审批的价值随频率上升而急剧下降。 所以设计审批点的第一目标不是「多拦几个」，是「少问几次」。 怎么把次数压下来？四条：
| 做法 | 省下什么 |
|---|---|
| 能写成钩子的写成钩子 | 一类动作完全不用审批 |
| 同一批改动合并审批 | 次数直接除以十 |
| 低分动作改成事后通知 | 不用等，出错再回滚 |
| 把「禁止」写进规则 | 根本走不到审批 |
四、动手 Demo：审批点设计：按影响面和可回滚性分级
八个动作，各给两个分，加起来决定处置。 然后算一笔审批疲劳的账。 两件事要说清楚：分是人打的，不是算出来的； 那个「认真看的概率」是个粗略模型，用来说明趋势，不是精确预测。
APPR = [
(u"改注释、改 README", 1, 1),
(u"改数据库表结构", 3, 3),
(u"改权限与密钥", 3, 3),
]
for n, a, b in APPR:
s = a + b
k = (u"自动" if s <= 2 else u"通知" if s <= 4
else u"审批" if s <= 5 else u"禁止")
实跑输出：
--------------------------------------------------------------------
审批点设计：按影响面和可回滚性分级
--------------------------------------------------------------------
① 两个维度，各一到三分
--------------------------------------------------------------------
| 动作 | 影响面 | 不可回滚 |
|---|:---:|:---:|
| 改注释、改 README | 1 | 1 |
| 加一个新函数 | 1 | 1 |
| 改一处已有逻辑 | 2 | 2 |
| 跨三个文件重构 | 2 | 2 |
| 改配置并重启服务 | 3 | 2 |
| 改数据库表结构 | 3 | 3 |
| 删一批文件 | 2 | 3 |
| 改权限与密钥 | 3 | 3 |
影响面：1 只碰一个文件、2 碰一片、3 影响线上。不可回滚：1 改错了能撤、2 要费点劲、3 撤不了。
② 三档处置
--------------------------------------------------------------------
| 动作 | 合计分 | 处置 |
|---|:---:|:---:|
| 改注释、改 README | 2 | 自动 |
| 加一个新函数 | 2 | 自动 |
| 改一处已有逻辑 | 4 | 通知 |
| 跨三个文件重构 | 4 | 通知 |
| 改配置并重启服务 | 5 | 审批 |
| 改数据库表结构 | 6 | 禁止 |
| 删一批文件 | 5 | 审批 |
| 改权限与密钥 | 6 | 禁止 |
自动 2 条、通知 2 条、审批 2 条、禁止 2 条。
! 注意「禁止」那一档只有六分以上——也就是「影响大且撤不回」。
这一档不是「很难批」，是「不批」：任何需要它自动做这两件事的场景，都是流程没设计好。
③ 审批点太多等于没有
--------------------------------------------------------------------
设一个人一天要审 N 次，认真看的概率按 20/N 估（N 不超过 20 时算 1）。
危险动作 8 个，漏掉的期望 = 8 乘（1 减 认真看的概率）。
| 审批频率 | 认真看的概率 | 漏掉的危险动作 |
|---|:---:|:---:|
| 8 次/天 | 1.00 | 0.0 个 |
| 15 次/天 | 1.00 | 0.0 个 |
| 30 次/天 | 0.67 | 2.7 个 |
| 60 次/天 | 0.33 | 5.3 个 |
| 100 次/天 | 0.20 | 6.4 个 |
一天审三十次，认真看的概率掉到三分之二；审一百次，基本就是闭眼点通过。
! 这不是人的问题，是设计的锅。
审批点是稀缺资源，要花在「想不到的坏」上——已知的坏交给钩子，别占审批额度。
④ 怎么把审批压下来
--------------------------------------------------------------------
| 做法 | 省下什么 |
|---|---|
| 能写成钩子的写成钩子 | 一类动作完全不用审批 |
| 同一批改动合并审批 | 次数直接除以十 |
| 低分动作改成事后通知 | 不用等，出错再回滚 |
| 把「禁止」写进规则 | 根本不会走到审批 |
八条分得很匀：自动两条、通知两条、审批两条、禁止两条。 这个分布是有意的——如果「禁止」占了八条里的六条，那这套流程根本跑不动。 看一眼「禁止」那两条：改表结构、改密钥。 它们的共同点是「影响大且撤不回」。 而「删一批文件」只到了审批档，因为如果文件进回收站，它是能撤的。 第三段那组数最值得记：一天三十次，漏掉的期望是二点七个。 意思是「你设了审批，但你已经漏了两个」。 这不是人的问题，是频率的问题。 所以第四段那四条做法，核心都是同一件事：减少「需要你点一下」的场景。 能自动判的给钩子，能事后看的给通知，能不做的写进规则。
30 秒实验
- 把你手上的动作按两个维度各打一次分。 打完看「禁止」那档有几条——有，说明有些活该换个做法。
- 数一下你昨天点了几次「通过」。 超过二十次，就该合并或者改成事后通知。
- 找一条「你以为在审批，其实在闭眼点」的。 把它改成钩子。
常见误区
- 「审批越严越安全。」 严到一定程度，人就开始闭眼点。 那时候它不是安全，是心理安慰。
- 「所有危险动作都要审批。」 危险动作里有一部分是「禁止」，不批。 把它放进审批队列，等于给了它一个「可能被批准」的机会。
- 「影响面和可回滚性差不多是一回事。」 差得远。 改密钥影响面三、可回滚性三；改配置影响面三、可回滚性二。 前者禁止，后者审批。
自测三问（点开对答案）
1. 两个维度里哪个更硬？为什么？ —— **可回滚性更硬，因为它决定「错了还能不能救」。** **影响面大但能撤的，可以审批；影响面小但撤不回的，反而更该禁止。** 2. 为什么「禁止」那一档不能改成「很难批」？ —— **因为「很难批」意味着它有可能被批。** **而这一档的动作，任何被批准的场景都说明流程设计错了。** 3. 审批频率为什么会让效果急剧下降？ —— **因为人会把它变成肌肉记忆。** **一天一百次的「通过」不是判断，是习惯动作。**下一篇 7.4 收这一章：把这些东西装进一个高风险仓库，给一份能抄的护栏模板。
- ☐ （本篇完，下一篇 7.4 高风险仓库的护栏模板）