LLM Wiki：用大语言模型构建个人知识库
介绍一种用 LLM 构建和维护个人 Wiki 的方法，让大语言模型从 RAG 检索工具变成知识库的主动维护者。
本文翻译整理自 LLM Wiki，原文是一份关于用 LLM 构建个人知识库的理念文档。
大多数人使用 LLM 处理文档的方式像 RAG：上传一堆文件，LLM 在提问时检索相关片段，然后生成回答。这种方式能用，但有个根本问题——每次提问 LLM 都是从零开始理解知识，没有任何积累。问一个需要综合五篇文档的微妙问题，LLM 每次都得重新找到并拼凑相关片段。Nothing is built up.
LLM Wiki 的思路不同。LLM 不只是在查询时检索原始文档，而是增量构建和维护一个持久化的 Wiki——一组结构化的、互相引用的 Markdown 文件，位于你和原始资料之间。
当你添加一份新资料时，LLM 不只是索引它以备检索。它会阅读资料、提取关键信息，并整合到现有 Wiki 中——更新实体页面、修订主题摘要、标注新数据与旧结论的矛盾、强化或挑战正在演化的综合结论。知识被编译一次，然后持续保持最新，而不是每次查询都重新推导。
关键区别：Wiki 是一个持久的、不断积累的产物。 交叉引用已经就位，矛盾已经被标注，综合结论已经反映了所有读过的内容。你每添加一份资料、每提一个问题，Wiki 都会变得更丰富。
你几乎不需要自己写 Wiki——LLM 负责编写和维护所有内容。你负责的是选材、探索和提出正确的问题。LLM 干的是苦力活——总结、交叉引用、归档和记账，这些让知识库真正有用的工作。实际使用中，一边开着 LLM Agent，另一边开着 Obsidian。LLM 基于对话编辑内容，你实时浏览结果——跟踪链接、查看图谱视图、阅读更新后的页面。Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。
这个方法适用范围很广：
- 个人成长：追踪目标、健康、心理、自我提升——归档日记、文章、播客笔记，逐步构建关于自己的结构化画像
- 深度研究：围绕一个主题持续数周或数月——阅读论文、文章、报告，增量构建一个有演化论文的综合 Wiki
- 读书笔记：逐章归档，为角色、主题、情节线和它们的关联构建页面。最终你会得到一个丰富的伴随 Wiki，类似 Tolkien Gateway 这样的粉丝百科
- 团队/企业：由 LLM 维护的内部 Wiki，由 Slack 讨论串、会议记录、项目文档、客户通话等喂养
- 竞品分析、尽职调查、旅行规划、课程笔记、兴趣深挖——任何需要随时间积累知识并保持有序的场景
原始资料层 — 你精心策展的源文档集合。文章、论文、图片、数据文件。它们是不可变的——LLM 只读不改。这是你的信息源头。
Wiki 层 — 由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、对比、概览、综合。LLM 完全拥有这一层。它创建页面、在新资料到来时更新、维护交叉引用、保持一切一致。你读它，LLM 写它。
Schema 层 — 一份文档（比如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM Wiki 的结构是什么、约定是什么、在摄取资料、回答问题或维护 Wiki 时应该遵循什么工作流。这是关键配置文件——它让 LLM 成为一个有纪律的 Wiki 维护者，而不是一个通用聊天机器人。你和 LLM 会随着时间共同演化这份配置。
把新资料丢进原始资料集合，告诉 LLM 处理它。典型流程：LLM 阅读资料 → 与你讨论要点 → 在 Wiki 中写摘要页 → 更新索引 → 更新相关实体和概念页面 → 在日志中追加记录。一份资料可能涉及 10-15 个 Wiki 页面。
我个人偏好一次摄取一份资料并保持参与——阅读摘要、检查更新、引导 LLM 该强调什么。但也可以批量摄取多份资料，减少干预。关键是发展出适合你风格的工作流，并把它记录在 Schema 中供后续使用。
你向 Wiki 提问。LLM 搜索相关页面、阅读它们、综合出带引用的回答。回答形式取决于问题——Markdown 页面、对比表格、幻灯片（Marp）、图表（matplotlib）、画布。
重要洞察：好的回答可以作为新页面存回 Wiki。 你请求的对比分析、你发现的关联——这些都是有价值的，不应该消失在聊天记录里。这样你的探索也会像摄取的资料一样在知识库中积累。
定期让 LLM 对 Wiki 做健康检查。检查项包括：
- 页面间的矛盾
- 被新资料替代的过时结论
- 没有入站链接的孤立页面
- 被提及但缺少独立页面的重要概念
- 缺失的交叉引用
- 可以通过网络搜索填补的数据空白
LLM 很擅长建议新的调查方向和新的资料来源。这能保持 Wiki 随着增长而健康。
两个特殊文件帮助 LLM（和你）导航不断增长的 Wiki：
index.md 是内容导向的。它是 Wiki 的目录——每个页面附带链接、一句话摘要，可选地包含日期、来源数量等元数据。按类别组织（实体、概念、来源等）。LLM 在每次摄取时更新它。回答查询时，LLM 先读索引找到相关页面，再深入阅读。在中等规模（约 100 份资料、数百个页面）下效果出奇地好，无需基于嵌入的 RAG 基础设施。
log.md 是时间导向的。它是只追加的操作记录——摄取、查询、检查。小技巧：如果每条记录以统一前缀开头（如 ## [2026-04-02] ingest | 文章标题），日志可以用简单的 Unix 工具解析——grep "^## \[" log.md | tail -5 就能获取最近 5 条记录。
- qmd：本地 Markdown 搜索引擎，混合 BM25/向量搜索 + LLM 重排，支持 CLI 和 MCP Server
- Obsidian Web Clipper：浏览器扩展，将网页文章转为 Markdown，方便快速摄取资料
- Obsidian Graph View：查看 Wiki 的连接结构，发现中心节点和孤立页面
- Marp：基于 Markdown 的幻灯片格式，可直接从 Wiki 内容生成演示文稿
- Dataview：Obsidian 插件，基于页面 frontmatter 运行查询，生成动态表格和列表
- Wiki 本身就是一个 Git 仓库，版本历史、分支、协作都是免费的
维护知识库最枯燥的部分不是阅读或思考——而是记账。更新交叉引用、保持摘要最新、标注新数据与旧结论的矛盾、在几十个页面间保持一致。人类放弃 Wiki 是因为维护负担增长得比价值还快。
LLM 不会厌倦，不会忘记更新交叉引用，一次可以处理 15 个文件。Wiki 能保持维护状态，因为维护成本接近于零。
人类的工作是策展资料、引导分析、提出好问题、思考这一切意味着什么。LLM 的工作是其他一切。
这个想法在精神上与 Vannevar Bush 的 Memex（1945）相关——一个私人的、策展过的知识存储，文档间有联想路径。Bush 的愿景更接近这个而非互联网的现状：私有的、主动策展的、文档间的连接和文档本身一样有价值。他无法解决的问题是：谁来做维护？LLM 可以。
✅ Wiki 是持久的、不断积累的知识产物，不是每次查询都从零推导
✅ 三层架构：原始资料（不可变）→ Wiki（LLM 维护）→ Schema（工作流配置）
✅ 三种核心操作：摄取、查询、检查，形成知识管理闭环
✅ 人类负责策展和提问，LLM 负责一切维护工作
✅ 适用场景广泛：个人知识管理、研究、读书笔记、团队协作等
- AI 编程入门指南 - 讲解如何高效使用 AI 辅助编程，从 AGENTS.md 编写到工作流实践