Appearance
LLM 编译知识库：如何让知识库持续积累和互联？
约 20 分钟
AI 私教已完成专属 1v1 AI 私教，围绕本节内容深度教学
回到私教重新学习
前两篇我们把 RAG 管线从搭建到优化都讲透了。分块、embedding、混合检索、Reranker——一套流程走下来，确实能让 Agent "查到资料"了。
但用了一段时间你会发现一个问题：每次查询都是从零开始的。
你上周问过"我们的部署流程是什么"，Agent 检索了一遍文档，综合了三个 chunk，给了你一个不错的回答。今天你同事问了同样的问题——Agent 又从头检索了一遍，又综合了一遍，可能给出一个措辞不同但内容差不多的答案。
三个人问三次，Agent 做了三次完全相同的工作。知识没有积累，答案没有沉淀。
还有一个更深层的问题：跨文档的关联，RAG 几乎发现不了。
文档 A 说"我们的用户增长在 Q2 放缓了"，文档 B 说"Q2 我们砍掉了增长团队的预算"。这两件事之间的因果关系，人看了一眼就明白，但向量搜索做不到——因为这两段话在语义空间里可能离得很远，各自的关键词也重叠度不高。
RAG 解决的是"找到相关内容"的问题，但它不解决"理解内容之间的关系"和"让知识持续积累"的问题。
2026 年 4 月，Andrej Karpathy 发了一篇 gist，提出了一个思路，在技术圈引起了很大的反响。他的核心观点是：别让 LLM 每次都从原始文档里临时拼凑答案了，让它先把文档"编译"成一个结构化的知识库，后面查的时候直接查编译产物。
这个思路其实不是 Karpathy 最先提出来的。1945 年，Vannevar Bush 在《As We May Think》这篇文章里就描述过一个叫 Memex 的设想——一张办公桌大小的设备，能存储你所有的书籍、记录和通信，最关键的是它支持"关联路径"（associative trails）：你可以在任意两份文档之间建立链接，形成你自己的知识网络。
Bush 的洞察是：文档之间的连接，和文档本身一样有价值。 知识不是一堆孤立的文件，而是一张网。
但 Bush 没能解决一个问题：谁来维护这些连接？人工维护的成本太高了——你每读一篇新文章，可能要更新十几个已有的链接和摘要。这就是为什么个人知识管理工具（Wiki、Obsidian、Notion）最终都变成了"只进不出"的仓库——新内容不断往里塞，但已有的内容再也没人回去整理和关联。
80 年后，LLM 解决了这个问题。维护的活，让 AI 干。
编译器类比：从源码到产物
Karpathy 用了一个程序员秒懂的类比：
原始文档就是源码，LLM 就是编译器，Wiki 就是编译产物。
你不会每次运行程序的时候都从源码编译一遍吧？你编译一次，生成可执行文件，后面直接跑可执行文件。RAG 就像每次都从源码解释执行——能跑，但慢，而且每次的执行路径可能不同。
编译知识库的思路是：让 LLM 提前把原始文档"编译"成结构化的 wiki 页面，建好交叉引用和索引。后面查询的时候，直接在编译产物上检索，而不是回到原始文档。
而且更关键的是：每次新增一篇文档，LLM 会把新信息整合进已有的知识体系里——更新相关的实体页面、修订摘要、标注矛盾、补充交叉引用。一篇新文档进来，可能触发 10-15 个已有页面的更新。
这就是"知识复利"——知识越多，每一篇新文档带来的价值越大，因为它跟已有知识产生的连接越多。
Karpathy 自己的描述更直白："Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。"
三层架构
编译知识库的架构很清晰，分为三层：
Layer 1：raw/（原始素材）
你收集的所有原始材料——文章、论文、PDF、会议记录、截图、数据文件。这一层是只读的，LLM 可以读但不能改。它是你的 source of truth。
Layer 2：wiki/（编译产物）
LLM 生成和维护的结构化 Markdown 文件。这一层完全由 LLM "拥有"——它负责创建页面、更新内容、维护交叉引用、保持一致性。你读它，LLM 写它。
wiki 里面存的是经过整合的知识：实体页面（某个人、某个产品、某个概念的全貌）、对比分析（A 和 B 的区别）、综述页面（某个领域的全景）、时间线（事件的发展脉络）。
Layer 3：schema（操作规范）
一个配置文件（在 Claude Code 里就是 CLAUDE.md），告诉 LLM 这个 wiki 的结构约定、命名规范、工作流程。这一层是你和 LLM 共同维护的——你定规则，LLM 按规则执行。
这三层的关系可以类比成软件开发：raw/ 是需求文档，wiki/ 是代码，schema 是编码规范。
有意思的是，这跟我们前面学过的很多概念都能对上：
- wiki 的 index.md 就像 Deferred Tool Loading 里的 ToolSearch——一个轻量索引，帮你快速定位到具体页面
- 三层架构就像 Skills 的 Progressive Disclosure——Level 1 看索引，Level 2 看页面，Level 3 回溯原始文档
- 查询的好答案存回 wiki 这个动作，就像后面马上要讲的 Memory 自动提取——有价值的信息自动沉淀下来，而不是用完就丢
你看，你的知识体系现在已经开始打通了。
三个核心操作
整个编译知识库只有三个操作，非常简洁。
Ingest（摄入）
新素材进来的时候，LLM 做的事情不是简单地"存一下"。它会读完原始文档，创建一个摘要页面，然后扫描已有的 wiki 找到所有相关的实体和概念——更新它们的内容、补充新信息、标注矛盾、建立交叉引用，最后更新索引和日志。
整个流程用图来看更直观：
一篇新文档进来，可能触发五个以上页面的更新。这就是为什么说"知识在复利"——不是线性增长，是网络效应。
Karpathy 说他更喜欢一次 ingest 一篇，中间参与一下——看看摘要对不对，引导一下重点。但批量 ingest 也行，看你的场景。
举个具体例子。假设你在做竞品分析，已经 ingest 了 10 篇关于竞品 A 的文章，wiki 里有一个 竞品A.md 页面，里面整理了它的产品功能、融资历史、团队背景。现在你找到了一篇新文章，讲的是竞品 A 最近的一次大裁员。
Ingest 这篇文章之后，LLM 不只是创建一个新的摘要页面。它会去更新 竞品A.md，在团队背景的部分补充裁员信息，可能还会标注一下"此前的团队规模数据需要更新"。如果 wiki 里还有一个 行业趋势.md 页面，它可能也会去那里加一条关于行业裁员潮的关联。甚至可能发现 竞品B.md 页面里提到"竞品 B 在同一时期逆势扩招"，于是在两个页面之间建立一条交叉引用。
一篇文章进来，知识网络变得更密、更准。这是 RAG 做不到的事情。
Query（查询）
在 wiki 上提问。LLM 先读 index.md 找到相关页面，再深入读具体内容，综合回答并标注来源。
这里有一个 RAG 做不到的事情：好的回答可以反写回 wiki。
你问了一个对比分析的问题——"竞品 A 和竞品 B 在人才策略上有什么区别"，LLM 读了两边的页面，给了一个详尽的对比。这个对比分析本身就是有价值的知识，不应该消失在聊天记录里。把它存成一个新的 wiki 页面 竞品人才策略对比.md，下次任何人问类似的问题，直接就能找到。
你的每一次探索都在给知识库增值，而不是一次性消费。 这就是 Karpathy 说的"知识复利"——不只是 ingest 的时候在积累，query 的时候也在积累。
Lint（清理）
定期做一次健康检查：
- 有没有页面之间互相矛盾？
- 有没有被新信息推翻的旧内容？
- 有没有孤立的页面（没有任何其他页面链过来）？
- 有没有重要概念被提到了很多次，但还没有自己的专属页面？
- 有没有信息缺口可以通过搜索来补充？
这个操作跟我们第二章讲的"保险丝"是同一个思路——不是等出了问题才修，而是主动巡检、提前发现。
Context Engineering 设计：三级缓存
编译知识库跟上下文管理怎么配合？这里有一个很优雅的三级缓存设计：
L0：index.md 常驻 system prompt
大概 2500 字符，是整个知识库的"目录"。每个 wiki 页面一行，包含链接和一句话摘要。这个东西常驻在 system prompt 里，每次会话都能看到——LLM 知道知识库里有什么，但不需要把所有内容都加载进来。
L1：wiki 页面按需加载
每个页面大约 1500 字符。用户提问的时候，LLM 通过 index.md 定位到相关页面，用 Read 工具读取。只读需要的，不读不相关的。
L2：原始文档仅在必要时回溯
如果 wiki 页面的信息不够详细，LLM 可以回到 raw/ 去读原始文档（每篇大约 8000 字符）。但大部分情况下 L1 就够用了——因为 wiki 页面已经是编译过的精华。
这个三级缓存的精髓是什么？越常用的信息离上下文越近，越原始的信息离上下文越远。
跟 CPU 的 L1/L2/L3 缓存完全一样。index.md 是 L1 缓存（小、快、常驻），wiki 页面是 L2（中等大小、按需加载），原始文档是 L3（大、慢、很少用到）。
Karpathy 表示，在中等规模下（100 篇左右的文档，几百个 wiki 页面），这套机制"出奇地好用"，不需要任何向量数据库或 embedding 基础设施。一个 index.md + grep 就够了。
qmd：当知识库规模上来之后
如果你的知识库只有几十篇文档，index.md 加 grep 完全够用。但规模上来之后呢？
上一篇我们用 qmd 的三种搜索模式（BM25 → 向量 → BM25+Rerank）串起了检索优化的完整流程。这里换个角度——qmd 不仅是搜索引擎，它也是编译知识库的天然好搭档。
它还提供了一个 MCP Server，可以直接接入 Claude Code 等 Agent——Agent 通过 MCP 协议调用 qmd 的搜索能力，就像调用一个内置工具一样。
但要注意一点：qmd 是搜索引擎，不是知识编译器。 它帮你快速找到已有的内容，但它不会帮你整合知识、建立交叉引用、维护页面一致性。编译知识库和 qmd 是互补的关系——编译知识库生产内容，qmd 帮你高效检索这些内容。
这里有一个实际的规模判断：如果你的 wiki 不到 200 个页面，index.md 常驻在 prompt 里大概 2500 字符，模型通过索引就能定位到大部分内容，不太需要额外的搜索工具。当 wiki 超过几百页之后，index.md 本身变得太长了，这时候 qmd 这样的工具就有价值了——它在索引和原始页面之间多加了一层高效检索。
编译知识库 vs RAG：什么场景用什么方案
到这里你可能想问：那 RAG 是不是可以扔了？还是说两者可以一起用？
都不是。RAG 仍有使用场景，而且大部分场景下，二者选一个就够了，关键是判断你的场景属于哪种。
直接用编译知识库的场景： 个人或小团队的知识体系，文档量不大（几十到几百篇），内容相对稳定，你需要知识持续积累和跨文档关联。比如个人研究笔记、团队内部 wiki、竞品分析库、课程知识体系。这种场景下编译知识库就够了，不需要再搭一套 RAG 管线。
直接用 RAG 的场景： 文档量大（几千几万篇），内容频繁变动，不可能也没必要全部"编译"。比如客服知识库、产品文档中心、法律法规库。这种场景下老老实实用 RAG，分块、embedding、向量搜索那一套。
不管用哪种方案，有一点要记住：wiki 的内容是 LLM 编译出来的，不是原始事实。 LLM 在整合信息的时候可能会理解偏差、遗漏关键细节、甚至引入错误的关联。所以 wiki 页面不应该被当成"最终真相"——它更像是一个高质量的索引和摘要层。当你需要精确数据或者做重要决策的时候，还是要回溯到 raw/ 里的原始文档去核实。这也是为什么三层架构里 raw/ 是只读且不可修改的——它是你永远可以回溯的 source of truth。
为什么这个模式现在才火？
Bush 1945 年就提出了 Memex，个人知识管理工具（Wiki、Evernote、Notion、Obsidian）也发展了二十多年。为什么"编译知识库"这个模式到 2026 年才真正落地？
因为之前缺一个关键角色：维护者。
更新交叉引用、保持摘要跟原文一致、标注矛盾、维护索引——这些事情琐碎、无聊、但必须有人做。人类最终都会放弃，因为维护成本的增长速度比知识价值的增长速度更快。
LLM 不会觉得无聊，不会忘记更新交叉引用，一次能同时更新十几个文件。维护成本接近零。
你扔一篇文章进去，它帮你读完、摘要、归类、跟已有知识关联好——你只需要花 30 秒看一下它的输出对不对。你做策展人，LLM 做图书管理员。
人类的角色变了：你负责选素材、提方向、问好问题、思考意义。LLM 负责剩下的一切——整理、关联、维护、索引。
这才是 Bush 80 年前真正想要的 Memex。他想象的"关联路径"需要用户一条一条手动建，这个成本扼杀了他的设想。现在 LLM 自动帮你建，Bush 那个梦终于可以落地了。
LLM Wiki 的本质和利弊
编译知识库这个模式，说白了就是"让 AI 帮你整理笔记"，技术上谈不上多新颖。但它真正有意思的地方在于改变了人和知识之间的关系。
以前你读一篇文章，读完了就读完了。除非你特别勤快地做笔记、建链接，否则这篇文章的知识就锁在你的脑子里（大概率几天后就忘了）或者锁在你的收藏夹里（大概率再也不会打开）。
现在，每一篇你读过的文章都会被编译进你的知识库，跟你之前读过的所有文章产生连接。你的知识不再是一堆散落的碎片，而是一张越来越密的网。而且这张网是活的——每加一个节点，已有的连接都可能被更新和补充。
当然，这个模式也有明显的局限。编译知识库依赖 LLM 的理解和整合能力——如果 LLM 对某个领域理解有偏差，编译出来的 wiki 可能带有系统性的错误。而且 wiki 页面都是 LLM 写的，你如果不去审核，就等于盲信了一个"自动化的二手信息源"。
所以我觉得正确的用法是：信任但验证。 让 LLM 做 90% 的整理工作，但关键结论和重要连接，自己过一遍。
实际使用
基于上面的理念和思路，我做了一个 wiki-ingest 的 skill，大家如果感兴趣可以参考这个 skill 的实现，背后的思路在前文已经全部介绍了。如果你想要用起来，可以直接用这个命令先安装:
bash
复制
bash
npx skills add sanyuan0704/sanyuan-skills --path skills/wiki-ingest然后通过 skills 来增加 wiki 语料:
bash
复制
bash
/wiki-ingest 【你的 wiki 语料】默认情况下输出内容都放在工作目录的 wiki 子目录下，因此查 wiki 的方式也非常简单: 把 wiki 目录的作用写到 CLAUDE.md 或者 AGETNS.md 里面，直接让 Agent 在需要的时候去读文件即可，因此对于查询操作而言，并不需要太多额外的操作。
串一下
RAG 解决了"找到相关内容"的问题，但没解决"知识积累"和"跨文档关联"的问题。编译知识库是一种不同的思路：让 LLM 提前把原始文档"编译"成结构化的 wiki，知识在每次 ingest 时复利式增长。
三层架构——raw/（原始素材，只读）、wiki/（编译产物，LLM 维护）、schema（操作规范，人机共建）。
三个操作——Ingest（摄入新素材，触发多页面更新）、Query（在 wiki 上检索）、Lint（定期巡检矛盾和缺口）。
三级缓存——index.md 常驻 prompt（L0）、wiki 页面按需加载（L1）、原始文档必要时回溯（L2）。跟 CPU 缓存一个思路。 下一篇我们聊 Agent 的记忆系统——上下文窗口关掉就清空了，那些"下次还用得到"的信息怎么存、怎么找？文件派和数据库派各有什么取舍？