LLM Wiki：知识只编译一次

RAG 的重复劳动问题#

RAG 每次查询都要走完整流程：检索 → 提取 → 合成。

同一个问题问两次，系统每次都从头干一遍活。你问”Transformer 是什么”，系统翻文档、提取内容、生成答案。换个说法再问，系统又从头来一次。

Wiki 模式的核心价值：知识整理一次，永久保存。下次直接查已编译的内容。

传统笔记 vs LLM Wiki#

传统笔记是”存起来以后自己找”，LLM Wiki 是”存起来让 agent 理解后帮你找”。

为什么 Markdown 是正确基础#

Karpathy 强调用 markdown，理由有三：

便携无锁定

.md 文件任何编辑器都能打开。不依赖某家公司活着。之前用过几个云笔记产品，后来倒闭了，数据导出特别麻烦。

LLM 原生支持

模型训练数据里有大量 GitHub README、技术文档。headers、列表、代码块这些结构，模型天然能识别。不需要额外解析。

强制清晰

markdown 的格式本身推动组织内容：标题命名段落，列表分开条目。不像某些富文本编辑器，混乱内容也能存进去。

Karpathy 有一句话：

No database. No vector embeddings. No server. Just files and a capable model.

三层架构#

1
wiki/
2
├── SCHEMA.md      # 规则、约定、标签分类
3
├── index.md       # 所有页面目录 + 一行摘要
4
├── log.md         # 操作日志（只追加）
5
│
6
├── raw/           # Layer 1: 原始来源（不可修改）
7
│   ├── articles/  # 网页文章
8
│   ├── papers/    # PDF/论文
9
│
10
├── entities/      # Layer 2: 实体页（人、组织、产品）
11
├── concepts/      # Layer 2: 概念/主题页
12
├── comparisons/   # Layer 2: 对比分析
13
└── queries/       # Layer 2: 有价值的查询结果

Layer 1：原始来源

agent 只读，不改。你丢进去的文章、论文，原样保存。source material 不丢失，万一 wiki 页面有错误，可以回去查原文。

Layer 2：Wiki 页面

编译后的知识。agent 创建、更新、建立链接。每个页面对应一个实体、概念或对比。

Layer 3：Schema

定义规则：标签分类、页面命名规范、什么时候该建新页面。给 agent 的”操作手册”。

人机协作分工#

你提供原材料，agent 加工整理。wiki 目录在本地，随时手动编辑。

四个核心操作#

适用场景判断#

适合：

• 学术研究（论文多、概念交叉引用频繁）
• 技术学习（框架/工具层出不穷）
• 行业跟踪（公司、产品、人物动态）
• 个人知识库（任何你想长期累积的领域）

判断标准：

• 信息会反复查询吗？
• 内容之间有交叉引用价值吗？
• 想长期累积，不是临时查一次？

三个都满足，就适合。

不适合：

• 临时一次性问题
• 纯数据存储（没有概念/实体需要链接）
• 高频变化数据（实时行情、天气预报）

如何触发 agent#

前提是 skill 启用。Hermes 默认启用，被禁用的话，从 config.yaml 的 disabled 列表移除。

之后对 agent 说：

• “创建一个 wiki，主题是 AI 工具” → 初始化目录结构
• “把这篇文章加入 wiki” → ingest 操作
• “wiki 里有没有关于 X 的内容” → query 操作
• “检查一下 wiki 有没有问题” → lint 操作

Obsidian 兼容性#

wiki 目录本身就是 Obsidian vault：

• [[wikilinks]] 渲染为可点击链接
• Graph View 可视化知识网络
• YAML frontmatter 支持 Dataview 查询

如果机器没有显示器（比如服务器），可以用 obsidian-headless 做 sync，让你在笔记本上用 Obsidian 浏览，agent 在服务器上写。

总结#

llm-wiki 的核心价值：知识只编译一次，之后直接用。

不像 RAG 每次从头检索，它是 agent 帮你维护一个结构化的 markdown 知识库。你丢源材料，agent 提取整理、建立链接、维护结构。

适合需要长期累积、反复查询、有交叉引用价值的领域。