LLM Wiki：用 LLM 构建个人知识库的一种模式

作者： Andrej Karpathy
日期： 2026 年 4 月
来源： https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

核心思想

大多数人与 LLM 和文档的交互方式看起来像 RAG：上传一堆文件，LLM 在提问时检索相关片段并生成答案。这能工作，但 LLM 每次都在从头重新发现知识，没有积累。如果你问一个需要综合五份文档的微妙问题，LLM 每次都不得不重新找到并拼接相关片段。什么都没被构建出来。

这里的想法不同。不是仅在查询时从原始文档中检索，而是让 LLM 逐步构建并维护一个持久的 wiki——一个结构化的、相互链接的 Markdown 文件集合，位于你和原始来源之间。当你添加新来源时，LLM 不仅为以后检索而索引它。它会阅读它，提取关键信息，并将其整合到现有 wiki 中——更新实体页、修改主题摘要、标注新数据与旧主张的矛盾之处、加强或挑战不断演变的综合结论。知识被编译一次，然后保持最新，而不是每次查询都重新推导。

这就是关键区别：wiki 是一个持久的、复利式增长的产物。 交叉引用已经存在。矛盾已经被标记。综合结论已经反映了你阅读过的一切。wiki 随着你添加的每个来源和你提出的每个问题而变得越来越丰富。

你永远不会（或很少）亲自写 wiki——LLM 撰写并维护所有内容。你负责来源策划、探索和提出正确的问题。LLM 做所有繁重的工作——总结、交叉引用、归档和记账，这些工作才能使知识库随时间推移真正有用。在实践中，我通常一边打开 LLM agent，一边打开 Obsidian。LLM 根据我们的对话进行编辑，我实时浏览结果——跟随链接、查看图谱视图、阅读更新的页面。Obsidian 是 IDE；LLM 是程序员；wiki 是代码库。

这可以应用于很多不同的场景：

• 个人：追踪自己的目标、健康、心理、自我提升——整理日记条目、文章、播客笔记，并随着时间推移构建一个关于你自己的结构化图景。
• 研究：在数周或数月内深入研究一个话题——阅读论文、文章、报告，并逐步构建一个具有演变论点的综合 wiki。
• 读书：边读边归档每一章，为人物、主题、情节线索及其关联建立页面。到结束时，你就拥有了一个丰富的配套 wiki。想想像 Tolkien Gateway 这样的粉丝 wiki——数千个相互链接的页面，涵盖人物、地点、事件、语言，由一群志愿者经过多年建立。你可以在阅读时亲自建立类似的东西，而 LLM 负责所有的交叉引用和维护。
• 商业/团队：由 LLM 维护的内部 wiki，由 Slack 帖子、会议记录、项目文档、客户电话提供信息。可能有人类在循环中审查更新。wiki 保持最新，因为 LLM 能做团队中没人愿意做的维护工作。
• 竞品分析、尽职调查、旅行规划、课程笔记、爱好深耕——任何你在随时间积累知识并希望它有条理而不是散落各处的地方。

架构

有三层：

原始来源——你策划的来源文档集合。文章、论文、图片、数据文件。这些是不可变的——LLM 从它们读取但永不修改。这是你的真相来源。

Wiki——一个由 LLM 生成的 Markdown 文件目录。摘要、实体页、概念页、对比、概述、综合。LLM 完全拥有这一层。它创建页面，在新来源到达时更新它们，维护交叉引用，并保持一切一致。你阅读它；LLM 写它。

Schema——一个文档（例如用于 Claude Code 的 CLAUDE.md 或用于 Codex 的 AGENTS.md），告诉 LLM wiki 是如何结构的，惯例是什么，以及在摄取来源、回答问题或维护 wiki 时应遵循什么工作流程。这是关键的配置文件——它使 LLM 成为有纪律的 wiki 维护者，而不是通用聊天机器人。你和 LLM 会随着你弄清楚什么对你的领域有用而共同演变这个文件。

操作

Ingest（编译）。 你将新来源放入 raw 集合并告诉 LLM 处理它。一个示例流程：LLM 阅读来源，与你讨论关键收获，在 wiki 中写一个摘要页，更新索引，更新 wiki 中相关的实体和概念页，并向日志追加一个条目。一个单一来源可能会触及 10-15 个 wiki 页面。就我个人而言，我更喜欢一次摄取一个来源并保持参与——我阅读摘要，检查更新，并指导 LLM 强调什么。但你也可以用较少的监督批量摄取许多来源。由你来开发适合你风格的工作流程，并将其记录在 schema 中供将来使用。

Query（查询）。 你向 wiki 提问。LLM 搜索相关页面，阅读它们，并用引用综合答案。根据问题的不同，答案可以采取不同的形式——一个 Markdown 页面、一个对比表、一个幻灯片（Marp）、一个图表（matplotlib）、一个画布。重要的洞察是：好的答案可以作为新页面归档回 wiki。 你要求的一个对比、一个分析、一个你发现的关联——这些是有价值的，不应该消失在聊天记录中。这样，你的探索就像摄取的来源一样在知识库中复利增长。

Lint（健康检查）。 定期要求 LLM 对 wiki 进行健康检查。寻找：页面之间的矛盾、新来源已经取代的陈旧主张、没有入向链接的孤儿页、被提及但缺乏自己页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。LLM 善于提出新的调查问题和要寻找的新来源。这能在 wiki 增长时保持其健康。

索引和日志

两个特殊文件帮助 LLM（和你）在 wiki 增长时导航它。它们服务于不同的目的：

index.md 是内容导向的。它是 wiki 中所有内容的目录——每个页面都列有链接、一行摘要，以及可选的元数据如日期或来源数量。按类别组织（实体、概念、来源等）。LLM 在每次摄取时更新它。回答查询时，LLM 先读取索引找到相关页面，然后深入阅读。在中等规模（~100 个来源，~数百个页面）下，这出奇地有效，避免了基于嵌入的 RAG 基础设施的需求。

log.md 是按时间顺序的。它是一个只追加的记录，记录发生了什么以及何时发生——摄取、查询、lint 通过。一个有用的提示：如果每个条目都以一致的前缀开头（例如 ## [2026-04-02] ingest | 文章标题），日志就可以用简单的 unix 工具解析——grep "^## \[" log.md | tail -5 会给出最后 5 个条目。日志提供了 wiki 演变的时间线，并帮助 LLM 理解最近做了什么。

可选：CLI 工具

在某些时候，你可能想构建一些小工具来帮助 LLM 更高效地操作 wiki。最明显的一个是 wiki 页面上的搜索引擎——在小规模下，索引文件就足够了，但随着 wiki 增长，你想要适当的搜索。qmd 是一个不错的选择：它是一个用于 Markdown 文件的本地搜索引擎，具有混合 BM25/向量搜索和 LLM 重新排序，全部在设备上。它既有 CLI（所以 LLM 可以 shell 出来调用它），也有 MCP 服务器（所以 LLM 可以将其作为原生工具使用）。你也可以自己构建更简单的东西——LLM 可以在需要时帮你 vibe-code 一个朴素的搜索脚本。

技巧和窍门

• Obsidian Web Clipper 是一个浏览器扩展，可以将网络文章转换为 Markdown。对于快速将来源放入你的 raw 集合非常有用。
• 在本地下载图片。 在 Obsidian 设置 → 文件和链接中，将"附件文件夹路径"设置为固定目录（例如 raw/assets/）。然后在设置 → 快捷键中，搜索"Download"以找到"为当前文件下载附件"并将其绑定到快捷键（例如 Ctrl+Shift+D）。剪辑文章后，按下快捷键，所有图片都会下载到本地磁盘。这是可选的，但很有用——它让 LLM 直接查看和引用图片，而不是依赖可能失效的 URL。注意，LLM 不能一次性原生读取带内嵌图片的 Markdown——解决方法是让 LLM 先阅读文本，然后单独查看部分或全部引用的图片以获得额外上下文。这有点笨拙，但足够有效。
• Obsidian 的图谱视图 是查看 wiki 形状的最佳方式——什么与什么相连，哪些是枢纽页面，哪些是孤儿。
• Marp 是一种基于 Markdown 的幻灯片格式。Obsidian 有一个插件。对于直接从 wiki 内容生成演示文稿很有用。
• Dataview 是一个 Obsidian 插件，它在页面 frontmatter 上运行查询。如果你的 LLM 向 wiki 页面添加 YAML frontmatter（标签、日期、来源数量），Dataview 可以生成动态表格和列表。
• wiki 只是一个 Markdown 文件的 git 仓库。你可以免费获得版本历史、分支和协作。

为什么这有效

维护知识库的烦人部分不是阅读或思考——而是记账。更新交叉引用、保持摘要最新、标注新数据何时与旧主张矛盾、在数十个页面中保持一致性。人类放弃 wiki 是因为维护负担的增长速度超过了价值。LLM 不会感到无聊，不会忘记更新交叉引用，并且可以一次触及 15 个文件。wiki 保持维护，因为维护成本接近于零。

人类的工作是策划来源、指导分析、提出好问题、思考这一切意味着什么。LLM 的工作是其他一切。

这个想法在精神上与 Vannevar Bush 的 Memex（1945）有关——一个个人策划的知识存储库，文档之间有联想轨迹。Bush 的愿景更接近这个，而不是网络后来的样子：私人的、积极策展的，文档之间的连接与文档本身一样有价值。他当时无法解决的是谁来维护。LLM 解决了这个问题。

注

本文档是故意抽象的。它描述的是想法，而不是具体的实现。确切的目录结构、schema 惯例、页面格式、工具——这些都取决于你的领域、你的偏好和你选择的 LLM。上面提到的所有内容都是可选和模块化的——选择有用的，忽略不需要的。例如：你的来源可能是纯文本的，所以你根本不需要图片处理。你的 wiki 可能足够小，索引文件就是你所需要的一切，不需要搜索引擎。你可能不在乎幻灯片，只想要 Markdown 页面。你可能想要一组完全不同的输出格式。正确的方式是与你的 LLM agent 分享这个内容，并一起合作实例化一个适合你需求的版本。这个文档的唯一工作是传达模式。你的 LLM 可以弄清楚其余部分。