Query 教程
LLM Wiki 不是资料坟场。真正的价值从 query 开始：你不断追问，Agent 基于已有 Wiki 回答，然后把有价值的回答继续写回 Wiki。
如果 ingest 是把资料放进来，query 就是让知识产生回报。
先说结论
- Query 不应该直接从 raw 重新开始，而应该先读
index.md和相关 wiki 页面。 - 好回答必须有依据，至少说明参考了哪些 wiki 页面。
- 高价值回答不应该留在聊天记录里，而应该写回
wiki/synthesis/或wiki/questions/。 - Query 是 LLM Wiki 复利的第二来源：不仅资料会积累，问题和答案也会积累。
1. 普通提问的问题
如果你问：
LLM Wiki 和 RAG 有什么区别？Agent 可能直接凭常识回答。
这不符合 LLM Wiki 的精神。
更好的问法是：
请基于当前 LLM Wiki 回答：
LLM Wiki 和 RAG 有什么区别？
要求：
1. 先阅读 index.md；
2. 再阅读相关 wiki 页面；
3. 回答时列出参考页面；
4. 如果这个回答有长期价值，请建议写回哪个 synthesis 页面。关键是：
让 Agent 从 Wiki 出发，而不是从模型记忆出发。
2. Query 的标准流程
flowchart TD
A["用户问题"] --> B["读 index.md"]
B --> C["选择相关 Wiki 页面"]
C --> D["读取页面"]
D --> E["综合回答"]
E --> F{"是否有长期价值?"}
F -->|是| G["写回 synthesis / question / concept"]
F -->|否| H["只回答"]
G --> I["更新 index.md 和 log.md"]3. Query prompt 模板
你可以直接复制：
请基于当前 LLM Wiki 回答下面的问题：
问题：
<这里写你的问题>
流程要求：
1. 先阅读 index.md。
2. 选择最相关的 wiki 页面，不要直接从 raw 开始。
3. 如果 wiki 信息不足，再说明需要查看哪些 raw source。
4. 回答时列出参考页面。
5. 明确区分：
- 已有 Wiki 支持的结论；
- 你的推断；
- 仍不确定的问题。
6. 如果答案有长期价值，请建议写回路径。
7. 在我确认前，不要写文件。这适合第一次问。
如果你已经信任流程，可以改成：
请基于当前 LLM Wiki 回答下面的问题，并把有长期价值的答案写回 Wiki。
问题：
<这里写你的问题>
要求：
1. 先读 index.md。
2. 读相关 wiki 页面。
3. 生成回答。
4. 如果形成新的综合判断，写入 wiki/synthesis/。
5. 如果形成新问题，写入 wiki/questions/。
6. 更新 index.md 和 log.md。
7. 最后列出新增和更新文件。4. 什么问题适合问 LLM Wiki
4.1 概念解释
基于当前 Wiki，解释什么是 LLM Wiki。
请不要泛泛回答，要引用已有页面。适合写回：
wiki/concepts/llm-wiki.md4.2 对比
比较 LLM Wiki、RAG、普通 Obsidian 笔记。
请给表格，并写出适用场景。适合写回：
wiki/synthesis/llm-wiki-vs-rag-vs-notes.md4.3 时间线
根据当前 Wiki，整理这个主题的发展时间线。
每个节点要标注来源页面。适合写回：
wiki/synthesis/<topic>-timeline.md4.4 研究计划
我想继续研究 LLM Wiki 的搜索层。
基于当前 Wiki，给我一个 7 天阅读和实验计划。适合写回：
wiki/questions/when-to-add-search.md
wiki/synthesis/llm-wiki-search-plan.md4.5 找缺口
基于当前 Wiki，告诉我这个主题还有哪些关键问题没搞清楚。
按优先级排序。适合写回：
wiki/questions/5. 回答应该长什么样
一个好回答应该包含：
## 回答
...
## 依据
- [[wiki/concepts/llm-wiki]]
- [[wiki/synthesis/llm-wiki-vs-rag]]
## 推断
- ...
## 不确定
- ...
## 建议写回
- `wiki/synthesis/llm-wiki-query-patterns.md`为什么要区分“依据 / 推断 / 不确定”？
因为 LLM Wiki 的目标不是让答案看起来完整，而是让知识库长期可信。
6. 把好答案写回 Wiki
假设你问：
LLM Wiki 最适合哪些学习场景？Agent 给了一个很好的分类：
| 场景 | 是否适合 | 原因 |
|---|---|---|
| 长期读论文 | 适合 | 需要累积概念和方法 |
| 临时查资料 | 不适合 | 成本太高 |
| 团队会议知识库 | 适合 | 需要持续整理 |
不要让它停在聊天里。
继续说：
这个回答有长期价值。
请把它整理成 wiki/synthesis/llm-wiki-use-cases.md。
同时更新 index.md 和 log.md。写回后的页面可以是：
# LLM Wiki Use Cases
## 结论摘要
LLM Wiki 最适合长期积累型知识任务，不适合一次性查询。
## 适合场景
| 场景 | 原因 |
| --- | --- |
| 长期读论文 | ... |
| 竞品研究 | ... |
| 个人复盘 | ... |
## 不适合场景
| 场景 | 原因 |
| --- | --- |
| 临时查一次 | ... |
| 法律结论 | ... |
## 依据
- [[wiki/concepts/llm-wiki]]
- [[wiki/sources/karpathy-llm-wiki]]这一步是 LLM Wiki 的复利。
聊天记录本来会消失。
写回之后，它会变成下一次 query 的基础。
7. Query 后要不要每次写回
不需要。
建议规则：
| 回答类型 | 是否写回 |
|---|---|
| 临时解释 | 不写 |
| 纠正拼写 | 不写 |
| 多来源综合 | 写 |
| 新比较表 | 写 |
| 新问题 | 写 |
| 决策依据 | 写 |
| 研究计划 | 写 |
你可以在 AGENTS.md 里加：
## Query 写回规则
以下内容应建议写回 Wiki：
- 跨多个页面形成的新综合判断；
- 用户明确说“这个很有用”的回答；
- 可复用的对比表、时间线、路线图；
- 新发现的重要问题；
- 对已有 concept page 的定义修正。
以下内容不必写回：
- 一次性闲聊；
- 简单改写；
- 没有新信息的重复解释。8. Query 的三种模式
8.1 Read-only Query
只回答，不改文件。
适合：
- 第一次探索；
- 不确定问题价值；
- 高风险主题。
Prompt：
只读回答，不要修改任何文件。
基于 index.md 和相关 wiki 页面回答。8.2 Suggest-write Query
回答，并建议写回。
适合默认模式。
Prompt：
先回答。
如果你认为值得写回 Wiki，请给出建议路径和页面大纲。
等我确认后再写。8.3 Auto-write Query
回答并写回。
适合你已经信任该主题的流程。
Prompt：
回答后自动写回有长期价值的内容。
完成后更新 index.md 和 log.md。新手建议从 suggest-write 开始。
9. 如何避免 Agent 胡乱写回
9.1 要求它先说明价值
在写回前，请先说明：
1. 为什么这个回答值得长期保存；
2. 应该写到哪个目录；
3. 是否更新已有页面比新建页面更好。9.2 优先更新旧页面
很多 Agent 喜欢新建页面。
但 Wiki 不是文件越多越好。
加规则：
写回 query 结果时，优先更新已有页面。
只有当主题明显独立，且 index 中没有合适页面时，才新建页面。9.3 每次列出 diff 意图
写文件前，请先列出计划新增 / 更新的文件和每个文件的修改意图。10. 练习
基于前面 ingest 的 Karpathy 资料，问 5 个问题。
问题 1：概念解释
基于当前 Wiki，解释 LLM Wiki 是什么。
只读回答，不要修改文件。问题 2：对比
比较 LLM Wiki 和 RAG。
如果答案值得保存，请建议写回路径。问题 3：适用场景
LLM Wiki 适合哪些学习和工作场景？
请基于已有页面回答，并建议是否写回 synthesis。问题 4：缺口
当前 Wiki 里还有哪些重要问题没研究？
请生成 5 个 question page 建议。问题 5：写回
请把“LLM Wiki 适用场景”整理成 wiki/synthesis/llm-wiki-use-cases.md。
更新 index.md 和 log.md。小结
Query 是 LLM Wiki 的使用方式，也是它继续生长的方式。
记住三条：
- 先读 index，再读 wiki，不要每次从 raw 重来。
- 回答要区分依据、推断和不确定。
- 有长期价值的回答要写回 Wiki。
下一篇讲 lint：怎么让 Agent 定期体检这个知识库。