Karpathy 的 LLM Wiki：把知识组装提前到提问之前

2026 年 4 月 2 日，Andrej Karpathy 在 GitHub 上发了一份 Gist，文件名朴素得不能再朴素——llm-wiki.md。没有代码，没有产品，他自己把它叫做「idea file」（点子文件）：一份可以直接粘贴给任何 LLM Agent 的指令，教它如何为你维护一部个人 wiki。

几周之内，这份单个 Markdown 文件收获了 5000+ star，Hacker News 上的讨论盖到近 300 分，各种语言的复刻、教程、扩展层出不穷，有人把它称作「2026 年最有影响力的 Agent 记忆文档」。一个没有任何代码的「点子」为什么能火成这样？因为 Karpathy 用一句话戳破了过去几年外挂知识方案的窗户纸：

知识应该在提问之前就被组装好，而不是在提问的那一刻现场拼装。

这篇文章试着把这条思路放回它的时间线里：它从哪来，撞上了什么，又可能把我们带去哪里。

前史一：RAG 统治的六年

要说清 LLM Wiki，得先回到 2020 年。那一年 Facebook AI 的研究者提出 RAG（检索增强生成），思路非常直接：模型的参数里装不下的知识，就在提问时去外部语料库里现查——把文档切块、向量化、存进向量库，查询时检索最相关的几段塞进上下文，让模型现场合成答案。

这套范式有效、通用、工程门槛可控，此后六年几乎成了「给 LLM 外挂知识」的默认答案。2024 年前后微软的 GraphRAG 又把知识图谱引入检索，用实体关系网络弥补向量检索「只见碎片、不见全局」的缺陷，社区里检索优化的文章汗牛充栋。

但无论怎么优化，RAG 有一个从未改变过的本质：知识在库里始终是原始形态。文档还是文档，碎片还是碎片，每次提问都是一次性的现场拼装——检索、拼接、生成，用完即弃。同一类问题问一百遍，模型就把同一段资料重新读一百遍、重新组装一百遍。知识从未被真正「整理」过，自然也谈不上积累和生长。

前史二：Agent 记忆的暗线

与此同时，另一条线索在悄悄生长：给 Agent 装上跨会话的长期记忆。

2023 年的 MemGPT 把 LLM 类比成操作系统，用分层分页的方式管理记忆，核心团队后来成立了 Letta；
Mem0 走「提取—归并—检索」路线，从对话中抽取事实、去重合并、按需召回，开源仓库积累到四万多 star，还发了正式论文；
Zep 的 Graphiti 用带时间戳的知识图谱做时序记忆，被视作 GraphRAG 思路在记忆场景的延伸。

这条线里最值得注意的声音来自 Letta。他们发布的基准测试 Is a Filesystem All You Need? 给出了一个略带挑衅的结论：对很多任务而言，让 Agent 直接在文件系统上读写组织记忆，效果优于精心设计的向量库方案。社区里「Agent 记忆是不是换皮 RAG」的争论吵了一年没有定论，但所有人都在等一个能把这件事讲清楚的叙事。

然后 Karpathy 来了。

LLM Wiki 到底是什么

Karpathy 的 Gist 说的事情，拆开看简单得出奇：

建一个普通文件夹，放一个 index.md 作为全库入口和地图；
把 Gist 里的指令粘给任意一个足够强的 Agent（Claude、Codex 或本地模型都行）；
之后 Agent 在你丢给它的文档、对话、资料上持续工作：主动撰写条目页、更新过期内容、维护页面之间的互相链接，并把新条目登记进 index.md；
你提问时，Agent 先读索引，再读相关条目页，用已经整理好的成品知识回答你。

没有向量库，没有 Embedding 管线，没有检索服务，全部家当就是一堆 Markdown 文件。Data Science Dojo 对它的定义可能是最准的：「一个由 AI Agent 主动构建和维护的持久知识库，让知识随时间复利」。

和 RAG 的本质区别

维度	RAG	LLM Wiki
知识形态	原始文档的向量碎片	整理成品条目，互相链接
整理时机	从不整理，查询时现场拼装	查询之前持续组装
查询动作	相似度检索 top-k 片段	读索引，读成品页
人类可读性	不可读（向量+切片）	完全可读、可改、可迁移
知识演进	语料不变则答案不变	条目持续更新，越用越厚

一句话：RAG 是把图书馆搬进考场，LLM Wiki 是让 Agent 提前替你把书读完、做好笔记，考试时只翻笔记。

为什么偏偏是现在

这个想法并不全新——「让模型维护结构化笔记」十年前就有人设想。它在这个时间点爆发，是因为几股力量恰好同时就位：

Agent 的文件操作变得可靠了。 coding agent 一代代迭代下来，「让模型读写文件、管理目录」从玄学变成了基本功；
Markdown 成了人机共享的最小公约数。 人能读能改，Agent 能写能链接，GitHub、笔记软件、博客系统全都原生支持；
长上下文降低了索引的门槛。 万字级上下文让「读索引再读条目」这种朴素策略足够好用；
大家对基础设施疲惫了。 不用再为每个知识库项目搭向量库、调 Embedding、优化召回，一个文件夹就是全部。

爆发：从一个点子到一个生态

Gist 发布后的两个月里，这个「点子」长出了一个生态。

有人把它实现了两遍，一遍按原样跑、一遍改写成代码，写成对比文章；有人发布了 LLM Wiki v2，融入自己构建 Agent 记忆的实战经验；读书场景的变体（booknotes）把整本书沉淀成笔记库；还有项目给它配上本地 SQLite「大脑」和 MCP 服务器，让 wiki 可以被多个工具共享调用；TiddlyWiki 社区讨论怎么把老牌个人 wiki 和这个模式接起来；NousResearch 的 Hermes Agent 干脆把它内置成默认能力。研究机构 aaif.io 则指出：Karpathy 从没把它包装成 Agent 记忆架构，但它几乎完美地映射了 Agent 记忆在实践中真正需要的样子。

同一条时间线上的另一场战争：公共百科

把镜头从个人知识库拉远，同一时期的公共知识库战场上，正上演着 LLM Wiki 的镜像故事——方向完全相反的一极。

Grokipedia：单一公司能否发行「真实」

2025 年 10 月 27 日，马斯克旗下的 xAI 上线了 AI 生成的在线百科 Grokipedia，公开的理由是「对抗维基百科的意识形态偏见」。但质疑声几乎立刻跟上：DW、《世界报》、NPR 等媒体的实测与追问指向同一个担忧——由单一公司训练、单一价值观校准的 AI 百科，凭什么比数万名志愿者吵架吵出来的共识更中立？2026 年 8 月，Lawfare 的报道又揭出更实际的问题：Grokipedia 在当年 4 月悄悄停止了人工审核改动，而且没有告知用户。

Wikipedia 的重负与反击

被对标的一方也不好过。Pew 的统计显示，2025 年全年爬虫和 AI 系统对维基百科的访问超过 880 亿次——志愿者维护的公共知识库，事实上成了整个 AI 互联网的免费供水系统。与此同时，AI 生成的低质量内容（AI slop）开始涌入编辑队列：第三方统计称 19 个月里有 7600 多个页面被标记为疑似 AI 生成文本，其中 99.5% 发生在 2025 年 8 月之后。

维基百科的回应是收紧。社区在 Wikipedia:Large language models 政策页下持续激辩，2026 年上半年编辑者投票明确拒绝了「让 AI 直接写条目」的路线，AI 生成文本不得直接进入条目。有意思的是，维基并没有一刀切地排斥 LLM：韩文维基社区开发的 WikiVault 就用 LLM 辅助翻译，成了社区自用 AI 工具的正面案例。

而 2026 年 7 月一篇题为《Small edits, large models》的论文揭示了这场攻守战真正的赌注：一小群志愿者对维基条目的修改，会顺着训练语料和检索锚点，实实在在地塑造各大 AI 系统对这些话题的叙述。**维基百科是 LLM 的上游水源。**这就让「AI 生成的内容污染维基」有了一层讽刺的循环意味：模型喝着自己的回流水，越喝越浑。

写在最后：知识复利与知识信任

把两条线放在一起看，LLM Wiki 的走红就不只是一个技术热点了。

个人这一侧，它把 Agent 的角色从「问答机器」换成了「知识园丁」。问答机器的产出是消耗品——答案看完就忘；园丁的产出是资产——每次交互都让知识库变厚一点，下一次的起点更高一点。这正是「复利」的本义。顺带一提，这篇博客本身就是我用 Agent 按固定工作流写的，写作规范、发布流程这些沉淀下来的文档，本质上就是一部小 wiki——这种「把经验固化成 Agent 可读的结构」的做法，正在变成一种通用的干活方式。

公共那一侧，Grokipedia 和 Wikipedia 的攻守则提醒我们：AI 能生成百科，但生成不了共识。维基百科真正稀缺的从来不是文字，而是那套「人人可查证、争议可追溯、偏见可制衡」的问责机制。在生成成本趋近于零的时代，人类审核不是被淘汰的旧流程，而是越来越贵、也越来越值得守护的稀缺品。

想上手试试的话，门槛低到不像话：新建一个文件夹，放一个空的 index.md，把 Karpathy 的 Gist 粘给你的 Agent，然后把你手头的资料丢给它。今天种下的第一条目，就是复利的第一个计息周期。