LLM Wiki 详细解读与实践

公众号名称：方圆AI分享

作者名称：方圆yo

发布时间：2026-04-13 20:00

前几天，AI 领域的大神 Andrej Karpathy 在 X（原 Twitter）上连发了两条推文，引发了非常大的关注和讨论。

第一条推文 LLM Knowledge Bases[1] 分享了他最近用 LLM 构建个人知识库的经验，引发了大量转发和讨论。

紧接着他又发了一条后续 Idea File 推文[2]，不仅对第一条做了补充，还开源了一份详细的 Idea File（Gist）[3]，把整套思路系统地梳理了出来。

读完之后，我觉得这套思路非常值得展开聊一聊。

很多人用 LLM 做知识管理，通常停留在”问一个问题，得到一个回答”的阶段。

Karpathy 正在做的事情，可以说从根本上改变了这个模式。他把 LLM 的主要工作从”写代码”转向了”管理知识”，让 LLM 成为一个不知疲倦的知识管理员，自动维护一套持续生长的 wiki 知识体系。

这篇文章会详细拆解这套方法的核心思想、实现架构和具体操作流程，读完之后你完全可以动手搭建自己的版本。

从 RAG 到知识编译：一个根本性的思路转变

大多数人接触 LLM 知识库的方式是 RAG（检索增强生成）。你上传一批文档，LLM 在你提问时检索相关片段，拼凑出一个回答。NotebookLM、ChatGPT 的文件上传、各种 RAG 系统，基本都是这个模式。

这个模式能用，但有一个核心问题：LLM 每次回答问题都是从零开始重新发现知识。知识没有积累，没有沉淀。

你今天问了一个需要综合五篇文档才能回答的复杂问题，LLM 费力地找到了相关片段并拼出了答案。明天你问一个类似的问题，它又要重新来过一遍。什么都没有”建立”起来。

Karpathy 的做法走了一条完全不同的路。他让 LLM 增量式地构建和维护一个持久化的 wiki。这个 wiki 是一组结构化的、互相链接的 Markdown 文件，存在于你和原始资料之间。

当你加入一份新的资料时，LLM 不只是把它丢进索引等着以后检索。它会真正地阅读这份资料，提取关键信息，然后把这些信息整合到现有的 wiki 中。更新实体页面、修订主题摘要、标注新数据和旧结论之间的矛盾、强化或挑战正在演进中的综合分析。

这里最关键的区别在于：wiki 是一个持久的、不断积累的产物。交叉引用已经建好了，矛盾之处已经被标记了，综合分析已经反映了你读过的所有内容。

每加入一份新资料、每问一个新问题，wiki 都会变得更丰富。知识被编译了一次，然后持续保持更新，而不是每次查询都重新推导。

Karpathy 自己的 wiki 已经积累到大约 100 篇文章、40 万字 的规模。在这个规模上，他可以向 LLM 提出各种复杂的问题，LLM 会去 wiki 中研究并找到答案。

他原以为需要用到复杂的 RAG 基础设施，但实际上 LLM 通过自动维护索引文件和文档摘要，在这个规模下就能相当顺畅地找到并阅读所有相关资料。

三层架构：原始资料、Wiki 和 Schema

这套系统的架构分为三个清晰的层次。

第一层是原始资料（Raw Sources）。这是你精心策划的源文档合集，包括文章、论文、图片、数据文件等等。这些资料是不可变的，LLM 只从中读取，永远不会修改它们。这一层是你的事实来源。

第二层是 Wiki。这是一个由 LLM 生成的 Markdown 文件目录。里面包含摘要、实体页面、概念页面、对比分析、概览、综合分析等各种类型的文档。

LLM 完全拥有这一层。它创建页面，在新资料到来时更新页面，维护交叉引用，保持所有内容的一致性。你负责阅读它，LLM 负责编写它。

第三层是 Schema。这是一份配置文档（比如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM wiki 的结构是怎样的、有哪些约定、在摄入资料时遵循什么工作流、回答问题时如何操作、维护 wiki 时该做什么。

这份文档是让 LLM 变成一个有纪律的 wiki 维护者的关键，否则它只是一个通用聊天机器人。你和 LLM 会随着时间推移共同演进这份 Schema，逐步摸索出最适合你的领域的规则。

把这三层放在一起看，原始资料提供事实基础，wiki 承载编译后的知识，schema 则定义了 LLM 如何在两者之间工作。

整个系统就像一个代码工程：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。你几乎从不手动编写或编辑 wiki，那是 LLM 的领地。你负责的是寻找好的资料来源、探索方向、提出正确的问题。

三大核心操作：摄入、查询与审查

在日常使用中，这套系统有三种核心操作。

第一种是摄入（Ingest）。你把一份新的资料放进 raw 目录，然后告诉 LLM 去处理它。

一个典型的流程是这样的：LLM 读取资料，和你讨论关键要点，在 wiki 中写一篇摘要页面，更新索引，更新整个 wiki 中相关的实体页面和概念页面，并在日志中追加一条记录。

处理一份资料可能会触及 10 到 15 个 wiki 页面。Karpathy 个人倾向于一次摄入一份资料并全程参与，他会阅读摘要、检查更新内容，引导 LLM 强调什么、忽略什么。

当然你也可以一次批量摄入很多资料，减少干预。关键是你需要根据自己的风格发展出适合自己的工作流，并把它记录在 schema 里供后续会话使用。

第二种是查询（Query）。你对 wiki 提问，LLM 搜索相关页面，阅读它们，然后综合出一个带引用的答案。

答案可以有很多不同的形式，具体取决于问题的类型。可以是一个 Markdown 页面，可以是一张对比表格，可以是一套幻灯片（Marp 格式），可以是一张 matplotlib 图表，也可以是一幅画布。

这里有一个重要的洞察：好的回答可以被归档回 wiki，成为新的页面。你要求做的对比分析、你发现的某个关联、一次深入的探索，这些都很有价值，不应该消失在聊天记录里。

通过这种方式，你的探索和提问也在知识库中不断积累，就像摄入新资料一样产生复合效应。

第三种是审查（Lint）。定期让 LLM 对 wiki 做一次健康检查。

检查的内容包括：页面之间的矛盾、被更新资料取代的过时结论、没有入站链接的孤立页面、被多处提及但缺少独立页面的重要概念、缺失的交叉引用、可以通过网络搜索填补的数据空白。

LLM 很擅长发现这些问题，也善于建议新的研究方向和值得探索的问题。这种审查机制让 wiki 在不断增长的同时保持健康。

索引与日志：让 LLM 高效导航的两个关键文件

随着 wiki 规模增长，有两个特殊文件帮助 LLM（和你）高效地导航整个知识库。它们各自承担不同的功能。

index.md 是面向内容的。它是 wiki 中所有页面的目录，每个页面附带一个链接、一行摘要，以及可选的元数据（如日期或来源数量）。按类别组织（实体、概念、来源等）。

LLM 在每次摄入新资料时都会更新它。当需要回答一个查询时，LLM 首先读取索引来找到相关页面，然后再深入阅读具体内容。

在中等规模（大约 100 份来源、几百个页面）下，这种方式效果出奇地好，完全不需要基于向量嵌入的 RAG 基础设施。

log.md 是按时间顺序的。它是一份只追加的记录，记载了什么事情在什么时候发生，包括资料摄入、查询、审查等。

一个有用的技巧是：如果每条记录都以一致的前缀开头（比如 ## [2026-04-02] ingest | Article Title），那么这份日志就可以用简单的命令行工具来解析。比如 grep "^## \[" log.md | tail -5 就能看到最近 5 条记录。

日志给出了 wiki 演进的时间线，也帮助 LLM 了解最近做过哪些操作。

这两个文件的设计非常巧妙。索引让 LLM 知道”有什么”，日志让 LLM 知道”发生了什么”。

前者用于定位知识，后者用于理解上下文。两者结合，LLM 就能在不依赖复杂检索系统的情况下，有效地在一个数十万字的知识库中工作。

可选工具：当 Wiki 长大后

当 wiki 增长到一定规模，你可能会想构建一些小工具来帮助 LLM 更高效地操作它。最明显的就是一个 wiki 搜索引擎。

在小规模下，索引文件已经够用了，但随着 wiki 变大，你需要真正的搜索能力。

Karpathy 提到了 qmd[4] 这个工具，它是一个本地的 Markdown 文件搜索引擎，支持混合 BM25/向量搜索和 LLM 重排序，全部在本地运行。

它既有命令行接口（让 LLM 可以通过 shell 调用），也有 MCP 服务器（让 LLM 可以把它当作原生工具使用）。当然你也可以自己搞一个更简单的。

Karpathy 自己就 vibe coded 了一个简单的搜索引擎，有一个 web 界面可以直接使用，但更多时候他把它作为命令行工具交给 LLM 在更大的查询中调用。

除了搜索，Karpathy 还提到了输出格式的多样化。他不喜欢在终端里看文本形式的回答，而是让 LLM 渲染成 Markdown 文件、Marp 格式的幻灯片、matplotlib 图表，然后在 Obsidian 里查看。

你可以根据自己的需求想象更多的可视化输出格式。

让 Obsidian 成为你的知识库 IDE

在工具链方面，Karpathy 选择了 Obsidian 作为前端 IDE，用来查看原始资料、编译后的 wiki 以及各种衍生的可视化内容。

这个选择并非偶然，Obsidian 的几个特性让它非常适合这个场景。

Obsidian Web Clipper 是一个浏览器扩展，可以把网页文章转换为 Markdown 格式。这对于快速把各种来源收集到 raw 目录里非常方便。

图片本地化也值得注意。在 Obsidian 的设置中，把附件文件夹路径设置为一个固定目录（比如 raw/assets/），然后给”下载当前文件的附件”功能绑定一个快捷键。剪藏一篇文章后按一下快捷键，所有图片就会下载到本地。

这样 LLM 就可以直接查看和引用图片，而不必依赖可能失效的 URL。

需要注意的是，LLM 目前还不能在一次处理中同时读取 Markdown 文本和内嵌图片。变通的办法是让 LLM 先读文本，再单独查看部分或全部引用的图片来获取额外的上下文。有些笨拙，但够用。

Obsidian 的图谱视图是查看 wiki 整体形态的最佳方式，可以直观地看到哪些页面之间有连接、哪些页面是中心节点、哪些页面是孤立的。

Marp 是一种基于 Markdown 的幻灯片格式，Obsidian 有对应的插件，可以直接从 wiki 内容生成演示文稿。Dataview 则是另一个有用的插件，它可以对页面的 YAML frontmatter 运行查询。

如果你的 LLM 在 wiki 页面中添加了标签、日期、来源数量等 frontmatter，Dataview 就可以生成动态的表格和列表。

还有一个不容忽视的优势：整个 wiki 本质上就是一个 Markdown 文件的 git 仓库。版本历史、分支、协作，你免费就得到了这些能力。

为什么这套方法真的有效

维护知识库最让人头疼的部分，从来都不是阅读和思考，而是那些琐碎的管理工作。

更新交叉引用、保持摘要与最新内容同步、标注新数据和旧结论之间的冲突、在几十个页面之间维护一致性。人类会放弃 wiki，因为维护负担的增长速度总是快于它带来的价值。

LLM 不会觉得无聊，不会忘记更新一个交叉引用，而且可以在一次操作中同时修改 15 个文件。wiki 之所以能持续被维护，是因为维护的成本接近于零。

在这个协作模式中，人类的工作是策划来源、指导分析方向、提出好的问题、思考这一切意味着什么。

LLM 的工作是其他所有事情：摘要、交叉引用、归档、记录，这些让知识库随着时间推移真正发挥作用的繁重劳动。

这其实和 1945 年 Vannevar Bush 提出的 Memex 概念一脉相承。Memex 设想的是一个私人策划的知识存储系统，文档之间有关联性的路径。

Bush 的愿景其实更接近于 Karpathy 描述的这个系统，而不是后来互联网真正变成的样子。它是私有的，主动维护的，文档之间的连接和文档本身一样有价值。

Bush 当年解决不了的那个问题是：谁来做维护工作？现在 LLM 可以。

应用场景远比你想的广

这套方法可以应用到非常多的场景中。

做个人成长和自我管理，你可以把日记、文章、播客笔记、健康数据等归档进去，LLM 帮你逐步构建出一幅关于自己的结构化全景图，追踪目标、心理状态和改进方向。

做深度研究，你可以花几周甚至几个月时间深入一个主题，阅读论文、文章、报告，LLM 帮你增量式地构建一个全面的 wiki，里面有一个不断演进的核心论点。

读一本书，你可以逐章归档，LLM 帮你建立角色页面、主题页面、情节线索页面，以及它们之间的关联。

读完之后你就有了一部丰富的伴读 wiki。想想像 Tolkien Gateway 那样的粉丝 wiki，上千个相互链接的页面，覆盖角色、地点、事件、语言，由志愿者社区花了好多年构建而成。现在你可以在阅读过程中借助 LLM 独自完成类似的事情。

做团队或企业知识管理，可以用 LLM 维护一个内部 wiki，数据来源是 Slack 讨论、会议记录、项目文档、客户通话。可以让人类参与审核更新。

wiki 之所以能保持最新，是因为 LLM 承担了团队里没有人愿意做的那些维护工作。

竞品分析、尽职调查、旅行规划、课程笔记、兴趣爱好深挖，任何你需要随时间积累知识并希望它们被有条理地组织起来的场景，都适用。

Idea File：LLM 时代的新分享方式

Karpathy 在这件事上还做了一个有趣的尝试。他没有分享具体的代码或应用，而是分享了一份 idea file。

他的观点是：在 LLM Agent 时代，分享具体代码的意义在降低。你只需要分享想法，然后让对方的 Agent 根据具体需求来定制和构建。

所以他把 LLM Wiki 的核心理念写成了一份 gist，这份文档被刻意保持在一定的抽象程度上。它描述的是模式（pattern），而不是具体实现。

确切的目录结构、schema 约定、页面格式、工具选择，这些都取决于你的领域、偏好和使用的 LLM。文档提到的一切都是可选的、模块化的。

你的资料可能全是纯文本，那就不需要图片处理。你的 wiki 可能规模很小，索引文件就足够了，不需要搜索引擎。你可能不关心幻灯片，只想要 Markdown 页面。

正确的使用方式是：把这份 idea file 交给你的 LLM Agent，和它一起根据你的需求来实例化一个适合你的版本。

文档的唯一职责是传达这个模式，你的 LLM 能搞定剩下的。

这本身就是一个很有启发性的观点。当 LLM 足够强大时，交流想法的粒度可以变得更高。

你不需要给出每一个实现细节，只需要把核心模式和关键约束讲清楚，剩下的让每个人和自己的 Agent 去适配。

动手实践：从零开始搭建你的 LLM Wiki

如果你看完想要自己试试，这里梳理一下完整的实践路径。

首先，创建项目目录。建立一个文件夹作为整个知识库的根目录，里面至少包含三个子目录：raw/ 存放原始资料，wiki/ 存放 LLM 生成的 wiki 页面，以及一个 schema 文件（如 CLAUDE.md 或 AGENTS.md）来定义 LLM 的工作规则。

用 git 初始化这个目录，这样你就自动获得了版本管理。

然后，配置 Obsidian。用 Obsidian 打开这个项目目录，安装 Web Clipper 浏览器扩展用于剪藏网页。在设置中把附件文件夹指向 raw/assets/，给”下载当前文件附件”绑定快捷键。

如果需要幻灯片功能就安装 Marp 插件，需要动态表格就安装 Dataview 插件。

接下来，编写 Schema。这是最关键的一步。

在 schema 文件中，你需要定义以下内容：wiki 的目录结构约定（比如 wiki/entities/、wiki/concepts/、wiki/sources/ 等分类方式）；摄入工作流（LLM 处理新资料时应该做哪些步骤）；索引维护规则（index.md 的格式和更新时机）；日志记录规则（log.md 的格式）；页面格式约定（frontmatter 应该包含哪些字段、链接如何组织等）。

这份 schema 不需要一步到位，你会在使用过程中和 LLM 一起不断完善它。

然后就可以开始第一次摄入了。把一篇文章或一份资料放进 raw/ 目录，告诉你的 LLM Agent 按照 schema 中定义的流程来处理它。

检查 LLM 生成的摘要页面、索引更新和日志记录是否符合你的预期。如果不满意，调整 schema 后重试。

从这里开始，就是一个持续的循环：摄入新资料、对 wiki 提问、定期做审查、在使用中完善 schema。

随着 wiki 的增长，你会自然地发现需要搜索工具、更精细的分类体系或新的输出格式，到那时再按需扩展。