LLM 维基

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

这是一个理念文件，旨在让你复制粘贴到自己使用的 LLM 智能体中（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目标是传达高层次的想法，而你的智能体会与你协作，构建出具体的实现细节。

核心理念

大多数人使用 LLM 处理文档的体验类似于 RAG（检索增强生成）：你上传一批文件，LLM 在查询时检索相关片段，然后生成答案。这种方式有效，但 LLM 每次都要从头重新发现知识。知识不会积累。当你提出一个需要综合五份文档的微妙问题时，LLM 每次都必须找到并将相关片段拼凑起来。没有东西被构建出来。NotebookLM、ChatGPT 的文件上传以及大多数 RAG 系统都是这样工作的。

这里的理念则不同。LLM 不是在查询时仅仅从原始文档中检索，而是 逐步构建并维护一个持久化的维基 —— 一个结构化的、相互链接的 Markdown 文件集合，位于你与原始资料之间。当你添加一个新资料时，LLM 不只是将其索引以备后续检索。它会阅读资料，提取关键信息，并将其整合到现有的维基中 —— 更新实体页面、修订主题总结、注明新数据与旧有论断相矛盾之处，从而强化或挑战不断演变的综合认知。知识被一次性编译，然后 保持更新，而不是每次查询都重新推导。

这是关键区别：维基是一个持久的、不断积累的产物。 交叉引用已经存在。矛盾之处已经被标记。综合认知已经反映了你读过的一切。每增加一个资料、每提出一个问题，维基都会变得更加丰富。

你从来（或很少）自己编写维基 —— LLM 负责编写和维护所有内容。你负责 sourcing（寻找资料）、探索以及提出正确的问题。LLM 做所有的脏活累活 —— 总结、交叉引用、归档、记账，这些工作让知识库随着时间的推移真正变得有用。在实践中，我会让 LLM 智能体在一边打开，Obsidian 在另一边打开。LLM 根据我们的对话进行编辑，我实时浏览结果 —— 跟随链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE；LLM 是程序员；维基是代码库。

这可以应用于许多不同的场景。举几个例子：

• 个人：追踪自己的目标、健康、心理、自我提升 —— 归档日记条目、文章、播客笔记，并逐步构建出一个关于自己的结构化画像。
• 研究：在数周或数月内深入研究某个主题 —— 阅读论文、文章、报告，逐步构建一个包含不断演变的论点的全面维基。
• 阅读一本书：边读边归档每一章，为人物、主题、情节线索及其关联构建页面。读完后你便拥有一个丰富的伴读维基。想想粉丝维基，比如 Tolkien Gateway —— 成千上万个相互链接的页面，涵盖人物、地点、事件、语言，由志愿者社区花费数年建成。你可以在阅读时个人构建出类似的东西，而 LLM 负责所有的交叉引用和维护。
• 商业/团队：一个由 LLM 维护的内部维基，输入来源包括 Slack 讨论串、会议记录、项目文档、客户通话。可能还需要人工参与审查更新。维基保持最新，因为 LLM 做了团队里没人愿意做的维护工作。
• 竞争分析、尽职调查、旅行计划、课程笔记、爱好深潜 —— 任何你需要随时间积累知识并希望将其组织起来而非散落各处的场景。

架构

共有三层：

原始资料 —— 你精心挑选的源文档集合。文章、论文、图像、数据文件。这些是不可变的 —— LLM 从中读取但从不修改。这是你的事实来源。

维基 —— 一个由 LLM 生成的 Markdown 文件目录。包含总结、实体页面、概念页面、对比分析、概览、综合报告。LLM 完全拥有这一层。它创建页面，在新资料到达时更新页面，维护交叉引用，并保持一切一致。你阅读它；LLM 编写它。

模式 —— 一个文档（例如，用于 Claude Code 的 CLAUDE.md 或用于 Codex 的 AGENTS.md），它告诉 LLM 维基的结构是什么、约定是什么，以及在吸收资料、回答问题或维护维基时应遵循的工作流程。这是关键的配置文件 —— 它让 LLM 成为一个守纪律的维基维护者，而不是一个通用的聊天机器人。随着你逐渐弄清楚什么对你的领域有效，你和 LLM 会共同演进这个模式。

操作

吸收。 你将一个新资料放入原始资料集合中，并告诉 LLM 处理它。一个示例流程：LLM 读取资料，与你讨论关键要点，在维基中编写一个总结页面，更新索引，更新维基中相关的实体和概念页面，并在日志中追加一条记录。一个单一资料可能会触及 10-15 个维基页面。我个人更喜欢一次只吸收一个资料并保持参与 —— 我会阅读总结，检查更新，并指导 LLM 哪些内容需要强调。但你也可以在较少监督下一次批量吸收多个资料。由你决定开发适合自己风格的工作流程，并将其记录在模式中，供未来会话使用。

查询。 你针对维基提出问题。LLM 搜索相关页面，阅读它们，并综合出一个带有引用的答案。根据问题的不同，答案可以采取不同形式 —— 一个 Markdown 页面、一个对比表格、一个幻灯片（Marp）、一个图表（matplotlib）、一个画布。重要的见解是：好的答案可以作为新页面归档回维基中。 你要求进行的对比、分析、你发现的联系 —— 这些都是有价值的，不应消失在聊天记录中。这样，你的探索就会像吸收的资料一样，在知识库中不断积累。

检查。 定期让 LLM 对维基进行健康检查。寻找：页面之间的矛盾、已被新资料取代的过时论断、没有入链的孤立页面、被提及但缺少独立页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。LLM 擅长提出值得探究的新问题和需要寻找的新资料。这能确保维基在增长过程中保持健康。

索引与日志

两个特殊文件帮助 LLM（和你）在维基增长时进行导航。它们用途不同：

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

log.md 是按时间顺序的。它是一个只能追加的记录，记录了发生的事情及时间 —— 吸收、查询、检查。一个有用的技巧：如果每个条目都以一致的前缀开头（例如 ## [2026-04-02] ingest | 文章标题），那么日志就可以用简单的 Unix 工具解析 —— grep "^## \[" log.md | tail -5 可以给你最后 5 个条目。日志为你提供了维基演进的时间线，并帮助 LLM 理解最近完成了哪些工作。

可选：CLI 工具

在某个时候，你可能会想要构建一些小工具，帮助 LLM 更高效地操作维基。在维基页面上进行搜索是最明显的一个 —— 在小规模下，索引文件就足够了，但随着维基的增长，你会需要真正的搜索功能。qmd 是一个不错的选择：它是一个针对 Markdown 文件的本地搜索引擎，具有混合 BM25/向量搜索和 LLM 重排序功能，全部在设备本地运行。它既有 CLI（因此 LLM 可以调用它），也有 MCP 服务器（因此 LLM 可以将其作为原生工具使用）。你也可以自己构建更简单的工具 —— 当需要时，LLM 可以帮助你凭感觉编写一个简单的搜索脚本。

技巧与窍门

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

为什么这有效

维护知识库最繁琐的部分不是阅读或思考 —— 而是记账。更新交叉引用、保持总结最新、注明新数据与旧论断的矛盾、在数十个页面之间保持一致性。人类放弃维基是因为维护负担的增长速度超过了其价值。LLM 不会感到无聊，不会忘记更新交叉引用，并且可以一次性处理 15 个文件。维基得以维护，因为维护成本几乎为零。

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

这个理念在精神上与 Vannevar Bush 的 Memex（1945 年）有关 —— 一个个人化的、精心策划的知识库，文档之间具有联想式轨迹。Bush 的愿景比后来互联网成为的样子更接近这个理念：私密的、主动策划的，文档之间的联系与文档本身一样有价值。他无法解决的部分是：谁来负责维护？LLM 承担了这部分工作。

注

本文档刻意保持抽象。它描述的是理念，而非具体实现。确切的目录结构、模式约定、页面格式、工具 —— 所有这些都取决于你的领域、你的偏好以及你选择的 LLM。上面提到的所有内容都是可选且模块化的 —— 选择有用的，忽略无用的。例如：你的资料可能只包含文本，因此你根本不需要处理图片。你的维基可能足够小，索引文件就足够了，不需要搜索引擎。你可能不关心幻灯片，只想要 Markdown 页面。你可能想要一套完全不同的输出格式。使用本文档的正确方式是：将其分享给你的 LLM 智能体，并一起协作，实例化一个符合你需求的版本。本文档的唯一工作就是传达这个模式。你的 LLM 可以搞定其余的事情。