company-kb/docs/05-路线图.md

05 · 路线图

P0→P5 分阶段作战图。每阶段可独立交付/验收/止步；后阶段是生长而非重做。frontmatter/type 契约从 P0 到 P5 稳定不变。 反过度工程铁律：编译层、向量库按信号触发延后，不预建。

---

阶段总览

阶段	目标（一句）	进入下阶段信号
P0 骨架+规范	定死唯一真相源物理形态 + 录入契约 + 命令雏形	任一成员照规范建合规文档、/kb-check 通过、CC 能读到并引用
P1 首个项目闭环	一个在跑项目资料全汇入、CC 可溯源问答	该项目问答稳定、同事认可价值，产生复制到第 2/3 个项目的需求
P2 多项目+飞书导入	扩到多项目 + feishu-pull.py 半自动增量导入	项目数 ≥3、飞书成主要文档源、公司级非项目知识无处安放
P3 全公司领域+Obsidian 成熟	加 company//domains/ 分区 + Obsidian 编辑成团队习惯	库覆盖主要知识、录入成习惯，产生「让 AI 主动编译/问答/喂 agent」需求
P4 处理层/编译+下游 agent	启用 llm-wiki 全量编译 + 下游 agent 消费接口	信号触发点：_index 首读定位失效 + 摄入悖论显现
P5 规模化（向量库）	向量库仅当导航层替代 index.md，编译层零改动	终态

---

P0 · 骨架 + 规范

目标：定死唯一真相源物理形态 + 录入契约 + 命令雏形。

交付物：

• 目录骨架（projects/ entities/ concepts/ questions/ meta/ tools/ .claude/commands/）+ .gitignore。
• meta/kb-contract.yaml（机器可读契约：types 数组含 active/reserved 标记 + 字段必填矩阵 + status/source enum）。
• CONVENTIONS.md + CLAUDE.md（项目级）+ docs/04~07。
• tools/kb-init.sh + tools/kb-lint-fm.py。
• projects/_example/（OKF 完整示例，照抄即合规）。
• .claude/commands/（/kb-new /kb-ingest /kb-ask /kb-save /kb-check /kb-status）。

验收：任一成员照规范建一页合规文档 → /kb-check 通过 → CC cd 进目录能读到并在回答中引用（带 source_link）。

止步点：若只需「可溯源 markdown + CC 检索」，停在 P0/P1 完全合理。

---

P1 · 首个项目闭环

目标：把一个在跑项目的资料全部汇入，CC 能可溯源回答「进展如何 / 为何这么定 / 需求方要什么」。

交付物：

• 选一个真实在跑项目 → /kb-new <代号> 建骨架。
• 全部相关资料（决策/聊天/文档）汇入，frontmatter 合规。
• CC 问答稳定，每条结论挂 source_link。

验收：该项目三类问题（进展 / 决策依据 / 需求）问答稳定准确，同事认可价值。

进入 P2 信号：产生「复制到第 2/3 个项目」的需求。

---

P2 · 多项目 + 飞书导入

目标：扩到多项目 + feishu-pull.py 半自动增量导入。

交付物：

• 复制 P1 模式到 ≥3 个项目。
• tools/feishu-pull.py 上线，半自动单向导出飞书文档到 projects/*/docs/，AI 自动补 frontmatter。
• meta/ingest-manifest.json 台账记录 hash 去重。
• 飞书双向前端（见 docs/08）：
  • 群机器人能问能答（tools/kb-bot/，长连接无公网）：群 @机器人 → /kb-ask → 带溯源回复。
  • 飞书呈现双载体（tools/feishu-render.py）：云文档（叙事）+ 多维表格 Bitable（结构，可筛选/看板）。
• NAS 投递区扫描（tools/nas-pull.py，编译链接模式）。

验收：飞书成为主要文档源；群里 @机器人 问答稳定带溯源；多维表格全库总览可用。

进入 P3 信号：项目数 ≥3、飞书成主要文档源、公司级非项目知识无处安放。

---

P3 · 全公司领域 + Obsidian 成熟

目标：加 company//domains/ 分区 + Obsidian 编辑成团队习惯。

交付物：

• 新增公司级分区（company//domains/），承接非项目知识。
• 视需要激活 entity/concept type 并建目录。
• Obsidian 成为团队日常编辑器，docs/obsidian-setup.md 插件清单落地（Dataview 等）。

验收：库覆盖主要知识、录入成习惯。

进入 P4 信号：产生「让 AI 主动编译/问答/喂 agent」的需求。

---

P4 · 处理层 / 编译 + 下游 agent

目标：启用 llm-wiki 全量编译（生成互链 wiki + hot/index）+ 下游 agent 消费接口。

交付物：

• llm-wiki 全量 raw→wiki 编译层启用，产物由单一执行者生成并提交（wiki//hot.md/index.md 仍 gitignore 或按约定提交，避免并发冲突）。
• 下游 agent 消费接口（frontmatter 过滤 + CC 子 agent）。

验收：编译产物可用，下游 agent 能按 type/status 过滤消费。

★ 信号触发点：_index 首读定位失效 + 摄入悖论显现——在此之前坚决不启用全量编译。

---

P5 · 规模化（向量库）

目标：向量库仅当导航层替代 index.md，卡帕西编译层与 type 契约原样保留。

★ P5 向量库红线（唯一硬触发点）：

~100 源 / 几百页 且 出现 index 首读定位不准 / 摄入悖论。 在此之前——任何「要不要上 RAG」的默认答案是「不」。

交付物：

• 向量库只做「找到相关页」的导航层，替代 index.md 首读定位。
• 编译层零改动，type 契约原样保留。

验收：向量库导航准确率优于 index.md 首读定位，且未触碰 frontmatter/type 契约。

---

生长机制（预留，不落地）

生长机制降为预留接口说明，不落地 /kb-grow 命令与监控脚本：

• 仅保留 meta/stats.md 人工可读源计数作红线观察点。
• 不预建密度/熵增监控。到 P5 红线时再启用向量库导航层，接口预留。