Karpathy三个月前在GitHub扔了篇gist，叫《LLM Wiki》。
没代码，没论文，就一页纯文字。
结果呢？
5000多颗星。评论区直接炸成黑客松。
一堆人排着队晒自己的实现。
说白了，这玩意儿戳中了一个我们忍了五年的痛点。
我干了快20年架构，踩过游戏高并发的坑，也搞过广告投放。
听我一句劝——
LLM Wiki 不会彻底取代 RAG，但它正在把 RAG 从主角降级成配角。
以后检索只是导航，真正值钱的资产，是一份 LLM 替你持续维护的、会自己生长的知识库。
这话可能刺耳，尤其是刚花大价钱上了 RAG 系统的团队。
RAG 这套，2020年就定型了。
文档切块，塞进向量库，提问时捡碎片，喂给大模型拼答案。
NotebookLM、ChatGPT 文件上传、市面上九成知识库产品，全是这个套路。
用着挺爽。
但有个巨坑。
LLM 每次回答问题，都是从零开始重新发现知识。
你问一个需要综合五份文档的刁钻问题，它现场找碎片、拼起来、推理一遍。
答完就忘。
下次再问类似的？对不起，重新来一遍。
没有一丁点积累。
打个比方：你请了个记性为零的顶级顾问。
每次见面都得把病历从头讲一遍。
顾问水平是真的高，但你迟早会疯。
Karpathy 换了个方向。
别让 LLM 在提问时才去读原始文档——
让它平时就把知识“编译”成一份持续维护的 Wiki。
-
- 原始层
：你喂进去的论文、文章、数据。不可变，LLM 只读不写。这是事实源头。 -
- Wiki 层
：一堆互相链接的 Markdown 文件。实体页、概念页、对比页、综述页。LLM 全权拥有这一层，建页面、改页面、维护交叉引用。你只负责读。 -
- Schema 层
：一个约定文件（比如 CLAUDE.md），告诉 LLM 这个 Wiki 的目录结构、命名规范、收录流程。这是把 LLM 从“闲聊机器人”变成“有纪律的图书管理员”的关键。
Karpathy 原话：没有它，LLM 就是个通用聊天机器人；有了它，LLM 才是个“懂规矩的 Wiki 维护者”。 -
收录：丢一份新资料进原始层。LLM 读完一口气干这些事——
写摘要页、更新总索引、更新所有相关实体页、标注和旧结论冲突的地方、往日志里追加一条记录。
一份资料可能动 10-15 个页面。
你可以一篇篇喂、全程盯着，也可以批量灌、事后抽查。
提问：基于已综合好的 Wiki 提问，LLM 先查索引找到相关页，读完再答，附引用。
关键设计是：好答案可以归档回 Wiki 变成新页面。
一次深度对比、一个意外发现的关联，不该消失在聊天记录里——这样你的探索本身也在给知识库复利。
体检：定期让 LLM 给 Wiki 做健康检查。
查什么？页面间的矛盾、被新资料推翻的过时结论、没有入链的孤儿页、被反复提到却没有自己页面的概念、缺失的交叉引用。
LLM 还擅长建议“下一步该找什么资料、该问什么问题”。
这是 Wiki 不烂尾的续命机制。
Wiki 长大的过程中，靠两个特殊文件导航，不需要 embedding 基础设施：
-
- index.md
：内容导向的总目录。每个页面一行——链接加一句话摘要，按类别分组。每次收录必更新。
提问时 LLM 先读索引锁定相关页，再钻进去细读。
实测在约 100 份资料、几百个页面的规模下好使得很。 -
- log.md
：时间线日志，只追加不修改。记录每次收录、提问、体检。
小技巧：每条目用统一前缀，这样grep "^## [" log.md | tail -5就能查最近动态，也让 LLM 知道最近干过什么。 -
Karpathy 原话很精辟：“Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。”
听懂了吗？
知识在这套体系里是编译产物，不是运行时临时算的。
交叉引用已经建好了，矛盾已经标注了，综述已经反映了所有读过的资料。
每多一份资料、每问一个问题，Wiki 就厚一层。
这才是“积累”该有的样子。
泼一盆历史的冷水：个人知识库这想法一点不新。
1945年，Vannevar Bush 就提出了 Memex 构想。
之后几十年，无数人尝试建个人 Wiki，绝大多数都烂尾了。
为啥烂尾？
不是读不动，是记账记不动。
更新交叉引用、同步摘要、标注新数据推翻了哪些旧结论——维护成本的增长速度远超 Wiki 价值的增长速度。
人会烦，会懒，会放弃。
但 LLM 不会烦。
它不会在周五晚上六点说“这周太累了引用下周再补”。
一次更新 15 个文件，眼都不眨。
维护成本约等于零，Wiki 就能一直活着。
就这么简单。
如果说 Karpathy 给的是“民间偏方”，那么 Google Cloud 六月份干的事就是“收编正规军”。
发布 Open Knowledge Format（OKF），把 LLM Wiki 模式正式化成一个开放规范。
OKF 的设计克制得让人感动：就是 Markdown 加 YAML frontmatter，唯一必填字段是 type。
没有 SDK，没有运行时，没有专用数据库。
你能 cat 一个文件，就能读 OKF；你能 git clone，就能分发它。
基本单位叫 Bundle（知识包）——一个自包含的 Markdown 文件目录树。
里面每个知识点叫 Concept（概念），一个概念一个文件，文件路径去掉 .md 后缀就是它的概念 ID。
每个概念文件就两部分：frontmatter 和正文。
规则就三条硬性的，其他全是软性建议。
消费方必须容忍未知类型、未知字段、断链——宽容到这个份上，就是为了让任何生产者、任何消费者都能即插即用。
真正有意思的是 7 月 25 日刚发的 v0.2。
解决一个扎心问题：当 Wiki 是 AI 写的，你凭啥信它？
人写的 Wiki 出了错，可以找人背锅。
AI 一晚上生成一万个概念，出了错找谁？
v0.2 的答案是五组字段，全部写在 frontmatter 里，让你在读正文之前就能判断这页可不可信：
-
-
溯源：这页内容从哪些材料提炼的，正文里具体某句话的出处用 Markdown 脚注逐条归因。 -
-
信任： generated记谁生成的、何时；verified记谁核验过、何时。核验者带human:前缀的就是“人工复核”档。三个信任等级，一句 frontmatter 过滤就搞定。 -
-
新鲜度：一个绝对日期，过期判断就是日期比大小。 -
-
生命周期： draft→stable→deprecated。废弃页面保留不删，历史查询可复现。 -
-
算数担保：一个指标页不只说“营收是这个数”，还带一段被认可的计算方式（如 SQL）和配套检验程序。执行后验证实际跑的 SQL 和被认可的 SQL 是否一致，不一致则数字拒展。 -
注意一个设计哲学：OKF 只记录信号，不打“可信度评分”。
评分是主观的、会过期的；信号是客观的，谁拿到都能自己算。
这个取舍，老架构师看了会点头。
想法很丰满，落地写代码，全是坑。
评论区里真刀真枪干过的人已经踩出来了：
第一，漂移。 收录新资料时 agent 漏更新交叉引用，页面悄悄过期。
体检不是可选项，是续命项。有团队直接挂定时任务跑矛盾检测。
第二，规模天花板。 纯 index.md 导航在几百个页面内好使得很，到几千个页面就开始喘。
过了这个量级，还是得加搜索引擎——绕了一圈，检索又回来了。
第三，写入时的实体对齐。 新资料里提到的“张伟”，到底是已有实体还是同名新人？
这个去重判断目前没有优雅解法，恰恰是这个模式“要么复利、要么蔓生”的分水岭。
第四，贵。 收录一份资料要动 10-15 个页面，token 烧得比 RAG 检索猛多了。
一次性问答场景，RAG 便宜得多。
第五，垃圾进，垃圾复利。 LLM 写错的东西也会被“编译”进 Wiki，还会被后续页面引用。
没有人工抽检，错误会利滚利。这也是 Google 火急火燎给 v0.2 加信任信号的原因。
所以我的判断是：一次性查资料的薄场景，RAG 照旧；需要长期深耕的领域，Wiki 碾压。
二者不是替代关系，是分层关系——检索退化为导航层，Wiki 才是沉淀层。
[偏激观点]：我赌两年内，“知识库”这个词的定义会变。
今天它等于“向量数据库 + 检索器”，两年后它会等于“一个 git 仓库，里面装着 AI 维护的 Markdown”。
向量库不会消失，但会缩回基础设施层，像今天的倒排索引一样，没人再拿它当卖点。
当年我们做高并发游戏服务器，就是这么被坑惨的。
2013年底，缓存设计偷懒，以为缓存是优化项，后来才发现缓存即架构。
RAG 是查询，Wiki 是缓存。
查询谁都会写，能活过三年的缓存设计才是本事。
真不行。那种每次从零检索的方式，太原始了。
你的文档库，打算继续每次从零检索，还是今晚就开始让 AI 给你攒一份会自己复利的 Wiki？
