中文 | English

LLM Wiki

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

这是一份想法文档，设计出来就是为了复制给你自己的 LLM Agent（例如 OpenAI Codex、Claude Code、OpenCode / Pi 等）。它的目标是传达高层思路，而你的 agent 会和你协作，把具体实现细节补出来。

核心想法

大多数人对 LLM 和文档的使用体验都类似 RAG：你上传一批文件，LLM 在提问时检索相关片段，再生成答案。这种方式可以工作，但 LLM 每次都要从头重新发现知识。知识不会沉淀。只要问题稍微细一点、需要综合五份文档，LLM 就得每次重新找到并拼接相关片段。什么都没有累积起来。NotebookLM、ChatGPT 文件上传，以及大多数 RAG 系统基本都属于这种模式。

这里的想法不同。它不是在提问时只从原始文档里检索，而是让 LLM 增量地构建并维护一个持久化 wiki。这个 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：一个文档（例如 Claude Code 用的 CLAUDE.md，或者 Codex 用的 AGENTS.md），告诉 LLM wiki 是怎么组织的、有哪些约定，以及在 ingest 来源、回答问题、维护 wiki 时应该遵循什么工作流。这是关键配置文件。正是它让 LLM 变成一个有纪律的 wiki 维护者，而不是一个泛化聊天机器人。你和 LLM 会随着实践不断共同演化这份 schema。

操作

Ingest。 你把一个新来源丢进原始资料层，然后让 LLM 去处理它。一个典型流程是：LLM 读取来源，和你讨论关键收获，在 wiki 里写一个摘要页，更新索引，更新相关的实体页和概念页，并往日志里追加一条记录。单个来源可能会触及 10 到 15 个 wiki 页面。就我个人来说，我更喜欢一次 ingest 一个来源，并且保持自己在环：我会读摘要、检查更新，并指导 LLM 应该强调什么。但你也可以选择一次批量 ingest 很多来源，减少监督。工作流完全可以按你的风格来演化，然后写进 schema，供未来会话使用。

Query。 你向 wiki 提问。LLM 搜索相关页面，读取它们，并带着引用给出综合答案。答案的形式可以很多样：markdown 页面、比较表格、幻灯片（Marp）、图表（matplotlib）、canvas。这里最重要的洞见是：好的答案应该回写进 wiki，成为新页面。 你问出来的比较、分析、发现的联系，本身就很有价值，不应该消失在聊天记录里。这样，你的探索过程会像 ingest 的来源一样，继续在知识库里复利。

Lint。 定期让 LLM 对 wiki 做健康检查。要找的问题包括：页面之间的矛盾、被新来源取代但仍未更新的旧结论、没有入链的孤儿页、频繁被提到却没有自己页面的重要概念、缺失的交叉引用、以及可以通过网络搜索补齐的数据缺口。LLM 很擅长建议下一个值得调查的问题，以及下一份该找的来源。这样 wiki 在增长过程中就能保持健康。

索引与日志

有两个特殊文件能帮助 LLM（也帮助你）在 wiki 变大后继续导航。它们承担不同职责：

index.md 面向内容。它是整个 wiki 的目录：列出每个页面、链接、简短摘要，以及可选的元数据，例如日期或来源数。通常按类别组织（实体、概念、来源等）。LLM 每次 ingest 都应更新它。回答问题时，LLM 先读索引，找到相关页面，再深入阅读。这种做法在中等规模下（约 100 个来源、数百个页面）已经非常有效，而且不需要额外的 embedding/RAG 基础设施。

log.md 面向时间。它是一个追加式记录，写明发生了什么、什么时候发生：ingest、query、lint pass。一个很实用的小技巧是：如果每条记录都以一致的前缀开头（例如 ## [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 server（所以 LLM 可以把它当作原生工具来用）。当然你也可以先做个简单点的版本，LLM 本身就能帮你很快写一个朴素搜索脚本。

Tips and tricks

• Obsidian Web Clipper 是一个浏览器扩展，可以把网页文章转成 markdown。对快速把来源拉进 raw 层非常有用。
• 把图片下载到本地。 在 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 的 graph view 是观察 wiki 形状的最好方式：哪些东西互相连接、哪些页面是枢纽、哪些页面是孤儿。
• Marp 是一种基于 markdown 的幻灯片格式，Obsidian 有插件。它很适合直接从 wiki 内容生成演示文稿。
• Dataview 是 Obsidian 的一个插件，可以对页面 frontmatter 运行查询。如果你的 LLM 给 wiki 页面加了 YAML frontmatter（标签、日期、来源数等），Dataview 就可以生成动态表格和列表。
• 这个 wiki 本质上就是一个 markdown git 仓库。版本历史、分支和协作能力都是现成的。

为什么这会起作用

维护知识库最繁琐的部分，不是阅读，也不是思考，而是簿记工作：更新交叉引用、保持摘要最新、标注新数据与旧结论冲突、让几十个页面保持一致。人类放弃 wiki，往往不是因为 wiki 没价值，而是因为维护成本增长得比价值还快。LLM 不会无聊，不会忘记补一个交叉引用，也可以一次性改 15 个文件。wiki 能被持续维护，是因为维护成本几乎为零。

人的工作是策展来源、引导分析、提出好问题，并思考这些东西到底意味着什么。LLM 的工作是剩下的一切。

这个想法在精神上和 Vannevar Bush 于 1945 年提出的 Memex 很接近：一个带有关联轨迹的个人化知识存储。Bush 的愿景其实比今天的 web 更接近这个方向：私有、经过主动策展，而且文档之间的连接本身和文档一样重要。他当时解决不了的问题是：谁来做维护。现在 LLM 可以承担这部分。

注

这份文档有意保持抽象。它描述的是这个想法，而不是某个唯一的实现方案。具体目录结构、schema 约定、页面格式、工具链，全都取决于你的领域、偏好和所用的 LLM。上面提到的一切都是可选和模块化的，取有用的，忽略不适合的即可。比如：如果你的来源全是纯文本，那你根本不需要图片处理。你的 wiki 也许足够小，索引文件就完全够用，不需要搜索引擎。你可能完全不关心幻灯片，只想要 markdown 页面。你也可能想要一套完全不同的输出格式。正确的使用方式就是：把这份文档交给你的 LLM agent，然后一起把它具体化成适合你的版本。这份文档唯一的工作，就是把模式讲清楚。其余实现细节，你的 LLM 可以和你一起想出来。