Karpathy 的 LLM Wiki 模式到底是什么？

一个让知识自动生长的公式：raw/ → ingest → wiki

作者：一只阿木木我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统。

问你一个问题

你有没有这种体验：

上周把一篇好文章"收藏"了。这周想用，找不到。 把 PDF 丢给 ChatGPT 问了问题，关掉标签页，下周再问，又要重新上传一遍。 Obsidian 里攒了 300 个笔记，想找某个观点，搜索半天，全是碎片，没有一条互相关联。

你不是懒。你不是没有好工具。

问题在于：你一直在用"检索型"的方式管理知识，而不是"编译型"的方式。

这篇文章要讲的，就是 Andrej Karpathy 在 2026 年 4 月提出的一个思路——它有 1600 万次浏览，GitHub 发布后几天内获得 5000+ star——它不是一个工具，而是一种根本性的认知转变。

第一部分：你的知识基础设施，从来不是为"积累"而设计的

一个让很多人不舒服的事实是：

我们的知识基础设施，从来都是为"检索"而设计的，而不是为"积累"。搜索引擎在检索。RAG 在检索。就连带记忆的 LLM，本质上也是在检索。它们问的都是同一个问题：哪些文档和这次查询相关？

所以当你问 ChatGPT 一个问题，它找到相关内容，给你一个答案。然后你关掉标签页。

下次你问同一个主题的问题，它从零开始。上次的洞察？消失了。上次发现的关联？不存在了。7这是传统 RAG 最致命的隐性缺陷：知识从未被保留下来。每次查询都从零开始。系统永远是失忆的——能干，但无法成长。

这就是为什么你的笔记是坟场：它们只负责躺着，不负责生长。

第二部分：Karpathy 做了什么——一个让 AI 社区炸锅的比喻

Andrej Karpathy——特斯拉 Autopilot 神经网络架构的背后推手、OpenAI 联合创始人、用课程教会了一代工程师深度学习的人——发现了这个问题，并提出了一个在架构上完全不同的思路。他称之为 LLM Wiki 模式。 2026 年 4 月，Karpathy 在 X 上发了一条帖子，描述他的工作流转变：不再主要用 LLM 生成代码，而是用它来构建个人知识库。这条帖子迅速走红，获得 1600 万次浏览；随后他在 GitHub Gist 发布的详细说明，在几天内收获了 5000+ 颗星。它击中了每个知识工作者都面临的痛点：维护成本会把知识体系压垮。

他用的比喻来自软件工程。

Karpathy 援引的类比来自软件工程：编译。当你写源代码，编译器会把它转化为优化后的二进制产物。编译后的产物是一个 wiki。不是数据库，不是向量库，而是一组人类可读、由 LLM 维护的 Markdown 文件——每个概念一个文件，带有交叉引用、来源追踪和 git 版本历史。这是核心概念的转变：从无状态检索，到有状态的、持续复利的知识。

把这个比喻刻进脑子里。后面所有的细节，都从这里展开。

第三部分：RAG vs LLM Wiki——一个普通人也能懂的对比

让我们用一个场景来说清楚这两种思路的本质差异。

场景：你在研究"AI Agent 架构"，已经积累了 50 篇论文。

传统 RAG 的做法：

传统 RAG 直接针对原始资料运行。每次查询都重新读相同的论文，重新切割相同的 PDF，重新合成相同的答案——你在每次请求时都在执行一遍源代码。

你问："Transformer 和 Mamba 架构的核心差异是什么？"

系统在 50 篇论文里搜索，找到相关段落，拼接后给你一个答案。下次你问相关问题，它重新做一遍。50 篇论文之间的关系？矛盾？演进脉络？每次都要重新推导。

LLM Wiki 的做法：

LLM Wiki 模式说：先编译你的知识。用 LLM 读取你的来源，把内容合成为结构化的、互相链接的 wiki 页面，然后针对这个编译后的产物运行所有查询。合成只发生一次（随着新来源增量更新）；查询每次都受益于预先整理好的、交叉引用的知识。

你把 50 篇论文 ingest 进 wiki。AI 在编译阶段就把论文之间的关系、矛盾、演进路径都整理好，写成互联的 Markdown 页面。

之后你问任何问题，AI 不是在 50 篇论文里"搜索"——它在一个已经预先理解了这 50 篇论文的知识图谱里"导航"。

 一个已经 ingest 了 50 篇论文的 wiki 能以比 RAG 处理同样 50 篇论文更深的深度回答问题，因为关系、矛盾和合成结论已经被预先编译好了。

第四部分：三层架构——读懂就真的读懂了

Karpathy 的 LLM Wiki 是一个三层架构：不可变原始来源层、LLM 编译的 Markdown 页面层、以及一个 Schema 文件——以此替代无状态 RAG，实现持久的、自我维护的知识库。 10 这三层是清晰分离的。理解它们，是一个持续复利的系统和一个慢慢腐烂的 Markdown 文件夹之间的区别。

第一层：raw/（原始资料，不可改动）

raw/ 文件夹存放你的原始文档：文章、PDF、会议记录、代码、规格说明。这些是不可变的。LLM 只读取它们，从不修改它们。这保证了 wiki 里的每一个声明都能追溯回原始来源，提供了一条 RAG 的分块级引用无法匹敌的审计链。

用一句话记住这层：这是你的"源代码"，永远不会被改写。

第二层：wiki/（LLM 编译出的知识图谱）

这是系统的核心产物。

LLM wiki 是一个普通 Markdown 文件构成的文件夹，由 AI agent 代你读取、写入和维护。每个文件是一个实体页：一个结构化的、类似 Wikipedia 的条目，对应一个概念，并用 [[wiki-links]] 链接到相关概念。 当你添加一个新来源，LLM 不只是给它建索引。它读取它，提取关键信息，创建或更新实体页，标注新数据与已有声明的矛盾，并维护整个 wiki 的交叉引用。

第三层：CLAUDE.md（操作规则，把 AI 变成专业知识工作者）

这是整个系统里最重要的文件。它定义了 wiki 的结构、命名规范、页面模板和操作工作流。它把一个通用 LLM 转变为一个有纪律的知识工作者。之所以命名为 CLAUDE.md，是因为 Karpathy 使用 Claude Code 作为主要 agent——但这个概念适用于任何有文件访问权限的 LLM agent。 2 Karpathy 在原文中只简短提及了 schema。但在实际使用中，它是整个系统里最重要的文件。没有这个文件，AI 产出的内容就会前后不一致、缺乏结构。

第五部分：三个核心操作——整个系统的动词

理解了三层架构，再来看三个操作就很简单了。

① Ingest（编译）——把资料变成知识

这是最重要的操作。

Ingest 的过程是：LLM 读取一个新来源，提取关键信息，写入或更新 wiki 页面，并与已有内容交叉引用。这是成本最高、推理最密集的操作——而正因为在最前面做完了，查询时才能直接调用预先编译好的合成结果，而不是原始文本。

更重要的是复利效应：合成提示强制执行一个关键不变式："保留并扩展已有内容——永远不要丢弃页面上已有的信息。"这就是让知识复利而不是覆盖的原因。每一个后续来源都让页面更丰富，而不只是不同。

② Query（查询）——从知识图谱里导航，而不是搜索

查询时：LLM 读取索引，找到相关的 wiki 页面，综合出答案。这通常比 RAG 在原始文档上的合成更轻量——但它并不是无需推理的。LLM 仍然在查询时跨 wiki 页面进行合成，但它处理的是结构化的、预编译的知识，而不是原始的分块文本。

③ Lint（维护）——让系统越用越健康

这是最容易被忽视，却决定系统能否长期运转的操作。

有一个值得认真对待的批评：因为 LLM 把来源合成为 wiki 页面，存在幻觉被固化为"事实"的风险。在纯 RAG 中，一个错误答案只是一个错误答案；而在 LLM Wiki 中，一个小的误解可能在互联页面中悄悄传播。这就是 Karpathy 强调 lint 步骤的原因——定期审计——以及任何严肃的实现都应该对照原始来源抽查生成页面。

Lint 的工作是检查：孤儿页、死链接、过时声明、矛盾、缺失的交叉引用——并给出修复建议。

第六部分：这个模式背后，藏着一个 1945 年的古老梦想

这不只是关于 wiki。Karpathy 指向的是一个更古老的愿景——1945 年 Vannevar Bush 提出的 Memex：一个个人化的、精心策划的知识存储，其中文档之间的连接与文档本身同样有价值。

Memex 当年没有实现，是因为技术不够。现在，LLM 的上下文窗口足够大，成本足够低，纯文本足够开放——技术第一次追上了这个梦想。

而 Karpathy 的贡献，是把这个梦想翻译成了一套任何人都能执行的操作公式。

第七部分：谁应该用这套模式？谁不该用？

Karpathy 的洞察是：维护知识库最昂贵的部分不是阅读或思考——而是记录工作：交叉引用、摘要、去重、冲突解决。这些恰好是 LLM 特别擅长的任务，而人类在两周后就会放弃的任务。LLM Wiki 模式翻转了工作分工：模型负责维护，人类负责策划和判断。

适合用这套模式的场景：

• 你有持续积累的研究主题（技术学习、行业研究、写作素材）
• 你的知识库规模在数十到数百页之间
• 规模批评"它无法扩展"是有道理的，但抓错了重点。这个模式对个人和小团队知识库（十到数百页的规模）运作得非常好。它不是要替代企业级知识管理系统——它替代的是你从未维护的笔记本，和你从未整理的收藏夹。

不适合的场景：

• 超过 10 万文档级别的大型企业文档库（用 RAG）
• 多用户并发访问：这个模式假设单一策划者。没有合并解决、访问控制、并发编辑协议。两个人对同一个 wiki 同时 ingest 会产生冲突编辑。团队协作需要一个协调层或真正的共享知识系统。

第八部分：这是 Karpathy 对 AI 使用方式的第三次进化

最后一个宏观视角，帮你理解这件事的历史坐标。

LLM Wiki 是 Karpathy 关于人机协作思考的第三阶段：Vibe Coding（2025 年 2 月）——不逐行审查就接受 AI 生成的代码；Agentic Engineering（2026 年 1 月）——人类编排 AI Agent 而不是直接写代码；LLM Knowledge Bases（2026 年 4 月）——AI 管理的不只是代码，而是知识本身，人类是策展者，而不是写作者。每个阶段都把更多认知劳动转移给 LLM，同时让人类保留判断和方向的角色。

LLM Wiki 模式问的问题不一样：如果一个勤勉的、永不疲倦的研究助理永远不忘记任何事，他会随着时间构建出什么？这就是那个转变——从检索到编译，从无状态到有状态的知识。不是更快的搜索，而是更慢的、更仔细的、累积性的理解——由机器维护，由人类引导。

一张你可以贴在桌上的对比卡

写在最后：给AI 时代普通人的一句话

你不需要是工程师，也不需要懂向量数据库。

你需要理解的，只有一件事：

到目前为止，你一直在"收藏"知识。从今天开始，你可以"编译"知识。

raw/ → ingest → wiki

资料进去，知识图谱出来。每加一个来源，系统比昨天更聪明。每问一个问题，答案比上次更准确。

这就是自动生长的知识系统。这就是 AI 时代每个普通人应该拥有的第二大脑。