这篇文章也有英文版本Read in English →
Karpathy LLM Wiki 是什么？一个卡片盒笔记法用户的实测
这一周，AI 社群被一篇技术笔记洗版。
作者是 Andrej Karpathy。
如果你没听过他 —— 他是 OpenAI 最早的创办成员之一，后来去 Tesla 当 AI 总监，现在自己开了 Eureka Labs 做 AI 教育。在 AI 圈子里，他说什么、隔天就会有一堆人跟着试。
4 月 3 日他在 X 发了一段话，隔天把整套做法写成一份 GitHub gist 放出来。一周之内 Hacker News、X、Substack 全在讨论。
最被疯狂转的一句是这个：
Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. — Karpathy gist
老实说，这篇红起来的时候我有点困惑。
这半年 Obsidian + Claude Code / Codex 的组合已经是 PKM 圈的显学之一。我自己去年底从 Roam 转到 Obsidian，跑 Nick Milo 的 LYT 框架加 Claude Code 当后台，也快半年了。身边还有几个朋友在做类似的事。
所以 Karpathy 这篇对我来说，第一眼看过去几乎没有新东西。
为什么这篇会爆成这样？
带着这个困惑，我花了半天用他的方法研究他的方法 —— 把 7 份素材丢进去跑了一次 ingest，然后跟我自己用了半年的 LYT 系统做对照。
跑完之后我想跟你说两件事。
第一，骨架一样。差在 workflow。
第二，根本的分歧不在技术，在哲学 —— 一张卡到底是什么？
他的内核主张很简单：不要做 RAG，改做 wiki。
RAG 的做法是每次查找时才临时从 raw 文档找答案。Karpathy 的做法是：让 LLM 作为 compiler，把 raw 文档增量编译成一份持久化的 markdown wiki，然后一直维护它。
这两者的根本差异是时间维度：
- RAG：每次查找 = 重新找答案（stateless、transient）
- LLM Wiki：一次编译、持续维护（stateful、compounding）
「the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged.」（wiki 是一个持久的、会累积的产物。交叉引用已经建好了，矛盾已经被标出来了。）
Karpathy 的理由是这个：
The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don’t get bored. — Karpathy gist
人会放弃 wiki，因为维护成本超过回报。LLM 不会累、不会忘记更新 cross-reference、可以一次动 15 个文档 —— 维护成本被压到接近零。
所以这个 pattern 的内核不是「让 AI 写笔记」。是「把 bookkeeping 压到接近零，人才有力气思考」。
顺带一提，Karpathy 把这个 pattern 连回 Vannevar Bush 1945 的 Memex 愿景。Bush 80 年前就想做「人的延伸记忆系统」，但他解决不了一件事 —— 谁来维护？Karpathy 对这句话的回答是：
The part he couldn’t solve was who does the maintenance. The LLM handles that.
这个历史纵深让这个 pattern 不只是 2026 年的一时热潮。是一个 80 年前的愿景终于有了答案。
我打开自己在 Obsidian 上的知识管理系统对照 Karpathy 的 gist，骨架几乎一样：
| Karpathy Pattern | 我的 LYT |
|---|---|
raw/（原始来源） | Atlas/Sources/ |
wiki/（LLM 维护的知识页） | Atlas/Dots/ + Maps/ |
| schema 档（规则设置） | CLAUDE.md + 各 SKILL.md |
index.md（索引） | Maps/ MOC |
Karpathy 的 gist 是工具不可知的 —— 他同时列了 Claude Code、OpenAI Codex、OpenCode 等选项。我用 Claude Code，所以对照我这边用 CLAUDE.md。
四个层对到了。但骨架像不代表两条路一样 —— 我用 LYT 半年，搭配 Claude Code 打了一套完整的 AI 工作流，知识库一直在长大，只是长大的方式跟 Karpathy 描述的完全不同。
跑完骨架对照之后，我发现 Karpathy 的 pattern 有几件事是我的系统还没做到的。
Ingest 时的矛盾侦测。新 source 进来，LLM 会比对新信息跟旧 wiki page 的冲突，标出矛盾，留给人判断。我的原子卡片目前不会互相比对。
跨 page 连锁更新。一个新 source 可能同时更新 10-15 张 wiki page。我建新卡时会补链接，但不会动旧卡的内文。
Lint。定期扫整座 wiki 做健康检查 —— 找矛盾、找孤立 page、找过期内容。更厉害的是它会侦测概念缺口：「你在好几个地方提到这个概念，但没有独立的 page」—— LLM 主动建议你建一张。
这些功能技术上都能加进我的系统。但 Karpathy 的贡献是他先把这些想清楚了，然后写成一份任何人都能用的 pattern。
学到了这些之后，剩下一个绕不过去的问题。
LYT 的答案是一个原子概念。一张卡一件事，边界由概念本身决定。好处是归档不用想太多，新东西进来就开新卡。代价是你要掌握一个主题的最新状态，得靠 MOC 和链接自己拼图。
Karpathy 的答案是一个主题聚合。一张 wiki page 是那个主题目前的 best-of 总整理。10 个 sources 可能被 LLM 并进 1-2 张 page。好处是打开一张就看到全貌，不用自己拼。
但我昨天跑 ingest 的时候就卡住了 —— 主题的边界在哪？ 几份 source 该并成一张 page、哪些该独立出来？最后跑出来的数量和边界，都是我临时决定的，不是某个规则告诉我的。
然后我意识到：这个问题我见过。Evernote 时代你在问「这个笔记放哪个 folder」。Notion 早期你在问「这个页面打哪些 tag」。Karpathy wiki 现在在问「这个 source 并进哪张 wiki page」。
三个问题的形状一模一样：对一个新进来的东西，你要决定它属于哪个容器。
卡片盒笔记法的内核概念 —— 原子化 —— 就是在绕开这个问题。一张卡一个概念，链接取代分类。新东西进来，同一个概念就补在旧卡上、不同概念就开新卡。边界由概念本身决定，不用想「归到哪个容器」。我用的 LYT 继承了这个内核，加上 MOC 和 AI 集成 —— 不是 pure Zettelkasten，但原子化的精神是一样的。
Karpathy 的主题聚合是往回走。它用 LLM 的能力把 compound 成本压低，但没解决「容器边界在哪」这个老问题。
容器边界是我自己跑完实验后的观察。但 HN 上还有两层不同角度的反对，攻击的都是人类的懒惰，不是 LLM 的能力。
除了容器边界问题，Karpathy 的 pattern 还有一个更根本的技术担忧。HN 上有人直接点名：
I don’t see why this wouldn’t just lead to model collapse. The compounding will just be rewriting valid information with less sense information.
论点是：LLM 写出来的 wiki 本身就有信息损耗 —— 看起来通顺但细节被磨平、风格被单一化。下次 ingest 时 LLM 会读到旧 wiki + 新 source，等于「LLM 在自己写的东西上再写」。长期下来可能变成平均的平均的平均，细节慢慢消失。这个现象 AI 圈有个名字叫 Model Collapse，2024 年 Nature 的论文 有完整论证。
HN thread 上有反驳的声音，但那些反驳针对的是 LLM 训练场景，跟 Karpathy 的 ingest 场景不完全一样。这个 pattern 会不会真的触发 Model Collapse，目前还没人跑够久可以证明。
这个反对最狠。HN 原文：
Rule of thumb: if you find yourself having to come up with instead of what it helps you produce, ask yourself ‘am I thinking?’
有深度的写作是从 produce（生产）的过程中 come up with（想出）东西。如果你只是让 AI produce、你只负责 come up with 问题，那你可能根本没在思考。
Karpathy 其实在 gist 里有预先反驳这点：
The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means.
「think about what it all means」这句话是他留给人类的。但 HN 的论点是：这是理论上的分工，实际上很少人会做到。
「vibe coding」是一个已经存在的现象 —— 不懂原理就让 AI 写 code，结果能跑但你不懂。HN 担心的是 vibe thinking —— 把「整理」外包等于把「思考」外包，wiki 看起来很有组织但你根本没内化。
这两个反对声音都在攻击人类的懒惰。但对我来说，它们不是真正的问题。
我也懒。但我的防御是前置的 —— 新东西进来先跟 LLM 讨论到我理解，理解完才决定要不要归档。思考在对话里发生，归档是思考完的结果。所以进知识库的每张卡都是我验证过的，LLM 下次读到的不是它自己 compound 出来的东西，Model Collapse 的前提就不成立。Vibe Thinking 也一样，归档是理解完的保存，不是理解前的外包。
而前面提到的矛盾侦测、lint、跨卡改写，我也都准备集成进自己的系统。
真正让我不搬家的原因只有一个：容器。
两条路都用 LLM 做 compound，bookkeeping 成本两边都压得下来。但 Karpathy 的 wiki page 是主题聚合 —— 你要决定主题边界在哪、哪些东西该并进同一张 page。LYT 的原子卡片绕开了这个问题 —— 一张卡一个概念，不用想归到哪里。
如果你有一个明确的主题要长期维护，而且对「这个东西该放哪张 page」这类决策不觉得烦，Karpathy 的 pattern 值得试。去读他的 gist，搭配 Mehmet 的实作文章。
如果你跟我一样，从 folder 出来、从 tag 出来，不想再走进另一个分类系统 —— 那原子化可能更适合你。
我用他的方法研究他的方法，结果没让我换系统。但让我搞清楚一件事：两条路的分歧不在技术，在你对分类的容忍度。
想看我怎么把 LYT + Claude Code 串成一套完整的 AI 工作流？这篇是完整介绍——从每天早上的「开工」到知识库、邮件、会议、目标管理全部串起来。
如果这篇让你有了想法，订阅电子报——我固定写 AI 工作流、和一路上想通的事。
想聊聊怎么把 AI 融入你的工作流？看看我的服务。
常见问题
- Karpathy 的 LLM Wiki 跟 RAG 有什么不同？
- RAG 每次查找重新从 raw 文档找答案，什么都不留。LLM Wiki 让 LLM 把 raw 增量编译成一份持久化的知识管理 wiki，然后一直维护它。差别是时间维度 —— RAG 每次重新推导，wiki 把推导结果存起来持续累积。
- 什么是 Model Collapse？
- LLM 反复读自己写的东西再改写，长期下来细节被磨平、风格单一化 —— 平均的平均的平均。Nature 2024 有论文论证。这是 HN 对 Karpathy pattern 最大的技术担忧。
- 卡片盒笔记法和 Karpathy LLM Wiki 的内核差别是什么？
- 容器。卡片盒笔记法的原子卡片一张一个概念，链接取代分类，不用想「这个东西归哪里」。Karpathy 的 wiki page 是主题聚合，一张 page 装一个主题的所有东西，但你要决定主题边界在哪。这是 folder 和 tag 时代的老问题换了个皮。
- 我该用 Karpathy 的方法吗？
- 问自己一个问题：你对「这个东西该放哪」这类分类决策烦不烦？如果不烦，而且有明确的主题要长期维护，Karpathy 的 pattern 值得试。如果你跟我一样，从 folder 出来、从 tag 出来，不想再走进另一个分类系统，那卡片盒笔记法的原子化路线可能更适合你。
