最近油管大神Karpathy提出的 LLM Wiki 概念很火，我做了一些初步的实践，记录一下过程和我的感受。
作者在GitHub给出了一篇文档，介绍这个东西。
要用这个东西，就需要把这个文档发送给你的AI工具，比如Claude，Codex，Cursor。
第一步：LLM Wiki系统实现
根据原作者的文档实现一个LLM Wiki系统，也就是让AI工具帮你写一些代码，实现这样的系统。
我用Cursor简单写了一个。我的提示词很简单，就只有一句话，然后Cursor默认给我用纯代码逻辑，而不调用LLM的形式帮我实现了一个雏形，生成了一些Python脚本，代码比较简单，总共只有不到1000行。
显然，第一版和预期的不一样。我让Cursor接入大模型继续帮我实现这个项目，进行了几轮对话。对话细节就不逐一展示了，主要包括：
1、一些bug修复。主要是让AI自己运行，自己修复的。
2、我觉得它在运行耗时命令时没有log，我不知道进度如何，所以让它加了一些log。
3、默认的实现是，如果LLM调用失败了，就会回退到纯Python脚本。我觉得这个效果不会好，所以我让它改成失败后直接终止运行。
4、默认它把文档导进去以后，会随机生成一个十六进制文件名。觉得这个可读性太差，所以我要求他改成了参考原始文件的文件名来生成。
第二步、构建（Ingest）
这个系统实现之后，就需要构建LLM Wiki，作者原文中说的是Ingest，在我的项目中Cursor说的是编译，都是类似的意思，也就是把原始文档读取进来进行理解，生成它的关键信息。
在一开始，Cursor实现的第一版是不需要LLM的系统，纯代码逻辑处理，我问的Cursor是怎么实现这个编译过程的，下面是它的解释。
后面Cursor改进的用LLM实现的系统，提示词大概是这样的：
我的原始文章是一些Markdown文件。这是我过去就已经养成的习惯，我本身刚好就是用的Obsidian记笔记。参考我之前的文章：
如果你平时习惯用其他的工具记笔记，包括印象笔记、为知笔记、微信收藏等等，你还需要把这些笔记导出到一个AI可以读取的格式，通常也就是Markdown之类的纯文本。
这个过程会比较麻烦，因为我其实也想把我微信收藏里面的内容导出，但是微信并没有提供这样一个批量导出的功能，挨个复制又太多了，很费时间。以后我不会再使用微信收藏功能去收藏我觉得不错的文章，而是会用OpenClaw帮我收集起来，这样方便我随时导出。
通过这个Ingest的过程，一篇原始文章就会转成类似下面这样的形式，相当于是对原始文件关键点的索引。
这个过程需要对每一篇文档分别做索引，每篇文章都需要调用大模型，如果你的文档很多，消耗的token还是不少的，耗时也挺久。当然如果你不在乎token成本，可以调用速度最快的大模型，并且可以并列执行。
除了这个文档以外，它还会生成一些索引文件。例如，在categories里生成一个索引文件，索引到这个分类下的所有文件。
还有最外层的index.md，会索引所有的文件。
第三步、查询（Query）
当构建好这个LLM Wiki以后，就可以查询问题了。
首先是查询的实现逻辑，这是Cursor给出的解释。
实际查询一个问题，运行下面的命令，得到图中的结果，并且这个查询结果被保存到项目中 wiki/query_answers/query-20260408-182829.md。
|
第四步、检查（Lint）
我认为Lint是作者原文中的精髓。Lint的任务分两部分：
一方面是比较机械的任务，检查这些文章有没有基本的缺失和错误，比如引用的文件出现了坏链，某个单独的文件没有被其他文件索引到等。
另一方面是更灵活的任务，包括自动从网上搜索、补全文件里面的缺失内容，找出不同文件之间的关联，给文章中提到的重要概念建立单独的文档等等。
但是我让Cursor解释了一下它当前的实现，可以说是差强人意，逻辑过于简单了，详见截图。
实际上这里要做的事情很复杂，需要一个功能完善的Agent才能搞定，但是Cursor里面的实现只是用了一次大模型调用，这显然是远远不够的。
我实际让他帮我运行了一次。除了log变化了，其他所有文件都没有更新。由于我的Wiki是刚创建完成的，显然没有什么明显的坏链问题，而更智能的补全，Cursor并没能自动帮我实现。
LLM Wiki与RAG的对比
最后，我还向Cursor提了一个问题，这个思路和常规的RAG有什么不一样？
总结
通过这样一个简单的实践，我的理解是，LLM Wiki相当于是给我们的一系列文档建立了一个基于AI的、可以模糊查询的搜索引擎。和传统的搜索引擎一样，它也需要对查询的东西提前进行索引，从而加快查询结果，提高查询准确率。
但是作者原文里面只是简单的说了核心思想，让你把这些核心思想丢给AI去设计和实现。
而AI最终实现效果如何，很大程度上取决于你的大模型，以及你在这个实现过程中的干预。
而在之后的构建、查询、检查过程中，效果到底如何也取决于你这个项目实现的效果，以及你所调用的大模型，甚至还包括你写的原始文档，以及你查询所用的句子。
他说的思想太过简单了，剩下的东西全部指望AI主动设计，我觉得很难有足够好的效果，还需要人工参与反复完善。
也有一些具体的技术实现难点，例如有很多人的文档并不是都放在Markdown之类文件里的，而是来自各种类型的笔记，还有包括笔记里的图片等多媒体内容。怎么把这些内容导出来交给LLM Wiki管理也是个难题。
有很多软件，例如微信收藏，软件实现和笔记保存格式可能有各种加密措施，目的就是“提高用户粘性”，不让你轻松地转移到别的工具上使用，没那么容易导出来。
总结来说，就像Github评论里所说的，这个LLM Wiki的思路早就在广泛使用了，并不是一个非常有颠覆性的东西。不过他确实提供了一个相对确定的核心框架，可以借鉴这个思路去细化，搭建自己的知识库。
原创不易，如果觉得文章有帮助，欢迎分享转发，也欢迎关注我的公众号：搬砖的小明
