卡帕西的LLM Wiki跑不通真实知识库！

卡帕西教大家怎么 LLM 构建个人知识库的文章老火了，叫 LLM Wiki。核心思路：让 LLM 替你做知识库的维护工作，你喂原材料，LLM 负责提炼、交叉引用、维护一致性。

看起来是真不错，用起来是真拉胯。

我拿我积累了五六年的 Obsidian 知识库去试。几千个文件，十几个领域的内容混在一起，一直苦于没人帮我整理，这个方案看起来正好解决痛点。

试完之后，啥也不是，浪费我一晚上。

LLM Wiki的整套设计从根基上就没考虑过真实知识库长什么样。卡帕西在文章里举的所有例子，读一本书、研究一个课题、做一个竞争分析，都是百页以内、单一领域、跑几天就结束的 demo。

真实知识库完全相反。编程笔记、游戏攻略、设计素材、项目管理模板混在同一个 vault 里，领域之间互相穿插，跨领域的交叉引用只会制造噪音。

内容类型也不一样。周计划和会议纪要适合保持原样当工作记录，调试时的挫败感需要亲自经历才有意义，只有读书笔记这类才适合被提炼成交叉引用的结构化知识。

卡帕西的设计有三层架构：底层放原始文档（不可变），中间是 LLM 维护的 Markdown wiki，顶层是一份 schema 文件告诉 LLM 维护规则。三个操作：Ingest 导入新源，Query 查询，Lint 做健康检查。导航靠一个 index.md 文件，每次查询 LLM 先读它来定位相关页面。

总之，看起来有点东西，实际上就是一坨！

百页就废的导航

卡帕西的导航方案依赖一个 index.md 文件。每次查询，LLM 先读这个文件来定位相关页面，再深入阅读。他在原文里声称，这套方法在"约 100 个源、数百页"的规模下运行良好。后文也提过，规模大了可以接入 qmd 这类本地搜索引擎来补充。

这是一个明确的规模上限。wiki 增长到两三百页以上，index.md 本身的长度就逼近 LLM 的上下文窗口，LLM 一次读不完，整个导航机制就失效了。

卡帕西对搜索引擎的补充只是一笔带过，触发条件没说清楚，迁移成本被低估，从纯文本索引迁移到 BM25 或向量搜索需要调整页面结构、加 frontmatter、建立索引，整个 ingest 流程都要跟着改。

在纵向规模之外，还有一个横向的维度问题：领域隔离。

卡帕西举的所有例子，读一本书，研究一个课题，做一个竞争分析，都指向单一领域。这些场景天然领域内聚。但大多数个人知识库里，游戏攻略、AI 编程笔记、项目管理模板、个人健康记录、读书笔记混在一起，这些是完全不同的领域。

这套模式没有领域隔离的概念，所有 wiki 页面放在同一个扁平目录里，共享同一个 index.md，同一个 Lint 流程扫描所有页面。往 wiki 里灌了几百页不同领域的内容后，index.md 充斥着不同领域的条目，Lint 会跨领域发现"矛盾"，Query 会返回跨领域的杂烩结果。卡帕西完全不Care这个，但你不能不Care

读不完的东西就不配进知识库

卡帕西设计的 ingest 流程很直接：把原始文档交给 LLM，LLM 读取、分析、提炼，编译成结构化的 wiki 页面。他在原文中展示的所有例子，文章、论文、单个章节，都是 LLM 单次上下文窗口能容纳的内容。整个流程有一个隐含假设：LLM 能一次性读完原始文档。

大量有价值的知识源远远超出这个范围。一本 400 页的书、一个数万文件的代码库、一套数千页的技术文档，LLM 一次读不完，提炼和整合进 wiki 就无从谈起。

我知识库里有几本大PDF，直接给ingest干废了。

ingest 流程需要额外的预处理机制来定位源文档中的重要段落，再喂给 LLM 去提炼。卡帕西没有说明这个预处理该怎么设计。

讽刺的是，这正是 RAG 的用途。卡帕西提出的模式是为了替代 RAG，但在导入环节，你需要 RAG 作为脚手架。这个矛盾在原文中完全没有被提及。

什么内容都往同一个模子里塞

卡帕西的三层架构里，原始文档是输入，wiki 页面是输出，方向是单向的。所有内容只有一种处理方式：被 LLM 读取、分析、提炼，编译成结构化的 wiki 页面。对于知识库运行中出现的矛盾，他定义了 Lint 操作来检测。

Lint 检测到矛盾之后，他假设用户会手动处理。新读的论文推翻三个月前的结论，不同作者对同一个概念有不同定义，数据来源之间的口径不一致，这些在知识库运行一段时间后是必然出现的。检测到之后怎么办？哪个来源胜出？按时间先后？按来源可信度？按原文的明确程度？卡帕西没有给出任何策略。

每次 Lint 发现矛盾都要自己逐条判断，矛盾积累的速度会超过手动处理的极限，Lint 最终只会产出一本越来越长的问题清单。

这套架构还假设所有内容都适合被编译成结构化的 wiki 页面。但真实知识库里至少有两类本质不同的内容。读书笔记、研究摘要、技术文档分析，适合被编译和交叉引用。周计划、会议纪要、AI 对话存档、项目进度追踪，价值在于保持原始状态，作为工作记录被检索和回溯。

把周计划交给 LLM 去 ingest，它可能会把任务清单拆散塞进各种 entity page，把时间线信息丢掉。把 AI 对话记录丢进去，LLM 会尝试从中提取知识点，但对话的原始上下文和思维过程才是真正有价值的部分。卡帕西没有区分这两种类型，也没有提供任何机制来决定哪些该编译、哪些该保留。结果要么所有内容都被编译，工作记录被破坏，要么只能手动区分，又回到了人工维护的老路。

所有难题留给读者自己发明

卡帕西在原文末尾说得很清楚：这是一个 idea file，具体实现取决于你的领域和偏好。

翻译过来就是：我只负责提想法，工程问题你自己解决。

前面讨论的三个问题，每一个都是因为这个抽象而缺失了关键的工程决策。导航的纵向规模和横向隔离、大型知识源的预处理、矛盾消解和内容分类，这些问题没有默认答案。卡帕西把所有困难的决策都甩给了读者，然后说"你可以根据自己的场景实例化"。

大多数尝试实现这套模式的人会在不同阶段遇到这些摩擦点，然后各自发明不兼容的解决方案。但卡帕西没有提供任何参考实现来降低这个成本。

卡帕西的核心想法，让 LLM 做知识库的维护工作，方向是对的。但一个没有回答关键工程问题的模式，不管听起来多优雅，终归只能在 demo 里跑通。你要拿它来承载长期的知识积累，这三个问题每一个都会让你停下来，重新造轮子。到那时候你会发现，你花在修补这套模式上的时间，比从头设计一个适合自己的知识管理系统还多。