如果你一直关注RAG，大概率刷到过这条消息：今年4月，Karpathy发了一份GitHub gist，主张别再用RAG去检索你的知识库——让大模型把笔记「编译」成一座持续生长的Wiki。Karpathy构建的LLM知识库「LLM Wiki」迅速爆火，在社区快速传播。知乎gist在GitHub上拿下5000多star，评论区长出20多个衍生项目。知乎到8月，知乎上已经开始出现落地方案的横向对比文了。
乍一看这又是一轮「RAG药丸」的狂欢，但扒完社区这4个月的讨论，我发现这次不太一样：支持和反对的两边都有真下场的人，也都拿出了真金白银的代价。
「知识编译」到底改了什么
先花30秒对齐。传统RAG是「查询时」的：你每问一次，它去文档堆里捞几个片段，现场拼一个答案，下次再问，再捞、再拼。
Karpathy的提法是把这份工挪到「写入时」：他把笔记当成不可修改的源代码，让LLM当编译器。36氪提前编译成结构化、互相链接的Markdown页面；每来一篇新材料，AI就更新相关条目、修订综述、标出新旧结论的冲突。
架构就三层：Raw（原始资料，不可变）、Wiki（编译产物，AI全权维护）、Schema（规则文件，规定知识库该怎么长）。日常三个动作：Ingest摄入新材料，Query从编译产物里查询，Lint定期体检，查矛盾、查过期、查死链。
支持派为什么兴奋？一句话：RAG是给知识加了个「搜索框」，Wiki是给知识画了张「地图」。
RAG的老毛病在个人知识库场景会被放大：捞出来的永远是碎片，你问「系统有哪些模块」它还能应付，你问「这个指标的口径到底怎么算」，它给你捞出两年前的旧方案、互相冲突的定义，然后非常自信地揉出一个错误答案；半年前你写下的判断和昨天的笔记互相打架，它照单全收，答出「人格分裂」。
更疼的是维护。知识管理圈流传一个数字：约82%的个人知识库系统在6个月内被放弃。这个数字出处比较杂，但现象几乎没人否认——链接的维护成本随笔记数接近平方级增长，而你能感知到的价值是亚线性增长的，两条线大概在500到2000条笔记之间交叉。知乎交叉点之后，每新增一条笔记，负担都大过收益。
Karpathy戳中的正是这里：维护知识库最累人的从来不是阅读，是记账——更新交叉引用、保持摘要新鲜、标注冲突。36氪人类会在这种枯燥面前放弃，LLM不会，它可以一口气改15个文件，把维护成本压到近乎为零。知乎有位在Obsidian上自己跑通类似方案的作者，让Agent读一周流水账出周报初稿：以前翻记录凑内容要一两个小时，现在5分钟出初稿。知乎
但反方的三记闷棍，同样是真的
第一棍：维护这个痛点没被解决。在「如何评价Karpathy提出的个人知识库的架构」的问题下，一条283赞的回答说得很直白：纵观当年的Evernote到现在的Notion和Obsidian，问题从来不是知识库有多么结构化，而是本地文件分类和关联到最后一定会失效，因为越到后面，无论是人还是LLM，都会被困在自己创造的系统里疲于奔命。知乎你的笔记每天在长、话题每天在漂移，编译器追的是一个移动靶。
第二棍打在范式本身：过度连贯的知识库，比充满矛盾的知识库更危险。LLM天然擅长生产连贯的叙述，但知识库要的不是连贯，是准确。知乎AI把冲突抹平、编译成通顺综述的那一刻，你也失去了「这里不对劲」的警报。
第三棍是工程现实。有作者拿国产模型真跑了一遍，总结出四个坑：一，上下文长度是命门，短上下文模型跑长任务中途一compact就丢信息；二，Schema设计比你想的重要10倍，他的规则文件从200字迭代了5版涨到几百行，没有好的Schema，LLM Wiki就是摆设。知乎三，Agent写入会出事故，文件互相覆盖，不上Git版本控制连哭都来不及；四，很多教程为了降门槛把Schema和Lint悄悄省掉，省了这两样，知识库基本废了。
最实打实的反例来自企业侧。腾讯开源的企业级知识平台WeKnora本身就是「混合检索+Wiki Mode」的合体，但选型复盘的实测结论是：在精确条款问答场景，GraphRAG、Wiki这些高级旋钮挨个做对照实验，大多没用甚至有害，「最后都关了」。知乎范式的先进程度，不等于业务的适配程度。
所以到底怎么选？社区其实已经吵出一条决策线
GitHub评论区里有个被反复引用的经验法则：先看数据量。个人知识库整理完通常也就几千到2万tokens，而现代模型的上下文窗口是200K到百万级。知乎这个量级下知识编译完胜：检索可靠性接近100%，几乎零基础设施，还能全局推理。
几百万tokens以上，只能用RAG。知乎上下文根本装不下。中间地带用混合：核心高频知识编译成Wiki，长尾、快变的资料留在RAG管线里。
翻译成能直接抄的判断：
个人、几万字的笔记、复用率高、追求观点一致 → 可以试知识编译，但Git备份和Lint巡检不能省
语料巨大、更新快、查询频率低 → 老老实实RAG，写入时的编译成本摊不平
企业精确条款问答、要逐句溯源 → 别迷信Wiki，混合检索+受控推理更稳，前面有「关了Wiki」的实测
内容创作者 → 参考范凯的改造思路：给知识库加产出层和行动层。范凯的原话是：知识库是弹药库，写作才是开枪。知乎而且AI先报方案、人拍板，别让AI替你决定分类。
想上手的话，生态里已有现成轮子：有人把Karpathy的知识库构想变成了开源项目。知乎claude-obsidian是目前最完整的实现，约5800 star。知乎Synthadoc的五态页面生命周期（草稿→活跃→过期→被矛盾→归档）专门解决页面状态管理；不想依赖云端API的，Synto可以接本地模型。也有人把这套想法直接做成了跨平台桌面应用，比如开源的llm_wiki，GitHub上3.4k star，迭代到v0.3，演示库里70个页面自动织出154条链接，编译完的知识图谱直接可视化。
最后说句判断
这次争论的本质，不是「RAG第N次死了」，而是知识库的定位在迁移：从「提前替模型决定答案材料」，变成「提供一个可探索、可验证的信息环境」。这个想法其实不新——1945年Vannevar Bush设想的Memex机器，就是要在文档之间建立「联想路径」，连接和文档本身一样宝贵。36氪它卡了80年，卡在「谁来维护」，而现在LLM接过了这份记账的活。RAG没有被淘汰，它只是从唯一选项变成了选项之一；知识编译也一样，它有清晰的适用边界，不是新的万能药。
接下来值得盯两个信号：一是企业场景里会不会冒出更多「关了Wiki」式的实测复盘；二是LLM-Wiki生态里，页面状态管理、摄入顺序偏见、提示注入防御这些工程问题的解法演进。这两条线，比下一轮「宣判死刑」的标题有信息量得多。
