本文翻译自karpathy llm-wiki
一种利用 LLM 构建个人知识库的模式。
这是一个理念文件，旨在供您复制并粘贴到自己的 LLM Agent（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）中。其目的是传达高层次的核心想法，而您的 Agent 将与您协同构建出具体的细节。
0.1. 核心想法
大多数人使用 LLM 和文档的体验都很像 RAG：上传一堆文件，LLM 在查询时检索相关的文本块，然后生成答案。这种方式虽然有效，但 LLM 在回答每个问题时都是在从头开始重新发现知识，没有任何积累。如果提出一个需要综合五份文档的微妙问题，LLM 每次都必须重新寻找并拼接相关的碎片，无法沉淀任何成果。NotebookLM、ChatGPT 的文件上传以及大多数 RAG 系统都是这样运作的。
而这里的想法则完全不同。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 对话、会议纪要、项目文档和客户电话。可以引入人工审核更新。由于 LLM 承担了团队中没人愿意做的维护工作，Wiki 得以保持最新状态。
- 竞品分析、尽职调查、行程规划、课程笔记、爱好深度挖掘 —— 任何需要随着时间推移积累知识并希望其井然有序而非零散各处的情景。
0.2. 架构
整个架构分为三层：
原始资料（Raw sources） —— 您精心收集的源文档。文章、论文、图片、数据文件。这些是不可变的 —— LLM 只会读取它们，绝不会修改它们。这是您的信任源（Source of Truth）。
Wiki 层（The wiki） —— 一个由 LLM 生成的 Markdown 文件目录。包含摘要、实体页面、概念页面、对比表格、概述和综合分析。LLM 完全拥有这一层。它负责创建页面、在新资料输入时进行更新、维护交叉引用并保持一切内容的一致性。您负责阅读，LLM 负责编写。
模式层（The schema） —— 一个说明文档（例如适用于 Claude Code 的 CLAUDE.md 或适用于 Codex 的 AGENTS.md），用于告诉 LLM Wiki 的结构、约定以及在导入资料、回答问题或维护 Wiki 时需要遵循的工作流。这是关键的配置文件 —— 正是它让 LLM 成为一个纪律严明的 Wiki 维护者，而不仅仅是一个普通的聊天机器人。随着您逐步摸索出适合自己领域的规范，您和 LLM 将共同完善这个文件。
0.3. 运行流程
导入（Ingest）。 您将新资料放入原始集合中，并指示 LLM 进行处理。一个典型的流程是：LLM 阅读资料，与您讨论关键要点，在 Wiki 中撰写摘要页面，更新索引，更新整个 Wiki 中相关的实体和概念页面，并在日志中追加一条记录。一份资料可能会触及 10-15 个 Wiki 页面。就我个人而言，我更喜欢逐个导入资料并全程参与 —— 我会阅读摘要、检查更新，并引导 LLM 应该侧重什么。但您也可以在较少监督的情况下批量导入大量资料。您可以自行开发适合自己风格的工作流，并将其记录在模式层中，以便在未来的会话中使用。
查询（Query）。 您针对 Wiki 提出问题。LLM 会搜索相关页面、阅读它们，并综合出带有引用的答案。根据问题的不同，答案可以采取不同的形式 —— Markdown 页面、对比表格、幻灯片（Marp）、图表（matplotlib）或画布（Canvas）。一个重要的启示是：优质的答案可以作为新页面重新归档到 Wiki 中。 您要求的对比、做出的分析、发现的联系 —— 这些都是宝贵的财富，不应该消失在聊天记录中。通过这种方式，您的探索过程就会像导入的资料一样，在知识库中产生复利。
规范检查（Lint）。 定期让 LLM 对 Wiki 进行健康检查。寻找：页面之间的矛盾、已被新资料取代的陈旧主张、没有入链的孤儿页面、提及了重要概念却缺少其专属页面、遗漏的交叉引用、可以通过网页搜索填补的数据空白。LLM 非常擅长提出新的研究问题和寻找新的资料方向。这能确保 Wiki 在成长过程中保持健康。
0.4. 索引与日志
两个特殊文件可以帮助 LLM（以及您）在 Wiki 扩大时进行导航。它们服务于不同的目的：
index.md 是以内容为导向的。它是 Wiki 中所有内容的目录 —— 列出了每个页面的链接、单行摘要以及可选的元数据（如日期或资料数量）。按类别（实体、概念、资料等）进行组织。LLM 会在每次导入时更新它。在回答查询时，LLM 会先阅读索引以找到相关页面，然后深入查看这些页面。在中小规模（约 100 份资料，数百个页面）下，这种方式的效果出奇地好，并且不需要基于向量嵌入（Embedding）的 RAG 基础设施。
log.md 是按时间顺序排列的。它是一个只允许追加的记录文件，记录了什么时间发生了什么事 —— 导入、查询、规范检查。一个实用的技巧：如果每条记录都以固定的前缀开头（例如 ## [2026-04-02] ingest | Article Title），那么该日志就可以使用简单的 Unix 工具进行解析 —— grep "^## \[" log.md | tail -5 可以直接为您提供最后 5 条记录。日志为您提供了 Wiki 演进的时间线，并帮助 LLM 了解最近完成了哪些工作。
0.5. 可选：CLI 工具
在某些时候，您可能想要构建一些小型工具，以帮助 LLM 更高效地操作 Wiki。针对 Wiki 页面的搜索引擎是最显而易见的需求 —— 在小规模下，索引文件就足够了，但随着 Wiki 的增长，您会需要真正的搜索功能。qmd 是一个不错的选择：它是一个用于 Markdown 文件的本地搜索引擎，支持 BM25 与向量混合搜索，并在设备端由 LLM 进行重排序。它既有 CLI（以便 LLM 可以调用命令行），也有 MCP 服务器（以便 LLM 可以将其作为原生工具使用）。您也可以自己构建更简单的工具 —— 随着需求的出现，LLM 可以帮助您盲凑（Vibe-code）出一个简单的搜索脚本。
0.6. 提示与技巧
Obsidian Web Clipper 是一款浏览器扩展，可将网页文章转换为 Markdown。这对于快速将资料获取到原始集合中非常有用。
本地下载图片。 在 Obsidian 设置 → 文件与链接中，将“附件文件夹路径”设置为固定目录（例如
raw/assets/）。然后在设置 → 快捷键中，搜索“下载”以找到“下载当前文件的附件”，并将其绑定到快捷键（例如 Ctrl+Shift+D）。抓取文章后，按下快捷键，所有图片就会下载到本地磁盘。这是可选的，但很有用 —— 它允许 LLM 直接查看和引用图片，而不用依赖可能会失效的 URL。请注意，LLM 无法在一次运行中原生读取带有内联图片的 Markdown —— 解决方法是让 LLM 先读取文本，然后单独查看部分或全部被引用的图片以获取额外的上下文。这虽然有点繁琐，但效果还不错。Obsidian 的关系图谱视图（Graph view） 是查看 Wiki 形状的最佳方式 —— 了解什么是相互连接的、哪些页面是核心枢纽、哪些是孤儿页面。
Marp 是一种基于 Markdown 的幻灯片格式。Obsidian 有针对它的插件。适用于直接从 Wiki 内容生成演示文稿。
Dataview 是一个 Obsidian 插件，可以在页面属性（Frontmatter）上运行查询。如果您的 LLM 为 Wiki 页面添加了 YAML 属性（标签、日期、资料数量），Dataview 就可以生成动态表格和列表。
Wiki 本质上只是一个包含 Markdown 文件的 Git 仓库。您可以免费获得版本历史、分支功能和协同工作支持。
0.7. 为什么这很有效
维护知识库最枯燥的部分不是阅读或思考，而是记录工作。更新交叉引用、保持摘要最新、标记新数据与旧主张的矛盾、保持几十个页面之间的一致性。人类之所以放弃 Wiki，是因为维护成本的增长速度超过了其带来的价值。而 LLM 不会感到厌倦，不会忘记更新交叉引用，并且可以在一次运行中修改 15 个文件。Wiki 能够得到持续维护，是因为维护的成本几乎为零。
人类的工作是精选资料、引导分析、提出好问题并思考这一切意味着什么。LLM 的工作则是处理其余的一切。
这个想法在精神上与 Vannevar Bush 的 Memex (1945) 相关 —— 这是一个私人的、精选的知识库，文档之间具有联想路径。Bush 的愿景更接近于此，而不是后来的互联网：私密、积极精选，且文档之间的连接与文档本身一样具有价值。他唯一无法解决的部分是谁来负责维护。而 LLM 解决了这个问题。
0.8. 说明
本文档特意保持了抽象性。它描述的是理念，而非具体的实现。确切的目录结构、模式规范、页面格式、工具链 —— 所有这些都将取决于您的领域、您的偏好以及您选择的 LLM。上面提到的所有内容都是可选且模块化的 —— 选择有用的，忽略没用的。例如：您的资料可能全是文本，因此根本不需要处理图片；您的 Wiki 可能足够小，索引文件就是您所需要的一切，无需搜索引擎；您可能不在乎幻灯片，只需要 Markdown 页面；您可能想要一套完全不同的输出格式。使用它的正确方法是将其分享给您的 LLM Agent，并共同演进出一个适合您需求的版本。本文档唯一的职责就是传达这种模式，剩下的交给您的 LLM 即可。
评论