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

这是一份想法说明文件，设计出来就是为了复制粘贴给你自己的 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^[1] 这样的粉丝 wiki：成千上万个相互链接的页面，覆盖角色、地点、事件、语言，由一群志愿者多年共同构建。你也可以在个人阅读过程中做出类似的东西，只不过所有交叉引用和维护都由 LLM 来完成。
• • 企业/团队：由 LLM 维护的内部 wiki，来源包括 Slack 讨论串、会议纪要、项目文档、客户通话。也可以有人类参与审核更新。wiki 能保持最新，是因为 LLM 承担了团队里没人愿意做的维护工作。
• • 竞争分析、尽职调查、旅行规划、课程笔记、爱好深潜：任何一种你会长期积累知识、并希望它是被组织起来而不是零散堆放的场景，都适用。

架构

这里有三个层次：

原始资料（Raw sources）：你精心整理的一组源文档。文章、论文、图片、数据文件都可以。这一层是不可变的，LLM 只能读取，绝不会修改。它是你的事实来源。

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）、一个 canvas。关键洞见在于：好的答案可以反过来作为新页面写回 wiki。 你提出的一个对比、一次分析、一个新发现的联系，这些都是有价值的，不应该消失在聊天记录里。这样一来，你的探索会像导入的来源一样，在知识库里形成复利。

Lint。 定期让 LLM 给 wiki 做一次健康检查。查看：页面之间是否存在矛盾、较新的来源是否已经推翻了某些陈旧结论、是否有没有入链的孤儿页面、是否有重要概念被提到却没有单独页面、是否缺少交叉引用、是否存在可以用一次网页搜索补上的数据空缺。LLM 很擅长提出值得进一步调查的新问题和新的资料来源。这样 wiki 在增长过程中就能保持健康。

索引与日志

有两个特殊文件能帮助 LLM（也帮助你）在 wiki 规模变大后继续高效导航。它们各自承担不同作用：

index.md 以内容为导向。它是 wiki 全部内容的目录：每个页面都有一条记录，附带链接、一行简介，以及可选的元数据，例如日期或来源数量。它按类别组织（实体、概念、来源等）。LLM 会在每次导入时更新它。回答问题时，LLM 先读索引找到相关页面，再深入具体页面。这个方法在中等规模下效果出奇地好（大约 100 个来源、数百个页面），而且避免了引入基于 embedding 的 RAG 基础设施。

log.md 以时间顺序为导向。它是一份只追加不修改的记录，记下发生了什么、发生在何时：导入、查询、lint 检查。一个有用的小技巧是：如果每条记录都以一致的前缀开头（例如 ## [2026-04-02] ingest | Article Title），那么日志就可以被简单的 Unix 工具解析，例如 grep "^## \ \[" log.md | tail -5 就能给你最近 5 条记录。日志能提供 wiki 演化的时间线，也能帮助 LLM 理解最近已经做过什么。

可选项：CLI 工具

在某个阶段，你可能会想构建一些小工具，帮助 LLM 更高效地操作 wiki。最显而易见的是 wiki 页面搜索引擎：在规模较小时，索引文件已经够用；但随着 wiki 变大，你会想要真正的搜索能力。qmd^[2] 是一个不错的选择：它是一个面向 Markdown 文件的本地搜索引擎，支持混合 BM25 / 向量搜索和 LLM 重排序，并且全部在本地设备上运行。它既有 CLI（因此 LLM 可以通过 shell 调用），也有 MCP server（因此 LLM 可以把它当作原生工具使用）。你也可以自己做一个更简单的版本，随着需求出现，LLM 可以帮你用 vibe-code 的方式快速写出一个朴素搜索脚本。

技巧与窍门

• • Obsidian Web Clipper 是一个把网页文章转换成 Markdown 的浏览器扩展。它对于快速把资料放入你的原始资料集合非常有用。
• • 把图片下载到本地。 在 Obsidian 的 Settings -> Files and links 中，把 “Attachment folder path” 设为一个固定目录（例如 raw/assets/）。然后在 Settings -> Hotkeys 中搜索 “Download”，找到 “Download attachments for current file”，并把它绑定到一个快捷键（例如 Ctrl+Shift+D）。剪藏一篇文章后，按下这个快捷键，所有图片都会被下载到本地磁盘。这是可选的，但很有用，因为它让 LLM 可以直接查看和引用图片，而不是依赖可能失效的 URL。需要注意的是，LLM 不能在一次读取中原生理解带内联图片的 Markdown；一种可行绕法是让 LLM 先读文本，再单独查看部分或全部引用图片，从而补充上下文。这个过程有点笨拙，但已经足够实用。
• • Obsidian 的 graph view 是理解你的 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 可以自己补全。

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

引用链接

[1] Tolkien Gateway: https://tolkiengateway.net/wiki/Main_Page
[2] qmd: https://github.com/tobi/qmd