[[Andrej Karpathy]] 最近在 GitHub 上发了一个 Gist，介绍了一套他叫做「LLM Wiki」的个人知识库管理模式。很多人说这是他这两年分享的东西里最实用的一个，我花了几天时间认真研究了一遍，觉得值得写一篇文章把它的核心逻辑说清楚。
Karpathy 不是第一次聊知识管理的话题了。2024 年初他就写过一篇关于 [[Obsidian]] 的「情书」，核心观点是 Obsidian 代表了他心目中软件应该有的样子——不是一个试图锁定用户的产品，而是一个哲学上站得住脚的工具。但那篇文章更多是在夸 Obsidian 的设计理念，而这次的 LLM Wiki 则是在讲具体的工作流：他到底怎么用 LLM 和 Markdown 文件来管理自己研究领域的知识积累。
Karpathy 为什么喜欢 Obsidian
在说 LLM Wiki 之前，先把他对 Obsidian 的看法说一下，因为这是整个体系的地基。
他对 Obsidian 最核心的评价是：
“My primary interest in Obsidian is not even for note taking specifically, it is that Obsidian is around the state of the art of a philosophy of software and what it could be.”
翻译过来就是：他对 Obsidian 的兴趣不主要在记笔记本身，而在于 Obsidian 体现了他认为软件应该有的样子。这个「软件哲学」具体是什么？他的答案非常干净：
Notes 就是磁盘上的 Markdown 文件。Obsidian 只是提供了一个渲染和编辑的界面，你的笔记实际上就是一堆 .md 文件放在一个文件夹里。没有私有格式，没有数据库，没有需要「导出」的操作。你可以用任何编辑器打开，可以用 git 版本管理，可以用任何 AI 工具直接读取和修改。这种设计天然地消除了厂商锁定。
他还明确批评了那些他认为「对用户不友好」的软件设计模式，包括把数据关在私有格式里、用各种方式制造切换成本。Obsidian 的设计完全反过来——就算哪天 Obsidian 公司倒闭了，你的笔记依然完整地躺在你的电脑上，任何能读 Markdown 的软件都能继续使用。
这个基础判断是他整个知识管理思路的出发点：选一个不会消失的格式，然后在上面构建自己的系统。
LLM Wiki 的核心思路
理解了为什么选 Obsidian 和 Markdown，再来看 LLM Wiki 这套模式就容易多了。
他在 Gist 里提出的核心问题是：传统的知识管理为什么做不下去？答案不是「没时间读」，也不是「不懂如何组织」，而是：「维护一个知识库最枯燥的部分不是阅读和思考，而是书记工作」。
具体来说，每次读完一篇新论文或文章，你需要更新相关的摘要页、在其他地方加上反向链接、检查有没有和之前的观点矛盾、把新内容整合进已有的分类体系里。这些事情单独做每件都不难，但加在一起就形成了一个让人放弃的积压。大多数人的 Obsidian 里都有一堆孤立的笔记，因为「书记工作」太累了，慢慢就不做了。
Karpathy 的洞察是：LLM 非常擅长做书记工作。它不会嫌烦，不会忘记，能同时处理大量的交叉引用和一致性检查。所以把这部分工作交给 LLM，人专心做它不擅长的事情——筛选和判断——整个系统就能持续运转下去。
三层架构设计
他的系统由三个层次组成，设计非常干净。
第一层是 /raw 目录，存放原始资料。这里放的是不可修改的「原始素材」：研究论文、GitHub 仓库、数据集、网页文章（用 Obsidian Web Clipper 转为 Markdown），以及文章里的图片（本地下载，这样 LLM 可以通过视觉能力直接读取）。这一层的原则只有一个：只进不改。LLM 会读取这里的内容，但永远不会修改它。原始资料保持原汁原味。
第二层是 /wiki 目录，存放 LLM 生成和维护的 Markdown 文件。这里是整个系统的核心。Wiki 里有摘要页、概念页、人物页、专题文章，以及把所有内容串联起来的自动反向链接。还有两个特殊文件：index.md 作为整体索引，log.md 作为只追加不修改的操作日志，记录每次 LLM 做了什么。这一层完全归 LLM 所有——它负责创建、更新、维护这里的一切。
第三层是一个 Schema 文档（类似 CLAUDE.md），定义了整个 Wiki 的结构规范和工作流程。它告诉 LLM 如何处理新素材、如何组织文章、用什么格式写摘要、如何处理矛盾信息。这是人工介入最多的地方——你通过修改 Schema 来调整 LLM 的行为，而不是去手动整理 Wiki 里的内容。
三种工作流
系统建好之后，日常操作只有三种模式。
Ingest（摄入）：拿到一个新的资料，放进 /raw 目录，然后让 LLM 处理。LLM 会读取内容，写出摘要，创建或更新 Wiki 里的相关页面，并在 10 到 15 个已有页面里加入与新内容相关的交叉引用，最后在 log.md 里记录本次操作。人需要做的只是把素材放进 /raw 然后触发这个流程。
Query（查询）：想了解某个话题时，不去搜索 /raw 里的原始文档，而是在 Wiki 里搜索。LLM 已经把所有原始资料提炼成了结构化的知识页，带着交叉引用和摘要，回答效率远高于直接检索原文。如果某个问答特别有价值，还可以把答案本身存回 Wiki，成为新的知识条目。
Lint（维护）：定期让 LLM 对整个 Wiki 做健康检查，找出矛盾的说法、过时的信息、没有被任何其他页面链接的孤立页，以及明显的知识空白。这个维护流程替代了人工梳理笔记，让知识库保持活跃而不是慢慢腐烂。
为什么不是 RAG
这里有一个值得展开的对比，因为很多人会问：这和 RAG（检索增强生成）有什么本质区别？
传统 RAG 的做法是：把文档切片嵌入向量数据库，每次查询时检索相关片段，让 LLM 临时综合这些片段来回答问题。每次回答都是从头开始的——没有记忆，没有积累。
LLM Wiki 的做法是：知识是预先综合好的，存在 Wiki 的页面里，带着交叉引用和上下文。每次查询利用的是已经完成的「思考工作」，而不是每次重新做一遍。
Karpathy 的比喻是：传统 RAG 像是每次问问题都要重新读一遍原始资料，LLM Wiki 像是问一个已经把文献都读透了的专家。后者的效率更高，答案的质量也更稳定，因为上下文是持续积累的，而不是每次临时拼凑的。
他还提到一个实际数字：他的 Wiki 大概有 100 篇文章、40 万词，这个规模完全可以让 LLM 直接在上下文窗口里处理，不需要向量数据库，不需要复杂的检索管道。对于个人研究来说，这套「编译好的知识 + 大上下文窗口」的组合，往往比 RAG 更实用也更容易维护。
工具选择的极简主义
Karpathy 在谈工具选择时的态度也值得记一下。他说的是：
“All you do is put Markdown files in a folder.”
AI 不在乎你用什么编辑器打开这些文件，重要的只是文件夹结构和 Schema。这种极简主义让整个系统的核心依赖降到了最低：Markdown 格式 + 文件系统 + 能运行 LLM 的工具（他自己用 [[Claude Code]]）。
他确实提到了几个有用的 Obsidian 插件：Dataview（对笔记的 YAML 元数据做查询，生成动态表格）、Marp（从 Markdown 直接生成演示文稿）、Obsidian Web Clipper（把网页转成本地 Markdown 文件，同时下载图片）。但他的态度是「有用就用，没有也完全没关系」，而不是「你必须配置这些才能工作」。
这一点和很多 PKM 爱好者的倾向正好相反——后者往往花大量时间研究插件组合和工作流配置，结果管理工具的时间比实际积累知识的时间还多。Karpathy 的系统简单到可以用任何文件系统实现，配置成本极低。
人机分工的哲学
整套方案背后有一个更大的哲学判断，我觉得这才是最值得思考的部分。
他把知识管理这件事拆成了两个角色：人是策展人（curator），LLM 是综合者（synthesizer）。
策展人做什么？决定什么值得进入系统，找资料、判断质量、过滤噪音。这些事情需要领域判断力，是 LLM 目前还替代不了的。
综合者做什么？把大量文本内容整理成结构化知识，维护一致性，建立交叉引用，处理书记工作。这些事情对人来说枯燥且费时，对 LLM 来说几乎没有边际成本。
这个分工的清晰，让整个系统变得可持续。以前个人知识管理的瓶颈是维护成本——内容多到一定程度之后，整理的负担会让人放弃。Karpathy 的方案把这个瓶颈移走了：LLM 承担了几乎所有的维护工作，人只需要持续提供好的素材。
我自己用 [[Obsidian]] 也几年了，这篇文章的知识库本身也是建在 Obsidian 上的。看完他的思路之后，最直接的感受是：他把一件我一直觉得「理论上应该能做」但实际一直没做起来的事情——用 AI 帮助维护知识库——给了一个具体可实施的方案。不需要部署向量数据库，不需要写复杂的 RAG 管道，就是三个文件夹加上一个 Schema 文件，LLM 做其余的事情。
最后
Karpathy 这套 LLM Wiki 方案发布才不到两周，已经有好几个开源实现冒出来了，包括直接对接 Claude Code 的版本和针对 Obsidian 优化的版本。这种快速的社区反应说明它击中了很多人的痛点——个人知识管理的维护成本一直是这件事做不下去的核心障碍。
对于已经在用 Obsidian 的人来说，这套方案几乎可以零成本地叠加上去——你已经有了 Markdown 文件和文件夹结构，缺的只是 /raw 和 /wiki 的分层设计，以及一个 Schema 文档来指导 LLM 的行为。
Gist 地址在这里：gist.github.com/karpathy/442a6bf555914893e9891c11519de94f，原文非常简洁，建议直接读一遍，十分钟足够，读完你会对这个方案有更直接的感受。