84f7950589
- 完整的知识库框架（P0-P5 路线图） - 12篇治理文档 - 工具脚本（kb-init.sh, kb-lint-fm.py, feishu-sync.py, kb-bot） - 7个 Claude 命令 - 示例项目和测试项目（wanniu-l1） - 契约文件（meta/kb-contract.yaml） Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
83 lines
4.0 KiB
Markdown
Executable File
83 lines
4.0 KiB
Markdown
Executable File
# 12 · 治理与规则维护
|
||
|
||
> 回答「中间处理规则放哪、谁维护、怎么改」。
|
||
> 核心区分：**物料录入=全员参与；规则修改=全员可提 PR，合入需至少一人 review。**
|
||
|
||
---
|
||
|
||
## 一、两类"规则"，分开放
|
||
|
||
「中间处理规则」其实是两种，位置与维护完全不同，混谈会乱：
|
||
|
||
| | ①数据契约规则 | ②处理程序规则 |
|
||
|---|---|---|
|
||
| 管什么 | 「长什么样才合格」 | 「怎么把原料变成知识」 |
|
||
| 内容 | type 集 / 字段必填 / enum / 派生规则 | 抽要点·去重·判类型·挂链·矛盾处理·检索·lint |
|
||
| **真相源** | `meta/kb-contract.yaml`（机器可读，唯一） | `.claude/commands/kb-*.md`（可执行 AI 指令，就是逻辑本身） |
|
||
| 人读镜像 | `CONVENTIONS.md`（宪法，只镜像不复述） | `docs/07-AI-native工作流.md`（四循环描述） |
|
||
| 谁执行 | `tools/kb-lint-fm.py` 运行时读 | CC 跑 `/kb-ingest`·`/kb-link`·`/kb-ask` 时执行 |
|
||
|
||
**结论**：中间处理规则**已经有家**，不是没处放——数据契约在 `kb-contract.yaml`，处理逻辑在 `.claude/commands/`，说明在 CONVENTIONS + docs/07。
|
||
|
||
> 前提：处理层（L3）目前**极薄**（只有 MVP 必需的去重/抽要点/补 frontmatter/lint/检索）。更深的处理（多级摘要、自动分类、喂下游智能体）属「第二件事」附近，**刻意延后不锁死**。
|
||
|
||
---
|
||
|
||
## 二、谁维护——归属矩阵
|
||
|
||
**分两条线，不要混**：
|
||
|
||
| 事项 | 谁做 | 门槛 |
|
||
|---|---|---|
|
||
| **物料录入**（丢资料/答问/点头） | **全员** | 无门槛，鼓励人人参与 |
|
||
| **规则修改**（改契约/命令/lint） | **全员可提，合入需 review** | 至少一人 review 后合并 |
|
||
|
||
- **物料谁都能丢，规则改动要过审**——因为改一条字段必填，全库 lint 行为就变，影响面大。
|
||
- 无固定"负责人"，但任何规则 PR **不可自审自合**，需另一人 review。
|
||
- 前期实际由技术主导 review；随团队成长，review 者可扩展。
|
||
|
||
---
|
||
|
||
## 三、规则怎么改（PR 流程）
|
||
|
||
任何人想改规则，走统一轻量流程：
|
||
|
||
```
|
||
① 起分支改动（改 kb-contract.yaml / .claude/commands/ / CONVENTIONS / docs/07）
|
||
② 本地跑 python3 tools/kb-lint-fm.py 确认全库仍 exit 0
|
||
（改了契约必须验证：既有页不被新规则误伤）
|
||
③ 提 PR，说明改什么、为什么、影响面
|
||
④ 至少一人 review → 合入 main
|
||
```
|
||
|
||
**改契约的额外铁律**：
|
||
- 改字段必填/enum → 先跑 lint 扫全库，确认存量页不被打成 error（若会，先补齐存量再改规则）。
|
||
- 加新 type → 走 `docs/11 §4` 登记流程（契约加条 + 建目录 + 飞书加视图）。
|
||
- 禁止在脚本里硬编码 type/字段——一律读契约。
|
||
|
||
**改命令/处理逻辑**（`.claude/commands/`）：
|
||
- 命令是 AI 的可执行指令，改它即改处理行为。
|
||
- review 关注：是否违背三条铁律（只读不擅改、不编造、有损操作挂起交人）。
|
||
|
||
---
|
||
|
||
## 四、处理层（L3）演进治理
|
||
|
||
处理层刻意留白，未来按信号生长，每次生长都是一次规则扩展，同样走 PR + review：
|
||
|
||
| 演进 | 触发信号 | 规则变化 | 阶段 |
|
||
|---|---|---|---|
|
||
| llm-wiki 全量编译 | `_index` 首读定位失效 | 加编译规则 + 编译产物归属（单一执行者） | P4 |
|
||
| 向量库导航层 | ~100 源/几百页 + index 失效 | 加检索规则，契约/编译层不变 | P5 |
|
||
| 喂下游智能体 | 第二件事成型 | 加 frontmatter 过滤/消费接口规则 | 第二件事 |
|
||
|
||
> 原则：**处理层怎么长，契约（type/frontmatter）尽量不动**——上层生长、地基稳定。任何 L3 规则新增都登记在册、可 review、可回滚。
|
||
|
||
---
|
||
|
||
## 五、一句话总结
|
||
|
||
- **中间处理规则不是没家**：数据契约→`kb-contract.yaml`，处理逻辑→`.claude/commands/`，说明→CONVENTIONS + docs/07。
|
||
- **物料全员录入，规则全员可提、review 合入**（不可自审自合）。
|
||
- **改规则先过 lint，改契约先扫全库**；处理层按信号生长，地基（契约）尽量不动。
|