LLM Wiki的起源：Karpathy 重新定义个人知识管理
2026年4月，OpenAI创始成员、特斯拉前AI总监Andrej Karpathy在X上分享了一套自己正在实践的工作流，称之为“LLM Wiki”。这条帖子在X上浏览量超过1700万，引发了整个开发者社区的广泛讨论。
Karpathy将这套想法整理成一份gist（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）进行分发。他在其中提出一个判断：在LLM Agent时代，分享具体代码或应用的意义正在变弱，现在只需要分享想法，把它交给Claude、Grok等Agent，它就可以根据你的需求自动搭建一个属于你自己的个人知识库。
这不是一个具体的工具或软件，而是一种元框架（meta-framework）——它不依赖某个具体模型或技术栈，而是在尝试定义一种人类与AI协作管理知识的方式。
估计很多老一点的程序员可能对wiki这个词很熟悉！维基百科就是这样做的。你也可以把LLM Wiki理解成给Agent用的一个“维基百科”。（说完这个，年龄立马暴露了
）
01
—
需要从RAG的困境说起
LLM领域的知识层出不穷，RAG还都没有用明白呢！LLM Wiki又出来了。但是这个LLM Wiki还真应该了解了解，它不是一个赶时髦的概念，也许真的会成为Agent知识管理中一个非常重要的技术。
要理解LLM Wiki的价值，首先要看清当前主流方案RAG的局限。
目前我们使用LLM处理文档的方式，本质上类似于RAG（检索增强生成）：上传一组文件，模型在查询时检索相关片段，然后生成答案。NotebookLM、ChatGPT的文件上传功能，以及大多数企业级RAG系统，都遵循这一模式。
Karpathy指出了RAG的根本问题：每一次提问，模型都在从零重新发现知识，重新拼凑。
如果你问一个需要综合五篇文档才能回答的复杂问题，模型每次都要重新定位、拼凑相关片段——没有任何东西被沉淀下来。Karpathy的原话是：“没有积累”（There's no accumulation.）
用计算机科学的术语来说：RAG表现得像解释器——运行时重新求值一切。
—
从“解释器”到“编译器”
LLM Wiki提出的是一种完全不同的思路：不是在查询时从原始文档中临时检索，而是让LLM逐步构建并维护一个持续存在的、结构化、相互链接的Wiki。不是让人来手动构建wiki，而是让大模型根据设定的格式和目标，来自动创建这个wiki。
Karpathy引用了一个程序员一听就明白的类比：RAG像解释器，LLM Wiki像编译器。
编译器做什么？它把源代码预先处理成可执行的程序，之后每次运行都基于编译产物，而非反复阅读源代码（Java就是这样处理的）。
LLM Wiki同理——将原始资料预先“编译”成结构化的Markdown Wiki，后续所有检索都基于这个编译产物展开，而非反复阅读原始材料。
03
—
LLM Wiki的架构设计
LLM Wiki采用清晰的三层架构：
第一层：原始资料（Raw Sources）——不可变层
将所有原始资料（论文、文章、PDF、网页剪藏等）放入raw/目录。这一层是不可变的——LLM只读取，绝不修改。这是事实基准，如果Wiki出了问题，可以从原始素材重建。
第二层：Wiki——已编译的知识图谱
LLM读取raw/中的素材后，主动“编译”出一整套结构化的Markdown Wiki。包含实体页面（人物、公司、论文）、概念页面（思想、方法、框架）、主题摘要、对比表格等，并构建一个全局视图index.md，这个全局视图就是将来Agent用来定位wiki页面的目录。
第三层：Schema——行为契约（可选）
通过SCHEMA.md或AGENTS.md等配置文件，定义知识库的主题边界、写作风格、知识粒度，约束LLM提炼知识的方向，保证全站风格统一。
04
—
查询知识
用户提问后，Agent的工作路径如下：
完整读取顶层索引
index.md——这相当于知识库的“目录”，列出了所有页面标题与核心摘要根据摘要自主判断哪些页面与问题相关
读取相关Wiki页面的完整全文——注意，不是碎片化的chunk，是完整的、结构化的页面
沿
[[wikilink]]进行多跳推理——从一个页面跳到另一个页面，通过知识网络完成深度推理基于完整的上下文生成答案
这一过程零向量检索、零分块、零碎片割裂，是LLM Wiki最纯正的原生使用方式。Agent不再像传统RAG那样从原始文档中拼凑片段，而是在一个已经编译好的、结构清晰的知识库上进行查询和检索。
05
—
知识库的自我生长
Karpathy反复提到“compounding（复利） ”一词。
标准个人知识管理工作流中，信息的增长充其量是线性的——收藏了200篇文章，190篇原封不动地躺着。知识不会自己相互关联，每次需要用到时，结构都得手动搭建。
LLM Wiki改变了这一点。模型不只是写一个摘要页面，它会通读整个现有Wiki，找出新内容与已有实体页面、概念页面的交集，然后更新所有相关内容。
每一个新输入都被整合进现有知识结构，而非堆叠在上面。矛盾被标记，交叉引用被添加，综合页面被修订。
这就是复利效应的实质：摄入的内容越多，新材料被解读时所处的上下文就越丰富。 普通的知识库里，添加第100条笔记不会让第50条笔记变得更聪明——但在LLM Wiki模式下，会。
看到这里，很多人已经隐隐感觉到了tokens在起飞，每一次wiki的重建，都需要重新构建整个知识连接，tokens的消耗确实是一个无法回避的问题。但这就是权衡，你得考虑要优质的内容，还是要省钱，毕竟RAG利用本地Embedding模型的话，几乎是0 tokens消耗。
但有些帐要长远地算，如果说RAG检索出的内容质量差，导致Agent Loop飞转起来，估计多余的两三轮Loop，节省出来的tokens就又搭进去了。
06
—
适用场景
Karpathy在gist中列举的适用场景包括：个人知识管理、长期研究某个主题、边读书边建立角色/主题/线索页、团队内部Wiki、竞品分析、尽调、旅行规划、课程笔记等。
这些场景有一个共同点：资料会不断累积，问题不会只问一次，人想要的通常不只是“找到片段”，而是“把结构慢慢整理出来”。
Karpathy指出，在约100篇文章、40万字规模的实践中，这套方案的效果显著优于传统RAG，且完全人类可读、可审计。如果只是临时查一个问题，RAG已经够用；但如果一个主题会反复碰、反复问、反复补材料，Wiki这层就开始产生真正的价值。
技术没有绝对的优劣，只有是否适配具体的使用场景。
