jzy/my_wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

重构WikiLLM技能结构并更新内容

Browse Source 
- 将wikillm技能移动到skills/wikillm/目录
- 添加详细的技能参考文档（workflows.md, qa.md, standards.md, errors.md）
- 更新README中的参考资料列表
- 添加Harness Engineering相关的图片和查询
- 更新wiki索引
This commit is contained in:
Junjian Wang
2026-04-13 18:43:50 +08:00
parent 94d4617299
commit a58453865b
10 changed files with 681 additions and 258 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/wikillm/SKILL.md
+37
View File
@@ -0,0 +1,37 @@
---
name: wikillm
description: Compiles raw documents into a structured, cross-linked Chinese Wiki knowledge base. Use when ingesting raw materials, answering questions about the wiki, or maintaining the wiki structure.
license: MIT
metadata:
version: "2.0"
author: WikiLLM Project
---
# WikiLLM Skill
利用 LLM 将原始文档和图像增量"编译"为结构化、交叉链接、高质量的中文 Wiki 知识库。
## 任务路由（首先阅读本节！）
在执行任何操作前，先判断当前任务属于以下哪个场景：
| 场景 | 判断标准 | 跳转至 |
|------|----------|--------|
| **增量编译** | `raw/` 目录有新增或修改的文件需要编译到 `wiki/` | [references/workflows.md](references/workflows.md) |
| **Q&A** | 用户针对 Wiki 内容提出问题（询问、咨询、探讨） | [references/qa.md](references/qa.md) |
| **Linting** | 需要检查 Wiki 的一致性、修复孤岛页面等 | [references/errors.md](references/errors.md) |
## 快速开始
### 核心逻辑
- 人工不直接编写 Wiki，仅负责投放素材和发起查询
- LLM 负责理解、重写、链接与维护
- 适配工具：Obsidian（IDE 前端）
### 详细文档
- **编译工作流**：见 [references/workflows.md](references/workflows.md)
- **Q&A 流程**：见 [references/qa.md](references/qa.md)
- **质量标准**：见 [references/standards.md](references/standards.md)
- **常见错误**：见 [references/errors.md](references/errors.md)
skills/wikillm/references/errors.md
+57
View File
@@ -0,0 +1,57 @@
# 常见错误与避免方法
## 错误 1：将 Q&A 当作编译任务处理
**表现**：用户提问时，直接去创建 `practices/` 或 `concepts/` 下的文档
**避免**：先看"任务路由"，Q&A 应该归档到 `wiki/queries/`
## 错误 2：忘记添加参考文档清单
**表现**：回答了问题，但没有链接到相关 wiki 页面
**避免**：Q&A 回答模板中必须包含"参考文档"部分
## 错误 3：归档后不更新 INDEX.md
**表现**：创建了 `wiki/queries/` 下的文档，但 INDEX.md 中没有入口
**避免**：使用 Q&A 检查清单，确保步骤 5 完成
## 错误 4：大文档只读取开头部分
**表现**：学术论文或长篇技术文章只基于开头部分生成简短摘要
**避免**：使用"大文档处理要求"的检查清单
## 错误 5：Wikilink 格式错误
**表现**：`[[Harness Engineering|Harness 工程]]` 而不是 `[[Harness-Engineering|Harness 工程]]`
**避免**：参考 Wikilink 格式规范
## 总体执行清单
* [ ] **任务路由确认**：已阅读任务路由，确认当前任务属于正确场景
* [ ] **Raw Check**: `raw/` 目录中是否包含待处理的新素材（图片/文档）？
* [ ] **Asset Sync**: `raw/images/` 下的所有图片是否已同步到 `wiki/assets/`？
* [ ] **Glossary Lock**: 是否已锁定全局术语表，确保翻译不漂移？
* [ ] **Multimodal Sync**: 图片是否已转化为可编辑的文字解析/Mermaid？
* [ ] **文件名规范**: 所有 wiki 页面文件是否使用 kebab-case（连字符分隔）命名？
* [ ] **Wikilink 格式检查**: 所有 `[[文件名|显示文本]]` 链接中的文件名部分是否与实际文件名完全匹配？
* [ ] **Wikilink Check**: 所有的核心概念是否都已变成 `[[可点击的链接]]`？
* [ ] **Marp Check**: 是否为需要汇报的内容生成了幻灯片格式？
* [ ] **Orphan Check**: 是否存在无法从 `INDEX.md` 触达的"孤儿页面"？
## Linting 检查清单
- [ ] **一致性检查**：扫描 `wiki/`，发现术语冲突时自动统一
- [ ] **孤岛扫描**：识别没有任何链接指向的页面，强制挂载到导航树
- [ ] **补丁发布**：当 `raw/` 有新版本时，在对应 Wiki 页面顶部发布摘要
## 最佳实践提示
* **手离开键盘**：不要手动修改 `wiki/` 目录下的内容，所有的修改应通过"向 LLM 发出 Lint 任务"或"添加 raw 素材后重新编译"来完成
* **搜索即创作**：把每一次对知识库的提问看作是一次"知识合成"，务必将高质量的回答存回库中
* **结构化思考**：在生成任何长篇文档前，先让 LLM 在内存中构建该主题的"概念地图"
* **利用编译日志**：遇到问题时，先查看 `wiki/compile.log` 了解之前的编译过程
skills/wikillm/references/qa.md
+46
View File
@@ -0,0 +1,46 @@
# Q&A 与知识沉淀详细指南
## Q&A 执行清单（严格按顺序执行）
- [ ] **步骤 1**：确认当前任务是 Q&A 场景（用户在提问，而非要求编译文档）
- [ ] **步骤 2**：Agent 模式 - 检索全库相关文档，进行跨文档推理
- [ ] **步骤 3**：生成回答，包含：
- 对问题的直接解答
- "参考文档清单"（使用 Wikilink 格式）
- [ ] **步骤 4**：判断是否需要归档：
- 是否具有通用研究价值？
- 是否可能被其他人再次查询？
- 如果是 → 继续步骤 5；如果否 → 结束
- [ ] **步骤 5**：自动归档：
- 将 Q&A 整理为一篇新的 markdown 文章
- 存入 `wiki/queries/` 目录
- 文件名使用 kebab-case，如 `How-to-Do-Something.md`
- 在 `INDEX.md` 的"Q&A 归档"部分创建入口
## Q&A 归档文档的元数据格式
```yaml
---
title: "问题标题（用中文）"
source: "WikiLLM Q&A"
date: YYYY-MM-DD
tags:
- "Q&A"
- "其他标签"
question: |
在这里记录原始问题
---
```
## Q&A 场景的子判断
- **简单查询**：可以直接用现有知识回答，无需创建新文档 → 仅回答，不归档
- **复杂查询**：答案具有通用研究价值，可能被其他人再次查询 → 回答 + 归档到 `wiki/queries/`
## 详细流程
**当用户针对 Wiki 发起复杂查询时**：
1. **Agent 模式**：LLM 检索全库文档，进行跨文档推理
2. **回答格式**：回答不仅要解决当前问题，还需提供"参考文档清单"
3. **自动归档 (Filing)**：若该次 Q&A 具有通用研究价值，LLM 需自动将其整理为一篇新的文章，存入 `wiki/queries/`，并在 `INDEX.md` 中创建入口
skills/wikillm/references/standards.md
+94
View File
@@ -0,0 +1,94 @@
# 输出质量标准与文件结构
## 标准文件系统架构
严格遵循 I/O 分离原则，确保知识库的纯净度与可迁移性：
```text
📁 wikillm
├── 📁 raw/ # 【输入层】原始素材（只读）
│ └── 📁 images/ # 原始图片文件（png, jpg, webp, gif, svg 等）
└── 📁 wiki/ # 【输出层】编译器生成的知识产物
├── 📁 concepts/ # 核心概念、原理分析
├── 📁 practices/ # 部署指南、最佳实践
├── 📁 visual/ # Marp 幻灯片、Matplotlib 趋势图
├── 📁 queries/ # 高价值 Q&A 的沉淀归档
├── 📁 assets/ # 图像和资源文件（从 raw/images/ 同步而来）
├── INDEX.md # 动态索引与学习路径
├── Glossary.md # 统一术语表与双链枢纽
└── sources.md # 来源文档索引（原始 URL 列表）
```
## 表达标准
**原则**：读起来像是由该领域的资深专家直接用中文撰写的。
**禁止词汇**：产生、输出（作为动词）、这个、那个（指代不明）
**提倡词汇**：负责构建、驱动、沉淀、权衡（Trade-off）
## 技术标准
| 维度 | 要求 |
| :--- | :--- |
| **术语表** | 必须包含 40+ 核心概念，中英对照并带有 Wikilink |
| **链接密度** | 每 500 字需包含至少 3-5 个内部链接 |
| **视觉呈现** | 复杂架构必须有 Mermaid 图，数据趋势必须有 Markdown 表格 |
| **Marp 适配** | 综述类文章必须同步生成一份 `visual/` 下的 Slide 文档 |
## 编译状态文件
项目使用三个核心文件来追踪编译状态：
### 1. `wiki/compile-results.tsv`
结构化的编译结果（TSV 格式）
- 字段：`raw_path`、`hash`、`last_modified`、`wiki_paths`、`compile_time`、`status`
- 记录每个 raw 文件的编译状态和生成的 wiki 文档
### 2. `wiki/compile.log`
详细的编译日志
- 记录每次编译的输入、输出、决策过程
- 用于调试、审查和回溯
### 3. `wiki/sources.md`
来源文档索引
- 记录所有原始来源的标题和 URL
- 格式：`- [标题](URL)` 的无序列表
- 按"学术论文"、"概念文章"、"实践指南"等分类组织
- 每次增量编译后更新
## Wiki 文档元数据
每个 wiki 文档的 YAML frontmatter 都包含 `raw_sources` 字段：
```yaml
---
title: 文档标题
source: [来源名称]
raw_sources:
- path: raw/source-file.md
hash: "sha256:abc123..."
---
```
## 常用命令
```bash
# 查看所有已编译文件
cat wiki/compile-results.tsv
# 查找特定文件的编译状态
grep "raw/xxx.md" wiki/compile-results.tsv
# 查看最近的编译日志
tail -100 wiki/compile.log
# 查看上次编译摘要
grep "=== 编译完成 ===" -A 5 wiki/compile.log
```
skills/wikillm/references/workflows.md
+144
View File
@@ -0,0 +1,144 @@
# 编译工作流详细指南
## 增量编译检查清单
- [ ] **扫描检查**：运行扫描，检查 `raw/` 目录中是否有新增或修改的文件
- [ ] **哈希对比**：与 `compile-results.tsv` 中的记录对比，确认变更
- [ ] **日志记录**：将检查过程写入 `compile.log`
- [ ] **只编译变更**：仅处理新增或修改的文件
- [ ] **更新 frontmatter**：确保新编译的 wiki 文档包含 `raw_sources`
- [ ] **更新状态文件**：追加/更新 `compile-results.tsv` 中的记录
- [ ] **更新来源索引**：更新 `sources.md`，添加本次新增的来源
## 阶段 0：增量检查
**任务**：检查 `raw/` 目录下哪些文件需要编译。
**步骤**：
1. 读取 `wiki/compile-results.tsv`，获取已编译文件的哈希记录
2. 遍历 `raw/` 目录，计算每个文件的 SHA-256 哈希
3. 对比哈希值，识别：
- **新增文件**：在 `compile-results.tsv` 中不存在的文件
- **修改文件**：哈希值与记录不同的文件
- **未修改文件**：哈希值相同的文件（跳过编译）
4. 将检查过程写入 `wiki/compile.log`
## 阶段 0.5：资源同步
**任务**：将 `raw/images/` 下的所有图片资源同步到 `wiki/assets/`。
**同步范围**：所有图像文件，包括但不限于：
- `png`, `jpg`, `jpeg`, `gif`, `webp`, `svg`
**同步方式**：
- 使用 `cp -r raw/images/* wiki/assets/` 进行完整同步
- `raw/images/` 是权威来源，同名文件直接覆盖
- 保留原始文件名（包括空格和特殊字符）
**验证**：确保 `wiki/assets/` 包含 `raw/images/` 中的所有文件
**时机**：每次编译前必须执行此步骤
## 阶段 1：多模态解构
**任务**：解析 `raw/` 目录下的新增或修改内容。
### 大文档完整阅读要求
对于篇幅较长的文档（学术论文、长篇技术文章），必须完整阅读和分析：
1. **完整内容获取**：
- 使用 Grep 搜索章节标题（如 `^#{1,3} `）了解文档结构
- 分段读取完整内容，确保覆盖所有主要章节
- 特别关注：摘要、引言、方法、实验、讨论、结论、附录等核心章节
2. **深度分析维度**：
- **核心论点**：提取文章的主要主张和关键发现
- **方法细节**：理解技术方案的实现细节和设计决策
- **实验结果**：完整记录所有实验数据、表格、图表信息
- **案例研究**：保留具体的定性示例和应用场景
- **相关工作**：建立与其他研究的联系和对比
3. **输出内容标准**：
- wiki 页面长度应与原文档的重要性和复杂度相匹配
- 学术论文应包含：摘要、核心方法、完整实验结果、详细讨论
- 技术文章应包含：问题背景、完整解决方案、实际应用案例
- 保留所有定量数据（表格、指标、分数等）
4. **例外情况**：
- 仅在以下情况下可生成较短摘要：
- 文档是纯新闻报道或简短公告
- 文档主要是代码或配置（无大量叙事内容）
- 用户明确要求仅生成摘要
### 视觉解析
对图片进行深度 OCR 与逻辑识别。将架构图转化为文字描述及 **Mermaid** 代码块，存入对应 Wiki 页面。
### 元数据提取
为每篇文档生成 YAML Frontmatter（包含：`tags`, `source`, `raw_sources`, `confidence_score`, `last_updated`）。
`raw_sources` 字段格式：
```yaml
raw_sources:
- path: raw/anthropic-harness-design.md
hash: "sha256:abc123..."
```
## 阶段 2：增量编译
**非线性重构**：不进行 1:1 翻译，而是基于源文档的"核心贡献"进行重写。
**中文化增强**：
- 消除翻译腔：使用行业专业术语（如将 "Agent" 译为 "智能体"）
- 添加上下文：为中文读者补充必要的背景知识或行业对比
**可视化输出**：若涉及多步流程或对比，自动生成 **Marp** 格式的幻灯片文件（`.md`），以便在 Obsidian 中演示。
## 阶段 3：网络化链接
### Wikilink 格式规范
- 文件名使用 kebab-case（连字符分隔），例如：`Harness-Engineering.md`
- Wikilink 格式为 `[[文件名|显示文本]]`，其中**文件名部分必须与实际文件名完全匹配**（不带 .md 扩展名）
**正确示例**：`[[Harness-Engineering|Harness 工程]]`（对应文件 `Harness-Engineering.md`）
**错误示例**：`[[Harness Engineering|Harness 工程]]`（文件名带空格，不匹配实际文件）
### 文章列表格式
**错误写法**（表格无法正确解析双链）：
```
| 文章 | 描述 |
|------|------|
| [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] | HashiCorp 创始人从怀疑论者到深度用户的六个阶段 |
```
**正确写法**（使用无序列表）：
```
- [[Mitchellh-Adoption-Journey|Mitchellh AI 采用之旅]] - HashiCorp 创始人从怀疑论者到深度用户的六个阶段
```
### 其他链接任务
- **双链注入**：全文检索 `Glossary.md` 中的术语，使用 `[[术语名]]` 自动包裹
- **反向链接**：在文末生成 `## 相关研究` 模块，强制链接到 Wiki 内部至少 2 篇关联文档
- **动态索引**：根据新增内容，自动更新 `INDEX.md` 中的"最新研究"与"学习路径"部分
## 阶段 4：健康检查与维护
- **一致性检查**：扫描 `wiki/`，发现术语冲突（如 A 文档叫"智能体"，B 文档叫"代理"）时，自动统一
- **孤岛扫描**：识别没有任何链接指向的页面，强制将其挂载到导航树中
- **补丁发布**：当 `raw/` 有新版本（如论文更新）时，在对应 Wiki 页面顶部发布 `[Update Patch]` 摘要
## 阶段 5：来源索引更新
**任务**：更新 `wiki/sources.md`，记录本次编译涉及的来源文档。
**格式规范**：使用简单无序列表，每项格式为 `- [标题](URL)`
**增量更新**：添加本次新增的来源，保持已有来源不变
**分类组织**：按"学术论文"、"概念文章"、"实践指南"等类别合理分组