AI 时代个人知识管理新范式：Karpathy 的 LLM wiki

01　你存了一百篇文章，但它们互不认识

大多数人的知识管理是这样的：

看到一篇好文章，收藏。读到一个好观点，记笔记。日积月累，笔记软件里躺着几百条碎片。

然后呢？

然后你需要用的时候，打开搜索框，输入关键词，翻来翻去，找到一条似乎相关的——但它是孤立的，跟其他笔记没有关系，跟你的思考脉络也没有关系。

你以为你在建知识库。其实你只是在堆仓库。

这就是传统 RAG（检索增强生成）模式的缩影：每次用的时候搜一遍，搜到什么算什么。 就像一个永远不整理的书房，找书靠翻，找到的那本书跟旁边那本完全没有关联。

NotebookLM 是这样，ChatGPT 的文件上传是这样，市面上绝大多数 AI 知识工具都是这样。

每次提问，AI 都在从头发现知识。没有积累。

Andrej Karpathy——前 OpenAI 联合创始人、前特斯拉 AI 总监——2026 年 4 月在 GitHub 上分享了一个截然不同的做法。

帖子发出两天，260 万人浏览，4.4 万人收藏。

他的方法不叫”搜索”。叫”编译”。

02　编译，不是检索

卡帕西的核心思路可以用一句话概括：

让 AI 把你的原始资料一次性”编译”成结构化的 wiki 页面，之后你所有的问题都基于这个 wiki 来回答，而不是每次都从原始文档里重新搜。

这个区别，有点像编译型语言和解释型语言的区别。

传统 RAG 是”解释执行”——每次运行都从源代码读一遍，现场理解，现场输出。

卡帕西的方法是”编译执行”——先把源代码编译成二进制，之后每次运行直接用编译好的产物，又快又稳。

更形象的比喻：你把研究资料交给一位全职的图书管理员。他不会忘记更新交叉引用，不会厌烦琐碎的整理工作，一次操作就能同时修改 15 个文件。 知识被”编译”一次之后，就持续保鲜，而不是每次查询都重新推导。

03　三层架构

整个系统分三层：

第一层：原始资料（raw）

文章、论文、图片、数据集，统统往里扔。这一层是只读的，AI 只看不改，就像编译器的输入源码。不整理、不重命名、不清理——扔进去就行。

第二层：Wiki 页面（wiki）

一堆 AI 生成的 Markdown 文件。摘要、实体页、概念页、对比分析、综述。页与页之间有超链接，形成一个互相引用的知识网络。全部由 AI 自动创建和维护，你只负责阅读。

卡帕西自己在一个研究方向上积累了大约 100 篇文章、40 万字。本来以为得上花哨的向量数据库方案，结果发现——AI 自己维护索引文件和文档摘要就够了，在这个规模下查什么都顺畅。

第三层：编译规则（Schema）

一份配置文件（比如 Claude Code 的 CLAUDE.md，或 Codex 的 AGENTS.md），告诉 AI 这个 Wiki 怎么组织、遵循什么规范、遇到不同操作该走什么流程。

这是把 AI 从通用聊天机器人变成专业 Wiki 维护者的关键。 没有这份规则，AI 只是一个随机应答的助手；有了它，AI 变成了一位纪律严明的图书管理员。

04　三个操作，循环不止

日常使用就三个动作：

▸ 灌入（Ingest）

把新资料丢进 raw/ 目录，告诉 AI 去处理。AI 读完之后会跟你讨论要点，写一页摘要，更新索引，然后跑去更新 Wiki 里所有相关的实体页和概念页。

一份资料可能会触发 10 到 15 个页面的更新。

卡帕西的操作细节：他目前是手动添加每一份资料，一份一份来，全程在线参与。等 AI”学会”了这个 Wiki 的模式之后，后面再加新文档就轻松了，只需要说一句”把这份新文档归档到我们的 Wiki”就行。

有人问怎么用它来读书。卡帕西的建议是：用 epub 格式而不是 PDF，一章一章地喂给 AI，让它边读边整理。

“别指望把一个 PDF 丢进去就让它总结，得慢慢来，一块一块地处理。当我分阶段做的时候，结果好得不得了，已经离不开了。”

▸ 提问（Query）

向 Wiki 提问。AI 会搜索相关页面，读完之后综合出一个带引用的回答。回答可以是 Markdown、对比表格、Marp 幻灯片、matplotlib 图表，各种格式都行。

关键的一步：好的回答可以被归档回 Wiki，变成新的页面。 你的每一次探索，都在给知识库”添砖加瓦”。问问题不只是在”消费”知识，你同时在”生产”知识。

▸ 巡检（Lint）

定期让 AI 对 Wiki 做一次”体检”：找矛盾、补缺失、发现新的关联、标记需要深入研究的方向。AI 还挺擅长给你出下一步的研究题目。

就像一个不知疲倦的编辑，永远在帮你校对。

卡帕西说自己平时就是一边开着 AI Agent，一边开着 Obsidian。AI 在对话中做编辑，他在 Obsidian 里实时看结果，点链接、翻图谱、读更新后的页面。

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

05　为什么不需要向量数据库

你可能会问：不搞向量数据库，搜索质量能行吗？

卡帕西的回答是：在个人知识库的规模下（100 篇量级），根本不需要。

向量数据库解决的是”百万文档中找最相关的几篇”的问题。但你的个人知识库有几百万篇文档吗？没有。你可能就存了几十篇、一百篇。这个量级，AI 的上下文窗口完全装得下。

一个索引文件 + AI 的上下文窗口 = 足够的检索能力。

多一个向量数据库，多的不是效率，是复杂度和维护成本。

卡帕西的优雅之处在于：用最简单的工具解决当前规模的问题，等到真正需要更复杂方案的时候再升级。 而不是一开始就上一个企业级架构，然后发现自己只是想管理一百篇读书笔记。

底层技术栈也简单到令人意外：就是一个嵌套目录，里面是 .md 文件和 .png 图片，再加几个 .csv 和 .py，Schema 写在 AGENTS.md 里。没有数据库，没有框架。

06　评论区里藏着的四个亮点

这条帖子的评论区相当热闹，卡帕西自己就回了几十条。几个最值得记住的：

亮点一：Farza 的实战验证

开发者 Farza 做了一个叫 Farzapedia 的个人 Wiki，喂了自己几年的笔记、截图、收藏。他让 AI 回答”我是怎么接触到吉卜力的”——Agent 自己跑去翻 Wiki，拉出了吉卜力纪录片的笔记、YC 公司落地页的截图，甚至是他几年前保存的 1970 年代甲壳虫乐队周边的照片，然后给出了一个相当靠谱的回答。

Farza 说他一年前用 RAG 做过类似的系统，”效果一言难尽”。而基于文件系统的知识库，Agent 天然就能理解，反而好用得多。

亮点二：AI 个性化的四个优势

卡帕西看到 Farzapedia 之后专门列出了这种方式的四个优势：

① 可见 — 记忆不是藏在模型里的黑箱。它就是一个 Wiki，你能看到 AI 知道什么、不知道什么，能检查、能管理

② 你自己的 — 数据在你本地电脑上，不在某个 AI 公司的系统里。你对自己的信息有完全的控制权

③ 文件优先 — 知识库就是一堆通用格式的文件：Markdown 和图片。想用 Obsidian 看就用 Obsidian，想自己写个界面也行

④ BYOAI（自带 AI） — 你可以用 Claude、Codex、OpenCode 或任何你喜欢的 AI 来接入这些数据

亮点三：Obsidian 创始人的”污染隔离”概念

Obsidian 的创始人 Steph Ango 也在评论区出现了，提出了一个叫 Contamination Mitigation（污染隔离）的概念：建议把个人的笔记库和 Agent 的工作区分开，让 Agent 在一个”乱一点的”空间里折腾，整理好的成果再搬回你的主库。

卡帕西表示认同——他的 raw/ 目录就是起这个作用的。

亮点四：有人总结了一句扎心的话

“Karpathy 的帖子有 4.4 万人收藏。但收藏和真正用起来，差的只是一个周末的动手时间。“

07　全网实操者的真实反馈：到底解决了什么问题

帖子发出后不到三周，全网涌现了大量实践者。他们来自不同领域，用 LLM Wiki 解决的痛点各不相同，但指向同一个结论：这套方法真正解决的，是传统知识工具做不到的三件事。

问题一：RAG 的”每次从零开始”症

一位在腾讯云开发者社区做了完整复现的工程师，总结了 RAG 的四个核心痛点：

① 分块损失 — 一篇结构化的论文切成 512 token 的碎片后，上下文关系全丢了

② 检索不稳定 — Embedding 相似度不等于语义相关度，换个说法就检索不到

③ 重复浪费 — 同一份文档，每次查询时 AI 都要重新”阅读”原文

④ 知识碎片化 — 原始文档之间没有显式关联，知识只是”堆”在数据库里

他的结论是：

“RAG 本质上是’检索时理解’——每次查询临时抱佛脚。LLM Wiki 的思路反过来：为什么不在入库时就让 AI 理解好？“

切换到 LLM Wiki 之后，查询速度和准确度都有明显提升。原因很简单：知识已经编译过了，AI 不需要每次重新推导。

问题二：知识”越攒越多，越来越找不到”

供应链 AI 领域的一位实践者，用 PromptQL 搭建了一个 200+ 页面的 LLM Wiki，采用 Wikipedia 风格的交叉引用。他的 AI Agent 在每次查询前会先读 Wiki，再给出回答。

他之前用传统 RAG 做过类似系统，最大的问题是：知识库越来越大，但检索质量越来越差——因为向量检索无法处理跨文档的隐含关联。而 LLM Wiki 通过显式的双链把关联提前建立好了，知识越多，关联越密，回答质量反而越高。

另一位开发者更直接：他用 LLM Wiki 构建了一个”会进化的 AI 分身”。上传文档后，AI 自动语义拆分、提取实体和概念、生成互联的百科页面。新知识与旧知识智能合并——去重 + 冲突处理。

“效果是分身的回答在逻辑和语感上高度统一，不会出现’AI 味’忽浓忽淡的问题。”

问题三：”想改 AI 的行为，得改代码”

一位开发者在完整实现了 LLM Wiki 之后，最感慨的设计是 Schema 驱动：

“修改 Schema 就能修改 AI 的行为，不需要改一行代码。想让摘要更详细？改 SCHEMA.md 里的字数限制就行。想新增一种页面类型？在模板里加一个定义即可。这在传统 RAG 系统中是不可想象的——通常你需要改 Prompt、改代码逻辑、重新部署。”

这一点对非技术用户尤其重要。你不需要懂 Python，不需要会配向量数据库。你只需要会编辑一个 Markdown 文件，就能控制整个知识库的行为。

附：RAG vs LLM Wiki 五维对比

▸ 信息密度： RAG 低（包含冗余） → LLM Wiki 高（经过精炼）

▸ 知识关联： RAG 隐式（向量空间） → LLM Wiki 显式（双链引用）

▸ 查询负担： RAG 重（需理解原文） → LLM Wiki 轻（知识已结构化）

▸ 行为修改： RAG 改代码→部署 → LLM Wiki 改 Markdown 文件

▸ 跨文档推理： RAG 每次从零拼凑 → LLM Wiki 已预编译在 wiki 里

“RAG 是用技术复杂度换取内容量。LLM Wiki 是用前期精炼换取查询时的简单与准确。“

08　一个 80 年前的梦

卡帕西在帖子里提到了一段 81 年前的往事。

1945 年，Vannevar Bush 提出了 Memex 的概念：一个私人的、经过整理的知识库，文档之间有关联性的”踪迹”相互连接。Bush 的愿景其实比后来的万维网更接近卡帕西现在做的事情：私密的、主动整理的、文档之间的连接和文档本身同样重要。

Bush 没能解决的问题是：谁来做维护。

81 年后，答案来了：LLM。

它不会忘记更新交叉引用，不会觉得整理工作无聊，一次操作就能触及几十个文件。Wiki 能持续保持更新，因为维护的成本趋近于零。

09　从 vibe coding 到知识编译

回头看卡帕西这两年的轨迹，能看到一条清晰的演进线：

2025 年 2 月 — 他造了 vibe coding 这个词，意思是写代码的时候完全”跟着感觉走”，让 AI 写，自己不看

2025 年底 — 他提出了 Agentic Engineering，用 AI Agent 来写代码，但加上了人类的监督和审查

2026 年 4 月 — LLM Knowledge Bases。这回 AI 操控的不再是代码，而是知识本身了

从”让 AI 写代码”到”让 AI 管知识”——这条演进线指向一个越来越清晰的方向：AI 不只是工具，而是思维的基础设施。

而贯穿这一切的，是 Markdown。不管是指导 Agent 的 CLAUDE.md，驱动研究的 program.md，还是被编译成 Wiki 的 raw/ 目录——人和 AI 之间的接口，就是纯文本。

Markdown 正在成为 AI 时代的编程语言。

10　你现在就可以动手

如果你想试一下这套方法，不需要写代码，不需要搭服务器。你需要的只是：

• 一个文件夹 — 放 raw 原始素材 + wiki 编译产物
• 一个能读文件的 AI — Claude Code、Cursor、甚至直接用 Claude.ai 上传文件都行
• 一份编译规则 — 告诉 AI 你的 wiki 长什么样、怎么组织

然后你就可以开始了——

把你的笔记、文章、读书摘录丢进一个文件夹。 让 AI 读一遍，生成 wiki 页面。 问它问题。看它怎么从你自己的资料里综合出答案。 让它把答案写回 wiki。

你会发现一件有意思的事：你比你以为的知道得更多。

那些碎片化的笔记，在 AI 的编译下，突然形成了你以前没看到的关联和脉络。

你存了一百篇文章。现在，它们终于互相认识了。

Beyond Algorithms

算法之内，驾驭工具；算法之外，做回自己