从RAG到LLM Wiki：用大语言模型构建会生长的个人知识库

上周，安德烈·卡帕西（Karpathy）在GitHub上发布了一个特别的gist，名叫“llm-wiki”。这不是一个代码库，也不是一个开源项目，仅仅是一个“想法文件”（idea file），一份阐述如何利用大型语言模型来构建个人知识库的思路文档。

然而，正是这个简单的文档，在Hacker News上引发了广泛讨论。原因在于，它提出了一套与当前主流的RAG（检索增强生成）方案截然不同的新范式。

RAG的“阿喀琉斯之踵”

目前，大多数人处理文档的方式依赖于RAG。无论是NotebookLM、ChatGPT的文件上传功能，还是市面上各种知识库产品，底层逻辑都大同小异：将文档切分、索引，当用户提问时，系统检索相关的文档片段，拼接起来生成答案。

RAG能工作，但它存在一个根本性的缺陷——它没有记忆，更没有积累。

每一次提问，对于AI来说都是一次从零开始的“考古发掘”。它需要重新搜索碎片，临时拼凑答案。上周你问过的、上个月你深入研究过的内容，在它的“脑”中并未留下任何结构化的痕迹。当你提出一个需要综合五份文档才能回答的复杂问题时，它每次都得老老实实地把那五份文档再翻找、拼接一遍。

这就像团队里有一位每天早晨都会失忆的同事，你昨天交代的重要事项，今天又得从头到尾复述一次。效率低下，且无法形成知识复利。

反转思路：让LLM“养”一个维基百科

卡帕西的方案完全反了过来。核心思想不再是“查询时临时检索”，而是让LLM增量构建并主动维护一个持久化的Wiki知识库。

每当你加入一份新的资料（论文、文章、笔记），LLM不会只是将其存储起来等待未来检索。相反，它会主动阅读这份资料，提取关键信息，然后将新知识整合进已有的Wiki结构中：更新相关实体页面、修订主题摘要、标记新旧数据之间的矛盾、补充交叉引用链接。

这意味着，知识是“编译一次，持续维护”的，而非“每次查询，重新发现”。这套方法的价值会随着时间积累而指数级增长。

卡帕西自己的实践方式是：一边运行着LLM Agent（如Claude Code），一边用Obsidian打开那个由AI维护的Wiki目录。AI像程序员一样在后台默默地修改和更新“代码库”（即Wiki），而他则在“集成开发环境”（即Obsidian）中实时查看结果——点击链接、查看关系图谱、阅读更新后的页面。

三层架构，权责清晰

这个方案采用了清晰的三层架构设计，确保了系统的稳定与可维护性：

• 原始资料层（Raw Sources）：存放你收集的一切原始材料，如文章、论文、截图、数据文件。这一层是只读的“事实来源”，LLM可以读取但绝不能修改，保证了源信息的真实性。
• 维基层（Wiki）：一个完全由LLM生成和维护的Markdown文件目录。里面包含了摘要页、实体（人物、概念）页、对比分析、领域综述等。这一层完全由LLM负责创作和更新，它创建页面、维护交叉引用、确保内容一致性。你的角色是“读者”，而它是“作者”。
• 模式/配置层（Schema）：一份指导LLM如何工作的“宪法”，通常命名为 CLAUDE.md 或 AGENTS.md。它定义了Wiki的组织规范、页面模板、工作流程等。你和LLM会共同迭代这份配置文件，逐步打磨出最适合你自身需求的知识管理体系。

这个设计非常巧妙：原始资料保真不变，Wiki由AI全权打理，配置规则控制行为边界。各层权责分明，有效避免了混乱。

三种核心操作，驱动知识生长

整个系统的运转围绕三种核心操作展开：

1. 摄入（Ingest）：将一份新文档放入“原始资料”目录，并触发LLM处理。LLM会解析文档，讨论其要点，然后据此创建或更新相关的Wiki页面。一份新资料可能触发十几甚至几十个关联页面的更新，知识网络得以自动扩展。
2. 查询（Query）：向Wiki提问。LLM会检索相关的Wiki页面，综合信息后给出带引用的回答。关键在于，一次高质量的查询与回答本身，也可以被反向沉淀回Wiki。你在分析中发现的深刻关联、对比得出的结论，不应消失在聊天记录里，而应成为知识库的一部分。
3. 审查（Lint）：定期让LLM对整个Wiki进行“健康检查”。它能自动发现内容矛盾、过期信息、孤立页面（没有链接指向的页面）以及缺失的重要页面。这个操作确保了Wiki在不断生长的同时，也能保持结构健康、内容一致。

这套方案能用在哪些场景？

• 个人成长记录：将你的日记、播客收听笔记、阅读摘要持续喂入系统，LLM能帮你构建一个结构化的“自我认知图谱”，发现你思想与兴趣的演变轨迹。
• 深度课题研究：花数月时间研究某个领域，每读完一篇论文或一份报告就进行一次“摄入”。到最后，你收获的不是一堆散乱的笔记，而是一个由AI维护的、带有完整综述和交叉引用的立体知识体系。
• 读书笔记系统：每读完一本书的一章就进行一次摄入，LLM会自动创建角色档案、主题解析页、情节线索图。读完全书，你就拥有了一个类似“托尔金网关”的专属书籍Wiki。
• 团队协作知识库：将团队的Slack讨论精华、会议纪要、项目文档、客户沟通记录纳入系统。LLM可以扮演那个永不疲倦的“知识库管理员”，维护一个实时更新的、结构清晰的团队内部Wiki，解决知识管理中最棘手的“维护”难题。

超越RAG：从“被动检索”到“主动编译”

RAG的本质是“被动检索”——问题驱动，临时抱佛脚。而LLM Wiki的模式是“主动编译”——资料驱动，持续建设。

在知识库规模较小时，两者的差异可能不明显。但随着资料量滚雪球般增长，差距会愈发显著。RAG的回答质量高度依赖于每次检索的精准度，检索不到的信息等同于不存在。而在LLM Wiki中，知识间的关联在摄入时就已经建立，矛盾在审查时就已经标记，复杂的综合分析可能早已写好。

另一个巨大优势是 “轻量” 。你几乎不需要复杂的基础设施：无需部署专用的向量数据库，无需搭建Embedding流水线。核心就是“Markdown文件 + LLM Agent + 一个本地编辑器（如Obsidian）”。当Wiki规模较小时，靠目录索引文件就能管理；规模变大后，可以引入像 qmd 这样的本地搜索工具（它混合了BM25和向量搜索），一切都可以在本地运行。

当然，必须坦诚地说：这不是一个开箱即用的产品。它更像一份“设计蓝图”或“高级技术文档”，需要你亲自动手配置Agent、设计初始Schema、并耐心调试工作流。它更适合那些有动手能力、愿意投入时间与AI协作、共同“培育”知识库的探索者。

如何开始实践？

你可以将卡帕西的gist全文复制到你的LLM Agent的配置文件（如 CLAUDE.md）中，然后与Agent协作，一步步搭建起你自己的Wiki。

大致的启动步骤包括：

1. 建立目录结构（例如 raw/ 存放原始资料，wiki/ 存放生成的Markdown页面）。
2. 撰写一份初始的Schema配置文件，定义页面类型、命名规范、摄入流程等基本规则。
3. 丢几份你当前感兴趣的资料到 raw/ 目录，启动第一次“摄入”操作。
4. 边使用边调整，把实践中发现的有效规则不断补充回Schema文件，迭代优化。

如果使用Obsidian，配合其“Web Clipper”浏览器插件可以非常方便地将网页内容保存为Markdown并存入原始资料库。对于图片等资源，建议下载到本地存放，避免因外链失效导致知识库“破损失忆”。

这并非一个可以一次性配置完美的系统。它更像是在培育一棵知识之树：你持续地喂养它（摄入资料），它则持续地生长、分枝、变得繁茂（更新Wiki）。关键在于开始并坚持使用，其巨大价值正是通过时间的复利效应积累而来的。

对于这类需要深度实践与持续维护的技术方案，在云栈社区这样的开发者社区中进行交流，分享各自在Agent调校、Schema设计上的心得与避坑经验，往往能事半功倍。技术探索的路上，同行者的视角总能带来新的启发。