LLM Wiki 入门：为什么它不是 RAG，也不是普通笔记软件

LLM Wiki 入门

flowchart LR
  A["Raw Sources 原始资料"] --> B["LLM Agent"]
  B --> C["Wiki Markdown 知识层"]
  C --> D["Index / Log / Graph"]
  D --> E["Query / Synthesis / Lint"]

Karpathy 在 2026-04 的 LLM Wiki gist 里提出了一个很简单但很有力的模式：不要只把资料丢给 RAG 等模型每次临时检索，而是让 LLM 长期维护一个结构化、可交叉引用、会持续增厚的 Markdown Wiki。

这篇是系列第一篇，只解决一件事：

LLM Wiki 到底是什么，它和 RAG、Obsidian、Notion、普通文件夹有什么区别？

如果你读完这一篇，应该能判断：

你是否需要 LLM Wiki；
它适合用来学什么；
为什么这个系列后面要从目录、规则、ingest、query、lint 一步步搭起来。

先说结论

LLM Wiki 不是一个软件，而是一种工作流：原始资料放一层，LLM 维护一层 Wiki，人负责阅读、判断和提问。
它和 RAG 最大的区别是“知识会积累”：RAG 往往每次回答都重新检索资料；LLM Wiki 会把资料提前整理成可持续演化的知识页面。
它和普通笔记最大的区别是“维护者不是你”：你不需要手工给每篇资料做链接、归档、合并、查重，Agent 会负责这些低价值但高消耗的工作。
最小可用系统只需要 Markdown + 一个 Agent + Git：Obsidian 很适合浏览，但不是必须；向量数据库一开始也不是必须。
这个模式特别适合长期学习一个领域：比如 AI Agent、投资研究、产品调研、读书项目、个人健康记录、团队知识库。

这篇文章会讲什么

LLM Wiki 的核心思想
它和 RAG 的区别
它和普通笔记软件的区别
三层架构：raw、wiki、schema
三个操作：ingest、query、lint
什么时候该用，什么时候不该用
你今天可以立刻做的最小实验

1. LLM Wiki 的核心思想

先用一句话讲：

LLM Wiki 是一个由 LLM Agent 维护的 Markdown 知识库。

它里面通常有三类东西：

层	谁维护	作用
`raw/`	人	保存原始资料，尽量不改
`wiki/`	LLM Agent	把资料整理成概念页、人物页、项目页、综述页
`AGENTS.md`	人 + LLM	规定 Agent 应该怎么维护 Wiki

这个设计有一个很重要的分工：

人负责选择资料；
人负责判断什么问题值得研究；
LLM 负责读、拆、归档、链接、更新；
LLM 负责发现冲突、补链接、维护索引；
人负责最后的判断和方向。

这和很多人过去用 AI 的方式不一样。

过去你可能是：

上传 10 个 PDF；
问一个问题；
模型临时找几段；
回答完就结束。

LLM Wiki 是：

你把资料放进 raw/；
Agent 读资料；
Agent 更新 wiki/ 中的一批页面；
下次再问问题时，它从已经整理好的 Wiki 出发；
好问题和好答案也会沉淀回 Wiki。

所以它不是一次性问答，而是长期积累。

2. 它为什么不是 RAG

RAG 的典型流程是：

问题 -> 检索相关 chunk -> 拼上下文 -> 模型生成答案

LLM Wiki 的典型流程是：

资料 -> Agent 整理成 Wiki -> 问题 -> 读 Wiki 页面 -> 生成答案 -> 好答案写回 Wiki

差别在这里：

维度	普通 RAG	LLM Wiki
知识形态	chunk	Markdown 页面
处理时机	查询时临时处理	ingest 时提前整理
是否积累	弱	强
适合问题	快速问答	长期研究、综合判断
人类可读性	通常低	高
可编辑性	依赖系统	Markdown 直接可改

RAG 很适合回答：

“这份文档里退款规则是什么？”
“合同第 3 条怎么说？”
“帮我查一下这批文档里有没有某个字段。”

LLM Wiki 更适合回答：

“过去 30 篇资料里，AIOps 的核心分歧是什么？”
“Claude Code、Codex、Cursor 的工作流差异怎么演化？”
“我最近读的这些文章共同指向什么趋势？”
“这个领域有哪些我还没搞清楚的问题？”

一句话：

RAG 更像搜索引擎，LLM Wiki 更像会自动维护的研究笔记系统。

3. 它为什么不是普通笔记软件

很多人用 Obsidian、Notion、Logseq，最后都会遇到同一个问题：

笔记不是不会写，是维护太累。

真正累的不是写一篇笔记，而是这些事：

给新页面找合适位置；
补双链；
合并重复概念；
更新旧结论；
发现两篇笔记互相矛盾；
做目录；
给页面加 frontmatter；
定期检查孤岛页面；
把一次聊天里的好结论整理回知识库。

这些事人类会烦，但 LLM 很适合做。

LLM Wiki 的关键，不是“让 AI 帮你写几段总结”，而是：

让 AI 成为知识库维护者。

你可以把它理解成：

类比	对应物
Obsidian	IDE
Markdown Wiki	代码库
LLM Agent	程序员
`AGENTS.md`	项目规范
Git diff	审查记录
lint	质量检查

这个类比很好用。

你不会希望程序员每次都随便改代码，所以你需要代码规范、测试、目录结构。

同样，你也不应该让 Agent 随便整理 Wiki，所以你需要：

页面命名规范；
引用规范；
ingest 流程；
query 流程；
lint 流程；
更新日志。

这就是本系列后面几篇要做的事。

4. 三层架构：raw、wiki、schema

一个 LLM Wiki 最小结构可以长这样：

llm-wiki/
├── AGENTS.md
├── index.md
├── log.md
├── raw/
│   ├── articles/
│   ├── papers/
│   ├── books/
│   └── assets/
└── wiki/
    ├── sources/
    ├── concepts/
    ├── people/
    ├── projects/
    ├── questions/
    └── synthesis/

raw 是原始资料层

这里放：

网页剪藏；
PDF；
论文；
访谈稿；
会议记录；
自己的日记；
图片和附件。

原则是：

raw 尽量不可变。

因为它是证据层。

LLM 可以读它，可以引用它，但不应该随便重写它。

wiki 是知识加工层

这里放：

source summary；
concept page；
people page；
company page；
project page；
timeline；
comparison；
synthesis；
open questions。

原则是：

wiki 由 Agent 维护，但人可以审查。

schema 是规则层

这里通常是 AGENTS.md 或 CLAUDE.md。

它规定：

目录怎么用；
页面怎么命名；
ingest 怎么做；
query 怎么做；
lint 怎么做；
引用怎么写；
遇到冲突怎么办；
不确定时怎么标注。

这个文件非常关键。

没有它，Agent 就只是一个会写总结的聊天机器人。

有了它，Agent 才像一个有纪律的 Wiki 维护者。

5. 三个操作：ingest、query、lint

LLM Wiki 的日常使用，基本围绕三个动词。

5.1 Ingest：把新资料吸收到 Wiki

你把一篇文章放进 raw/articles/，然后对 Agent 说：

请 ingest raw/articles/karpathy-llm-wiki.md。
按照 AGENTS.md 的流程：
1. 先生成 source summary；
2. 更新相关 concept pages；
3. 如有必要，新建 people / projects / questions 页面；
4. 更新 index.md；
5. 在 log.md 追加记录；
6. 最后列出你修改了哪些文件。

一次 ingest 可能会改 10 个页面。

这正是它的价值。

5.2 Query：基于 Wiki 提问

你问：

基于当前 Wiki，解释 LLM Wiki 和 RAG 的区别。
回答时请引用具体 wiki 页面，不要直接重新读 raw。
如果答案有长期价值，请把它整理成 wiki/synthesis/llm-wiki-vs-rag.md。

注意这里不是只要聊天回答。

好的回答应该被写回 Wiki。

5.3 Lint：检查知识库健康

你定期让 Agent 做：

请 lint 当前 Wiki。
检查：
1. 孤岛页面；
2. 重复页面；
3. 缺引用页面；
4. 互相矛盾的说法；
5. 应该新建但还没新建的概念页；
6. index.md 是否过时；
7. log.md 是否缺记录。

最后生成 wiki/synthesis/wiki-lint-report-YYYY-MM-DD.md。

Lint 是 LLM Wiki 和普通笔记的关键区别之一。

普通笔记越写越乱。

LLM Wiki 可以让 Agent 定期整理。

6. 什么时候适合用 LLM Wiki

适合：

场景	原因
学一个新领域	知识会持续积累
读一批论文	需要合并概念、方法、作者和结论
做竞品研究	需要横向比较和持续更新
写长期博客	资料和观点可以沉淀
个人复盘	日记、目标、项目会形成长期模式
团队知识库	会议、Slack、文档需要有人整理

不适合：

场景	原因
只查一次资料	普通搜索或 RAG 更快
资料非常少	直接读就行
结论必须法律级准确	需要人工审校和正式引用体系
不愿意审查 Agent 改动	Wiki 可能慢慢跑偏

LLM Wiki 不是魔法。

它最适合一种状态：

你会长期学习一个主题，但你不想把精力浪费在整理和维护上。

7. 最小实验：今天就能开始

你不需要一次搭完所有东西。

先建一个最小目录：

my-llm-wiki/
├── AGENTS.md
├── index.md
├── log.md
├── raw/
│   └── articles/
└── wiki/
    ├── sources/
    ├── concepts/
    └── synthesis/

然后做三步。

第一步：放入第一篇资料

比如：

raw/articles/karpathy-llm-wiki.md

第二步：写最小 AGENTS.md

# LLM Wiki Maintainer

你是这个知识库的维护者。

## 原则

- 不修改 raw/ 中的原始资料。
- 所有整理后的内容写入 wiki/。
- 每次 ingest 都必须更新 index.md 和 log.md。
- 遇到不确定信息，用 `待确认：` 标注。
- 不要删除旧结论，除非明确说明原因。

## Ingest 流程

1. 阅读指定 raw source。
2. 在 wiki/sources/ 写一篇 source summary。
3. 抽取重要概念，更新或新建 wiki/concepts/ 页面。
4. 如果形成综合判断，写入 wiki/synthesis/。
5. 更新 index.md。
6. 在 log.md 追加记录。
7. 最后汇报修改文件列表。

第三步：让 Agent ingest

请 ingest raw/articles/karpathy-llm-wiki.md。
按照 AGENTS.md 执行。
先不要追求完美，目标是跑通第一轮。

如果它能生成：

wiki/sources/karpathy-llm-wiki.md
wiki/concepts/llm-wiki.md
wiki/concepts/rag-vs-wiki.md
wiki/synthesis/why-llm-wiki-works.md
更新 index.md
更新 log.md

你的 LLM Wiki 就已经活了。

常见误区

误区 1：一开始就上向量数据库

不要急。

Karpathy 的模式里，index.md 在中小规模下已经很好用。等到几百页之后，再考虑搜索工具。

误区 2：把 raw 和 wiki 混在一起

不要把原文和整理稿放一个目录。

否则以后你分不清：

哪些是证据；
哪些是解释；
哪些是 Agent 的综合判断。

误区 3：让 Agent 自己决定一切

LLM Wiki 不是全自动知识库。

你仍然要决定：

哪些资料值得放进来；
哪些问题值得追；
哪些结论可信；
哪些页面需要重写。

Agent 是维护者，不是主人。

练习

今天只做一个练习：

建一个 my-llm-wiki/ 文件夹；
放一篇你最近读过的文章到 raw/articles/；
写一个最小 AGENTS.md；
让 Agent ingest；
打开生成的 index.md，看看它是否真的能导航。

如果这一步跑通，后面的系列就有意义。

小结

LLM Wiki 的核心不是“AI 总结文章”，而是：

让知识从一次性问答，变成一个会持续积累、会被维护、能反复查询的 Markdown 系统。

它有三层：

raw/：原始资料；
wiki/：整理后的知识；
AGENTS.md：维护规则。

它有三个动作：

ingest：吸收资料；
query：基于 Wiki 提问；
lint：检查和维护。

参考资料

Karpathy: LLM Wiki