RAG 退下，Karpathy 的 LLM Wiki 来了

第一章：你的知识库为什么总是半途而废 #

你有没有过这样的经历？兴冲冲地装好 Obsidian，花了整整一个周末搭模板、建文件夹、写第一篇笔记。两周后打开一看，只有三篇半成品躺在那里，最新的那篇还是上周的。

不是你一个人的问题。Karpathy 在他最新发布的 llm-wiki.md 里一针见血地指出了真相：人类放弃知识库的原因，从来不是工具不好，而是维护成本增长得比价值快。

更新交叉引用、保持摘要同步、标注新旧数据的矛盾点——这些琐碎的"记账"工作，没人愿意干。而一个活了的知识库，恰恰需要这些。

2026年4月4日，这位前 OpenAI 创始成员、Tesla AI 总监在 GitHub Gist 发了一篇文档。不到24小时，88条评论，5个开源实现项目冒了出来。社区炸了。

他说了一个很反直觉的东西：别让 LLM 每次都从原始文档里重新检索了。让它帮你建一个活的知识库——持续积累、自动维护、越用越聪明。

这篇就是来拆解这个模式的。工具你今天就有，方法读完就能用。

第二章：RAG的致命伤——每次都从零开始 #

先说清楚 RAG 到底哪不对。

你把一堆文件丢给 ChatGPT 或 NotebookLM，问它一个问题。它会从文件里检索出相关的片段，然后拼出一个答案。下次再问，它又从头检索一遍。同一个问题问两次，它干的活完全一样。

Karpathy 用了一个精准的比喻：LLM 在每次查询时都从零开始重新发现知识。没有积累。

这意味着什么？你问一个需要综合五篇文档才能回答的复杂问题，LLM 每次都得重新找到那五个片段，重新拼装。上次回答时建立的理解、发现的关联、标注的矛盾——全部归零。

更要命的是，你问了好问题之后，那个答案就消失了。好的分析、有价值的对比、你发现的关联——它们沉没在聊天记录里，不会被保存，不会被复用。

这就像你每次打开课本都得从第一页开始读。不管你看了多少遍，知识从不沉淀。

LLM Wiki 的思路完全不同：知识编译一次，然后持续维护。 交叉引用已经建好了，矛盾已经标注了，综合分析已经反映了你读过的所有东西。每加一个新来源，知识库就更丰富一层。

第三章：三层架构，搞懂LLM Wiki的骨架 #

Karpathy 把 LLM Wiki 设计成三层结构，每层职责明确。

第一层：原始资料（Raw Sources）。 你收集的所有文档——文章、论文、图片、数据文件。这些是只读的，LLM 只读取不修改。这是你的事实来源，神圣不可侵犯。

第二层：Wiki 本体。 一个由 LLM 生成和维护的 Markdown 文件目录。里面有摘要页、实体页、概念页、对比页、总览页、综合分析页。LLM 全权负责这层——它创建页面，新资料来了就更新，维护交叉引用，保持一致性。你读，它写。

第三层：Schema 配置。 一个告诉 LLM 怎么工作的配置文件。Wiki 怎么组织、命名规范是什么、摄入新资料时走什么流程——全写在这里。这个文件是你和 LLM 共同演化的，用得越久，它越懂你的习惯。

原始资料是不可动的地基，Wiki 是 LLM 帮你盖的大楼，Schema 是施工图纸。

第四章：三步操作：吃进去、问出来、养健康 #

LLM Wiki 的日常操作就三个词：Ingest、Query、Lint。

Ingest——吃进去。 你往原始资料库里丢一个新文件，告诉 LLM 处理它。LLM 读完之后，跟你讨论要点，写一篇摘要，更新索引，更新所有相关的实体页和概念页，再往日志里追加一条记录。Karpathy 说，一个来源可能影响 10 到 15 个 Wiki 页面。这就是为什么人不愿意手动维护——但 LLM 不在乎。

他个人偏好的方式是逐个摄入、全程参与：读摘要、检查更新、引导 LLM 重点关注什么。你也可以批量丢进去让 LLM 自己处理，看你的风格。

Query——问出来。 你对 Wiki 提问。LLM 搜索相关页面，综合出带引用的答案。这里有个关键洞察：好的答案应该被存回 Wiki，成为新的页面。 你要的一次对比、一段分析、一个你发现的关联——这些都是有价值的，不该消失在聊天记录里。

Lint——养健康。 定期让 LLM 给 Wiki 做个体检。找矛盾、找过时的信息、找没有入链的孤儿页面、找应该有独立页面但还没有的重要概念。LLM 还会建议你去调查什么新问题、找什么新资料。

三步循环，Wiki 就活了。

第五章：工具准备——Obsidian加LLM就够了 #

好消息是，你需要的东西要么已经有了，要么装起来很快。

Obsidian。 这是 Karpathy 本人推荐的工具，也是社区的主流选择。它本质上就是一个能看 Markdown 文件的编辑器，但它的图表视图是你观察 Wiki 形状的最好方式——什么和什么有关联、哪些页面是枢纽、哪些是孤岛。LLM Agent 在一边改文件，你在另一边实时看结果。用他的话说：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

LLM Agent。 Claude Code、OpenAI Codex、OpenCode 都行。Karpathy 的原文是设计成直接丢给 LLM Agent 的——复制粘贴进去，Agent 就知道该怎么帮你建 Wiki 了。

Web Clipper。 Obsidian 官方的浏览器插件，能把网页文章一键转成 Markdown 存进你的原始资料库。配合图片下载功能（在设置里绑定一个快捷键），所有图片都会存到本地。这样 LLM 就能直接看图，不用依赖随时可能失效的外链。

至于搜索引擎，小规模时一个索引文件就够了。Karpathy 说它在百来个资料源、几百页的规模下运行良好。规模上去了可以考虑 qmd——Tobi Lütke 做的本地 Markdown 搜索引擎。不过这是锦上添花，起步不需要。

第六章：一个真实场景跑一遍完整流程 #

用"读一本书建 Wiki"这个场景走一遍。

你在读一本技术书。每读完一章，把章节内容存到原始资料目录里。然后告诉 LLM：处理这一章。

LLM 会做什么？读完内容后跟你聊关键要点，然后开始干活：写章节摘要，更新全书总览，创建或更新概念页，标注和之前章节的关联。

读完一整本书，你的 Wiki 里就有了：每章摘要、关键概念的独立页面、主题间的关系图、你自己的疑问和发现。想想指环龙粉丝维基 Tolkien Gateway——几千个关联页面，志愿者花了好几年建出来。你现在一个人边读边建，LLM 帮你做所有交叉引用。

另一个更贴近日常的场景：个人成长追踪。你每天往资料库里丢日志、文章、播客笔记。LLM 帮你维护一个关于"你自己"的结构化画像——你的目标进展、反复出现的主题、你从不同来源学到的东西之间的关系。一个月后回头看，你会发现一些你自己注意不到的模式。

第七章：社区已经在玩什么 #

Karpathy 这篇文档发布才 24 小时，社区反应堪比接力赛。

有人立刻做了 browzy.ai——npm 命令行工具，带全文搜索和 Obsidian 双链语法。fakechris 做了 obsidian_vault_pipeline，自动把原始资料批量处理进 Obsidian 仓库。kfchou 写了 wiki-skills，把模式做成了 Claude Code 技能。还有 Thinking-Space，口号是"为 Claude Code 时代重新设计的 Obsidian"。

评论区里有个有趣的共识：不止一个人说"我独立得出了完全相同的模式"。有人称之为"收敛验证"——很多人独立走到同一个地方，说明这不是一个人的想法，是行业趋势的方向。

有人已经跑了这套模式几个月，说"缺失的恰好就是让 LLM 主动合成，而不是被动检索"。甚至有人报告 Claude 已经把这个想法融入工作流，还起了个名字叫"Karpathy-Index"。

这说明两件事：一，这个需求是真实的、迫切的；二，工具已经就位了，不需要等什么新东西。

第八章：今天开始你的第二大脑 #

说到底就三件事。

找你手边的一个话题——任何你正在积累资料的东西。一本书、一个技术方向、一个研究项目，都行。建三个文件夹：一个放原始资料，一个放 Wiki 页面，一个放 Schema 配置。打开你的 LLM Agent，把 Karpathy 的那篇 llm-wiki.md 丢给它，说"帮我按这个模式建一个 Wiki"。

就这么简单。不需要学什么新框架，不需要配什么复杂工具。你已经在用 Obsidian 了更好，没有的话一个文件夹加一个编辑器就够了。

真正改变的不是工具。是你和知识的关系。以前的"第二大脑"之所以半途而废，不是因为 Obsidian 不够好，不是因为 Notion 功能不够多。是因为那些需要日复一日维护的琐事——更新引用、标注矛盾、保持一致——没人愿意干。LLM 把这个成本压到了接近零。

知识不等人。你今天读过的东西、发现过的关联、产生过的洞察——如果不记下来，下周就忘了。如果只是丢进一个文件夹，跟没记一样。LLM Wiki 给了一个真正让知识活着的方案：你负责思考和选择，LLM 负责剩下的所有脏活。

80年前，Vannevar Bush 提出了 Memex——一个个人策展的知识库，文档之间有联想式的关联路径。他的愿景比现在的互联网更接近这个方向：私密的、主动维护的、文档之间的连接和文档本身一样有价值。他唯一没解决的是：谁来维护？

现在有了答案。