Karpathy 在做什么

4 月初，Andrej Karpathy 把一份名叫 LLM Wiki 的 idea file 放上 GitHub Gist。几天内，这份文档拿到 5,000+ stars 和 1,900+ forks，热度本身已经说明它击中了很多人心里的一个旧痛点：我们每天都在往 LLM 里塞资料，但大多数问答都像一次性消费，问完就散，下一次还要从头再来。

Karpathy 提出的解法，不是把更多文档塞进一次更长的上下文，也不是再搭一层更复杂的 RAG，而是在原始资料和问答之间，插入一个持续维护的中间层。这个中间层不是向量库，而是一套结构化的 Markdown wiki。原始资料保持不可改动，作为 source of truth；LLM 负责读资料、提炼信息、更新主题页、补链接、标注矛盾、回写查询结果；人类负责选材料、提问题、看更新、改 schema。

这套思路有意思的，不是“Obsidian + LLM”这个包装，而是它把知识管理的重心，从临时检索往持续整理挪了一步。Karpathy 甚至明确说，在中等规模下，大约 100 个 source、几百个页面，index.md 加日志文件就可能先跑起来，不一定立刻需要 embedding-based RAG。这个判断对普通人很重要，因为它把门槛拉回到了个人可以操作的范围。

它瞄准的，其实是那些原本没人愿意长期维护的整理和簿记工作。材料越来越多，真正能复用的结构却一直没长出来，这正是它会火的原因。

它为什么一下子打中这么多人

原因不复杂。很多人不是缺一个更会答题的模型，而是缺一个不会随着聊天窗口关闭就消失的工作表面。

它踩中的，还不只是一个产品点子。过去两年，很多讨论把注意力放在模型参数、上下文长度和 RAG 管线，仿佛知识系统的升级主要靠底层能力扩容。但从工程直觉看，真正折磨人的往往不是“模型知道得不够多”，而是资料管理没有形成复利。你有文章、会议记录、播客笔记、代码决策、手写判断，可它们彼此之间不说话。Karpathy 的文章之所以被广泛转发，是因为它把这个问题命名了。

更妙的是，它给出的入口很轻。它没有要求你先建知识图谱平台，也没有让你先部署一套企业级 infra。它说得很朴素：raw sources、wiki、schema 三层；ingest、query、lint 三个动作；Obsidian 当 IDE，LLM 当维护者，wiki 当代码库。这个比喻一下子让很多人知道该从哪下手。

它会被广泛转发，还有一点很关键：很多人第一次比较清楚地看到，知识也许也能像代码一样被持续重写、对比、回滚和演化。这个想象比任何一句口号都更有吸引力。

评论区真正吵的，不是喜不喜欢

评论区最值得看的，不是喝彩，也不是挖苦，而是很多做过类似系统的人一上来就摸到了边界。

支持者最看重的，往往是那条 compile loop。有人把它直接概括成 “compile, don’t retrieve really clicks”。这类支持不是空泛喝彩，而是来自做过实际工具的人。他们的感受大致一致：当知识不再只是上传后等待检索，而是被持续整理成主题页、关系页、索引和日志时，新会话确实更容易接上旧会话，很多背景不必重复解释。

真正有分量的支持，通常都会跟着一句保留。sage-wiki 的作者在评论区里说得很直白，真正让他“点头”的是 compile loop 会形成飞轮，但接着马上补了一句：真正难的是概念去重，究竟什么内容值得长成一篇独立条目，以及关系提取要做到多细。这个反馈很关键，因为它把讨论从“能不能做”拉回到“怎样才不失控”。

质疑也很集中，而且都打在硬处。

  • 第一，出处追踪不够硬。评论区有人明确指出，如果把 PDF 编译成 wiki 条目，模型默认会改写、压缩、合并，页码和段落级出处很容易丢失。对于科研、法律、医学这类高要求场景，“没有幻觉引用”更多是一种愿望，而不是技术保证。
  • 第二，记忆形成规则不清。也有做 agent memory 的开发者指出，这类 schema 大多在讲“如何表示记忆”和“如何使用记忆”，但真正更难的是：什么触发一条记忆诞生，什么证据能让它升级成长期知识，它的有效性由谁评估。这个过程很难完全自动化。
  • 第三，社区对“自动化注水”的担忧并不小。评论区里那句带刺的 “slop machine” 虽然有情绪，但它打到的问题是真实的。如果一个系统只会不停把摘要、比较、派生页面往库里回写，却没有严厉的淘汰和校验机制，知识库就会很快从资产变成噪声堆。

所以，争论的重点并不是喜不喜欢 Karpathy，而是这套东西最后会把知识管理做成复利，还是把信息过载自动化。

研究给它撑腰，也给它泼冷水

把评论区先放一边，再看几篇近两年的研究，轮廓会稳很多。

微软研究院在 GraphRAG 里指出，baseline RAG 在两类问题上表现很差：一类是需要把分散信息“连点成线”的问题，另一类是需要对大规模材料做整体理解的问题。这和 Karpathy 的直觉是同方向的。很多真正有价值的问题，不是“从哪一段里找答案”，而是“若干段之间的关系已经被谁提前整理出来”。如果没有中间层，你每问一次，模型都在重新拼装。

再看 Agent KB。这篇 2025 年论文的重点，不是个人知识管理，而是跨任务复用经验。它把高层策略和执行日志一起沉淀到共享知识库里，在 GAIA 和 SWE-bench 等任务上带来明显提升。对这篇文章来说，它最重要的启发不是数字本身，而是一个更底层的判断：外部化、可复用、能跨轮次调用的经验结构，确实可能给 agent 带来实质增益。也就是说，知识库不是伪命题。

MemGPT 则提醒我们，记忆不是“都塞进去”这么简单。它把上下文管理比成操作系统的分层内存，核心思路就是不同信息要放在不同层级，不该都挤在前台窗口里。这个思路和 LLM Wiki 很兼容，也正好说明一个事实：知识库不是越大越好，关键是哪些信息该进入长期层，哪些只该留在工作层，哪些应该被忘掉。

但研究带来的冷水也很直接。

Lost in the Middle 说明，即便模型有长上下文能力，也不代表它能稳定利用长上下文。相关信息放在中间位置时，性能会明显下降。这意味着“把所有资料塞进大上下文里直接问”并不稳。这支持了 Karpathy 对编译式中间层的偏好，但也反过来提醒我们：如果你的 wiki 自己变成一份超长、结构混乱、重复堆叠的文本，模型一样会读不明白。

RAGChecker 则指出，RAG 系统评估之所以困难，是因为它是模块化系统，还涉及长答案和测量可靠性问题，所以必须把检索模块和生成模块拆开诊断。这个结论对 LLM Wiki 更重要。因为一旦你允许模型把查询结果、比较结论、关系抽取再写回 wiki，错误就会沿着“读取错误资料 -> 生成错误摘要 -> 回写错误页面 -> 下次再拿错误页面当依据”这条链传染。换句话说，Karpathy 解决了“知识不积累”的痛点，但没有自动解决“错误也会积累”的问题。

所以，研究层面的结论并不神秘：编译式知识中间层有前景，但要成立，必须同时解决结构、评估、记忆分层和出处追踪；只靠“让模型多写几个 Markdown 文件”，根本不够。

普通人该学的，不是“建一个更大的库”

很多人看完 Karpathy 的文章，第一反应是开始想象一个覆盖自己全部阅读、工作、生活、健康、投资、职业和日记的超级知识库。我的建议正相反。普通人最该学的，不是“做大”，而是先把 LLM 从一次性回答器，变成长期整理器。

这个差别听起来小，实际上很大。

如果你把 LLM 当回答器，你的目标是尽快得到一个像样的答案。你会自然追求更多资料、更长上下文、更快生成。可如果你把 LLM 当整理器，你关心的就变成：这次读完一批材料之后，究竟沉淀出了什么结构，哪些概念被澄清了，哪些分歧被显性化了，哪些判断需要下次继续追，哪些结论应该暂时挂起。

普通人能拿走的，大概有三点。

  • 第一，知识管理的真正单位不是“收藏”，而是“结构变化”。一篇文章值不值得进库，不在于它是不是热门，而在于它会不会改变你现有的某个主题页、比较页、结论页。
  • 第二，好的知识库不追求全，而追求复用。只要某个主题未来三个月你还会反复问、反复比较、反复修正，它就值得建；如果只是看个热闹，临时聊天比建库更划算。
  • 第三，人的角色没有消失，只是从记笔记的人，变成定义边界、审出处、做裁剪的人。Karpathy 自己在原文里也没有说“我完全不管”，他反而强调自己更喜欢一次 ingest 一个 source，并且一直参与摘要审看和重点引导。

普通人真正该带走的，不是“终于能把第二大脑外包给 AI”，而是“终于能把过去太碎、太烦、没人愿意维护的整理工作自动化一部分”。边界感比幻想重要。

怎么用，才不至于越做越累

真想试的话，先守住四条线。

1. 先限定题目，再谈知识库

不要从“人生知识库”开始。先从一个未来 6-12 周会反复用到的题目开始，例如：

  • 正在持续研究的一个行业主题
  • 一门准备系统学习的课程
  • 一个跨几周推进的项目
  • 一本值得做深读的书
  • 一类会反复出现的家庭或健康记录

题目小，结构才会长得出来。题目太大，系统只会变成更精致的仓库。

2. 原始材料必须不可改，派生内容必须可回溯

Karpathy 原文里最值得照抄的，不是 Obsidian，而是三层结构。普通人也该坚持这个边界：

  • 原始材料单独放，永远不让模型改。
  • 派生页面单独放，明确标出来自哪些 source。
  • 每次重要更新都记日志，知道哪天因为哪份材料改了什么判断。

如果一条结论已经找不到它最初来自哪份材料，这个库很快就会失去可信度。

3. 不是所有问答都值得回写

回写是这套方法最诱人的地方，也是最危险的地方。一个简单标准是：只有当某次问答满足下面三个条件，才值得回写成页面或更新已有页面。

  • 它整合了不止一个 source
  • 它改变了现有结构，而不是重复现有结论
  • 你愿意在一周后再看它一次

很多即时问答应该留在对话里结束，不要为了“积累”而硬塞回知识库。否则你积累的不是知识，而是派生噪声。

4. 必须定期做 lint，但 lint 不只是查死链

Karpathy 把 lint 说成健康检查，我很赞同，但对普通人来说，lint 最重要的不是技术整洁，而是内容清洁。每周至少扫一次：

  • 哪些页面只是同义改写，应该合并
  • 哪些判断已经过时，应该降级
  • 哪些高频结论没有足够出处
  • 哪些条目长期没人再问，可以归档
  • 哪些主题页已经太长，需要拆分

如果没有删减动作，知识库迟早会败给自己的体积。

更稳的玩法：把它当研究台，不要当人生总库

对大多数普通人，最稳的用法不是照着 Karpathy 的设想做一套总库，而是把它当一个个有限周期的主题研究台。

比如你最近三个月想搞清楚“AI coding agent 到底会如何改变开发者工作流”。你可以这样做：

  • 建一个只服务这个主题的 raw 文件夹
  • 每次只加少量高质量 source，不追求全网搬运
  • 让 LLM 维护 主题页、玩家页、争议页、时间线、未解决问题
  • 每次提问优先要求它更新现有页，而不是新建更多页
  • 每周做一次清理，删重复条目，补遗漏出处
  • 到研究周期结束时，导出一份结论页和一份仍待观察的问题页

这样做有个好处：你的知识库不会一路失控地膨胀。它像一个项目工作台，有开始、有积累、有收束。完成一个主题后，你可以归档，再开下一个，而不是试图用一个系统吞掉生活中的一切。

普通人最容易犯的错，是还没从一个问题里得到真正的判断，就先迷上了维护知识系统本身。系统一旦比问题更重要，知识管理就会变成新的拖延形式。

哪些时候不要用

Karpathy 的文章很容易让人兴奋，但这套方法并不适合所有场景。

第一，不适合要求页码级、段落级、逐句可追责的严肃引文任务。评论区里对 page-level citation 的担忧完全成立。只要模型在中间做了改写和归并，你就不能把它当成严格的引文器。

第二，不适合高度时效、强事实性的即时决策任务，比如实时行情、法律条文更新、药物与疾病建议。知识库的长处是结构化沉淀，不是替代即时核验。

第三，不适合你自己其实没有复用需求的主题。很多人不是缺知识系统，而是缺更少的输入。一个不会被反复调用的问题，不值得进入持续维护流程。

第四，不适合完全放手。只要你不愿意抽样检查摘要、关系和出处，这个系统最后大概率会把你的偏差自动制度化。

这些边界听起来不热血，但比热情重要。

最后的判断

我对这篇热文的看法很简单：值得认真看，但别带着神话去用。

我愿意认真看这篇文章，是因为它抓住了今天 LLM 使用里一个很真实的断层。我们的问题从来不只是“怎么把资料检索出来”，还包括“怎么把一次次阅读、比较、追问和修正沉淀成能继续复用的中间结构”。在这一点上，LLM Wiki 比很多只谈参数和上下文长度的讨论更接近真实工作。

但也别太快把它当成新的知识宗教。只要把材料持续喂给模型，一个会自我生长、自我校正、自我清理的第二大脑就会自然出现，这种想法太轻松了。研究和评论区都已经说明，出处、评估、分层、去重、忘记和人工复核，一个都不能少。

所以，普通人最好的姿势不是膜拜，也不是冷嘲热讽，而是小范围试。先找一个你真的会反复使用的题目，让 LLM 帮你做最枯燥的整理和维护，再看看它有没有让你更快形成判断，而不是让你更忙。

如果最后这个系统没让你更快形成判断，只让你多了几百页看不完的 Markdown，那它就不是知识库，它只是更高级的信息堆积。真正值得追的，不是库越来越大，而是你越来越少需要从头想同一个问题。