项目Wiki与知识库管理 Skill

一个自适应的项目Wiki管理系统。核心能力：检测项目类型 → 设计Wiki结构 → 生成指导文档 → 增量更新Wiki → 评估优化指导文档。指导文档本身是活文档，每次更新都会被审视和改进。

核心理念

Wiki不是静态文档，而是项目知识的活的载体。指导文档也不是一成不变的规范，而是随着项目演进而持续进化的方法论。每次操作都是一次学习——学习如何更好地组织这个特定项目的知识。

三件事同等重要：

1. Wiki内容——准确、关联、时效
2. 指导文档——反映项目现状、引导正确组织
3. 自我评估——指导文档是否仍然适用？需要调整吗？

初始化流程

首次使用时执行。如果项目中已有wiki目录和指导文档，跳过初始化。

步骤1：确认Wiki存储位置

询问用户选择存储模式：

• 项目内模式：Wiki存放在项目目录下 wiki/（默认路径，可自定义）
• Obsidian Vault模式：Wiki存放在指定的Obsidian Vault中（需要提供vault路径或名称）

两种模式的核心逻辑一致，区别仅在于文件操作方式：

• 项目内模式：直接使用文件读写工具
• Obsidian模式：优先使用Obsidian CLI命令（obsidian create、obsidian search等）

步骤2：检测项目类型

扫描项目根目录，根据以下信号判断项目类型：

信号文件/目录	推断的项目类型
package.json、tsconfig.json、src/	前端/Web应用
pom.xml、build.gradle、src/main/java/	Java后端服务
requirements.txt、setup.py、pyproject.toml	Python项目
go.mod、*.go	Go项目
Cargo.toml、src/lib.rs	Rust项目
Dockerfile、docker-compose.yml + API代码	容器化服务
.ipynb、notebooks/、data/	数据科学项目
SKILL.md、skills/	技能/插件项目
大量 .md 文件、无代码框架	文档/知识项目
多种语言混合 + README.md	通用软件项目
无明确技术栈信号	通用型（向用户确认）

检测后告知用户推断结果并确认，因为项目可能属于混合类型。

步骤3：设计Wiki结构

根据项目类型，参考 references/project-templates.md 中的模板，设计Wiki目录结构。模板是起点而非约束——根据项目的实际情况调整。

设计原则：

• 最小必要：初始只创建确定需要的分类，不要预设空壳
• 按需增长：遇到新类型内容时再扩展分类
• 扁平优先：层级不超过3层，过深意味着结构需要重构
• 内容驱动：分类从已有内容归纳，而非凭空设计

步骤4：生成指导文档

创建 wiki-guide.md（指导文档），这是Wiki的"元知识"——描述Wiki应该如何组织、内容标准是什么、哪些已覆盖、哪些缺失。

指导文档格式见下方"指导文档结构"章节。

步骤5：生成初始Wiki页面

根据项目现有文件，生成初始Wiki内容：

1. 扫描项目关键文件（README、配置文件、核心代码目录）
2. 为已有内容创建对应的Wiki条目
3. 建立条目间的交叉引用
4. 生成索引页

---

指导文档结构

wiki-guide.md 是Wiki的自我描述文件，存放在Wiki根目录。它回答：这个Wiki应该包含什么、如何组织、当前状态如何、哪里需要改进。

# Wiki指导文档

## 项目画像
- 项目名称：
- 项目类型：
- 技术栈：
- 核心特征：（一句话描述项目本质）

## 组织原则
- 分类逻辑：（按什么维度组织——模块/功能/层次/领域）
- 命名规范：（文件和目录的命名规则）
- 层级限制：最深N层（默认3层）
- 关联策略：（何时建立交叉引用）

## 内容标准
### 必须包含
- （每个Wiki条目必须有的字段，如：概述、关联、更新日期）

### 推荐包含
- （根据条目类型可选的内容）

### 质量红线
- （不达标的内容需要标记改进）

## 当前结构
（Wiki的目录树，标注每个目录的用途和当前条目数）

## 覆盖地图
| 知识领域 | 覆盖状态 | 评分 | 说明 |
|---|---|---|---|
| （领域名） | ✅良好/⚠️部分/❌缺失 | 1-5 | 补充说明 |

## 改进记录
| 日期 | 触发原因 | 调整内容 | 效果评估 |
|---|---|---|---|
| | | | |

---

核心操作

1. 更新Wiki（Update）

这是最常用的操作。当用户提供新内容或要求更新Wiki时执行。

流程：

输入内容 → 读取指导文档 → 定位归属 → 更新/创建条目 → 评估指导文档 → 更新指导文档

详细步骤：

1. 读取指导文档：理解当前的Wiki组织逻辑和内容标准

2. 分析输入内容：

   • 内容属于哪个知识领域？
   • 是全新知识还是对现有内容的补充/修正？
   • 是否涉及多个领域？

3. 定位归属：

   • 能放入现有分类 → 直接更新或创建条目
   • 现有分类不合适 → 考虑扩展分类或调整结构
   • 不确定 → 向用户确认

4. 更新Wiki条目：

   • 新建条目时遵循指导文档的内容标准
   • 更新已有条目时保留历史脉络（可使用折叠区或变更日志）
   • 每个条目末尾标注更新日期
   • 主动建立与相关条目的双向链接

5. 评估指导文档（关键步骤！）：

   每次更新后，思考以下问题：

   • 结构适配性：新内容是否顺畅地融入了现有结构？如果需要"硬塞"，说明结构可能需要调整
   • 覆盖完整性：是否有新暴露的知识领域尚未在覆盖地图中体现？
   • 标准适用性：内容标准是否对这类新内容给出了清晰指引？还是留下了模糊地带？
   • 命名一致性：新条目的命名是否与已有条目保持一致？
   • 关联充分性：新内容是否暴露了之前未建立的关键关联？

6. 更新指导文档：

   • 如果评估发现问题，立即更新指导文档
   • 更新覆盖地图
   • 在改进记录中追加条目
   • 如果做了结构性调整，说明调整原因和预期效果

2. 初始化Wiki（Init）

见上方"初始化流程"。仅在项目首次创建Wiki时执行。

3. 查询Wiki（Query）

当用户提出与项目知识相关的问题时：

1. 读取指导文档了解Wiki全景
2. 在Wiki中搜索相关内容
3. 综合相关条目回答问题
4. 如果发现Wiki中的信息不足以回答：
   • 标注覆盖地图中的缺失项
   • 建议用户补充相关内容
   • 评估是否需要调整指导文档

4. 健康检查（Lint）

定期或用户要求时执行：

检查维度：

维度	检查内容
孤立条目	没有入链/出链的页面
内容矛盾	不同条目间的冲突信息
过时信息	超过30天未更新的动态内容
缺失页面	被引用但未创建的条目
断链	指向不存在页面的链接
标签一致	相似概念是否使用一致标签
结构膨胀	是否有过深（>3层）或过宽（>10子项）的目录
指导偏移	指导文档的描述与实际Wiki状态的偏差

健康检查后：将发现的问题汇总，评估是否需要调整指导文档。

---

Obsidian模式特殊说明

当用户选择Obsidian Vault模式时：

文件操作

优先使用Obsidian CLI：

# 创建笔记
obsidian create name="笔记名称" content="内容"

# 搜索知识库
obsidian search query="搜索关键词"

# 读取当前活动文件
obsidian read

# 向日记追加内容
obsidian daily:append content="内容"

# 列出标签及计数
obsidian tags counts

# 获取vault信息
obsidian vault info=path
obsidian vault info=files
obsidian vault info=folders

参数说明：file=<名称> 通过wikilink解析；path=<路径> 需要从vault根目录的精确路径。多行内容用 \n 表示换行。

标签体系

Obsidian模式使用标签增强检索：

• 主题标签：#主题/子主题
• 状态标签：#状态/待完善、#状态/已完成
• 类型标签：#类型/概念、#类型/指南、#类型/参考
• 质量标签：#质量/需补充、#质量/已验证

---

指导文档评估框架

每次Wiki更新后，用此框架评估指导文档是否需要调整。评估不是走过场——如果发现指导文档与实际需求脱节，必须修正。

评估信号

需要调整的信号（绿色=好，红色=需改）：

信号	含义
新内容自然归入现有分类	结构设计合理
新内容需要"创造"新分类才放得下	可能需要扩展结构
同一类内容反复出现在不同位置	分类逻辑需要重新审视
条目命名不一致	命名规范需要加强或调整
更新条目时不确定该改哪些关联	关联策略需要更明确
覆盖地图中多个领域标记"缺失"	可能初始化时对项目理解不足
用户反复提出同类问题	Wiki可能缺少该领域的完整条目

调整策略

1. 小幅调整：新增子分类、补充内容标准字段 → 直接执行，记录在改进记录中
2. 结构调整：合并/拆分/重命名目录 → 先告知用户调整方案，确认后执行
3. 原则调整：改变组织原则或分类逻辑 → 必须与用户讨论，这是重大变更

---

与其他Skill的协作

当项目本身是skill项目（检测到 SKILL.md）时，Wiki应包含：

• Skill能力描述的索引
• 使用场景的关联图谱
• 效果反馈的沉淀

当项目中已有其他文档体系（如API文档、README等）时：

• Wiki不重复已有内容，而是索引和关联
• Wiki条目中引用已有文档的位置
• 在"覆盖地图"中标注哪些领域由外部文档覆盖

---

操作日志

每次操作在Wiki根目录的 changelog.md 中追加记录：

## [YYYY-MM-DD] 操作类型 | 简述
- 触发：[用户输入/健康检查/定时任务]
- 变更：[创建了什么/更新了什么/调整了什么]
- 指导文档评估：[是否调整/调整原因]
- 待跟进：[需要注意的事项]

---

使用参考

详细的Wiki模板和评估标准，在以下参考文件中：

• references/project-templates.md —— 各项目类型的Wiki结构模板
• references/quality-criteria.md —— Wiki内容质量评估标准

当检测到特定项目类型时，读取对应的模板作为初始化参考。当评估指导文档时，参考质量标准进行判断。