采用路径
本页把白皮书叙事落到可执行动作上：先说明为什么采用顺序很重要，再解释团队如何分阶段组织系统，最后给出起步动作。
先回答为什么值得采用
很多团队使用规则失败，不是因为规则本身不够多，而是因为采用顺序错误：一上来就复制大量规则，结果价值目标、系统边界和治理方式都没有定义清楚。
正确的采用路径要先解决三件事：
- 为什么组织要把规则当成长期资产。
- 哪些系统边界应该先被固定。
- 谁来维护、验证和扩展这套知识系统。
再回答系统如何组织
建议把采用过程拆成三个阶段。
阶段一：确认价值主张
- 用 决策者摘要 对齐采用目标。
- 明确是为了统一输出、沉淀知识，还是为了降低 onboarding 成本。
- 约束第一批试点仓库，避免一开始铺得太大。
阶段二：确认系统结构
- 参考 站点蓝图 选择规则、文档和发布层的边界。
- 确定哪些内容进入
rules/，哪些内容留在 playbook 或白皮书。 - 把规则证据库当作验证层，而不是唯一入口。
阶段三：建立治理闭环
- 让规则变更进入 Git 和 PR。
- 让团队在真实项目中验证命名、目录、测试和边界约束。
- 用 角色路径 分配维护职责，避免只有单点作者理解系统。
最后回答怎样开始
下面是一条最小可执行路线：
| 周期 | 动作 | 产出 |
|---|---|---|
| 第 1 周 | 选 1 个试点仓库，读完项目总览与站点蓝图 | 价值判断和边界清单 |
| 第 2 周 | 选择基础规则组合，跑 1 次真实开发回合 | 第一批有效 / 无效信号 |
| 第 3 周 | 把重复补充提示写回规则，并进入 PR 流程 | 组织自己的规则基线 |
| 第 4 周 | 根据角色路径分配维护责任与升级节奏 | 轻量治理模型 |