波仔
🐎 第10章 炉火纯青：工程化实战
📄 一句话概括

团队落地的第一个真问题不是「写什么规范」，是「谁的配置算数」。四级各自按各自的规则合。 实测四级合一次：模型听最近的一级、允许清单取并集、禁止清单只能加不能减、模式取最严。 并集是「谁都不能减」。

📝 本章和前面几章的关系

上一节讲一个人怎么写指令，这一节讲一个团队怎么不打架。 这一节有真跑：组织、团队、个人三级配置合到一个人身上，每个键的输出单独看。

一、四个键，四条规则

模型：取最近的一级。越靠近使用者越具体，组织只给一个默认值。 允许清单：四级并集。谁都不能把别人开的权限关掉。 禁止清单：并集，而且被上级锁住的项不能删。安全项只能加不能减。

权限模式：取最严的那个。宽松的不能覆盖严格的。 四条规则没有一条是「下级服从上级」，也没有一条是「上级听下级的」。 每个键按自己的性质单独定规则，这样才不会出现「改一个键顺带改坏另一个」。

二、真跑：四级合一次

组织层给两条禁止（删根目录、读密钥文件）、模式是默认；团队层给模型和两条允许； 个人层给模型、两条允许、以及最严的计划模式。 结果：模型落在个人给的 opus；允许清单合成四项；禁止清单两项全部来自组织； 模式落在 plan，因为它是四级里最严的。 注意允许清单的来源是「个人、团队」两级——组织那级没给，但也不影响。

这四个输出放在一张表里，一眼就能看出「哪一级在起作用」。排查配置冲突时最有用。

三、并集规则的副作用

并集是「谁都不能减」。好处是安全项删不掉，坏处是权限只会越攒越大。 团队共享里只要加一句裸的命令执行权限，所有人的机器上就都多了一条通道。 而且它不会被发现：每个人看到的都是「我的配置里没有这一条」，但它确实生效了。

所以团队里允许清单的写法要立规矩：必须带限定，不许出现裸工具名。 这一条正好接上 10.3 节的第二条准则——允许清单里不许有裸命令。

四、组织锁与指令文件的治理

锁得太少等于没锁；锁得太多，团队会绕过它自己搞一套。 实操上只锁两样：禁止清单、以及「能不能用全部放行模式」。其余都放开。 指令文件（CLAUDE.md）也要有治理：谁能改、改完谁审、多久清一次。

最常见的腐化是一年之后它变成两千行，里面一半是过期规矩——而 agent 每一轮都在读它， 过期的规矩也在生效。 所以治理的核心动作是删，不是加。定个季度，把不再成立的条目删掉。

五、渐进式路线图与新人培训

路线图分四步：先统一指令文件，再统一允许清单，再上共享技能，最后才上插件分发。 顺序有讲究：前两步只改文件、不动工具，阻力最小；后两步要改习惯，得等前面见效。 跳过前面直接上插件，通常的结果是「装了一堆，没人用」。

新人培训只讲三件事：指令文件在哪儿、哪些事必须先问、出问题去哪儿看日志。 这三件事讲完就能上手。剩下的（技能怎么写、钩子怎么挂）等他碰到再讲。

六、动手 Demo：四级配置合到一个人身上，每个键听谁的

组织、团队、个人三级配置，加上默认值，合成一份最终生效的配置。 四个键四条规则，逐条算给出来源，方便排查「到底是谁在起作用」。

modes = [(STRICT.index(c[u"mode"]), lvl, c[u"mode"])
         for lvl, c in ((u"组织", ORG), (u"团队", TEAM), (u"个人", MINE))]
modes.sort()
mode_rank, mode_src, mode_v = modes[0]   # 取最严的那一个

实跑输出：

--------------------------------------------------------------------
四级配置合到一个人身上，每个键听谁的
--------------------------------------------------------------------

  团队落地的第一个真问题不是「写什么规范」，是「谁的配置算数」。
  四级：组织策略、团队共享、个人、默认。四个键各有各的合并规则。

  ① 四个键，四条规则
  --------------------------------------------------------------------
| 键 | 怎么合 | 为什么 |
|---|---|---|
| model | 取最近的一级 | 越靠近使用者越具体 |
| allow | 四级并集 | 谁都不能把别人开的权限关掉 |
| deny | 并集，且被锁的不能删 | 安全项只能加不能减 |
| mode | 取最严的 | 宽松的不能覆盖严格的 |


  ② 真跑：四级合一次
  --------------------------------------------------------------------
| 键 | 最终值 | 来自哪一级 |
|---|---|---|
| model | opus | 个人 |
| allow | 4 项 | 个人、团队 |
| deny | 2 项 | 组织（已锁） |
| mode | plan | 个人（最严） |

  model 是 opus，来自个人：个人写了 opus，就盖掉团队的 sonnet。
  allow 合成 4 项：Bash(npm test:*)、Read、Edit、Bash(git:*)。四级并集，谁加的都在。
  deny 有 2 项，全部来自组织：Bash(rm -rf:*)、Read(.env)。
  mode 落在 plan，因为 plan 是四级里最严的，个人写的它生效了。

  ③ 并集规则的副作用
  --------------------------------------------------------------------
  并集是「谁都不能减」，好处是安全项删不掉，坏处是权限只会越攒越大。
  团队共享里只要加一句裸 Bash，所有人的机器上就都多了一条通道。
  所以团队里 allow 的写法要立规矩：必须带限定，不许出现裸工具名。
  这一条正好接上 10.3 节的第二条准则——工具权限里不许有裸 Bash。

  ④ 组织锁的正确用法
  --------------------------------------------------------------------
  锁得太少等于没锁；锁得太多，团队会绕过它自己搞一套。
  实操上只锁两样：deny 列表、以及「能不能用 bypass 模式」。
  其余都放开：模型、风格、钩子这些让团队自己定，反而更容易推。

  ⑤ 配置冲突怎么排查
  --------------------------------------------------------------------
  - 先看最终值：现在的 model 到底是谁的。
  - 再看哪一级给的：把四级分开打印，一眼能看出被谁盖了。
  - 最后看锁：改不动的时候，往往不是写错了，是被上级锁了。
  ! 四级划分和合并规则是这一课的归纳；字段名与优先级以各家实际配置系统为准。

①四个键四条规则：模型取最近的一级、允许清单取并集、禁止清单并集且锁住的不能删、模式取最严的。 ②真跑：模型落在 opus（个人）、允许合成四项、禁止两项全来自组织、模式落在 plan（最严）。 ③并集的副作用：团队共享里加一句裸命令，所有人的机器上都多一条通道，而且不会被发现。 ④组织只锁两样：禁止清单、能不能全放行。指令文件的治理核心是删，不是加。

30 秒实验

  1. 把个人的模式从 plan 改成「全部放行」，重跑一遍。最终模式变了吗？为什么？
  2. 给团队层加一条和禁止清单冲突的允许项，重跑一遍。最终哪一条生效？这个冲突该怎么发现？
  3. 把组织层的锁去掉，重跑一遍。个人能删掉那两条禁止吗？这种情况下最坏会发生什么？

常见误区

  1. 以为下级服从上级。每个键规则不同，禁止清单是只能加不能减，模式是取最严。
  2. 以为个人能覆盖一切。模式取最严，宽松的覆盖不了严格的。
  3. 允许清单写裸工具名。并集一扩散，所有人都多一条通道，而且没人知道。
  4. 组织把所有键都锁上。团队会绕过它自己搞一套，最后比不锁更乱。
  5. 指令文件只加不删。半年后两千行，一半是过期规矩，而且每轮都在生效。
自测三问（点开对答案） 1. 四个键各自的合并规则是什么？ —— 模型取最近一级、允许清单取并集、禁止清单并集且锁住的不能删、模式取最严的。 2. 并集规则最危险的地方是什么？ —— 它只能加不能减。团队里加一句裸命令，所有人都会带上，而且从自己的配置里看不出来。 3. 团队落地该按什么顺序推？ —— 先指令文件、再允许清单、再共享技能、最后插件分发。前两步只改文件，阻力最小。

团队到位了，最后换个视角：把前面九章摊成四层，看它们怎么配合。

相关笔记