Karpathy 最新分享：用 LLM 搭建你的个人知识库，让 AI 帮你「养」一座活的 Wiki

开头说几句

Andrej Karpathy 又整活了。

这次他没讲 Transformer 原理，没讲训练技巧，而是在 GitHub Gist 上安静地发了一篇不到两千字的短文，标题叫 LLM Wiki。讲的是一件很朴素的事：怎么让大语言模型帮你维护一个私人知识库。

读完之后我挺上头的。上头的原因是，他把我一直隐隐约约在做、但从来没系统化想清楚的事情，用极其清晰的架构语言说明白了。

于是有了这篇文章。

我打算把 AK 的原文完整翻译一遍，然后在每个关键节点做深度展开——加背景、加场景、加实操细节、加我自己的理解。目标是让你看完之后，能直接动手搭一个自己的 LLM Wiki。

准备好了？我们开始。

现有方案的问题：每次都从零开始

先回到大多数人使用 LLM 处理文档的日常场景——RAG（检索增强生成）。

你把一堆文件丢给某个工具，比如 NotebookLM、ChatGPT 的文件上传功能，或者任何一个 RAG 系统。你提问，它从文件里检索相关片段，拼凑出答案。

这套流程能用，但它的核心问题是：每一次提问，LLM 都在从头发现知识。

打个比方。你有一个复杂的研究课题，涉及五份论文、三份报告和两个数据集。你问了一个需要交叉综合的问题。RAG 系统要在这次对话里现找、现读、现拼。下次你再问一个类似的问题，它又得重新来一遍。什么都没有积累下来。没有任何东西被"修建"过。

NotebookLM 是这样，ChatGPT 的文件上传是这样，绝大多数 RAG 方案都是这样。

问题出在"知识是消耗品"这个隐含假设上。 每次查询都像一次性筷子——用完就扔。上次的推理过程、交叉引用关系、发现的矛盾点、形成的综合判断，全部消失在聊天历史里。

AK 的解法：让 LLM 养一座 Wiki

AK 提出的方案完全不同。

他的核心想法用一句话概括：让 LLM 增量式地构建并维护一个持久的 Wiki——一套结构化、互相关联的 Markdown 文件集合，夹在你和原始资料之间。

当你添加一份新资料时，LLM 做的事情远超"索引以备后用"。它读这份资料，提取关键信息，然后把新知识整合进已有的 Wiki——更新实体页面、修订主题摘要、标注新数据与旧结论之间的矛盾、强化或挑战正在形成的综合判断。

知识被编译一次，然后持续保持最新，不再每次查询时重新推导。

这是一个根本性的差异。

这到底意味着什么？

传统 RAG 的隐喻是"图书馆"——书在那里，你每次去翻。AK 的 Wiki 则是一个"活的研究项目"——每读一篇新论文，研究笔记就会更新，引用网络会重建，你的整体理解会迭代。

把这个区别具体化：

维度
传统 RAG
LLM Wiki

知识状态
每次查询从零开始
持续积累、增量更新

交叉引用
实时检索拼凑
预先建立并持续维护

矛盾检测
几乎不存在
摄入新资料时自动标注

综合判断
临时生成
作为 Wiki 页面持久化

可浏览性
只能通过对话访问
Markdown 文件可独立浏览

AK 原文中有一句话特别精准：

Wiki 是一个持久的、复利式的制品。 交叉引用已经在那儿了。矛盾已经被标记了。综合判断已经反映了你读过的所有东西。每添加一份资料、每问一个问题，这个 Wiki 都在变得更丰富。

我觉得"复利式"这三个字是这套方案最核心的价值主张。知识不再被消费，而是被投资。每一次摄入、每一次提问，都是在给这个知识体增值。

你在这个系统里扮演什么角色？

一个值得注意的设计选择：你自己几乎不写 Wiki，或者很少写。所有内容都是 LLM 写的、LLM 维护的。

你的角色是：

• 策展人——找到好的资料源
• 探索者——提出好的问题
• 方向盘——决定关注什么、深挖什么、忽略什么

LLM 则包揽了所有苦力活——摘要、交叉引用、归档、记账。这些事情是一个知识库能长期保持有用的关键，但也是人类最容易放弃的部分。

AK 自己的工作方式是：一侧开着 LLM Agent（比如 Claude Code 或 Codex），另一侧开着 Obsidian。LLM 根据对话编辑 Wiki 文件，他在 Obsidian 里实时浏览更新——点链接、看图谱、读刚生成的页面。

他用了一个很妙的类比：

Obsidian 是 IDE；LLM 是程序员；Wiki 是代码库。

如果你写过代码，这个类比一下就通了。你不用亲手搬每一块砖，但你得知道房子长什么样。

这套方案适合什么场景？

AK 列了几个方向，我展开说说每个的实际意义：

个人成长

追踪你自己的目标、健康、心理状态、自我提升。把日记条目、读过的文章、播客笔记、课程笔记都喂进去，慢慢建立一个结构化的"自我画像"。

这个场景的杀手级特性是面向自己的纵向分析。三个月前你对某件事的看法、半年前你的健康指标变化趋势、你反复出现的思维模式——这些东西散落在各种笔记里时毫无价值，但被 Wiki 结构化之后，就成了一面镜子。

深度研究

花几周甚至几个月深入一个课题——读论文、读报告、读行业分析，同时让 LLM 增量式地构建一个全面的 Wiki，包含一条不断演化的核心论点。

做过学术研究的人都懂那种痛：读了五十篇论文，脑子里其实只记得最近读的两三篇。早期读的那些，内容已经模糊了。交叉引用关系？全凭记忆。这个 Wiki 方案直接解决了知识衰减问题——你读过的每一篇都活在 Wiki 里，你对它的理解也活在那里。

读一本书

边读边录入每一章，为角色、主题、情节线索建 Wiki 页面，记录它们之间的关联。读完整本书后，你手里有一个丰富的伴读 Wiki。

AK 举了一个很直观的例子：想想 Tolkien Gateway——几千个互相链接的页面，覆盖角色、地点、事件、语言，由社区志愿者花了好几年建起来。你可以在读书过程中个人搭一个类似的东西，LLM 负责所有交叉引用和维护工作。

一个人 + 一个 LLM = 一个粉丝社区几年的产出。这个效率提升惊人。

团队/商业场景

一个由 LLM 维护的内部 Wiki，数据来源是 Slack 对话、会议记录、项目文档、客户通话录音。可以让人类审核更新结果。Wiki 之所以能保持最新，是因为 LLM 做了团队里没人愿意做的维护工作。

这个场景非常贴近企业痛点。大多数公司的内部 Wiki（Confluence、Notion 之类）都有一个共同命运：热火朝天地搭建，然后慢慢腐烂。原因就是维护成本太高且没有人愿意承担。LLM 天然适合这个角色。

其他场景

竞品分析、尽职调查、旅行规划、课程笔记、爱好深潜——任何你在一个方向上持续积累知识、并且希望它有组织而非四处散落的场景。

架构设计：三层结构

这是整套方案的骨架，AK 用了非常干净的分层设计。

第一层：原始资料（Raw Sources）

你精心收集的源文档。文章、论文、图片、数据文件。

核心原则：不可变。LLM 从这些文件读取内容，但永远不修改它们。这是你的真相源（source of truth）。

想想为什么这一条很重要——你需要随时能回到原始资料去验证 Wiki 里的任何一个结论。如果 LLM 改了原始文件，你就失去了审计线索。

实操建议：
- 在 Obsidian 里建一个 raw/ 或 sources/ 目录
- 文章按日期或主题分子目录
- 文件名带标题和来源信息，方便后续定位

第二层：Wiki

一个由 LLM 生成的 Markdown 文件目录。包含摘要页、实体页、概念页、对比分析、综述、综合判断。

LLM 完全拥有这一层。 它创建页面，在新资料到来时更新它们，维护交叉引用，保持整体一致性。你是读者，LLM 是作者。

Wiki 的页面类型可以很丰富：

• 实体页：一个人、一家公司、一个项目的专属页面
• 概念页：一个技术概念或理论框架的解释
• 摘要页：某份原始资料的结构化摘要
• 对比页：两个或多个实体/方案的横向对比
• 综述页：某个主题的全局概览
• 综合判断页：基于所有已知信息形成的结论性分析

这些页面之间通过 Markdown 链接互相关联，形成一个知识网络。

第三层：Schema（配置文件）

一份文档（比如 Claude Code 的 CLAUDE.md，或 Codex 的 AGENTS.md），告诉 LLM 这个 Wiki 的结构规范、惯例约定、以及在摄入资料、回答问题、维护 Wiki 时应该遵循的工作流程。

这是整套系统的配置文件——正是这份文档让 LLM 变成了一个有纪律的 Wiki 维护者，而不是一个通用聊天机器人。

你和 LLM 会随着时间共同演进这份配置，逐步摸索出适合你自己领域的最佳实践。

我对这一层的理解是：它是"元知识"——关于如何组织知识的知识。 好的 Schema 就像好的代码规范，它不会直接产出价值，但它决定了整个系统的长期可维护性。

一份 Schema 通常应该包含：

• Wiki 的目录结构及每种页面类型的命名惯例
• 摄入新资料时的标准流程
• 页面格式规范（比如 YAML frontmatter 里应该有哪些字段）
• 交叉引用的命名和链接规则
• LLM 在不确定时应该如何处理

核心操作：三大工作流

操作一：摄入（Ingest）

你把一份新资料丢进原始目录，告诉 LLM 去处理它。

一个典型的摄入流程是这样的：

1. LLM 读完整份资料
2. 跟你讨论关键要点
3. 在 Wiki 里写一个摘要页
4. 更新索引
5. 更新相关的实体页和概念页（可能涉及 Wiki 中的 10-15 个页面）
6. 在日志里追加一条记录

一份资料可能触动十几个 Wiki 页面——这正是"增量整合"的具体表现。

AK 个人偏好一次只摄入一份资料，而且全程参与——他会读摘要、检查更新、引导 LLM 关注重点。但你也可以批量摄入、少监督。关键是找到适合自己的节奏，然后把它写进 Schema 里，这样后续的会话就能自动遵循。

我的建议：前十份资料一定要一份一份来。 这个阶段你在和 LLM 建立默契——Wiki 的结构还在成型，页面类型还在探索，交叉引用的风格还在磨合。等稳定之后再考虑批量处理。

操作二：查询（Query）

你对 Wiki 提问。LLM 搜索相关页面、阅读它们、综合出一个带引用的答案。

答案可以有多种形式，取决于问题类型：

• 一个 Markdown 页面
• 一张对比表格
• 一份幻灯片（用 Marp 格式）
• 一张图表（用 matplotlib）
• 一张思维导图

这里有一个关键洞察：好的问答结果可以被回写到 Wiki 里，变成新页面。

你在某次对话中做了一个有价值的对比分析，或者发现了一个有趣的跨领域关联——这些东西不应该消失在聊天历史里。把它们存进 Wiki，它们就跟摄入的原始资料一样，成为知识复利的一部分。

这个设计非常优雅。它让"探索"和"积累"变成同一个动作。你问的每一个好问题，都在让 Wiki 变得更好。

操作三：巡检（Lint）

定期让 LLM 对 Wiki 做健康检查。具体检查项：

• 矛盾检测：不同页面之间的说法是否有冲突？
• 过期判断：某个结论是否已经被更新的资料推翻了？
• 孤岛页面：哪些页面没有任何入链？可能是被遗忘的知识碎片
• 缺失页面：哪些重要概念在多处被提到但还没有独立成页？
• 引用缺失：哪些关联应该存在但还没有建立？
• 知识缺口：哪些区域可以通过一次网络搜索来补充？

LLM 还擅长做一件事：建议你下一步应该调查什么问题、寻找什么资料。这让 Wiki 的增长有了一个正反馈循环——Wiki 越丰富，LLM 就越能发现哪里还有空白，你就越知道该往哪里挖。

这个"巡检"操作是我觉得最被低估的部分。它把 Wiki 从一个"被动的信息容器"变成了一个"主动请求完善的智能系统"。

索引与日志：两个特殊文件

随着 Wiki 增长，你需要两个核心文件来帮助 LLM（和你自己）导航。

index.md —— 面向内容

这是一份 Wiki 的目录清单。每个页面都列出来，附带链接、一行摘要，可选地加上元数据（日期、资料源数量等）。按类别分组——实体、概念、资料摘要等。

LLM 每次摄入新资料时都会更新索引。回答问题时，LLM 先读索引找到相关页面，再深入阅读。

AK 说这个方案在中等规模（约 100 份资料、几百个页面）下效果出奇地好，不需要搞嵌入向量那套 RAG 基础设施。

这里有一个认知突破点：当 LLM 自己维护的 Wiki 结构足够好时，一个纯文本的索引文件就能替代整套向量检索系统。 结构化本身就是最好的检索策略。

log.md —— 面向时间线

一个只追加的记录文件——谁在什么时候做了什么。摄入、查询、巡检，全部记录在案。

一个实用技巧：如果每条记录以统一格式开头（比如 ## [2026-04-02] ingest | 文章标题），这份日志就可以用 Unix 命令行工具解析：

grep "^## \[" log.md | tail -5

这条命令给你最近 5 条操作记录。

日志提供了 Wiki 演化的时间线视角，帮助 LLM 了解最近发生了什么。在长期维护中，这个上下文非常重要——它让 LLM 知道"上次我们讨论到哪里了"。

可选工具：当 Wiki 长大之后

到了一定规模，你可能需要一些小工具来帮 LLM 更高效地操作 Wiki。

最明显的需求是搜索。小规模下 index.md 就够用了，但 Wiki 长大之后，你需要真正的搜索能力。

AK 推荐了 qmd——一个本地 Markdown 搜索引擎，支持 BM25 和向量搜索的混合模式，加上 LLM 重排序，全部在本地运行。它同时提供 CLI（让 LLM 可以调用命令行）和 MCP Server（让 LLM 可以作为原生工具使用）。

你也可以自己造一个更简单的搜索脚本——LLM 本身就能帮你"随手撸"一个够用的搜索工具。

实操技巧清单

AK 在原文里提了几个实用贴士，我一个个展开。

Obsidian Web Clipper

一个浏览器扩展，能把网页文章转成 Markdown。

对于快速把资料收进原始目录来说，这个工具极其好用。浏览器里看到一篇好文章，Clip 一下，一份格式化好的 Markdown 就出现在你的 raw/ 目录里了。比手动复制粘贴然后调格式快十倍。

本地化图片

在 Obsidian 设置里，把"附件文件夹路径"设为固定目录（比如 raw/assets/）。然后在快捷键设置里找到"Download attachments for current file"，绑个快捷键（比如 Ctrl+Shift+D）。

Clip 一篇文章后按一下快捷键，所有图片就下载到本地了。

这一步可选但有用——它让 LLM 能直接查看和引用图片，不依赖可能会失效的外部 URL。

一个需要注意的限制：LLM 目前没法在一次pass里同时读 Markdown 文本和内联图片。变通办法是让 LLM 先读文本，再单独查看引用的图片来获取额外上下文。稍微有点笨拙，但够用。

Obsidian 图谱视图

看 Wiki 的宏观结构——什么跟什么连着、哪些页面是枢纽节点、哪些是孤岛——图谱视图是最好的方式。

当你巡检 Wiki 时，图谱视图能直观告诉你哪些区域知识密度高、哪些区域还很稀疏。它把一个抽象的知识网络变成了可视化的地图。

Marp

一个基于 Markdown 的幻灯片格式。Obsidian 有对应插件。

如果你要做一个演讲或汇报，可以直接从 Wiki 内容生成。不用再打开 PowerPoint 从零做起。

Dataview

一个 Obsidian 插件，能对页面的 YAML frontmatter 做查询。

如果你的 LLM 在 Wiki 页面上加了 frontmatter（标签、日期、资料源数量），Dataview 可以生成动态表格和列表。比如"显示所有标记为'待验证'的页面"或者"列出过去一周更新过的所有概念页"。

版本控制

Wiki 就是一个 Markdown 文件的 Git 仓库。版本历史、分支、协作——这些能力你白拿。

这一点容易被忽略，但在实践中非常有价值。有了 Git，你可以放心让 LLM 大刀阔斧地改 Wiki——改坏了随时回滚。你也能看到每个页面的演化历史,了解某个结论是怎么一步步被修正的。

为什么这套方案有效？

维护知识库，最磨人的部分从来不是阅读和思考——是记账。

更新交叉引用、保持摘要跟最新资料同步、标注新数据跟旧结论的冲突、在几十个页面间维护一致性。人类放弃 Wiki 的原因只有一个：维护负担的增长速度超过了 Wiki 带来的价值。

LLM 不会厌倦，不会忘记更新某个交叉引用，而且能在一次操作中触达 15 个文件。Wiki 能持续保持良好状态，因为维护成本接近于零。

人类的任务是策展资料、引导分析、提出好问题、思考这一切的意义。LLM 的任务是剩下的一切。

一个有趣的历史连接

这个想法在精神上与 Vannevar Bush 1945 年提出的 Memex 概念一脉相承。

Memex 是一个设想中的个人知识存储设备，文档之间可以建立"联想链"（associative trails）。Bush 的愿景其实更接近 AK 的 Wiki，而不是后来万维网实际变成的样子——私有的、主动策展的、文档之间的连接跟文档本身一样有价值。

Bush 当年没解决的那个问题是：谁来做维护？

八十年后，LLM 接了这个活儿。

该怎么开始？我的建议

AK 原文说得很清楚——他的文档是有意抽象的。具体的目录结构、Schema 惯例、页面格式、工具选择，全部取决于你的领域、偏好和使用的 LLM。上面提到的所有内容都是可选的、模块化的——拿对你有用的、忽略没用的。

正确的使用方式是：把这份文档分享给你的 LLM Agent，一起协作搭建一个适合你需求的版本。文档唯一的任务是传达这个模式。你的 LLM 能搞定剩下的事。

不过如果让我给一个建议的话，我会说分四步走：

第一步：选定场景。 从一个你真正关心的小领域开始。比如你正在研究的一个课题、你在读的一本书、你的健康管理。不要一开始就想做"所有知识的 Wiki"。

第二步：搭好骨架。 创建 raw/、wiki/、CLAUDE.md（或你的 LLM 对应的配置文件）三个核心结构。在配置文件里写明：页面类型有哪些、新资料进来时怎么处理、链接怎么命名。不用写太精细，够启动就行。

第三步：逐份喂入资料。 前十份要认真对待。每摄入一份，检查 LLM 生成的摘要和更新是否合理。根据实际情况调整配置文件。这个阶段你在给 LLM 校准方向。

第四步：开始提问。 这时候 Wiki 里已经有了一些积累。试试问一些需要交叉综合的问题。看看 LLM 的回答质量。记得把好的回答存进 Wiki。

然后就是循环——摄入、查询、巡检、摄入、查询、巡检。Wiki 会越来越丰富，你的理解会越来越深。

写在最后

我喜欢这个方案的原因是它从根本上重新定义了一个关系：人和 LLM 之间的分工。

不是让 LLM 代替你思考，是让 LLM 代替你做那些"该做但你懒得做"的苦力活。你负责看方向、做判断、问问题。它负责抄写、归档、更新、交叉引用，把你每一次的思考都沉淀下来。

这可能是 LLM 落地到个人工作流中最自然、最高效的模式之一。

试试看吧。