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>
62 lines
2.2 KiB
Markdown
Executable File
62 lines
2.2 KiB
Markdown
Executable File
# 首个闭环 · 项目资料
|
||
|
||
> 第一件事的单点验证场景
|
||
> 状态：方案阶段 | 最后更新：2026-06-24
|
||
|
||
## 1. 目标
|
||
|
||
选一个正在跑的项目，把它散落在飞书文档、微信/飞书聊天、本地文件、NAS 里的资料，汇聚成**一处结构化、带元数据、可溯源**的库。跑通一个，再复制到其他项目。
|
||
|
||
## 2. 知识库本体结构
|
||
|
||
```
|
||
公司AI/
|
||
├── README.md # 总说明
|
||
├── docs/ # 方案文档（本目录）
|
||
├── CONVENTIONS.md # 录入规范（元数据/命名/目录约定）
|
||
└── projects/
|
||
└── <项目代号>/
|
||
├── _index.md # 项目概览、状态、关键决策索引
|
||
├── docs/ # 正式文档（从飞书/本地汇入）
|
||
├── decisions/ # 决策记录（每条带时间/参与人/背景）
|
||
├── conversations/ # 聊天沉淀（微信/飞书摘录）
|
||
└── assets/ # 附件、图、原始文件
|
||
```
|
||
|
||
## 3. 元数据约定（可溯源核心）
|
||
|
||
每个汇入文件头部带 YAML frontmatter：
|
||
|
||
```yaml
|
||
---
|
||
title: 文档标题
|
||
source: 飞书文档 | 微信群 | 本地 | NAS
|
||
source_link: 原始链接或路径
|
||
author: 产生人
|
||
created: 2026-06-24 # 内容产生时间
|
||
ingested: 2026-06-24 # 汇入知识库时间
|
||
tags: [需求, 决策]
|
||
---
|
||
```
|
||
|
||
## 4. 录入方式（混合）
|
||
|
||
- **人工沉淀**：重要文档、决策——同事按规范手动放入（全员参与）。
|
||
- **自动拉取**：飞书文档走飞书开放 API 同步；聊天先人工摘录，后续接飞书机器人自动归集。
|
||
|
||
## 5. 跑通标准（验收）
|
||
|
||
选定项目资料归位后，任何人在 CC 里 `cd` 进该项目目录，就能让 AI 基于这堆资料回答：
|
||
- 这个项目现在进展到哪了？
|
||
- 某个决策为什么这么定？
|
||
- 客户/需求方要的是什么？
|
||
|
||
且**每条回答都能溯源到出处**（靠 frontmatter 的 source/source_link）。
|
||
|
||
## 6. 动手顺序
|
||
|
||
1. 建知识库骨架：`README.md` + `CONVENTIONS.md`（地基，先定死规范）。
|
||
2. 用户给定项目代号，建 `projects/<代号>/` 结构。
|
||
3. 现有资料先人工汇入，跑通闭环。
|
||
4. 验证 CC 检索效果 → 再考虑接飞书 API 自动同步。
|