百页就废的导航卡帕西的导航方案依赖一个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 流程很直接把原始文档交给 LLMLLM 读取、分析、提炼编译成结构化的 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 里跑通。你要拿它来承载长期的知识积累这三个问题每一个都会让你停下来重新造轮子。到那时候你会发现你花在修补这套模式上的时间比从头设计一个适合自己的知识管理系统还多。