119 lines
6.6 KiB
Markdown
119 lines
6.6 KiB
Markdown
# 使用 LLM 生成高质量中文 Wiki 知识库
|
||
|
||
## 1. Skill 概述
|
||
本 Skill 旨在利用大模型（LLM）将原始文档和图像（`raw/`）增量“编译”为 **结构化、交叉链接、高质量的中文 Wiki 知识库（`wiki/`）** 的完整思路和方法。
|
||
|
||
* **核心逻辑**：人工不直接编写 Wiki，仅负责投放素材和发起查询；LLM 负责理解、重写、链接与维护。
|
||
* **适配工具**：Obsidian（IDE 前端），通过插件支持更多格式：
|
||
- Markdown（文本内容）
|
||
- Matplotlib（数据可视化）
|
||
- Marp（幻灯片渲染）
|
||
- Mermaid（架构图）
|
||
|
||
---
|
||
|
||
## 2. 标准文件系统架构
|
||
严格遵循 I/O 分离原则，确保知识库的纯净度与可迁移性：
|
||
|
||
```text
|
||
📁 wikillm
|
||
├── 📁 raw/ # 【输入层】原始素材（只读）
|
||
└── 📁 wiki/ # 【输出层】编译器生成的知识产物
|
||
├── 📁 concepts/ # 核心概念、原理分析
|
||
├── 📁 practices/ # 部署指南、最佳实践
|
||
├── 📁 visual/ # Marp 幻灯片、Matplotlib 趋势图
|
||
├── 📁 queries/ # 高价值 Q&A 的沉淀归档
|
||
├── INDEX.md # 动态索引与学习路径
|
||
└── Glossary.md # 统一术语表与双链枢纽
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 核心工作流 (The "Compilation" Loop)
|
||
|
||
### 阶段 1：多模态解构 (Ingest & Analyze)
|
||
* **任务**：解析 `raw/` 目录下的新增内容。
|
||
* **视觉解析**：对图片进行深度 OCR 与逻辑识别。将架构图转化为文字描述及 **Mermaid** 代码块，存入对应 Wiki 页面。
|
||
* **元数据提取**：为每篇文档生成 YAML Frontmatter（包含：`tags`, `source`, `confidence_score`, `last_updated`）。
|
||
|
||
### 阶段 2：增量编译 (Incremental Writing)
|
||
* **非线性重构**：不进行 1:1 翻译，而是基于源文档的“核心贡献”进行重写。
|
||
* **中文化增强**：
|
||
* 消除翻译腔：使用行业专业术语（如将 "Agent" 译为 "智能体"）。
|
||
* 添加上下文：为中文读者补充必要的背景知识或行业对比。
|
||
* **可视化输出**：若涉及多步流程或对比，自动生成 **Marp** 格式的幻灯片文件（`.md`），以便在 Obsidian 中演示。
|
||
|
||
### 阶段 3：网络化链接 (Wikilinks & Indexing)
|
||
* **双链注入**：全文检索 `Glossary.md` 中的术语，使用 `[[术语名]]` 自动包裹。
|
||
* **Wikilink 格式规范**：
|
||
- 文件名使用 kebab-case（连字符分隔），例如：`Harness-Engineering.md`
|
||
- Wikilink 格式为 `[[文件名|显示文本]]`，其中**文件名部分必须与实际文件名完全匹配**（不带 .md 扩展名）
|
||
- 正确示例：`[[Harness-Engineering|Harness 工程]]`（对应文件 `Harness-Engineering.md`）
|
||
- 错误示例：`[[Harness Engineering|Harness 工程]]`（文件名带空格，不匹配实际文件）
|
||
- **文章列表格式**：
|
||
- 错误写法（表格无法正确解析双链）：
|
||
```
|
||
| 文章 | 描述 |
|
||
|------|------|
|
||
| [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] | HashiCorp 创始人从怀疑论者到深度用户的六个阶段 |
|
||
| [[Building-Your-First-Harness|构建你的第一个 Harness]] | 从个人开发者到工程组织的三级实用框架 |
|
||
```
|
||
- 正确写法（使用无序列表）：
|
||
```
|
||
- [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] - HashiCorp 创始人从怀疑论者到深度用户的六个阶段
|
||
- [[Building-Your-First-Harness|构建你的第一个 Harness]] - 从个人开发者到工程组织的三级实用框架
|
||
```
|
||
* **反向链接**：在文末生成 `## 相关研究` 模块，强制链接到 Wiki 内部至少 2 篇关联文档。
|
||
* **动态索引**：根据新增内容，自动更新 `INDEX.md` 中的”最新研究”与”学习路径”部分。
|
||
|
||
### 阶段 4：健康检查与维护 (Linting)
|
||
* **一致性检查**：扫描 `wiki/`，发现术语冲突（如 A 文档叫“智能体”，B 文档叫“代理”）时，自动统一。
|
||
* **孤岛扫描**：识别没有任何链接指向的页面，强制将其挂载到导航树中。
|
||
* **补丁发布**：当 `raw/` 有新版本（如论文更新）时，在对应 Wiki 页面顶部发布 `[Update Patch]` 摘要。
|
||
|
||
---
|
||
|
||
## 4. 输出质量标准 (The Gold Standard)
|
||
|
||
### 表达标准
|
||
> **原则**：读起来像是由该领域的资深专家直接用中文撰写的。
|
||
* **禁止词汇**：产生、输出（作为动词）、这个、那个（指代不明）。
|
||
* **提倡词汇**：负责构建、驱动、沉淀、权衡（Trade-off）。
|
||
|
||
### 技术标准
|
||
| 维度 | 要求 |
|
||
| :--- | :--- |
|
||
| **术语表** | 必须包含 40+ 核心概念，中英对照并带有 Wikilink |
|
||
| **链接密度** | 每 500 字需包含至少 3-5 个内部链接 |
|
||
| **视觉呈现** | 复杂架构必须有 Mermaid 图，数据趋势必须有 Markdown 表格 |
|
||
| **Marp 适配** | 综述类文章必须同步生成一份 `visual/` 下的 Slide 文档 |
|
||
|
||
---
|
||
|
||
## 5. Q&A 与知识沉淀 (Filing Back)
|
||
|
||
**当用户针对 Wiki 发起复杂查询时：**
|
||
1. **Agent 模式**：LLM 检索全库文档，进行跨文档推理。
|
||
2. **回答格式**：回答不仅要解决当前问题，还需提供“参考文档清单”。
|
||
3. **自动归档 (Filing)**：若该次 Q&A 具有通用研究价值，LLM 需自动将其整理为一篇新的文章，存入 `wiki/queries/`，并在 `INDEX.md` 中创建入口。
|
||
|
||
---
|
||
|
||
## 6. 执行清单 (Checklist)
|
||
|
||
* [ ] **Raw Check**: `raw/` 目录中是否包含待处理的新素材（图片/文档）？
|
||
* [ ] **Glossary Lock**: 是否已锁定全局术语表，确保翻译不漂移？
|
||
* [ ] **Multimodal Sync**: 图片是否已转化为可编辑的文字解析/Mermaid？
|
||
* [ ] **文件名规范**: 所有 wiki 页面文件是否使用 kebab-case（连字符分隔）命名？
|
||
* [ ] **Wikilink 格式检查**: 所有 `[[文件名|显示文本]]` 链接中的文件名部分是否与实际文件名完全匹配？
|
||
* [ ] **Wikilink Check**: 所有的核心概念是否都已变成 `[[可点击的链接]]`？
|
||
* [ ] **Marp Check**: 是否为需要汇报的内容生成了幻灯片格式？
|
||
* [ ] **Orphan Check**: 是否存在无法从 `INDEX.md` 触达的”孤儿页面”？
|
||
|
||
---
|
||
|
||
## 7. 最佳实践提示
|
||
* **手离开键盘**：不要手动修改 `wiki/` 目录下的内容，所有的修改应通过“向 LLM 发出 Lint 任务”或“添加 raw 素材后重新编译”来完成。
|
||
* **搜索即创作**：把每一次对知识库的提问看作是一次“知识合成”，务必将高质量的回答存回库中。
|
||
* **结构化思考**：在生成任何长篇文档前，先让 LLM 在内存中构建该主题的“概念地图”。
|