组织：什么时候需要 ops
多仓库、多人协作之后，单靠每个仓库的 CLAUDE.md 不够用了
当同一个组织有了第二个要共享规则的代码仓库，或者有了不该让所有写代码的人看到的内容，单靠每个仓库各自的 CLAUDE.md 就管不住了。这时候要升到组织档，多做四件事：建一个 ops 仓放跨仓库的结论，给组织配一个 ops agent，把记忆分成公开和私人两层，让规则能自动回流到每个项目。
为什么每个仓库一份 CLAUDE.md 不够
我同时运营两个组织：十几个代码仓库、几十个 agent、几位协作者。在有 ops 之前，问题是一点点冒出来的：
- 同一条规则在三个仓库的 CLAUDE.md 里各写一遍，改了一处，另外两处还是旧的
- 跨仓库的决策（命名、权限、谁负责什么）没有归宿，只能写在某个 PR 描述里，半年后谁也找不到
- 事故复盘里有客户和商业细节，放不进将来要开源的代码仓
- 在 A 仓库里开的会话，不知道 B 仓库上周刚定下的事
这些都不是“写得不够多”，而是没有一个专门放“组织层面”东西的地方。
升档信号
下面三条满足任意一条，就该从产品档升到组织档（完整判断见选档）：
| 信号 | 你会看到的症状 |
|---|---|
| 同一组织有 2 个以上代码仓库，要共享规则和决策 | 同一段规则在多个 CLAUDE.md 里复制粘贴 |
| 有不该让所有写代码的人看到的内容，或者代码仓是一个上游项目的 fork | 复盘、客户信息、权限清单不知道往哪放 |
| 有不写代码的协作者（运营、市场、商务） | 他们要看 SOP，却得去代码仓里翻 |
反过来，只有一个仓库的产品不需要 ops 仓；只是打算开源、或者有长期有效的决策，在仓库里放一个 docs/adr/ 就够了。这本手册自己就是产品档：它的写作规范放在仓库根目录的 STANDARDS.md，不需要 ops 仓。
组织档要多做的四件事
ops 仓
放跨仓库的决策、剧本、复盘。一句话判断什么放 ops 仓、什么留在代码仓。
ops agent
每个组织一个：知道规则在哪、什么事归它管、什么事必须先问人。
记忆分层
团队结论进 git，个人判断留私人记忆，不再增加新的存储。
进化回路
模板继承、园丁 agent、护栏体检：让复盘变成会自动生效的规则。
这也是我建议的落地顺序：先建 ops 仓，把跨仓库的决策和复盘搬过去；再配 ops agent；记忆分层随用随整理；进化回路最后补，但不能不补。我自己就是前三件做得勤、第四件补得晚，结果吃了亏（见让 ops 和项目一起进化）。
我的结构
个人总助手 跨组织路由：这件事归哪个组织、交给谁
├── 组织 A 的 ops agent 这个组织的宪法、权限、复盘
│ ├── SOP skill
│ └── SOP skill
└── 组织 B 的 ops agent
├── SOP skill
└── SOP skill三层各管一件事：
- 个人总助手：一个用户级 skill，只做路由。它不存任何组织的规则，只判断“这件事归谁”，然后交给对应组织的 ops agent
- ops agent：每个组织一个。它知道这个组织的宪法（ADR、playbook、红线）放在哪，知道哪些事可以直接做、哪些必须先问人
- SOP skill：可重复的具体操作，比如打包、部署、合并上游、给新成员开权限。它们大多是从反复手工执行的操作里提炼出来的
粒度是每个组织一个 ops agent，不是每个仓库一个。权限、成员、跨仓库决策都是组织层面的；按仓库拆，同一份宪法会被复制成很多份，然后各自漂移。两个组织也不能共用一个：它们的权限边界和保密内容不同，混在一起，迟早会把一个组织的信息带进另一个组织的文档里。
常见坑
- 模板复制后会各自漂移：第二个组织的规则从第一个复制过来，半年后两边都过期了
- 同一个组织的记忆不要按目录分裂
- 防护规则会悄悄失效：写进复盘不等于生效