原文:https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

作者:Andrej Karpathy

翻译:Fable 5(Cursor)

一种利用 LLM 构建个人知识库的模式。

这是一份想法文档(idea file),它被设计成可以直接复制粘贴给你自己的 LLM Agent(例如 OpenAI Codex、Claude Code、OpenCode / Pi 等)。它的目标是传达这个高层次的想法,而具体细节将由你的 Agent 与你协作构建出来。

核心想法

大多数人使用 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 讨论串、会议纪要、项目文档、客户通话。可以让人类参与审核更新。wiki 之所以能保持最新,是因为 LLM 承担了团队里没人愿意做的维护工作。
  • 竞争分析、尽职调查、旅行规划、课程笔记、爱好深挖——任何你需要随时间积累知识,并希望它井然有序而不是散落各处的场景。

架构

共有三层:

原始来源(Raw sources)——你精心挑选的源文档集合。文章、论文、图片、数据文件。这些是不可变的——LLM 从中读取,但绝不修改它们。这是你的事实来源(source of truth)。

wiki——一个由 LLM 生成的 markdown 文件目录。摘要、实体页面、概念页面、对比、总览、综合结论。LLM 完全拥有这一层。它创建页面,在新来源到来时更新页面,维护交叉引用,并保持一切一致。你负责读;LLM 负责写。

schema(模式)——一份文档(例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md),它告诉 LLM wiki 是如何组织的、约定是什么,以及在摄入来源、回答问题或维护 wiki 时应遵循什么工作流程。这是关键的配置文件——正是它让 LLM 成为一个有纪律的 wiki 维护者,而不是一个泛泛的聊天机器人。随着你摸清什么适合你的领域,你和 LLM 会共同演进这份文档。

操作

摄入(Ingest)。 你把一个新来源放进原始集合,并让 LLM 处理它。一个示例流程:LLM 阅读来源,与你讨论关键要点,在 wiki 中撰写一个摘要页面,更新索引,更新 wiki 中相关的实体和概念页面,并向日志追加一条记录。单个来源可能会涉及 10-15 个 wiki 页面。就我个人而言,我更喜欢一次摄入一个来源并保持参与——我阅读摘要、检查更新,并指导 LLM 该强调什么。但你也可以以较少的监督一次性批量摄入多个来源。由你自己去摸索适合你风格的工作流程,并把它记录在 schema 中供未来的会话使用。

查询(Query)。 你针对 wiki 提问。LLM 搜索相关页面,阅读它们,并综合出一个带引用的答案。根据问题的不同,答案可以采取不同的形式——一个 markdown 页面、一张对比表、一份幻灯片(Marp)、一张图表(matplotlib)、一个画布(centitiesanvas)。重要的洞察是:好的答案可以作为新页面归档回 wiki 中。 你要求的一份对比、一份分析、你发现的一个联系——这些都很有价值,不应该消失在聊天记录里。这样一来,你的探索就会像摄入的来源一样,在知识库中复利积累。

体检(Lint)。 定期让 LLM 对 wiki 做健康检查。检查内容包括:页面之间的矛盾、已被更新来源取代的过时论断、没有任何入链的孤立页面、被提及但缺少专属页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。LLM 很擅长建议新的问题去研究、新的来源去寻找。这能让 wiki 在成长过程中保持健康。

索引与日志

有两个特殊文件帮助 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 了解最近做过什么。

可选:CLI 工具

到某个阶段,你可能想构建一些小工具,帮助 LLM 更高效地操作 wiki。针对 wiki 页面的搜索引擎是最显而易见的一个——在小规模下索引文件就够用了,但随着 wiki 增长,你会需要真正的搜索。qmd 是一个不错的选择:它是一个面向 markdown 文件的本地搜索引擎,具备混合 BM25/向量搜索和 LLM 重排序,全部在设备端运行。它既有 CLI(LLM 可以通过 shell 调用它),也有 MCP 服务器(LLM 可以把它当作原生工具使用)。你也可以自己构建更简单的东西——LLM 可以在需要时帮你 vibe-code 一个简易的搜索脚本。

技巧与窍门

  • Obsidian Web Clipper 是一个把网页文章转换为 markdown 的浏览器扩展。对于快速把来源收进你的原始集合非常有用。
  • 把图片下载到本地。 在 Obsidian 设置 → Files and links 中,把 “Attachment folder path” 设置为一个固定目录(例如 raw/assets/)。然后在设置 → Hotkeys 中搜索 “Download”,找到 “Download attachments for current file” 并绑定一个快捷键(例如 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 仓库。你免费获得版本历史、分支和协作能力。

为什么这行得通

维护知识库中乏味的部分不是阅读或思考——而是记录整理(bookkeeping)。更新交叉引用、保持摘要最新、标注新数据与旧论断相矛盾的地方、在几十个页面之间维持一致性。人类之所以放弃 wiki,是因为维护负担的增长快于价值的增长。LLM 不会感到无聊,不会忘记更新某个交叉引用,并且可以一次性修改 15 个文件。wiki 能够持续得到维护,是因为维护成本接近于零。

人类的工作是精选来源、指导分析、提出好问题,并思考这一切意味着什么。LLM 的工作是其余的一切。

这个想法在精神上与 Vannevar Bush 的 Memex(1945)一脉相承——一个个人的、精心策展的知识存储,文档之间有关联轨迹(associative trails)。Bush 的愿景更接近于此,而不是后来 web 变成的样子:私有的、主动策展的,文档之间的连接与文档本身同样有价值。他没能解决的部分是由谁来做维护。LLM 解决了这个问题。

说明

这份文档有意保持抽象。它描述的是想法,而不是某个具体的实现。确切的目录结构、schema 约定、页面格式、工具链——所有这些都取决于你的领域、你的偏好以及你选择的 LLM。上面提到的一切都是可选且模块化的——取其有用,舍其无用。例如:你的来源可能是纯文本的,那你完全不需要图片处理。你的 wiki 可能小到只需要索引文件,不需要搜索引擎。你可能不关心幻灯片,只想要 markdown 页面。你可能想要一套完全不同的输出格式。使用这份文档的正确方式,是把它分享给你的 LLM Agent,然后一起协作实例化一个符合你需求的版本。这份文档唯一的任务就是传达这个模式。剩下的,你的 LLM 可以自己搞定。