Wiki Query

---
name: wiki-query
description: 基于本知识库已构建的 wiki 和源文件回答用户关于库内内容的问题，或为库内主题的任何任务（写作、分析、咨询等，形式不限）提供依据。先读 wiki/hot.md 与根 wiki/INDEX.md、再按需读相关目录的 INDEX.md 定位页面，读取最相关的 wiki 页面，必要时回溯源文件，再用 [[wikilink]] 引用并标注来源给出综合回答或创作依据——默认检索优先，问答与库内主题的创作都要先查本库，即使话题熟悉也不能凭训练记忆产出库内内容。领域无关，适用于任何已构建 wiki 的知识库。Triggers on: 介绍, 讲解, 总结, 概括, 梳理, 有哪些, 是什么, 是谁, 怎么回事, 为什么, 怎么办, 怎么处理, 怎么解决, 如何, 怎样, 方法, 方案, 原因, 影响, 作用, 对比, 区别, 关系, 根据知识库回答, 查知识库, 查一下知识库, wiki 里怎么说的, 知识库里有没有, 问问知识库, answer from the wiki, what does the knowledge base say, who is, what is, how to, how do I, summarize from notes.
version: 2.0.0
---

# wiki-query: 知识库问答

使用 vault 的 wiki 和源文件来回答问题、为库内主题的创作与分析提供依据。**先检索、后产出**——wiki 的价值就在于避免每次从零检索，也避免凭训练记忆作答或创作（记忆可能与本库版本不符）。不只是问答：**主题与本库重叠的任何任务都是检索任务**（形式不限），产出必须基于本库材料。

## 核心原则

- **检索优先，禁止凭记忆**：回答关于本知识库资料内容的问题前，必须先读 wiki（见「回答流程」）。即使你"觉得自己知道"，也要以本库 wiki/源文件为准——本库可能是特定版本、摘编或带标注，与你的训练记忆不一致。凭记忆直接作答是本 skill 最要避免的错误。
- **源文件不可变**：只能读取源文件，绝对不能修改或删除。
- **wiki 优先**：先从已编译的 wiki 页面回答，wiki 不足时再回溯源文件。
- **来源标注**：回答中必须注明信息来源（哪些 wiki 页面和源文件提供了关键信息）。
- **引用格式**：凡引用 wiki 页面或源文件，一律用 `[[页面名]]` 双括号 wikilink 语法（如 `[[知识库五范式]]`），不要用纯文本路径或 `[文字](路径)` markdown 链接——只有 wikilink 能在界面中点击跳转。页面名可用裸名（无需目录），系统会自动定位。

## 检索优先（默认）

- **默认先查**：被调用时先读 `wiki/hot.md` / 根 `wiki/INDEX.md`（再按需读相关目录的 INDEX.md）定位相关页面——**即使问题看起来是你熟悉的话题**也要先查本库（本库可能是特定 / curated / 摘编版本，与你的训练记忆不同，不查无从得知）。确认 wiki 有相关内容后据此作答；wiki 无相关内容时再回溯源文件，或明确说明知识库尚未覆盖。
- **唯一例外**：问题问的是工作区的近期活动或状态（如「总结今天的工作」「最近改了哪些文件」——依赖 `git log` / 文件系统 mtime）。这类直接用原生 Bash/检索回答，不必查 wiki。

## Vault 结构

vault 根目录就是当前工作目录。源文件在子目录中（如 raw/、notes/、docs/）。
wiki 相关内容的目录结构：
- `raw/` — 未处理的原始资料目录
- `raw/wechat/` — 微信通道收到的网页、文件等原始资料统一先放在这里
- `wiki/` — 所有 wiki 页面的根目录
- `wiki/INDEX.md` — 根索引：只列目录级概览（各目录页数 + 覆盖范围）与概述入口页，不逐页罗列
- `wiki/<dir>/INDEX.md` — 每个内容目录（sources/entities/concepts/comparisons/questions）自己的索引，列全该目录页面及一句话摘要
- `wiki/log.md` — 按时间顺序记录的操作日志（最新条目在最上面）
- `wiki/hot.md` — 近期上下文缓存（~500 字，每次操作后刷新）
- `wiki/meta/` — 元数据目录（lint 报告等）
- `wiki/sources/` — 源文件摘要页，由 raw/、notes/、docs/ 等原始资料生成
- `wiki/entities/` — 人物、组织、工具等实体页
- `wiki/concepts/` — 概念、模式、框架等
- `wiki/comparisons/` — 对比分析页
- `wiki/questions/` — 归档的问答页

页面路径规则：
- 默认使用单文件页面，例如 `wiki/entities/molio.md`、`wiki/concepts/agent-routing.md`
- 只有当某个实体、项目或主题需要拆成多个稳定页面时，才建立同名目录，并用 `index.md` 作为该目录入口

## 回答流程

1. **先读 `wiki/hot.md`**（如果存在）：近期上下文缓存，快速了解 wiki 当前状态。
2. **读根 `wiki/INDEX.md`**：了解 wiki 全貌（有哪些目录、各自覆盖什么、各多少页），判断哪些目录与问题相关。
3. **读相关目录的 `wiki/<dir>/INDEX.md`**：按根 INDEX 的目录行，读一两个相关目录的索引，从中定位最相关的页面。若目录没有 INDEX.md（旧库为单索引布局，根 INDEX 本身逐页列全），直接用根 INDEX 定位即可——不要因找不到目录索引而报错，也不要回头整读根 INDEX 之外的东西。
4. **读相关 wiki 页面**：读取定位出的最相关 3-5 个页面。
5. **按需回溯源文件**：wiki 页面不能完全回答时，读取原始源文件（`raw/`、`notes/`、`docs/` 等）获取更多细节。
6. **综合回答**：组织一个清晰、结构良好的回答，带 `[[wikilink]]` 引用与来源标注。

**检索义务与任务形式无关**：只要任务主题与本库内容重叠——无论它是问答、写作、分析、咨询、决策、策划还是这里没列出的任何形式——都先走同一套检索流程（hot.md → 根 INDEX → 目录 INDEX → 相关页面，必要时回溯源文件），然后**基于检索到的库内材料产出**，引用 `[[wikilink]]` 并标注来源。不要检索完又丢开材料凭记忆产出，那等于没查。

根据问题的复杂度自行决定检索深度：
- 简单事实查询：hot.md + 根 INDEX + 相关目录 INDEX + 1 个相关页面通常就够。
- 需要综合多个页面的问题：多读几个相关页面。
- 深度研究性问题：可能需要扫描更多页面甚至回溯源文件。

### 如果 wiki 尚未构建

`wiki/INDEX.md` 不存在时：直接检索源文件（`raw/`、`notes/`、`docs/` 等）回答，并在结尾提示用户可用 `wiki-build` skill 构建结构化 wiki 以获得更好的问答质量。不要假装 wiki 存在，也不要凭记忆冒充库内内容。

## 回答格式

提供：
- 对问题的直接回答
- 要点及简要解释
- 相关 `[[wiki 链接]]` 供进一步阅读
- 来源标注：列出哪些 wiki 页面和源文件为你的回答提供了信息

## 归档建议

每次回答后，评估回答是否具有归档价值。以下特征命中任一即有归档价值：
- 跨多个来源的综合分析
- 概念对比或方法论比较
- 某个主题的深入探讨（超出 wiki 已有内容）
- 发现了新的实体、关系或洞察

如果有归档价值，在回答末尾提出建议：
- 说明为什么值得归档
- 建议的页面路径和标题
- 等用户确认后再创建页面并更新 INDEX.md 和 log.md（或调用 `wiki-save` skill）

如果是简单的事实查询或已有 wiki 页面覆盖的内容，不提归档建议。