选档：小工具、产品还是组织
用三个信号判断项目处在哪一档，以及什么时候该升档
亲历小工具产品组织更新于 2026-10-16
先判断项目在哪一档，再决定要做多少事。小工具不需要 ops，组织不能只靠一个 CLAUDE.md。按档位做事，既不会给一个周末项目套上整套流程，也不会让一个多人协作的组织靠记忆运转。
三档的定义
| 档位 | 特征 | 规则和文档放哪 | 必备 |
|---|---|---|---|
| 小工具 | 一个人、一个仓库、没有长期用户 | README + 一页 CLAUDE.md | 最小护栏、先出计划再动手 |
| 产品 | 有真实用户、要持续迭代，通常一个仓库 | 仓库里的 docs/：specs、plans、adr、runbooks、retros，加上 .claude/ | 六阶段流程、异构模型审查、发版清单 |
| 组织 | 多个代码仓库、多人协作、对内对外有权限差异 | 独立的 ops 仓 + 代码仓里保留 spec、plan 和跟代码绑定的 runbook | 组织级 ops agent、记忆分层、进化回路 |
什么时候升档
小工具 → 产品：出现了真实用户。只要有人依赖它，就需要计划、审查和发版纪律。
产品 → 组织：下面三条满足任意一条：
- 跨仓治理：同一个组织有 2 个以上代码仓库，需要共用规则和决策
- 权限隔离：有不该让所有写代码的人看到的内容（成员权限、客户、商业信息、事故细节），或者代码仓是一个上游项目的 fork、需要和上游保持干净
- 非代码协作：有不写代码的协作者要参与治理（运营、市场、商务）
只是“打算开源”或者“有长期有效的决策”，单仓产品也会遇到，不构成升档理由：在仓库里放一个 docs/adr/ 就够了。
升档不是一次性的大改造。从产品档升到组织档时，我的做法是先建 ops 仓，把跨仓库的决策和复盘搬过去，再逐步补上 ops agent 和体检机制。详见组织篇。
每一档最容易犯的错
- 小工具：直接开干，不配任何护栏。一条
rm -rf或git push --force就能毁掉一个下午。看小工具的最小护栏。 - 产品：有流程但没有人工关卡，agent 自己写、自己审、自己合并。看自己审自己等于没审。
- 组织：经验写进了复盘，却没有变成会自动生效的规则，同一个坑反复踩。看防护规则会悄悄失效。
这本手册自己在哪一档
产品档：一个仓库、有读者、持续更新。它的写作规范放在仓库根目录的 STANDARDS.md，没有单独的 ops 仓。
相关
- 启动器：选好档位，照清单走
- ops 放哪：独立仓还是放进项目