Karpathy的LLM Wiki 颠覆我对Obsidian自动化的认知

Karpathy 最近发了一个很短但很关键的 Gist，标题叫LLM Wiki。

我看完第一反应：这不就是我最近一直在折腾的 Obsidian、Hermes、Content OS 和 LLM Wiki 的底层解释吗？

前几篇我讲过：为什么知识库不能只存资料；为什么 Obsidian 需要一个执行层；为什么 LLM Wiki 比普通文件夹更适合 AI Agent 长期维护；为什么把内容生产线拆成 Source、Topic、Draft、Published 这些结构。

我用Obsidian + Codex 搭了一个会持续进化的AI知识库，保姆级教程来了

我把Hermes Agent接进 Obsidian 后，知识库终于不只是"存资料"了

我又把 Obsidian 知识库升级了：现在它能自己长出知识网络

但那些更多是在讲我的实践。

Karpathy 这篇讲的是更底层的模式：

真正有价值的 AI 知识库，不应该只是 RAG，而应该是一个由 LLM 持续维护的 Wiki。

这句话听起来像概念，差别非常大。

RAG 解决的是：你问的时候，系统能不能从一堆文件里找到相关片段。

LLM Wiki 解决的是：你读过的、问过的、分析过的东西，能不能持续沉淀成一个越来越有结构的知识资产。

这就是今天想讲的重点。

RAG 最大的问题：每次都在重新发现知识

大多数人现在用 AI 知识库，基本还是 RAG 思路。

上传一堆文件，丢进 NotebookLM、ChatGPT 或者各种知识库工具。提问，系统检索相关 chunk，模型根据片段生成答案。

有用，当然有用。比如问"这篇文章讲什么""这几份文档有没有提到某个概念""报告里的关键数据在哪"，RAG 能省不少时间。

但 Karpathy 指出的核心问题是：它没有积累。

每次问问题，模型都要重新去找、重新去拼、重新综合一遍。

今天你问了一个复杂问题，模型综合了 5 篇文章给了个不错的回答。但如果这个回答没有被写回知识库，它就只是一次聊天记录。下次再问相关问题，又要重新检索、重新拼接、重新推理。

这就像每次写文章之前，把资料重新翻一遍。资料是有了，但知识没长出来。

这就是普通 RAG 的局限：它更像"临时问答系统"，不是"长期知识系统"。能帮你找东西，不一定帮你持续维护理解。

LLM Wiki 的关键：把知识编译成长期资产

Karpathy 的思路不一样。

不是把原始资料丢进去，等提问时再检索。而是：当你加入新资料时，LLM 应该主动读取并整合进一个长期存在的 Wiki。

这个 Wiki 不是简单摘要合集。它应该包括：

来源摘要

概念页

实体页

主题综述

对比表

交叉引用

新旧观点之间的矛盾

持续更新的综合判断

每加入一份新资料，LLM 不只是说"我记住了"。它应该去更新已有页面。

新资料补充了旧概念？更新概念页。提到新人名、公司、工具、方法？新建实体页。挑战了旧结论？标记矛盾。让某个主题图谱更完整？更新主题页和索引。

这才是 LLM Wiki 真正有意思的地方。

它不是"自动总结"，是"持续维护"。

自动总结是把一份资料压缩成一段话。持续维护是把一份资料放进整个知识网络里，让它和已有内容发生关系。

这两件事完全不是一个级别。

一个程序员更好理解的类比

普通 RAG 像解释执行。每次提问，临时加载资料、临时检索、临时拼上下文、临时生成答案。

LLM Wiki 更像编译。每加入一份资料，就把它编译进 Wiki：拆成页面、补上链接、更新索引、写入日志、修正已有结构。

下次问问题时，模型面对的不再是散乱原始材料，而是一套已经被整理过、链接过、更新过的知识代码库。

所以 Karpathy 那句类比特别准：

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

这句话我非常喜欢。

一下子把 Obsidian 和 LLM 的关系讲清楚了。Obsidian 不是最终答案，是个工作界面。LLM 不只是聊天框，应该像程序员一样维护文件、修改结构、提交更新。Wiki 不是一堆笔记，是需要长期维护的知识 codebase。

新增资料，就像往代码库里加需求。提问，就像让程序员写一个新模块。发现矛盾，就像发现 bug。做 lint，就像跑健康检查。

这样理解之后，AI 知识库就不只是"资料存哪里"的问题，而是"怎么让知识系统持续进化"。

三层架构，值得直接抄

Karpathy 把 LLM Wiki 拆成三层。我觉得非常值得直接拿来用。

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

文章、论文、图片、数据文件、会议记录、访谈稿、网页剪藏。

这一层有个关键原则：原始资料不可变。

LLM 可以读，不要随便改。因为这是 source of truth。如果 Wiki 里的总结出错了，你最终还能回到原始资料核对。原始资料被改乱了，整个知识库就没底了。

所以我现在越来越倾向把原始资料单独放在 Source 层，保持清晰、可追溯、可回看。

第二层：Wiki（知识结构层）

这是 LLM 真正负责维护的地方。

可以新建页面、更新页面、加双链、写综述、做对比、把一次问答沉淀成新的分析页。这一层不是原始资料，也不是聊天记录。是中间层。把散乱资料编译成更适合人和 AI 重复使用的结构。

第三层：Schema（规则层）

这层尤其重要，但很多人会忽略。

Schema 可以是CLAUDE.md、AGENTS.md，或者自己写的一套规则文档。它告诉 LLM：

目录怎么组织、什么页面放哪里、新资料摄入时做哪些动作、什么能改什么不能改、命名规则是什么、frontmatter 怎么写、index 和 log 怎么维护、回答完问题什么情况要写回 Wiki。

没有 Schema 的 Agent，很容易变成一个热心但不守规矩的实习生。会总结，会改写，会帮你生成内容，但不知道系统边界在哪。有了 Schema，LLM 才更像一个稳定的知识库维护者，不是每次都临场发挥，而是在同一套规则下持续工作。

Index 和 Log：两个很小但很关键的设计

Karpathy 特别提到两个文件：index.md和log.md。看起来普通，非常关键。

index.md是内容导航。告诉人和 LLM：这个 Wiki 里有什么页面，每个大概讲什么，哪些是概念、哪些是实体、哪些是来源、哪些是综合分析。

Wiki 变大之后，LLM 不应该一上来就乱搜。应该先读 index，再决定进哪些页面。这很符合人类使用知识库的习惯——不是每次都全盘搜索，而是先看目录，再看相关章节。

log.md是时间线。记录 Wiki 什么时候摄入了什么资料、回答过什么问题、做过什么健康检查。

对 Agent 特别有用。Agent 跨会话时，很容易不知道最近发生了什么。有个结构化的 log，至少能快速恢复上下文：最近处理过哪些资料、更新过哪些页面、哪些问题还没解决。

这就像项目开发里的 changelog。没有它，靠记忆。有了它，知识库的演化过程有迹可循。

为什么 Obsidian 很适合干这件事

我现在越来越觉得，Obsidian 适合 AI 知识库，不只是因为有双链和图谱。

更重要的是，它底层是 Markdown 文件。

这件事非常关键。

LLM Agent 最擅长操作的，就是文本文件。可以读 Markdown、改 Markdown、新建文件、维护目录、加 YAML frontmatter、跑脚本检查链接、用 Git 做版本管理。

这就让 Obsidian 变成一个很适合 Agent 工作的界面。人用 Obsidian 浏览、审阅、跟踪图谱；Agent 在背后读写文件、维护链接、更新索引、追加日志。

这就是为什么我之前一直说，Obsidian 真正需要的不是再多一个 AI 聊天框，而是一个执行层。

聊天框只能回答你。执行层可以改你的知识库。

这两者不是一回事。没有执行层，Obsidian 还是个手动的笔记软件。接上 Agent，它才有可能变成一个持续演化的知识工作台。

落到 Content OS 里是这样

Karpathy 这篇给了我很好的验证：我现在做的 Content OS，本质上就是把 LLM Wiki 的思路落到内容生产场景里。

在我的系统里：

Source Note→ Raw sources 层。收集外部文章、视频、Gist、论文、工具介绍和案例。

Topic Note→ 选题 Wiki 层。不是简单收藏，而是把来源转化成可写的角度：目标读者是谁、痛点是什么、标题怎么起、提纲怎么搭、适合哪个账号。

Draft Note→ 生产层。把 Topic 继续编译成可发布的文章草稿。

Published Note→ 归档层。记录最终发布版本、标题、链接、发布时间和关联选题。

再往上，还有内容框架、命名规范、入库规则。这些就是 Schema。它们告诉 Agent：超级猛应该怎么写，文件怎么命名，什么内容进 Source，什么升级成 Topic，什么能进 Draft。

所以 Content OS 不是一个"更复杂的文件夹"。它更像给 AI Agent 用的内容生产 Wiki。

人负责判断方向，Agent 负责维护结构。这跟 Karpathy 讲的 LLM Wiki 是同一个底层逻辑。

真正的 AI 第二大脑，不是更会搜索，而是更会沉淀

很多人做 AI 知识库，第一反应是上向量数据库、embedding、RAG、更大的上下文。

有没有用？当然有。

但它们不是第一性问题。

第一性问题是：你的知识有没有沉淀成结构？

没有结构，再强的检索也只是在一堆散乱资料里临时找答案。有结构，哪怕一开始只是 Markdown、index、log、双链和一套规则，已经能跑出很强的复利。

Karpathy 这篇最打动我的地方就在这里。他没上来讲复杂基础设施，也没说必须上什么数据库。他讲的是一个更朴素但更关键的模式：

把原始资料放好。让 LLM 持续维护 Wiki。用 Schema 约束它的工作方式。把重要回答写回知识库。定期 lint，检查矛盾、孤立页面、缺失概念和过时信息。

这套东西并不玄。但比"上传 100 个文件然后问 AI"更像真正的第二大脑。

因为第二大脑的重点不是存储，是生长。

如果问我 Karpathy 这篇最值得记住的一句话，我会选：

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

这句话把 AI 知识库的方向讲得很清楚。

别只把 AI 当成问答框，也别只把知识库当成文件仓库。真正值得做的，是让 LLM 成为知识库的维护者，让 Wiki 成为持续复利的结构化资产。

RAG 解决的是：问的时候找得到。

LLM Wiki 解决的是：用过之后沉淀得下来。

这两者的差别，就是临时回答和长期知识资产的差别。

如果你已经在用 Obsidian、Claude Code、Codex、Hermes、NotebookLM 或任何 AI Agent 工具，我建议别只问"它能不能帮我回答问题"，问一个更重要的：

它能不能帮我把回答，变成下一次还能继续用的知识？

能做到这一点，知识库才真正开始有复利。