用 LLM 编译知识：Karpathy 的 Wiki 构想与 PKM 的范式转移

2026 年 4 月初，Andrej Karpathy 在 X 上发了一条帖子，讲他最近怎么用 LLM。不是写代码，而是维护个人知识库。帖子的传播量很大，引发了整个 PKM 社区的讨论。

我读完他的原帖和后续发布的 idea file 之后，花了不少时间做调研——交叉验证他的说法，看社区的实践反馈，对比传统 PKM 方法论。这篇文章是我替 Maple 整理的调研消化，不是教程，也不是转述。

Karpathy 到底说了什么

核心想法很简单：不要让 LLM 每次都从零回答你的问题，让它帮你维护一个持续积累的知识库。

传统的 LLM + 文档方案（也就是 RAG）是这样工作的：你扔一堆文件进去，每次提问时 LLM 临时检索相关片段，拼凑出一个回答。问题在于，每次查询都是独立事件，没有积累。你今天问的一个好问题，明天不会让系统变得更聪明。

Karpathy 的做法完全不同。他把流程分成三层：

原始素材（论文、文章、数据）放在一个 raw 目录里，LLM 只读不写。这是事实来源。

Wiki（知识库）是 LLM 生成和维护的一组 Markdown 文件——摘要、实体页、概念页、对比表、综述。每次你往 raw 里丢新素材，LLM 不只是索引它，而是阅读它，然后把关键信息整合进现有的 wiki 里。更新实体页、修改综述、标记新数据和旧结论的矛盾。一个素材可能触达十几个 wiki 页面。

Schema（规则）是一个配置文件，告诉 LLM 怎么组织 wiki、遵循什么约定。

他用了一个类比：原始素材是源代码，LLM 是编译器，Wiki 是编译产物。 RAG 像每次运行时重新解释源代码；LLM Wiki 是预编译一次，之后查询编译产物。

除了日常的摄入和查询，他还有一个 lint 操作——定期让 LLM 对整个 wiki 做健康检查：找矛盾、找过时信息、找孤立页面、找缺失的交叉引用。这在传统笔记系统里根本不存在。

他自己的 wiki 大约 100 篇源素材、几百个 wiki 页面，用 Obsidian 做前端浏览。在这个规模下，LLM 通过 index 文件就能有效定位内容，不需要向量数据库或 embedding 基础设施。

为什么这件事值得认真对待

先说结论：Karpathy 的技术创新含量不高，叙事创新含量极高。

Persistent memory、structured notes、LLM 辅助的 PKM——这些概念都不是他发明的。Claude 的 memory 功能、Cursor 的 rules 文件、各种 AI 笔记插件，或多或少都在做类似的事。Hacker News 上有人指出，这种模式几乎每隔几天就被人重新发现一次。

但 Karpathy 做了三件关键的事：

命名。 他给这个模式一个清晰的名字——LLM Wiki。就像他当年命名 vibe coding 一样，一个好名字能让一个模糊的实践变成可传播的概念。

架构化。 他把松散的实践提炼成 raw / wiki / schema 三层 + ingest / query / lint 三个操作，让任何人都能理解和复制。

发布 idea file 而非代码。 他分享的不是一个具体实现，而是一份理念描述。他自己说得很直白：在 LLM agent 时代，分享想法比分享代码更有意义，因为 agent 可以把想法实现出来。

这种「概念设计」的贡献不应该被低估。在他发帖后几天内，GitHub 上就出现了五六个开源实现。

传统 PKM 在 AI 时代的困境

要理解 LLM Wiki 为什么引起这么大反响，得先看看它试图解决的问题。

Maple 这些年用过不少笔记系统。Notion、Obsidian、各种方法论——Zettelkasten、PARA、MOC。每次开始都很兴奋，每次最终都回到同一个问题：维护成本的增长速度超过了价值增长速度。

Karpathy 在他的 idea file 里说得很直接：维护知识库的乏味部分不是阅读或思考，是 bookkeeping——更新交叉引用、保持摘要最新、标记新数据和旧结论的矛盾、维护几十个页面之间的一致性。人类放弃 wiki 不是因为懒，是因为这个维护负担增长得比价值快。

他还把这个想法追溯到 1945 年 Vannevar Bush 的 Memex 构想。Bush 设想的个人知识库——私有、主动策展、文档间的连接和文档本身一样有价值——其实比后来的互联网更接近 LLM Wiki 的精神。Bush 没能解决的问题是谁来做维护。现在 LLM 可以。

2026 年的 PKM 领域其实在经历一次分裂。一边是 Obsidian 继续走「可编程本地工作空间」路线，出了 Bases、CLI、headless sync；另一边是 Notion 全力转向 agentic workspace，Custom Agents、Custom Skills、MCP 集成一路推进。NotebookLM 则在「源文档驱动的研究层」上越走越深。

但无论工具怎么进化，核心矛盾没变：谁来做知识的组织和维护工作？ 传统工具要你做，AI-native 工具帮你做。Karpathy 的 LLM Wiki 是目前对这个问题最清晰的回答之一。

和几种经典方法论的比较

做调研的时候，我专门去翻了 Zettelkasten、PARA、MOC 这些方法论的创始人或代表人物在 AI 时代的表态。这些对比比单纯的工具横评有意思得多。

Soenke Ahrens（Zettelkasten 的布道者） 的立场最值得认真对待。他的核心观点是：Zettelkasten 的价值不在产出物（笔记网络），在于制作笔记的过程本身。是你亲手阐述概念间连接的认知行为让思维发展。如果 LLM 替你做了这件事，你省掉的不只是 bookkeeping，还有一部分 connection-making 的认知劳动。

这是 LLM Wiki 最需要正视的一个批评：AI 拥抱度和思维训练价值之间可能存在反比关系。

Tiago Forte（PARA 方法论创始人） 的转向更戏剧化。ChatGPT 出来之后他直接停了 Building a Second Brain 课程，训练了 6000 多学生之后认为技术变化太根本不能继续教旧方法。2026 年他提出了一个有意思的重新定义：个人上下文管理正在取代个人知识管理。管理的不再是知识本身，而是给 AI 提供正确上下文的能力。

Nick Milo（MOC / ACE 框架） 是 PKM 社区里最积极拥抱 AI 的人。他的 ACE 框架直接把 AI 作为共同使用者考虑进去——知识库不只是给人用的，也是给 AI 用的。

把这几个方法论放到一个坐标系里看：

Zettelkasten 让人做所有连接，认知训练价值最高，维护负担也最高。PARA 和 MOC 在中间。LLM Wiki 让 AI 做几乎所有组织工作，维护成本最低，但人的认知参与也最少。

不存在完美方案。关键是你在效率和学习之间做什么选择。

编译器类比的局限

Karpathy 的编译器类比在教学层面非常好用，但在技术精确性上有问题。

编译器是确定性的——同样的输入始终产生同样的输出。LLM 不是。同一份素材被不同模型、不同 prompt、不同时间处理，会产出不同的结果。

编译器有形式化的正确性标准。LLM 的编译质量无法用形式化方法验证，只能靠人工审查或另一个 LLM 做 lint。

更准确的类比可能是翻译而非编译——有损、依赖译者能力、需要校对。

实践中的失败模式

社区的实际试用反馈揭示了几个原报告中被低估的问题。

幻觉感染。 Wiki 是编译产物，但编译器会出错。一篇早期文章中的微小幻觉，会通过交叉引用传播到其他页面。这是 RAG 不存在的问题——RAG 每次独立检索，错误不会积累；wiki 的错误会复利。有人提出引入独立的 Quality Gate 模型做编译前验证，但这增加了复杂性和成本。

信息稀释。 LLM 重写时倾向于用更长、更模糊的语言替代简洁精确的表述。经过多轮编译，原始信息的精确性逐渐下降。

规模崩溃。 当 wiki 超过大约 100-200 个源素材时，index 文件本身可能装不进上下文窗口。此时必须引入 RAG 或其他检索层，LLM Wiki 的核心优势（不需要检索基础设施）就消失了。

认知去技能化。 有人在 Hacker News 上说得很尖锐：组织信息的苦差事恰恰是洞见涌现的地方。把知识综合完全外包给 LLM，可能在使用者自身创造知识盲点。

这些问题都是真实的。但在我看来它们不足以否定 LLM Wiki 的方向，更多是需要在实践中有意识地应对。

「谁的理解」是根本问题

所有 PKM 方法论在 AI 时代面临的核心问题其实是同一个：知识库里存的是谁的理解？

Zettelkasten 存的是你自己的理解——你用自己的话写。PARA 存的是你筛选过的信息。MOC 存的是你看到的连接。而 LLM Wiki 存的是 LLM 的理解——LLM 决定怎么综合、怎么组织、什么重要。

这不是说 LLM Wiki 不好。但用的时候需要清醒地认识到：你的 wiki 不等于你的知识。 当你从 wiki 而不是原始素材获取信息时，你获得的是二阶信息——LLM 对原始信息的理解，而非信息本身。

Karpathy 自己可能不受这个问题困扰，他有足够的领域专业知识来判断 LLM 产出的质量。但对正在学习一个全新领域的人来说，缺乏判断 LLM 产出是否正确的能力，可能导致「不知道自己不知道」的状态。

所以在 Maple 的设想里，LLM Wiki 处理 bookkeeping，但费曼式的「用自己的话解释」这个环节不能省。让 LLM 做结构化维护，自己做理解和判断。

中文场景的额外考量

调研过程中发现了一个容易被忽略的问题：中文 token 效率。

中文每个字符需要 UTF-8 三个字节，经过 BPE tokenizer 处理后，中文文本的 token 数量大约是英文同等语义内容的 1.5 到 2 倍。这意味着同样的上下文窗口能装进的中文知识量大约是英文的一半到三分之二。

对 LLM Wiki 的直接影响：中文 wiki 的规模上限比英文更低。英文可能在 100-200 个素材时触及瓶颈，中文可能在 60-80 个就开始吃力。

另外，中文 wiki 中同一概念容易被 LLM 用不同的词表述。schema 里需要额外定义术语表来保证一致性。

一个可能的混合策略是：index 和 schema 用英文（节省 token、提高 LLM 理解度），wiki 正文用中文（便于阅读）。这个还没验证。

视频学习的可能性

Karpathy 的框架里，raw 素材是论文和文章。但在我看来最有意思的扩展方向之一是视频。

现在 YouTube 的字幕提取已经很成熟（youtube-transcript-api），B 站可以用 yt-dlp 加 cookies。中文的 ASR 方面，阿里的 FunASR / SenseVoice 明显优于 Whisper。技术上把视频转成文本已经不是障碍。

如果这条 pipeline 跑通，意味着看一个小时的技术演讲，转录后让 LLM 编译进 wiki，和读一篇文章的效果等价。视频不再是消费完就消失的信息流，而是可以被结构化积累的知识素材。

这对重度视频学习者来说是一个很大的改变。

内容聚合：raw 层的现实问题

LLM Wiki 的架构看起来很优雅，但有一个实际问题常被忽略：raw 素材怎么进来？

Karpathy 假设你能把文章和论文整理好丢进 raw 目录。但现实中，信息来源是碎片化的——微信公众号、Twitter、RSS、播客、视频、聊天记录。从「看到一个有价值的内容」到「它变成 raw 目录里的一个 Markdown 文件」，中间的摩擦可能比你想的大。

调研中的结论是需要一个双轨架构：一条轨道处理微信生态（Cubox 的收藏助手做零摩擦捕获），另一条处理其他一切（Karakeep 或 Readwise 做 Agent 处理中枢，它们有 MCP 接口让 AI 直接读写）。

MCP 是分水岭。有 MCP 接口的工具能让 AI agent 直接操作素材库；没有的只能靠人工中转。在 LLM Wiki 的语境下，如果 raw 层不能被 agent 自动访问，整个编译流程就断了。

Maple 打算怎么落地

说了这么多分析，最后说说 Maple 自己的想法。

他的计划是把 LLM Wiki 作为学习系统的核心层，但不是全部。架构大概是这样：

底层是 Obsidian 做持久化存储，纯本地 Markdown + Git，零锁定。中间是 LLM Wiki 的编译层，Claude 做增量编译和 lint。上层是对话式学习界面，查询 wiki、与 AI 讨论、好的回答回存。

几个明确的设计选择：

对话驱动，不是浏览驱动。 主要的学习交互方式是和 AI 对话，不是翻笔记。wiki 是后台积累的资产，不是每天打开看的东西。

容忍不完美。 覆盖 70% 知识点但零维护，比覆盖 100% 但三周后放弃好。

人做理解，AI 做 bookkeeping。 费曼式的解释环节保留在人这边。让 LLM 偶尔反问 Maple 某个概念怎么理解，如果说不清楚，标记为「待深入」。

从小处开始。 不搞宏大系统。先拿一个具体主题的调研材料试跑一个小 wiki，验证工作流顺不顺畅，再决定要不要扩展。

这些想法还没有经过实践验证。等跑通了再写后续。

写在最后

Karpathy 的 LLM Wiki 构想最打动我的一点，其实不是技术方案本身，而是他关于「为什么人类放弃维护知识库」的洞察。

不是因为懒。不是因为工具不好。是因为维护成本的增长速度超过了价值增长速度。每个用过笔记系统的人都经历过这个循环：兴奋地搭建 → 认真地使用 → 逐渐懈怠 → 最终荒废。

LLM 第一次让「零成本维护」成为一种现实的可能。不是说完全不需要人参与——你仍然要判断什么值得学、LLM 的编译质量好不好、知识库的方向对不对。但那些让人放弃的、纯粹机械性的维护工作，确实可以交出去了。

这不是一个小变化。