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>
81 lines
3.8 KiB
Markdown
Executable File
81 lines
3.8 KiB
Markdown
Executable File
# 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（一律读契约）。这也是「先少后多」策略的落地：先激活真痛的，其余登记在册、按需激活。
|