LLM Wiki："想法文件" 知识管理范例

一种使用 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 这样的爱好者 wiki：数千个相互链接的页面涵盖人物、地点、事件和语言，由志愿者社区耗费数年构建而成。借助 LLM 完成交叉引用和维护，你在阅读过程中也可以为自己构建类似的东西。

企业或团队：由 LLM 维护的内部 wiki，以 Slack 讨论串、会议转录、项目文档和客户通话记录作为输入，也可以让人类参与审核更新。wiki 能够持续保持最新，是因为 LLM 承担了团队中无人愿意做的维护工作。

竞争分析、尽职调查、旅行规划、课程笔记、兴趣爱好的深度探索——任何需要长期积累知识，并希望知识得到有序组织而不是四处分散的场景，都适合这种模式。

它包含三个层次：

原始资料——由你精心挑选的源文档集合，包括文章、论文、图片和数据文件。这些内容不可变：LLM 可以读取，但绝不会修改。它们是你的事实来源。

wiki——一个存放 LLM 生成的 markdown 文件的目录，其中包括摘要、实体页面、概念页面、对比内容、概览和综合分析。这个层次完全由 LLM 负责。它会创建页面、在新资料加入时更新页面、维护交叉引用，并让所有内容保持一致。你负责阅读，LLM 负责写作。

schema——一份告诉 LLM 如何组织 wiki、遵循哪些约定，以及在摄取资料、回答问题或维护 wiki 时应采用什么工作流的文档，例如 Claude Code 使用的 CLAUDE.md，或 Codex 使用的 AGENTS.md。这是最关键的配置文件：正是它让 LLM 成为一名纪律严明的 wiki 维护者，而不是一个普通聊天机器人。随着你逐渐摸索出适合自己领域的方法，你和 LLM 会共同推动这份 schema 演进。

摄取。你将一份新资料放入原始资料集合，然后让 LLM 处理。一个示例流程是：LLM 阅读资料、与你讨论关键结论、在 wiki 中编写摘要页面、更新索引、更新整个 wiki 中相关的实体和概念页面，最后在日志中追加一条记录。单份资料可能影响 10～15 个 wiki 页面。就我个人而言，我更喜欢逐份摄取资料，并全程参与：阅读摘要、检查更新，并指导 LLM 应该突出哪些内容。不过，你也可以在较少监督的情况下，一次批量摄取多份资料。你需要自行设计符合个人习惯的工作流，并把它记录在 schema 中，供未来的会话使用。

查询。你基于 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 理解最近完成了哪些工作。

到了某个阶段，你可能会想构建一些小工具，帮助 LLM 更高效地操作 wiki。最显而易见的工具，是一个用于搜索 wiki 页面内容的搜索引擎。在规模较小时，索引文件已经足够；但随着 wiki 增长，你会需要真正的搜索能力。qmd 是一个不错的选择：它是一款面向 markdown 文件的本地搜索引擎，支持 BM25／向量混合搜索和 LLM 重排序，而且所有处理都在设备端完成。它既提供 CLI——让 LLM 可以通过 shell 调用，也提供 MCP server——让 LLM 可以将其作为原生工具使用。你也可以自行构建一个更简单的版本：需求出现时，让 LLM 帮你通过 vibe coding 编写一个朴素的搜索脚本即可。

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 的关系图视图是观察 wiki 形态的最佳方式：哪些内容相互连接、哪些页面是枢纽、哪些页面处于孤立状态。

Marp 是一种基于 markdown 的幻灯片格式，Obsidian 也有相应的插件。它适合直接根据 wiki 内容生成演示文稿。

Dataview 是一个 Obsidian 插件，可以针对页面 frontmatter 执行查询。如果你的 LLM 会为 wiki 页面添加 YAML frontmatter，例如标签、日期和资料数量，Dataview 就能生成动态表格和列表。

wiki 本质上只是一个由 markdown 文件组成的 git repo。版本历史、分支和协作能力都可以直接获得。

维护知识库最繁琐的部分，不是阅读，也不是思考，而是记录管理：更新交叉引用、让摘要保持最新、标记新数据与旧论断发生矛盾的地方，以及维持数十个页面之间的一致性。人们之所以放弃 wiki，是因为维护负担的增长速度超过了它所带来的价值。LLM 不会感到厌倦，不会忘记更新交叉引用，而且可以在一次处理中修改 15 个文件。wiki 能够持续得到维护，是因为维护成本几乎降到了零。

人类的工作是筛选资料、引导分析、提出好问题，以及思考这一切意味着什么。其余所有工作，都属于 LLM。

从精神内核上看，这一想法与 Vannevar Bush 在 1945 年提出的 Memex 有关：一个由个人精心整理的知识存储系统，文档之间通过关联路径相连。相比后来真正形成的 Web，Bush 的愿景其实更接近这里描述的模式：私有、主动维护，而且文档之间的联系与文档本身同样有价值。他当时无法解决的问题是：由谁负责维护。如今，LLM 可以承担这项工作。

本文有意保持抽象。它描述的是一种思路，而非某个具体实现。确切的目录结构、schema 约定、页面格式和工具链，都取决于你的领域、个人偏好，以及你选择的 LLM。上面提到的一切都可以按需选用和自由组合：选择有用的部分，忽略无用的部分。例如，你的资料可能只有文本，因此完全不需要处理图片；你的 wiki 规模可能很小，只使用索引文件就足够了，不需要搜索引擎；你可能并不关心幻灯片，只想要 markdown 页面；你也可能需要一套完全不同的输出格式。正确的使用方式，是把这份文档分享给你的 LLM Agent，然后与它共同把这个想法实例化成一个适合你需求的版本。本文唯一的任务，就是传达这种模式。其余部分，你的 LLM 自然能够解决。