company-kb/docs/11-信息全景与非项目结构.md

11 · 信息全景与非项目结构

知识库不只是「项目」。本文定义公司信息全景、非项目信息的落地结构，以及以后加新类别的登记流程（可生长性核心）。

---

一、公司信息全景

按稳定度/归属分，5 人公司的信息大致这几类。契约已预留对应 type，按痛感分批激活，不一次全上（反过度工程）。

类别	内容	type	状态
项目	客户/内部项目的文档·决策·聊天	project/decision/conversation/doc	✅ 已用
公司基本信息	公司档案·团队·组织·对外介绍	doc	✅ 本次纳入
共享学习知识库	外部知识·学习资料·读书笔记	doc	✅ 本次纳入
公司制度/SOP	报销·请假·发布·入职流程	runbook	预留
实体档案	客户/供应商/竞品（跨项目枢纽）	entity	预留
术语/黑话	缩写·产品名·行业名词	concept	预留
指标口径	KPI·财务·业务数据定义	metric	预留
问答沉淀	高频问题的权威答案	question	预留

---

二、目录结构扩展

非项目信息提到顶层平级（跨项目、不随项目结束消失），不塞进 projects/：

公司AI/
├── projects/        # 项目（有生命周期）        ✅
├── company/         # 公司基本信息（本次新增）
│   └── _index.md    # 公司档案入口（type: doc）
├── learning/        # 共享学习知识库（本次新增，按领域分）
│   ├── _index.md    # 学习库总览
│   ├── ai/          # 领域子目录：AI
│   ├── management/  # 领域：管理
│   └── industry/    # 领域：行业
├── entities/ concepts/ questions/   # 预留 type，按需激活
└── metrics/ company-sop 等          # 未来登记后新增

• company/ 与 learning/ 本次都用现成 doc type（不急着激活新 type），靠目录 + tags 区分，够用。
• learning 按领域分子目录（用户定），每篇学习笔记归入对应领域；跨领域用 tags 补充。
• 量大到需要专属字段时（如学习资料要「掌握程度」），再升级成独立 type（走第四节流程）。

---

三、飞书呈现映射

沿用「多维表格=全库地图 + 云文档=详情」，非项目信息只是多加视图：

信息类别	多维表格视图	云文档
公司基本信息	「公司信息」视图（筛 company/ 路径）	公司介绍/团队文档
共享学习库	「学习库」视图（按领域 tags 分组）	重点学习主题长文
项目	按项目分组视图（已有）	各项目概览

群机器人自动全覆盖——问「公司是做什么的」「XX 领域有什么学习资料」都能答（检索整库，不分项目与否）。

---

四、以后加新类别的登记流程 ★可生长性核心★

加新一类信息不用改代码——kb-contract.yaml 是唯一契约，改它即可：

想加一类（例：以后要"财务指标库"）
  ① 在 meta/kb-contract.yaml 的 types 加一条：
       - name: metric
         active: true
         dir: metrics/
         desc: 一个指标及其口径、来源
     （若需专属字段/派生必填，一并在 fields/derived_rules 登记）
  ② 建对应顶层目录（mkdir metrics/）
  ③ 飞书多维表格加一个筛该 type 的视图
  ④ 一次 PR 合入
  → 完成：lint 自动认它、机器人自动能查，无需改任何脚本

原则：核心 type 集封闭稳定，扩展走这条轻量登记。结构稳定但能生长——不因加类别而重构。禁止在脚本里硬编码 type（一律读契约）。这也是「先少后多」策略的落地：先激活真痛的，其余登记在册、按需激活。