原文作者：Mocha · 原文来源：今日头条
本文为作者本人文章的站内同步版本。
最近 AI 圈里开始出现一种很有意思的说法：
“RAG 已经过时了，现在应该用 LLM Wiki。”
甚至有人说，RAG 已经是“没人用的老技术”。
这个说法显然有点夸张。
RAG 不但没有消失，而且依然是今天很多 AI 知识库、企业搜索和问答系统的重要基础设施。
真正值得关注的，是另一件事：
我们过去习惯让 AI 在“提问的时候找知识”，而 LLM Wiki 开始尝试让 AI 在“知识进入系统的时候，就把它整理好”。
这看起来只是处理时机发生了变化，背后却可能代表着完全不同的知识库思路。
先说清楚：LLM Wiki 到底是什么？
2026 年 4 月 4 日，Andrej Karpathy 发布了一份名为 LLM Wiki 的 GitHub Gist。
他把它称为一种：
“使用 LLM 构建个人知识库的模式。”
它并不是某款具体的软件，也不是一种新的大模型技术，而更像是一套知识管理方法论。
Karpathy 观察到，我们现在使用 AI 处理文档时，大部分系统都很像 RAG：
上传一堆文件。
用户提出问题。
系统寻找相关内容。
把找到的片段放进上下文。
最后由大模型生成答案。
这个方式当然有效。
问题在于，很多计算会不断重复。
假设你的知识库里有 100 篇行业报告。
今天你问：
某家公司过去三年的产品策略发生了什么变化？
AI 需要重新从几十篇文档里寻找相关信息，然后临时完成一次综合。
一个星期之后，你再问一个类似的问题，它可能又要重新寻找、重新拼接、重新理解。
上一次分析出来的知识，并没有天然变成一个可以继续利用的“知识资产”。
Karpathy 对这种现象的描述很形象：
传统 RAG 往往是在每次提问时，重新从原始材料里发现知识。
LLM Wiki 想解决的就是这个问题。
它不是每次帮你“找资料”，而是在帮你“编百科”
LLM Wiki 的核心变化，是建立了一个位于原始资料和用户之间的中间层。
你丢进去一篇文章之后，AI 不只是把它切块、建立索引，然后等着未来某一天被搜索。
它会直接阅读这篇文章。
然后判断：
这里出现了哪些人物？
哪些公司？
哪些概念？
哪些观点？
哪些内容和以前的资料有关？
哪些信息补充了已有知识？
哪些地方甚至和过去的材料存在冲突？
接着，AI 会把这些信息写进一个长期存在的 Wiki。
比如你的知识库里已经有：
OpenAI
Anthropic
AI Agent
Computer Use
几张页面。
现在你又加入一篇新的 Agent 行业报告。
LLM Wiki 可能不会简单地再创建一篇“行业报告摘要”。
它可能会：
更新「AI Agent」页面；
修改「Anthropic」页面中的相关内容；
创建一个新的概念页面；
给几个页面增加交叉链接；
同时记录新报告和旧报告之间出现的数据差异。
知识不是简单地增加了一份文件，而是被重新融入了整个知识网络。
这才是 LLM Wiki 真正有意思的地方。
RAG 和 LLM Wiki，最大的区别是什么？
如果一定要用一句话区分：
RAG 更像“检索”，LLM Wiki 更像“编译”。
可以从几个角度来看。
01. 知识什么时候被处理？
传统 RAG 的主要计算发生在查询阶段。
你问问题之后，系统才开始寻找相关内容，再让模型临时进行组合和推理。
LLM Wiki 则把相当一部分工作提前到了知识录入阶段。
资料一进来，AI 就开始阅读、总结、关联和更新。
所以以后再使用这些知识时，很多整理工作已经提前做完了。
02. 知识以什么形式存在？
很多经典 RAG 系统的底层，会把文档拆成 Chunk，然后建立关键词索引、Embedding 或其他检索结构。
这些东西主要是为机器检索准备的。
LLM Wiki 的核心资产则是：
一组结构化、互相链接、可以直接阅读的 Markdown 页面。
也就是说，这个知识库不仅 AI 能读。
人也能直接打开来看。
这也是为什么 Karpathy 自己会把 Obsidian 和这种模式结合起来。
他说得很形象：
Obsidian 是 IDE，LLM 是程序员，Wiki 就是代码库。
03. 新知识进入之后发生什么？
传统 RAG 中，增加一篇文章通常意味着：
新增一份文档；
切块；
建立索引。
至于它和过去的 500 篇文章有什么关系，往往要等未来有人提问时才临时判断。
LLM Wiki 则会主动问：
这篇文章会改变我已经知道的什么？
于是它可能修改已有页面、增加关联，甚至记录不同来源之间的冲突。
知识因此开始出现一种很重要的特征：
积累。
LLM Wiki 的三层结构
Karpathy 在最初的设计里，把 LLM Wiki 分成了三个层次。
第一层：Raw Sources，原始素材
这是整个系统最重要的事实来源。
包括：
论文；
网页；
PDF；
图片；
会议记录；
研究报告；
聊天记录；
数据文件……
这些文件原则上保持原样。
AI 可以阅读，但不会直接修改它们。
这样未来如果 Wiki 中出现错误，我们永远可以回到原始资料检查。
第二层：Wiki，知识层
这一层才是 AI 真正工作的地方。
里面可能有：
人物页面；
公司页面；
概念页面；
主题总结；
对比分析；
时间线；
研究结论……
新材料进来以后，LLM 可以创建页面，也可以修改旧页面。
页面之间通过链接形成一张不断增长的知识网络。
这里有一个非常关键的设计思想：
人主要负责阅读 Wiki，AI 负责维护 Wiki。
第三层：Schema，规则层
第三层其实很容易被忽略，却可能是整个系统最重要的一部分。
它是一份规则文件。
比如 Claude Code 可以使用 CLAUDE.md，Codex 可以使用 AGENTS.md。
里面规定：
知识库有哪些页面类型；
文件应该放在哪里；
什么情况下创建新页面；
什么时候更新旧页面；
引用应该怎么写；
发现冲突怎么办；
新资料应该经过什么处理流程……
换句话说：
你不是每一次都重新告诉 AI 怎么整理知识，而是在给这个“AI 图书管理员”制定一套长期工作的规章制度。
一篇新文章进入之后，究竟发生了什么？
这里也需要纠正一个很容易传播错误的说法：
LLM Wiki 并没有规定所有系统必须按照固定的“分析阶段→生成阶段”两步运行。
Karpathy 最初描述的是一种更加灵活的 Ingest（摄取）流程。
比如一篇新的研究报告进入知识库之后，Agent 可以：
阅读原文；
总结重要观点；
和已有知识进行比较；
创建新的 Wiki 页面；
更新已有页面；
修改索引；
补充交叉链接；
最后在日志里记录这次知识库发生了什么变化。
一篇新的资料，甚至可能同时修改十几个页面。
而且除了 Ingest，Karpathy 还特别设计了两个非常重要的操作。
一个叫 Query。
也就是针对已经整理好的 Wiki 提问。
另一个叫 Lint。
这个词程序员应该非常熟悉。
它相当于定期给知识库做一次“体检”。
AI 会寻找：
互相矛盾的页面；
已经过时的信息；
没有任何页面链接过来的孤岛内容；
被反复提到却没有独立页面的重要概念；
缺失的引用；
需要继续调查的数据空白。
这意味着 AI 不只是在“使用知识库”。
它还在维护知识库。
这才是 LLM Wiki 最值得关注的地方
过去我们一直把知识库理解成一个“仓库”。
往里面放资料。
需要的时候再搜索。
但 LLM Wiki 想把知识库变成另外一种东西：
一个会自己整理的知识系统。
这在几个场景里尤其有意思。
团队知识库
公司的知识通常散落在：
群聊；
会议纪要；
需求文档；
客户反馈；
项目记录；
邮件……
真正的问题往往不是“没有资料”。
而是：
资料太多，却没人整理。
如果 Agent 能持续把这些材料整理成项目页面、产品页面、客户页面和决策记录，那么新员工打开的不再是一个堆满文件的网盘。
而是一套已经整理好的“公司百科”。
Karpathy 在最初的构想中，就把 Slack 讨论、会议转录、项目文档和客户沟通作为团队 Wiki 的典型来源。
长期研究和行业分析
第二个特别适合的场景，是长期研究。
比如你研究 AI Agent 半年。
每天保存文章、论文、融资信息、产品发布和公司动态。
传统方法最后很容易得到：
2000 个收藏夹链接。
LLM Wiki 想得到的则是：
一套持续更新的公司页面；
技术路线页面；
人物页面；
产品页面；
趋势页面；
以及这些内容之间不断变化的关系。
更重要的是：
当两个来源互相矛盾时，不必简单覆盖旧结论。
你完全可以在 Schema 中规定：
保留两个来源，并明确标注分歧。
这对行业研究、竞品分析、尽职调查尤其重要。
所以，RAG 真的要被淘汰了吗？
并没有。
事实上，把 RAG 和 LLM Wiki 完全放到对立面，本身可能就是一种误解。
当 Wiki 只有几十、几百个页面时，目录和普通搜索可能已经够用。
但当知识库越来越大以后，你仍然需要快速找到相关页面。
Karpathy 在原始方案里也专门提到：
规模扩大后，可以给 Wiki 增加搜索能力，甚至使用 BM25 + Vector Search + LLM Reranking 这样的混合检索。
一些后来的 LLM Wiki 实现，同样保留了向量语义搜索。
所以更合理的架构，很可能不是：
RAG → LLM Wiki
而是：
Raw Sources → LLM 编译 → Wiki → Search / RAG → Agent
检索并没有消失。
真正发生变化的是：我们开始给“检索”增加一个已经被 AI 整理过的知识层。
从“搜索文件”到“积累知识”
如果非要给两种模式做一个比喻：
传统 RAG 像是在你的书房里安装了一套非常强大的搜索系统。
你问一个问题，它迅速冲进书架，从几十本书里找到相关的几页，再拿回来给你。
而 LLM Wiki 更像是：
你雇了一个永远不会嫌麻烦的研究助理。
每买一本新书，他都会认真读一遍。
然后更新人物卡片、概念卡片、时间线和主题笔记。
发现两本书说法不一样，他会留下标记。
发现新的概念，他会建立页面。
发现旧结论已经过时，他会补充说明。
当你半年以后再次打开这个知识库时，你看到的不只是：
“我存过多少资料。”
而是：
“关于这件事情，我已经积累了什么知识。”
这可能才是 LLM Wiki 最值得关注的地方。
它并没有宣布 RAG 的死亡。
它真正提出的问题是：
既然大模型已经能够阅读、总结、比较和修改文档，我们为什么还要让知识永远停留在一堆等待被搜索的原始文件里？
从“把资料存起来”，到“让知识持续生长”。
也许，这才是下一代 AI 知识库真正值得期待的变化。
参考资料
Andrej Karpathy，《LLM Wiki》，2026 年 4 月 4 日。
社区目前已经出现多种基于这一模式的开源实现，其中既有纯 Markdown / Agent Skill 方案，也有加入向量搜索、知识关联和桌面 UI 的完整应用。
继续阅读
WorkBuddy为何领先：功能、体验与腾讯生态研究
从腾讯文档、ima、微信助理与连接器的公开资料，分析WorkBuddy功能和生态协同可能怎样影响使用体验，并区分桌面访问量、用户数与交付质量。
WorkBuddy资料库怎么用？把常用材料整理成一份可反复调用的FAQ
用三份虚构文档实测WorkBuddy内置资料库的添加、读取、FAQ生成、保存和新任务复用。含可复制提示词、真实截图及本次积分记录，明确未提供的信息和未验证的功能。
腾讯发布 Buddy One：文档、会议、知识库，终于能一起找了
腾讯发布 Buddy One，连接 WorkBuddy、腾讯文档、腾讯会议、ima 和腾讯网盘。梳理免费跨应用检索、700元连续包月VIP、通用积分与暂不支持解绑等使用前需了解的规则。
WorkBuddy 20个办公高频场景提示词，速来领取
整理20个WorkBuddy办公场景的可复制提示词，覆盖会议纪要、Excel清洗、文件归档、报告周报与提醒设置，附输入材料、演示结果和检查项；自动执行需具备相应接入与权限。