知识管理最大的敌人不是遗忘，是维护

你有没有这种经历：在 Notion 或 Obsidian 里建了一个精心设计的知识库，前两周兴致勃勃地整理笔记、建双向链接，第三周开始偷懒，第二个月就再也没打开过。

我有。不止一次。

不是因为懒。是因为维护一个活的知识库，其工作量的增速远超它带给你的价值增速。你新收集了一篇论文，要更新三个相关页面的交叉引用，检查两处可能过时的结论，顺手修一下上周忘记补的标签。这些"记账工作"不难，但累积起来，足以让任何人放弃。

2026 年 4 月初，Andrej Karpathy 在 GitHub 上发了一个 Gist，标题叫 LLM Wiki。12 小时内拿了 2100 颗 Star，X 上的帖子被围观了 1200 多万次。他没有发布任何代码，只发了一个"idea file"。

我仔细读了这份 Gist，把社区的实现和批评都翻了一遍。我的判断是：这个概念本身不新，但他找到了一个过去一直缺失的角色来填补知识管理中最致命的空缺。

LLM 不是搜索引擎，是编译器

Karpathy 的核心命题用一句话概括：Compile, don't retrieve.

传统的 RAG（检索增强生成）是这么工作的：你问一个问题，系统把你的原始文档切成碎片，用向量搜索找到最相关的几块，塞进 LLM 的上下文窗口，让它临场发挥。每次查询都是一次独立的、无状态的处理。上一次查询积累的理解，到下一次查询时完全归零。

LLM Wiki 反过来：在你"摄入"一份新资料的时候，就让 LLM 把它消化成结构化的 Markdown 页面，和已有的知识建立交叉引用，标记与旧结论的矛盾。这些页面本身就是知识资产，下次查询时 LLM 读的是编译好的 wiki，不是原始碎片。

用软件工程的类比：RAG 像解释型语言，每次运行都从源码开始解析；LLM Wiki 像编译型语言，先编译成可执行文件，运行时直接用。

架构极其简单。三层：

三个操作：Ingest（摄入新资料时编译）、Query（在编译好的 wiki 上查询）、Lint（定期健康检查，找矛盾和知识缺口）。没有向量数据库，没有 embedding，就是 Markdown 文件加一个 index.md 做全局索引。

Karpathy 说这套东西在"中等规模下效果出奇地好"。他自己的 wiki 大约 100 篇文章、40 万字。开发者 Farza 用类似方法把 2500 条日记转化成了 400 篇结构化百科，评价是"比一年前用 RAG 做的系统好用得多"。

真正的问题从来不是工具，是谁来维护

回到开头那个场景：为什么人人都建过知识库，人人都放弃了？

不是 Notion 不好用。不是 Obsidian 的双向链接不够强。问题出在一个更根本的地方：知识库的维护成本随规模指数增长，但人类投入维护的意愿随时间线性衰减。

Karpathy 引用了 1945 年 Vannevar Bush 的 Memex 概念，那是最早描述个人知识系统的愿景。80 年过去了，从 Wiki 到 Evernote 到 Notion 到 Obsidian，工具换了一代又一代，但"谁来维护"这个问题从未被解决。每次技术迭代解决的都是"如何更方便地输入"，从来没有解决"如何可持续地维护"。

LLM Wiki 的真正价值不在于"知识编译"这个概念（确实不新），而在于它给出了一个此前不存在的答案：让 LLM 当维护者。

你往 raw/ 里扔文件，LLM 自动更新 10-15 个相关页面、重建索引、标记与旧结论的冲突。你不需要操心交叉引用、不需要手动打标签、不需要检查一致性。这些"记账工作"全部交给 LLM。

你的角色从"组织者"变成了"策展者"：决定什么值得摄入，审核 LLM 编译的质量，在关键处做判断。Karpathy 自己的定义很精准：

Human responsibility: curation, direction, thinking.
LLM responsibility: everything else.

但认知摩擦被消除了，这是个问题

最有力的批评不是来自技术层面，而是来自知识管理哲学。

Niklas Luhmann 用 Zettelkasten（卡片盒）方法写了 70 本书、400 多篇论文。这个系统的核心不是卡片本身，而是写卡片的行为：你必须用自己的话重新表述一个想法，必须思考它和已有卡片的关联，必须决定它放在哪里。这些摩擦力不是低效，而是认知整合的机制。

批评者用了一个精准的类比：

Luhmann 的 Zettelkasten 是锻炼本身。Karpathy 的 Wiki 是教练的报告。

教练报告记录了你的训练数据，但肌肉是你自己练出来的。如果 LLM 替你"消化"了所有资料，你得到的是一份光滑的综合报告，但可能绕过了真正建立理解所需要的挣扎。

Hacker News 上有人说得更直接："Karpathy mistakes the words to be the goal, rather than the thinking that caused the words."

这个批评成立吗？我觉得部分成立。

关键在于你用 LLM Wiki 做什么。如果目的是深度学习一个全新领域，让 LLM 全自动编译可能确实绕过了必要的认知挣扎。但如果目的是管理你已经有判断力的领域的信息流，比如跟踪 50 个竞品的动态、维护团队的技术知识库，那么"记账工作"确实不产生认知价值，交给 LLM 完全合理。

批评者自己也给出了折中方案：让 LLM 做地图层（索引、交叉引用、缺口发现），把综合判断留给人。LLM 发现矛盾后停下来提示你，而不是自动解决。我认为这是最务实的用法。

100 页是一道坎

技术层面最硬的约束是规模。

Karpathy 的方案用 index.md 做全局索引，LLM 在查询时先读索引再定位页面。这在 100 页以内工作得很好，但超过 500 页就开始退化，1000 页以上完全不可行。本质上 index.md 是线性搜索，随页面增长 LLM 需要处理的上下文线性增加。

Karpathy 推荐用 qmd（支持 BM25 + 向量搜索）缓解这个问题。但一旦引入向量搜索，它就开始向 RAG 靠拢。社区里也有人分层索引（从 200 token 的极简摘要到 20K token 的完整内容），分四级渐进披露。这些都是有效的补丁，但也说明原始设计在规模上有硬限制。

另一个被低估的问题是幻觉的累积效应。LLM 编译的内容和原始资料混在同一个系统里，如果某次编译引入了错误推断，后续查询会引用这个错误、放大它、让它成为"事实"。Karpathy 自己承认必须配合 Git 做版本控制，但光有 Git 不够，你还需要定期人工抽查。对个人知识库来说勉强可行，对企业级应用来说是一个严肃的工程挑战。

Karpathy 真正在说什么

如果只看 LLM Wiki 本身，它是一个有明确适用范围的知识管理方案：中等规模、相对稳定的知识、有判断力的个人用户。不是万能药。

但如果把它放进 Karpathy 过去两年的轨迹里看，信号就清晰多了。

2025 年初他提出 Vibe Coding（用自然语言让 AI 写代码）。年中他自己修正说 Vibe Coding 已经过时了，新的范式叫 Agentic Engineering。年底他做了 AutoResearch，让 AI agent 自主跑实验（700 次试验/2 天）。到 2026 年 4 月，他发布 LLM Wiki，token 用途从代码操作彻底转向知识操作。

这条线的方向很明确：从人写代码，到 AI 写代码，到 AI 自主做研究，到 AI 维护知识。人的角色在整条链路上持续上移，从执行者到审核者到策展者。

他有一句话我印象很深：

我不再需要向人类解释了，我是在向智能体解释。如果智能体理解了，它们就能以无限的耐心向人类重传这些知识。

这句话的含义比 LLM Wiki 本身大得多。它在说：人类的护城河不再是知识的传递，而是核心直觉的产出。整理、编译、传递这些中间环节，全部可以交给 AI。你要做的是决定方向、做判断、产出别人无法替代的洞察。

LLM Wiki 只是这个大趋势中的一个具体实例。但它恰好击中了一个人人都有体感的痛点：知识库为什么总是烂尾。答案不是更好的工具，而是换一个不会厌倦记账的维护者。

对我自己的启发

作为一个 AI 工具的深度用户和团队管理者，我从 LLM Wiki 里提取了三个可执行的判断：

第一，知识管理应该分三层。核心知识用编译维护（LLM Wiki 的思路），长尾信息用检索（RAG），实时数据直接 API 查。不要试图用一套系统解决所有问题。

第二，Schema 设计比工具选型重要。LLM Wiki 的质量完全取决于 Schema（那个 CLAUDE.md）的设计质量。这其实就是我一直在做的事情：用 CLAUDE.md 和 AGENTS.md 定义 AI 的行为框架。知识管理的 Schema 和 Agent 的系统指令，本质上是同一件事。

第三，Markdown 是被低估的人机协议。Karpathy 选择 Markdown 不是因为它技术先进，而是因为它是人和 AI 都能读写的最小公约数。人类用 Obsidian 浏览、AI 用文件系统导航、Git 负责版本追踪，各司其职。这比任何 SaaS 的私有格式都更持久。

至于要不要自己搭一个 LLM Wiki，我会等社区的工程化成熟度再高一些。Karpathy 自己都说了，现在还是"a pile of janky scripts"。但他提出的那个核心问题，对每一个做知识工作的人都成立：

你的知识库，有没有一个不会厌倦的维护者？