很多团队在知识建设上都会经历同一个阶段：文档越来越多，检索越来越强，问答也能跑起来，但真正需要复用的判断却始终沉不下来。你能把资料找回来，却很难保证下一次不用再理解一遍。
这也是我看 Andrej Karpathy 提出 LLM Wiki 时最有感的一点。它真正切中的，不是“再造一个知识库产品”，而是把一个长期被忽略的问题说透了：有些知识适合在查询时临时拼装，有些知识则应该在入库时就先完成一轮整理、抽象和连接。前者更接近 RAG，后者更接近 wiki 式的知识编译。
如果把这两类机制混成一件事，知识系统很容易沦为一个更昂贵的搜索入口。它能回答问题，但不能稳定复用判断；能召回原文，却不能把经验真正积累下来。
问题不在“能不能找到”，而在“要不要反复理解”
RAG 的价值从来都不小。它擅长保存原始语义，适合挂接大规模资料，也适合处理那些低频、长尾、临时出现的问题。对于“某份方案里有没有提过这个字段”“去年的会议里谁说过这件事”这类问题，RAG 的路径非常合理：先把资料找出来，再让模型基于上下文完成理解。
问题在于，团队里并不只有这类问题。
很多真正消耗协作成本的内容，恰恰不是“找不到”，而是“每次都要再想一遍”。比如：
• 为什么当时选了方案 A，没有选方案 B。 • 某类系统约束为什么一直存在，不能轻易改。 • 一个业务规则的边界到底在哪里，历史上踩过哪些坑。 • 几份零散资料之间，究竟能抽出什么稳定结论。
这类内容只靠检索并不划算，因为它们的成本不在召回，而在重复理解。
RAG 的能力边界：保存原料，按需取用
从系统设计角度看，RAG 更像一种“存储优先”的范式。它尽量不提前改写知识，而是把原始材料保留下来，在用户发问时再做上下文拼装。
这种范式有三个天然优势：
• 信息保真度高，离原始出处近。 • 扩展资料规模相对直接。 • 对冷门问题更友好，不需要提前判断哪些内容值得加工。
但它也有明显边界。只要一个问题会高频重复出现，RAG 就会不断重复支付同一种理解成本。系统每次都要重新检索、重新组装、重新归纳。短期看没问题，长期看就会暴露出两个症状：
• 回答能出来，但稳定性依赖当次召回质量。 • 知识能访问，却没有真正形成可维护的资产。
换句话说，RAG 很擅长“把资料带到现场”，却不天然负责“把判断沉淀下来”。
如果把两种思路并排看，差异会更直观：
图：RAG 负责把原始资料带回现场，LLM Wiki 负责把高频判断沉淀成可复用资产
LLM Wiki 的关键，不是整理文档，而是编译知识
LLM Wiki 更有意思的地方，在于它把“理解”这件事往前移了一步。
它不是等问题来了再临时组织答案，而是在资料进入系统时，就先把其中可复用的部分抽成更稳定的知识对象。原本分散在报告、聊天、会议纪要、设计文档里的内容，会被改写成更适合长期复用的页面、概念、关系和阶段性判断。
这也是为什么我更愿意把它理解为“编译”，而不是“整理”。
“整理”通常意味着换个目录、改个标题、把东西放整齐；“编译”则意味着结构发生了变化。原始资料是高噪声、低结构的，而编译后的知识对象应该具备更强的复用性，至少要回答清楚下面几类问题：
• 这件事到底在讲什么。 • 它跟哪些概念或对象有关。 • 哪些判断是稳定的，哪些只是阶段性的。 • 当新资料进来时，原有结论要不要更新。
如果没有这一步，知识库再大，也可能只是文档仓库；只有当资料之间开始形成关系，判断开始拥有版本感，系统才真正进入“知识资产”阶段。
Obsidian 在介绍 backlinks 时强调过一件很重要的事：知识的价值不只在单页内容，也在页面之间的相互引用和反向链接。Obsidian Backlinks[1] 这点放到团队场景里尤其成立。真正有复用价值的，不是某一份孤立文档，而是文档之间逐渐显露出来的关联结构。
真正值得编译的，是“半熟知识”
并不是所有内容都值得用 wiki 方式做重度沉淀。
一个实用的判断方法，是按“出现频率”和“单次理解成本”把知识分层。最值得编译的，往往不是最热的内容，也不是最冷的内容，而是那部分反复出现、但每次都要花脑力重新确认的“半熟知识”。
可以把它简单理解成下面这张表：
这类“半熟知识”在不同角色里都很常见。
对产品或运营来说，它可能是：
• 竞品分析里反复出现的稳定结论。 • 某条关键指标波动背后的因果链。 • 过去几个版本反复验证过的用户分层逻辑。
对研发团队来说，它更可能是：
• 某个系统边界为什么不能轻易打破。 • 一类故障的典型触发条件与规避方式。 • 技术选型背后真正的取舍，而不是表面上的功能对比。
这些知识的共同特征是：你通常知道个大概，但不敢完全凭记忆拍板。只要这种“我得再确认一下”的场景频繁出现，就说明这部分知识已经值得被编译。
更靠谱的架构，不是二选一，而是分层协作
把 RAG 和 LLM Wiki 视作对立路线，往往会把问题想得过窄。它们解决的其实不是同一层问题。
RAG 更像召回层，负责把原始资料带回来；LLM Wiki 更像沉淀层，负责把已经证明会重复使用的知识加工成稳定结构。一个偏“找到”，一个偏“留住”。
更实用的系统通常长这样：
图：原始资料同时流向召回层与知识编译层，回答与沉淀各走一条链路
这个结构背后的分工很清楚：
• 原始资料层负责保真，不急着下结论。 • 检索层负责覆盖面，解决“去哪找”。 • 编译层负责提炼高频判断，解决“值不值得反复再想”。 • 复用层负责把这些沉淀后的内容重新喂回团队协作。
一旦这样拆开，很多争论就会自动消失。不是“RAG 还是 LLM Wiki”，而是“哪些内容只需要被检索，哪些内容值得被编译”。
判断一套知识系统有没有长出来，要看它会不会复利
一个只有问答能力的系统，本质上仍然偏工具型。你问一次，它答一次；你换个问法，它再临时拼一次。它当然有用，但这种有用更接近即时服务，而不是长期积累。
真正成熟的知识系统会出现另一种迹象：新的资料进入后，不只是“可被搜到”，而是会改变已有理解；旧的判断也不是静态躺在那里，而是能被补充、修正、链接和替换。到这一步，知识才开始复利。
这时你会看到两个变化：
• 同类问题的回答越来越稳定，因为底层判断已经被沉淀。 • 团队对关键概念的理解越来越一致，因为大家复用的是同一批经过编译的页面，而不是各自从原文现推一次。
Karpathy 提醒我们的，恰恰是这一点：知识系统不能只追求“把答案找出来”，还得关心“哪些理解值得留下来”。llm-wiki[2]
结语
所以，知识库的终点并不是在 RAG 和 LLM Wiki 之间二选一。
更准确的说法是：RAG 让系统保有回到原始资料的能力，LLM Wiki 让系统把高频、昂贵、值得复用的判断沉淀成资产。前者解决信息召回，后者解决知识复用。
如果一个团队只有 RAG，它拥有的是更强的检索；如果它同时拥有一层持续更新的 wiki 式沉淀，它才真正开始拥有自己的知识系统。
