本文根据 Karpathy 的 LLM Wiki idea file 整理，并结合当前 vault 的实践方式重写。
LLM Wiki 要解决什么
LLM Wiki 解决的，不是“怎么搜到答案”，而是“怎么让知识留下来”。
现在大家使用大模型处理文档，最常见的方式还是文件问答。你把一堆文章、PDF 或会议纪要扔进去，等到自己有问题时，再让模型从里面检索相关片段、临时拼装一个答案。
这种方式当然有用，但它有一个很明显的问题：每次都像重新来过。
如果一个问题需要综合五篇资料，模型就要重新找五次、拼五次、解释五次。下一次你再问一个相近的问题，它还是要重新做一遍。整个系统并不会因为你已经问过很多问题，就自动变得更懂这个主题。
Karpathy 提出的 LLM Wiki，本质上是在这个过程中插入一个新的中间层。
它不满足于“查询时再理解文档”，而是主张让 LLM 持续维护一个持久化的 markdown wiki。每加入一个新 source，模型都去读取、提炼、归纳、补链接、修正旧说法。久而久之，你得到的不再只是一次次聊天记录，而是一个越来越完整的知识库。
这也是 LLM Wiki 最有价值的地方：
它把大模型从一个临时回答问题的接口，变成了一个持续维护知识库的助手。
三层结构
真正关键的是三层结构。
Karpathy 对这个模式的拆法非常简单，但非常有用。他把整个系统分成三层：
Raw sources
原始资料层。文章、PDF、截图、会议纪要、网页剪藏都放这里。这一层应该保持只读，因为它是事实来源。Wiki
知识层。这里放 summary、concept page、entity page、comparison、synthesis，以及各种 index 和 log。它不是原始资料，而是被 LLM 吸收、重写和维护过的知识。Schema
规则层。也就是告诉 LLM “这个 wiki 应该怎么维护” 的那份文件。比如目录分工、ingest 规则、query 怎么回写、lint 检查什么。在 Codex 里，这个角色通常就是AGENTS.md。
这三层看起来很朴素，但它解决的是知识库最容易失控的三个问题：
- 没有 raw/source 边界，原文就容易被误改
- 没有 wiki 层，查询结果就会一直停留在聊天里
- 没有 schema，LLM 就很容易退化成临时聊天机器人
换句话说，这套结构的价值，不在于目录好看，而在于职责明确。
和传统 RAG 的区别
它和传统 RAG 真正不一样的地方，在于工作重点。
很多人第一次看到 LLM Wiki，会问一句：这不还是另一种 RAG 吗？
表面上看，它们当然有交集。两者都保留原始资料，也都可能会在需要时回看 source。但它们的工作重点完全不同。
传统 RAG 关注的是：
“现在这个问题，我该从哪里找片段来回答？”
LLM Wiki 关注的是：
“这些资料读完之后，知识库该如何被更新？”
这意味着 RAG 更像查询时检索，LLM Wiki 更像摄取后的编译。
这也是为什么 Karpathy 会强调一个很关键的判断：
查询本身也应该能写回知识库。
如果你问出了一个很好的对比、分析或者连接，它不应该消失在聊天窗口里，而应该成为新的 wiki 页面。只有这样，知识库才会随着 ingest 和提问一起增长，而不是每次重新从零开始。
Ingest、Query 和 Lint
真正让这套方法运转起来的，是 Ingest、Query 和 Lint。
很多人把 Obsidian + LLM 的玩法理解成“把资料放进去，让模型帮我总结”。但在 LLM Wiki 里，最重要的不是单次总结，而是一整套反复运行的工作流。
第一步是 ingest。
你把新资料放进 raw collection，让 LLM 去处理。这里的 ingest 不只是写一页摘要，而是可能同时更新很多地方：概念页、实体页、对比页、index，甚至 log。Karpathy 在原文里还专门提到，一篇 source 影响十几页 wiki 是很正常的。
第二步是 query。
在这套模式里，query 不只是为了“问出一个答案”，而是为了“用已有 wiki 来思考，并在必要时继续扩展 wiki”。也就是说，好的答案本身也是可以入库的。你今天问出来的一次比较分析，明天应该成为可以直接复用的一页知识，而不是埋在聊天记录里。
第三步是 lint。
这是很多知识库最容易缺的一步。随着页面越来越多，问题也会越来越多：有些结论已经过时，有些页面没有任何入链，有些概念被说了十次却没有独立页面，有些页面之间开始出现冲突。如果没有定期 lint，知识库迟早会变成一个越来越乱的 markdown 仓库。
所以 LLM Wiki 真正完整的闭环是：
- ingest 负责增长
- query 负责使用和继续沉淀
- lint 负责维护健康
如果只做第一步，它就很容易退化成“自动总结资料”；如果三步都在，才更像一个会持续变好的知识系统。
为什么 Obsidian 适合这套方法
为什么 Obsidian 特别适合这套方法？
Karpathy 在原文里有一句很有名的比喻：
- Obsidian 是 IDE
- LLM 是程序员
- Wiki 是代码库
这句话之所以准确，是因为 Obsidian 的强项从来不是“智能回答”，而是：
- markdown 天然轻量
- 双链和 backlinks 很适合做交叉引用
- graph view 很适合观察结构
- Dataview 可以对 frontmatter 做动态查询
- git 让版本管理变得很自然
这些能力单独看都不神奇，但和一个会持续维护内容的 LLM 放在一起，就会很强。
你负责找资料、判断方向、提出问题；LLM 负责把一大堆容易拖延的维护工作做完。它补链接，它更摘要，它扩概念页，它记 log，它帮你把“散乱的阅读记录”慢慢变成“有结构的知识网络”。
这也是 LLM Wiki 最打动我的地方：
它不是试图让模型替你思考，而是试图把知识维护里那些最琐碎但又最重要的部分交给模型。
更值得改变的是工作方式
如果你已经在用 Obsidian，最值得改变的不是工具，而是工作方式。
很多人看到这套方法，第一反应是要不要上新的数据库、向量引擎、搜索系统。
但 Karpathy 的原文其实很克制。他甚至明确提到，在中等规模下，index.md 就已经足够有用，不一定非要立刻上 embedding-based RAG。
所以更值得先改变的，其实不是技术栈，而是工作方式：
- 把 raw source 和 knowledge notes 分开
- 每次 ingest 后，不只是写一篇总结，而是更新相关主题页
- 把高价值 query 回写成知识页
- 给知识区维护 index 和 log
- 定期做 lint，清掉脏链接、孤儿页和过时结论
如果这些习惯建立起来，Obsidian 才会慢慢从一个“放笔记的地方”，变成一个真的会生长的 LLM Wiki。
如果只用一句话总结 LLM Wiki 的价值，我会这样说：
它不是教你怎么让大模型读更多文件，而是教你怎么让大模型帮你维护一个会持续增值的知识库。
