一种使用大语言模型构建个人知识库的模式。

这是一份理念文件，设计初衷是让你复制粘贴给自己的 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 这样的粉丝维基——由志愿者社区历时多年构建的数千个相互链接的页面，涵盖人物、地点、事件、语言。你可以在阅读时亲手构建类似的东西，由 LLM 完成所有交叉引用和维护工作。

• 商业/团队：由 LLM 维护的内部 wiki，输入来自 Slack 讨论串、会议记录、项目文档、客户通话，可能还有人审核更新。wiki 之所以能保持最新，是因为 LLM 做了团队里没人愿意做的维护工作。

• 竞品分析、尽职调查、旅行规划、课程笔记、爱好深度钻研——任何需要随时间积累知识、并且希望知识被组织起来而非散落各处的场景。

架构#

一共有三个层次：

1. 原始素材——你精心策展的来源文档集合。文章、论文、图片、数据文件。这些是不可变的——LLM 从中读取，但绝不修改。这是你的事实之源。

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

3. 模式文档——一份告诉 LLM wiki 如何组织的文档（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md）：结构是什么、约定有哪些、在摄取来源、回答问题或维护 wiki 时应遵循什么工作流程。这是关键的配置文件——正是它让 LLM 成为一个守纪律的 wiki 维护者，而不是一个泛泛的聊天机器人。随着你逐渐弄清楚什么适合你的领域，你和 LLM 会共同演进这份文档。

操作#

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

查询。 你针对 wiki 提问。LLM 搜索相关页面，阅读它们，然后综合出带引用的答案。答案可以根据问题的不同呈现不同形式——一个 markdown 页面、一个对比表格、一套幻灯片（Marp）、一张图表、一块画布。重要的洞见：好的答案可以归档回 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 了解最近做了什么。

可选：命令行工具#

某个时候，你可能想构建一些小工具，帮助 LLM 更高效地操作 wiki。针对 wiki 页面的搜索引擎是最显而易见的——小规模时索引文件就够了，但随着 wiki 增长，你需要真正的搜索。qmd 是个好选择：它是一个针对 markdown 文件的本地搜索引擎，具有混合 BM 25/向量搜索和 LLM 重排序，全部在本地设备上运行。它同时提供 CLI（LLM 可以通过 shell 调用）和 MCP 服务器（LLM 可以将其作为原生工具使用）。你也可以自己构建更简单的东西——LLM 可以在需要时帮你 vibe-code 一个朴素的搜索脚本。

技巧与窍门#

• Obsidian Web Clipper 是一个将网页文章转换为 markdown 的浏览器扩展。对于快速将来源收入原始集合非常有用。

• 将图片下载到本地。 在 Obsidian 设置 → 文件与链接中，将"附件默认存放路径"设置为固定目录（例如 raw/assets/）。然后在设置 → 快捷键中，搜索"Download"找到"Download attachments for current file"，将其绑定到快捷键（例如 Ctrl+Shift+D）。剪藏完一篇文章后，按下快捷键，所有图片就会下载到本地磁盘。这是可选的但很有用——它让 LLM 能直接查看和引用图片，而不是依赖可能失效的 URL。注意，LLM 无法一次性原生读取带内联图片的 markdown——解决办法是让 LLM 先读文本，然后单独查看部分或全部引用的图片以获得额外上下文。有点笨拙，但效果不错。

• Obsidian 的图谱视图是查看 wiki 形态的最佳方式——什么与什么相连，哪些页面是枢纽，哪些是孤儿。

• Marp 是一种基于 markdown 的幻灯片格式。Obsidian 有相应插件。可用于直接从 wiki 内容生成演示文稿。

• Dataview 是一个对页面 frontmatter 运行查询的 Obsidian 插件。如果你的 LLM 为 wiki 页面添加 YAML frontmatter（标签、日期、来源计数），Dataview 就能生成动态表格和列表。

• Wiki 就是一个 markdown 文件的 git 仓库。 版本历史、分支和协作都是免费的。

为什么这行得通#

维护知识库中乏味的部分不是阅读或思考——而是簿记工作。更新交叉引用、保持摘要不过时、注意新数据何时与旧论断矛盾、在数十个页面间保持一致。人类放弃 wiki，是因为维护负担的增长快于价值的增长。LLM 不会厌倦、不会忘记更新交叉引用，并且可以一次处理 15 个文件。Wiki 之所以能保持被维护，是因为维护成本接近零。

人类的任务是策展素材、引导分析、提出好问题、思考这一切意味着什么。LLM 的任务是其余的一切。

这一理念在精神上与 Vannevar Bush 的 Memex（1945）一脉相承——一个私人的、经过策展的知识存储，文档之间有关联轨迹。Bush 的设想比实际的互联网更接近这一点：私密的、主动策展的，文档之间的连接与文档本身同等有价值。他没能解决的部分是：由谁来做维护。LLM 解决了这个问题。

注意#

本文档有意保持抽象。它描述的是理念，而不是具体实现。确切的目录结构、模式文档的约定、页面格式、工具——所有这些都取决于你的领域、你的偏好和你的 LLM 选择。上面提到的所有内容都是可选和模块化的——选有用的，忽略没用的。例如：你的来源可能只有文本，那么你完全不需要图片处理。你的 wiki 可能足够小，只需要索引文件，不需要搜索引擎。你可能不在乎幻灯片，只想要 markdown 页面。你可能想要一套完全不同的输出格式。正确的使用方式是与你的 LLM Agent 分享它，并共同协作，实例化一个适合你需求的版本。本文档唯一的任务是传达这个模式。其余的，你的 LLM 可以自己搞定。