一、四个成熟度信号

先看「什么人适合被推广」，不看「多少人」。

第一个信号最容易被忽略，但它最重要。 没有反复跑过的流程，团队化只是把「不规范」复制给更多人。 为什么是「跑过很多次」而不是「跑得很顺」？ 因为「顺」是一次的感觉，「很多次」是稳定的证据。 二十次里有三次出问题但都解决了，比一次很顺更有说服力—— 那三次解决的问题，恰好就是团队化之后别人会踩的坑。 后三个信号是「成果」而不是「过程」。 有人写过规则文件，说明有人吃过亏并记下来了；有 review 和 CI，说明已经有闸门。 这三样只要有一份，别人的起点就不是零。

二、推早了会怎样

Demo 里六个团队画像：一个人的老张、两个后端、三人小组、六人前端组、十人全栈组、 刚组队的五人。 按四个信号打分，够条件的只有两个。 最值得注意的是「十人全栈组」——人最多，分最低。 它没写过规则、没有 review，只有 CI。 这说明「人多」跟「成熟」是两件独立的事，甚至可能负相关—— 人多了靠口头传递更累，反而更没精力沉淀。 推早了的代价可以算。 Demo 里设了十条规则、三十天腐化四成，也就是四条过期。 一个人踩是每周四次；三个人十二次；十个人四十次。 这就是「放大倍数」：它不是「多花了配置的时间」，是把一条错规则复印给了所有人。 更麻烦的是，这四十次尝试里没有一次会报「规则错了」——它只会表现成「按规矩做了但没效果」。 所以「先补前置」比「先上系统」便宜得多。 补前置是三件事：把跑顺的命令写下来、找一个人一起用两周、把踩过的坑记成三条规则。 三件事都不需要平台，只需要时间。

三、团队化的第一件事

右边三样的共同点：它们都发生在「还没有内容」的时候。 没有内容就搭架子，架子会空着。 左边三样有一个共同的时间顺序：先有内容，再找人，再扩大。 反过来做——先定规范再找场景——你会发现定的规范有一半用不上。 还有一个反直觉的点：第一件事应该是「写下来」，不是「做得更好」。 你现在那套命令可能不完美，但只要它能跑通，就值得先写下来。 完美主义在这里的代价是「永远没有第一版」，而没有第一版，别人连「改哪」都不知道。

四、动手 Demo：什么时候值得推行团队化：四个信号各打一次分

六个团队画像，按四个信号各打一次分，看哪几个够条件。 再算一次「推早了」的放大倍数：规则过期率乘人数。 打分规则是我定的——数量级有意义，具体阈值要按你们团队调。 能看的是【同样的规则，人多之后代价怎么变】。

TEAMS = [
    ("老张一个人", 1, 40, 1, 0, 0),
    ("两个后端", 2, 25, 1, 1, 0),
    ("三人小组", 3, 18, 1, 1, 1),
    ("六人前端组", 6, 12, 0, 1, 1),
    ("十人全栈组", 10, 6, 0, 0, 1),
    ("刚组队的五人", 5, 2, 0, 0, 0),
]
# 字段：名字、人数、命令次数、有规则、有 review、有 CI

for name, people, times, rule, review, ci in TEAMS:
    s = (2 if times >= 20 else 1 if times >= 10 else 0) + rule + review + ci
    print(name, people, times, s, "可以" if s >= 4 else "再等等")

实跑输出：

--------------------------------------------------------------------
什么时候值得推行团队化：四个信号各打一次分
--------------------------------------------------------------------

  团队化不是「人多就该上」。它的前提是「这套流程在一个人身上已经稳了」。

  ① 四个成熟度信号
  --------------------------------------------------------------------
| 信号 | 怎么看 | 它说明什么 |
|---|---|---|
| 同一套命令跑过很多次 | 数次数 | 流程稳定，不靠临场发挥 |
| 有人写过规则文件 | 看仓库里有没有 | 吃过亏，并且记下来了 |
| 有 code review | 看合并流程 | 已有闸门 |
| 有 CI | 看有没有自动检查 | 反馈不靠人 |

  四个信号里，第一个最容易被忽略，但它最重要——没有反复跑过的流程，团队化只是把不规范复制给更多人。

  ② 六个团队各打一次分
  --------------------------------------------------------------------
| 团队 | 人数 | 命令次数 | 规则 | review | CI | 分 | 结论 |
|---|---:|---:|---|---|---|---|---|
| 老张一个人 | 1 | 40 | 有 | 无 | 无 | 3 | 再等等 |
| 两个后端 | 2 | 25 | 有 | 有 | 无 | 4 | 可以 |
| 三人小组 | 3 | 18 | 有 | 有 | 有 | 4 | 可以 |
| 六人前端组 | 6 | 12 | 无 | 有 | 有 | 3 | 再等等 |
| 十人全栈组 | 10 | 6 | 无 | 无 | 有 | 1 | 再等等 |
| 刚组队的五人 | 5 | 2 | 无 | 无 | 无 | 0 | 再等等 |

  六个团队里够分的是 2 个。注意「十人全栈组」没够——人多不等于成熟。
  ! 这一列最容易误读：分数高不代表「该上团队化」，只代表「上的时候不会白费」。
  分数低也不是不能上，是上了要先补前置。

  ③ 推早了会怎样：一条规则的放大倍数
  --------------------------------------------------------------------
| 人数 | 规则条数 | 三十天后过期 | 每周无效尝试 | 放大 |
|---:|---:|---:|---:|---|
| 1 | 10 | 4 | 4 | 1 倍 |
| 3 | 10 | 4 | 12 | 3 倍 |
| 6 | 10 | 4 | 24 | 6 倍 |
| 10 | 10 | 4 | 40 | 10 倍 |

  一条过期的规则，一个人踩到是每周 4 次；十个人就是 40 次。
  ! 这就是「推早了」的真实代价：不是多花了配置的时间，是把一条错规则复印给了所有人。

  ④ 第一条该做的事
  --------------------------------------------------------------------
| 先做这个 | 不要先做这个 |
|---|---|
| 把你自己跑顺的那套命令写下来 | 先选一个平台 |
| 找一个人一起用两周 | 先开全员会宣讲 |
| 把踩过的坑记成三条规则 | 先写三十条规范 |

  右边三样的共同点：它们都发生在「还没有内容」的时候。没有内容就搭架子，架子会空着。

六个里够分的两个：两个后端、三人小组。 它们的共同点不是人多，是「四个信号都不缺」。 「老张一个人」那一行值得看：四十次命令，最高的一档，但因为没有 review 和 CI，只拿了三分。 这个结果是对的——一个人用的时候，review 和 CI 确实不必要； 但要把这套东西交给第二个人，那两样就成了别人敢不敢信的依据。 放大倍数那张表四行，第三列都是四。 不变的是「过期四条」，变的是「多少人踩」。 这就是团队化风险的形状：它不增加错误的种类，只放大错误的次数。 最后一句话要记：把一条错规则复印给所有人。 复印这个比喻很准——因为复印出来的每一份都一样错，而且都盖着你的名字。

30 秒实验

1. 数一下你最近一个月跑同一个命令的次数。 不到十次的，说明流程还没稳，先别急着共享。
2. 翻你的仓库，找找有没有一份「给 Agent 看的规则文件」。 没有的话，它就是你要补的第一个信号。
3. 写下你踩过的三个坑，每个坑写成一条规则。 三条就够，别写三十条。

常见误区

1. 「团队人多，就该上团队化。」 人多不等于成熟。 Demo 里十人组的分最低——人多反而更没精力沉淀。
2. 「先搭好平台，人自然会用。」 没有内容就搭架子，架子会空着。 先有跑顺的流程，再谈共享。
3. 「规范要一次写全，以后不用改。」 一次写三十条的结果是没人看完。 先三条，用一个月再加。

下一篇讲具体怎么共享：三层配置各管一段，以及能力包为什么要版本化。

• ☐ （本篇完，下一篇 13.2 共享规则、权限与能力包）

相关笔记

• 共享规则、权限与能力包
• 自动化的边界：风险分级与信任建立
• 项目地图、关键入口与禁区
• 🛠️ Codex快速入门 · 索引