一、四步顺序

四个人数是 1、2、3、6，不是 1、5、20、100。 这一点很关键：第四步的「全组」是「一个小组」，不是「全公司」。 一个小组跑通了，才谈得上第二个小组。 四步的顺序有一个内在逻辑：每一步解决的是上一步留下的新问题。 一个人时有手感就够了；两个人时手感传不过去，所以要文件；三个人时文件管不住分歧，所以要闸门； 六个人时闸门要自动化，所以要 CI。 三个验收标准里，第三个最容易被【做】成形式。 「review 与 CI 都跑起来」不是「开了 review 功能」，是「有一次 diff 被拦下来了」。 跑起来和被用上，是两件事。

二、为什么不能跳步

Demo 里六个人各有一套自己的规则，两两比对。 十五对组合，每一对都有两项以上不一致。 这个结果不是「他们不团结」，是「他们各自踩过不同的坑」。 张踩过缩进的坑，所以有 indent；李踩过长文件的坑，所以有 max_files； 王踩过误提交的坑，所以有 auto_commit。 跳步的代价就是这个数：你要先把十五对分歧收敛成一份。 而收敛的方式如果是「开个会讨论」，会开不出结果—— 因为每一条背后都有一个具体的事故，而事故之间没有可比性。 正确的收敛方式是「按事故排序」： 最近三个月发生过两次以上的坑，进规则；只发生过一次的，先记着。 这条判据能让讨论从「谁对」变成「多久发生一次」，而后者有数据。

三、每一步的验收

验收标准必须是「一个状态」，不是「一个动作」。

右边四行有个共同点：都能被「一次事件」证实或否证。 「开过会」不能被否证，「有人被拦下来过」能。 第四行是最值得做的那一条。 找一个没参与的人，只给他文档和仓库，看他能不能跑起来。 跑不起来的地方，就是文档缺的地方。 这条验收比任何「满意度调查」都准，因为它不问你感觉如何，只问「能不能跑通」。 而且它可重复：换一个新人，结论应该一样。

四、本章小结

四节的共同点是「把感觉换成能被证实的东西」。 成熟度换成四个信号，共享换成三层配置，隔离换成三棵树，顺序换成四个验收状态。 这一章讲的是「一群人」。下一章讲「边界」—— 哪些事无论如何都不该交给它，以及出错之后怎么归因。

五、动手 Demo：小团队试点的落地顺序：四步，每步一个验收

四步各一个人数、一个通过率、一个返工率、一个验收标准。 再算一次跳步的代价：六个人的规则两两比对，看有多少对不一致。 四个比率是我按经验设的，不是测出来的——能看的是【方向对不对】，不是【能到多少】。 而那个「十五对全有分歧」是脚本真算的。

rule_sets = {
    "张": {"line_width", "indent", "test_cmd"},
    "李": {"line_width", "indent", "lint", "test_cmd", "max_files"},
    "王": {"line_width", "test_cmd", "auto_commit"},
    "赵": {"indent", "lint", "test_cmd", "map"},
    "钱": {"line_width", "test_cmd", "lint", "scan"},
    "孙": {"test_cmd", "max_files", "auto_commit"},
}

for a, b in itertools.combinations(sorted(rule_sets), 2):
    diff = (rule_sets[a] | rule_sets[b]) - (rule_sets[a] & rule_sets[b])
    if len(diff) >= 2:
        print(a, b, len(diff))

实跑输出：

--------------------------------------------------------------------
小团队试点的落地顺序：四步，每步一个验收
--------------------------------------------------------------------

  团队化最常见的失败不是「做错了」，是「跳步了」。四步各有一步的验收。

  ① 四步与各自的验收
  --------------------------------------------------------------------
| 步骤 | 人数 | 一次通过率 | 返工率 | 验收标准 |
|---|---:|---:|---:|---|
| 1 一个人用顺手 | 1 | 35% | 55% | 同一套命令跑满二十次 |
| 2 两个人共享规则 | 2 | 45% | 45% | 两人用同一份规则文件两周 |
| 3 三人小组加闸门 | 3 | 58% | 36% | review 与 CI 都跑起来 |
| 4 全组推广 | 6 | 65% | 30% | 新人上手不靠口头教 |

  四个人数、四个比率。注意最后一步的人数写的是六——它是「一个小组」的规模，不是「全公司」。

  ② 为什么不能跳步
  --------------------------------------------------------------------
| 两人 | 不一致的项 | 条数 |
|---|---|---:|
| 孙×张 | auto_commit、indent、line_width、max_files | 4 |
| 孙×李 | auto_commit、indent、line_width、lint | 4 |
| 孙×王 | line_width、max_files | 2 |
| 孙×赵 | auto_commit、indent、lint、map、max_files | 5 |
| 孙×钱 | auto_commit、line_width、lint、max_files、scan | 5 |
| 张×李 | lint、max_files | 2 |

  六个人两两组合 15 对，有 15 对存在两项以上不一致。
  ! 跳步的代价就是这个数：不是多开几次会，是要先把 15 对分歧收敛成一份。

  ③ 每一步该补的前置
  --------------------------------------------------------------------
| 跳到第几步 | 必须补什么 |
|---|---|
| 直接全组推广 | 先写出至少一份跑满二十次的流程 |
| 从第 3 步开始 | 先让两个人用同一份规则两周 |
| 从第 4 步开始 | 先有一个小组的 review 和 CI 在跑 |

  三行是同一个意思：把上一步的验收补上，再往前走。补的不是流程，是「别人凭什么信这套流程」。

  ④ 推广时的三个坑
  --------------------------------------------------------------------
| 坑 | 症状 | 怎么绕 |
|---|---|---|
| 规则一次写三十条 | 没人看完，也没人遵守 | 先三条，用一个月再加 |
| 能力包不版本化 | 一个项目升级，别的全坏 | 第一次共享就锁版本 |
| 跳过新人验证 | 老人都会，新人一脸问号 | 让新人只靠文档上手一次 |

  第三行是最值得做的验收：找一个没参与的人，只给他文档和仓库，看他能不能跑起来。
  跑不起来的地方，就是文档缺的地方。
  ! 这条验收比任何「团队满意度调查」都准，因为它不问你感觉如何，只问「能不能跑通」。

  ⑤ 四步走完之后
  --------------------------------------------------------------------
| 指标 | 第一步 | 第四步 | 方向 |
|---|---|---|---|
| 一次通过率 | 35% | 65% | 升，好事 |
| 返工率 | 55% | 30% | 降，好事 |
| 新人上手时间 | 靠问人 | 靠文档 | 不靠人了 |
| 规则条数 | 3 条 | 8 条左右 | 涨，但可控 |

  四个数里两个是比率，方向都对：通过率往上、返工率往下。另两个不是数，但趋势同样清楚。
  这些值是我按经验设的，不是测出来的。能看的是「方向对不对」，不是「能到多少」。

四步那张表里，最后一步写的是六个人。 它不是笔误——「全组推广」推的是「一个小组」，不是「全公司」。 一个六人小组跑通了，第二个小组才有模板可抄。 十五对全有分歧，这个数看着吓人，但它其实是好消息。 它说明每个人都真的在用自己的方式干活，而不是「其实没人想过这事」。 有分歧能收敛，没想法才难办。 收敛的办法不是开会，是按事故排序。 最近三个月发生两次以上的进规则，一次的先记着—— 这条判据把「谁对」换成了「多久一次」，而后者有数据。 最后那张表四行里，第四行最值得做：找一个没参与的人，只靠文档跑一次。 跑不起来的地方就是文档缺的地方，而且这个结论可重复——换一个新人，答案应该一样。

30 秒实验

1. 写下你现在处在第几步。 写下那一步的验收标准达到没有。 两件事都写不出来，说明你在跳步。
2. 找一个没参与你项目的人，只给文档和仓库，看他能不能跑起来。 卡住的地方，就是你要补的地方。
3. 数一下你们最近三个月每个坑发生了几次。 两次以上的进规则，一次的先记着。

常见误区

1. 「直接全组推广，边用边改。」 边用边改的意思通常是「改的人累死，用的人各改各的」。 六个人十五对分歧，收敛要时间。
2. 「验收就是看有没有做。」 做是动作，达到状态才是验收。 「开了 review」和「有一次 diff 被拦下来」是两件事。
3. 「共识靠开会形成。」 开会能形成表态，形成不了共识。 按「多久发生一次」排序，才有可讨论的对象。

第 13 章到这里收住。最后一章讲边界：哪些事不该交，出错之后怎么归因。

• ☐ （本篇完，下一篇 14.1 幻觉、越界与错误归因）

相关笔记

• Worktrees、云任务与异步协作
• 什么时候值得推行团队化
• 自动化的边界：风险分级与信任建立
• 🛠️ Codex快速入门 · 索引