速读#
这篇不争「LLM Wiki 会不会取代 RAG」，而是把问题放回规模：小规模、可维护的个人知识库，不一定需要向量库。真正要带走的是量尺：先量自己的资料体量，再决定用 Markdown Wiki，还是上 embedding 和检索层。
起因：llm-wiki#
2026 年 4 月 4 日，Karpathy 在 GitHub 发了个标题简单到只有「llm-wiki」一个词的 gist。它很快积累了 5000 多星和数千次 fork，Medium 和 Substack 上也出现了一批复现。圈里随即开始聊一个戳人的问题：RAG 是不是要被取代了。这篇不转述它，记我读到它之后发生的一件更私人的事——我回头量了一遍自己的知识库，量出来的结论不太体面，放在后面说。
llm-wiki 怎么工作#
llm-wiki 一句话的核心是：知识应该是复利积累的，而不是每次查询都从零开始。架构分三层——不可变的原始资料（PDF、笔记、转录稿、书签）在最底下；LLM 维护的 wiki 层在中间，放摘要、实体页面、交叉引用、矛盾标记；最上面是一个 CLAUDE.md 那样的 schema 文件，告诉 LLM 怎么维护这个 wiki。对应三种操作：ingest 摄入新资料并整合进 wiki、query 从已编译的 wiki 层读答案、lint 定期扫矛盾、孤立页面、缺失反向链接和知识漂移。
拿我自己的一篇博客举例会更具体。ingest 阶段：把写 Cloudflare Tunnel 那篇复盘的 Markdown 喂给 LLM，它提取核心概念（出站模型、零端口、Tunnel token），生成对应的 wiki 条目，自动链接到已有条目（可达面、防护面）。query 阶段：问它「怎么让服务被公网访问」，LLM 从已编译的 wiki 层直接读答案，不需要重新扫原始 Markdown。lint 阶段：定期扫 wiki，发现「零端口」条目缺少反向链接到「Tunnel」，标记为孤立页面——这就是 Karpathy 说的「代码库维护」。
Karpathy 自己给的类比很直接：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。再配个 --save 标志，新合成出的答案若代表新知识就自动归档成新页面，下回会话立刻能用——这就是「复利」的具体形状。
Wiki 与 RAG#
LLM Wiki 把结构化索引预先编译进可读文件，LLM 查询前已经「读完」了相关内容，全程纯 Markdown、零基础设施；RAG 则是查询时才动态从向量库检索片段、临时拼装，要依赖向量库加 embedding pipeline 加检索层。分歧其实在整合发生在何时：Wiki 把理解的工作前置到写入时，每次 ingest 都在为下一次查询铺路；RAG 把整合推迟到查询时，向量库里存的是素材，理解要现场拼装。一个持续积累，一个每次现拼。
| 维度 | LLM Wiki | RAG |
|---|---|---|
| 适合规模 | 原文示例约 100 个来源、数百页 | 更大或频繁变化的语料 |
| 基础设施 | 零（纯 Markdown） | 向量库 + embedding + 检索层 |
| 可读性 | 全人类可读 | embedding 空间黑盒 |
| 更新方式 | 增量 ingest，并改写 wiki | 增量或重新 embedding |
| 结果积累 | 默认可把综合结果写回 | 通常需要另建写回流程 |
差别落到哪条线上，是这次最值钱的一句话：落到规模和查询方式上。Karpathy 的原文没有给出一个固定 token 阈值，只说这套索引方式在约 100 个来源、数百页的中等规模下仍然有效。对我更实用的判断是：索引和查询所需页面能否稳定放进模型上下文，人工还能否读懂并维护；如果每次都要从数万份持续变化的文档里动态找片段，RAG 的检索层才更有价值。这个边界不能只靠一个数字替所有场景决定。
回头量自己的东西#
这是我复盘 AI 辅助编程时留下的纪律：能跑 ≠ 理解，新概念要落到自己的真实量级上校准。
我自己折腾过知识库——笔记散在几个 app 里，也搭过调过 RAG 那套 embedding、向量库、检索层。一量就量出问题来了：我的资料远没到数万文档，整理后大约是百来份材料，索引和相关页面仍能直接阅读。换句话说，我之前为这套搭的检索 pipeline，在当前规模下是过度工程了。
这个发现要诚实说，不是「我原来错了」，是我把 RAG 当成了知识库的默认答案，没先问量级。RAG 适合海量，我这套不是海量；LLM Wiki 那种「纯 Markdown + LLM 维护 + 复利积累」的模式，反而更贴我这种规模——零基础设施、全可读、增量 ingest，而且 query 结果能存回当复利。所以我在当前场景下的判断是：自己用的知识库，从「搭 RAG」往回撤到「试 LLM Wiki 那套」是更对路的方向。但这只对我这个量级成立，我不把它当通用结论。
别默认 RAG#
为什么这次规模对照给我的冲击比概念本身大，因为它治了我一个挺久的习惯：遇到「知识管理」就默认上 RAG。之前折腾 RAG 时，有一部分动力其实不是规模需要，是「显得正经」——向量库、embedding、检索层一套摆出来，像那么回事。但跑过才慢慢意识到，我对那套 pipeline 的理解是有缺口的，和当初 Dockerfile 多阶段构建「能跑不懂」同一种状态：embedding 召回为什么准、为什么不准，我讲不透；pipeline 能跑，但它的边界我没摸清。把真实资料量摆出来后，这个缺口也到了明面上——在我这个量级，RAG 的复杂度换不回它该有的收益。
LLM Wiki 那套「编译时积累、纯文件可读」反而是把我拉回「理解层」的工具：wiki 是 Markdown，我能逐行读、能 lint 出矛盾，不是埋在 embedding 空间里的黑盒。
可读才可维护#
关于可读性的感受，它能和我别的几条经验接上。RAG 的 embedding 是黑盒，出问题排查很绕；LLM Wiki 是全人类可读的 Markdown，矛盾能 lint、孤立页面能扫——可读性不只是「好看」，是「可维护、可纠错」。这点和「日志堆栈要打全给人看」「日志是服务器在跟你说话」是同一条线：人能读的东西，人才能维护；黑盒的东西，出事只能猜。
判断收敛成三条，边界也写清楚#
跑完这次校准，我对 llm-wiki 这件事的判断收敛成三条。LLM Wiki 不是 RAG 的替代品，两者各有适用场景，分界线要看资料规模、变化速度和查询方式。我的知识库该往 Wiki 这条路试，不该默认 RAG——但只对我这个量级成立，不外推成通用结论。可读性是可维护性的前提，wiki 的全可读不是装饰，是它「能 lint、能纠错、能复利」的根，黑盒换不来维护性。
这些判断我也留了边界。LLM Wiki 不是没代价：它依赖 LLM 的 ingest/lint 质量，维持得好需要好 schema（CLAUDE.md 那种）；维护成本不是零，只是从「基础设施成本」挪到了「维护纪律成本」。资料接近模型上下文和人工维护上限时，两种方案都值得实测，不能只凭篇数决定。我这套往 Wiki 方向调整还在进行中，不是已完成的结论——我写「该试」，不写「已验证最优」。
Karpathy 这个标题只有一个词的 gist，给我最大的不是「又学了个模式」，是它逼我量了自己的量级，发现自己之前把 RAG 当默认答案是过度工程。RAG 没错，错在没先问「我这套有多大」。这次规模校准改变了我的姿势：先量规模，再选方案——不追新词，也不恋旧解。
同一个「知识管理」问题，答案随量级变。这是我读 llm-wiki 最大的收获：不是多了个工具，是多了把量尺。