LLM Wiki与RAG最大的区别：不是“问完就扔”，而是“问→答→答案变成新知识→下次问得更准”。Ingest一篇5000字文档消耗约500k tokens，Query一次约70k tokens。知识会积累、极简（没有向量库）、支持体检。适合个人和小团队，上限约100-200篇文章。

两周前，Andrej Karpathy（卡帕西）在GitHub上发了个LLM Wiki，全网都在讨论。

公司周会要做分享，我就想：与其讲概念，不如自己上手试试。

于是花了点时间快速搭了一个，放了两篇文档进去，问了几个问题。虽然体验不深，但确实看到了一些有意思的东西。

今天就来聊聊我是怎么做的，以及这东西背后的原理到底是什么。

为什么想试试

主要是好奇。

平时用RAG的时候总觉得有点别扭：每次问问题都要重新检索一遍，问过的东西不会沉淀，下次还得重新问。

LLM Wiki的想法挺有意思：让AI帮你持续维护一个结构化的知识库，而不是每次都从零开始。

听起来不错，但能不能真的用起来？试试就知道了。

怎么搭起来的

我的方案是：

1. 先用Claude网页版，把CLAUDE.md写好
2. 让Claude网页版定义清楚文件夹结构、命名规范
3. 在本地批量构建文件夹
4. 把原始文档放到对应的文件夹里，然后让Claude Code开始干活，包括：整理文件（也就是编译）、问答

这么做的好处是，我可以检查CLAUDE.md文件和文件夹结构，这让我更放心。

整个过程中使用的工具包括：

• Obsidian Web Clipper（Chrome插件）：将网页内容以Markdown形式存储在本地
• Claude Code：负责对话、生成和更新wiki
• Obsidian：用来浏览和查看wiki

选择Obsidian的原因是，Claude Code生成的Wiki实际上是Markdown文件的集合，而Obsidian作为笔记软件原生支持Markdown。只要文件一更新，Obsidian就能及时看到。这样可以实时查看Wiki的具体内容。

LLM Wiki的三个核心操作

搭好之后，我放了两篇文档进去，问了两三个问题。虽然我只是简单试了试，但通过研究原理和实际操作，能看出这个系统的设计思路。

1. Ingest（喂资料）

你给它一篇新资料，它会：

• 理解全文
• 跟你对话，确认wiki生成方向
• 根据确认结果去生成Wiki，包括：实体文件、概念文件、索引文件、日志文件等

需要注意的是第二步：确认Wiki的生成内容。

这实际上是个体力活。因为LLM会基于它自己的理解去编译原始文档，虽然生成的内容与原始文档在方向上保持一致，但表述会有所不同。

你需要检查它是否出现了幻觉，所以工作量也不小。当然，这是为了确保生成的Wiki准确无误。如果你能容忍一定的幻觉，在这个阶段也可以检查得粗略一些，或者干脆不检查，直接让LLM自动生成。

2. Query（提问）

你问一个问题，它会：

1. 先看索引，定位到相关页面
2. 读取这些页面，合成答案
3. 关键来了：如果这个答案质量不错，它会存回wiki

这就是跟传统RAG最大的区别。

• 传统RAG：问 → 答 → 结束
• LLM Wiki：问 → 答 → 答案变成新知识 → 下次问得更准

我问了两三个问题，确实看到它把答案整理成了新的页面。虽然没有长期使用，但能感觉到：如果持续用下去，wiki会越来越厚，查询会越来越准。

这就是知识复利的逻辑。

3. Lint（体检）

这个功能我没深度用，但原理上很重要。

定期让AI扫描整个wiki，找：

• 矛盾的信息（A页面说是这样，B页面说是那样）
• 过时的内容（三个月前的数据还在用）
• 孤立的页面（没有任何链接指向它）
• 缺失的概念（明明很重要，但没有专门的页面）

如果长期使用，这个功能应该能帮你保持wiki的健康度。

原理拆解：为什么这个设计能用起来

虽然我只是快速上手试了试，但研究下来，能看出几个关键的设计点。

关键设计1：文档预处理

其实Wiki本身就是用户问题和文档之间的一个中间层。

在没有问答之前，我们的系统已经基于原始文档生成了一个Wiki，这个Wiki本身就已经包含了各种概念之间的关系，类似于一本百科全书。

所以它通过LLM，实际上把RAG系统那一套策略给搞定了。通过这样的方式，当来了一个问题之后，它能够很容易从Wiki里找到有用的答案，而不是像RAG一样要搭建一个复杂的工作流程，甚至是设计一套问答策略。

关键设计2：把问答沉淀下来作为知识

传统的RAG实际上更多是将原文档切分成知识切片，当问题进来后直接去检索，再把相关的知识切片给到大模型最终生成答案。即便同一个问题问多次，系统还是会重复走一遍流程，没有任何沉淀。

但是LLM Wiki却可以把问答本身作为知识沉淀到Wiki里，问得越多，Wiki里沉淀的知识就越多，回答也就越精准。

关键设计3：能够对知识库进行”体检”

这也是有意思的地方。

因为一般情况下，在RAG系统中，如果知识本身存在矛盾，实际上在知识处理阶段是检测不出来的；但通过LLM Wiki，却可以检测出来。

成本：token消耗

虽然我只试了两篇文档，但可以看看大概的成本：

• Ingest一篇5000字的文档：大约消耗500k tokens（包括生成摘要、更新相关页面）
• Query一次：大约消耗70k tokens

整体来看，LLM Wiki在Ingest阶段消耗的token还是比较多的。

初步感受

虽然只是快速试了试，但能看出一些不一样的地方：

1. 知识会积累

这是最明显的区别。

传统RAG是”用完即扔”，LLM Wiki是”越用越厚”。我只放了两篇文档，问了几个问题，就已经能看到wiki在”长大”——自动生成了一些概念页、摘要页。

如果长期用下去，这个积累效应应该会更明显。

2. 极简

没有向量库、没有embedding、没有复杂的检索管道。就是一堆Markdown文件。

这意味着：

• 迁移成本低（随时可以换工具）
• 可读性强（人类可以直接看）
• 调试方便（出问题了直接看文件）

局限性

虽然体验不深，但通过研究和实操，也能看出一些明显的局限：

1. 规模有上限

卡帕西自己说了，这个方案适合个人或小团队，大约100-200篇文章。如果你的知识库有几千篇文档，这个方案可能不适合。

2. 需要人工监督

AI不是万能的，尤其是Ingest阶段。重要资料最好人工核对，定期跑Lint检查错误。别指望扔给AI就不管了，那样肯定会出问题。

3. 不适合企业级

这个方案本质上是”个人生产力提升”。如果要做企业级知识库，会遇到：

• 权限管理（谁能看哪些页面）
• 并发编辑（多人同时改怎么办）
• 安全合规（敏感信息怎么处理）

这些问题，本地Markdown文件夹解决不了。

适合谁用

基于原理和初步体验，我觉得LLM Wiki特别适合：

个人长期项目

• PhD研究（文献综述、实验记录）
• 读书笔记（跨书的概念整合）
• 自我提升（健康追踪、技能学习）

小团队内部知识库

• 会议纪要自动整理
• 项目文档维护

需要长期积累的领域

• 竞品分析（持续跟踪）
• 行业研究（信息整合）
• 旅行规划（经验沉淀）

核心是：你需要一个会”长大”的知识库，而不是一次性的问答工具。

最后说两句

LLM Wiki不是完美方案，但它提供了一个新思路：

与其让AI每次都从零开始，不如让AI帮你持续构建一个真正属于自己的知识体系。

这个知识体系：

• 会随着你的使用越来越厚
• 会自动发现你没注意到的关联
• 会把碎片化的信息整合成结构化的知识

用卡帕西的话说：LLM不应该只是个聊天机器人，它应该是个知识编译器。

我觉得这个方向是对的。

虽然我只是快速试了试，但如果你也想上手，建议：

1. 先花时间把Schema写好
2. 从小规模开始（几篇文档）
3. 重点关注Ingest的质量

有问题欢迎留言交流。