知识管理的未来正在被LLM Wiki重新定义，但盲目跟风可能让你陷入新的效率陷阱。本文深度解析Karpathy提出的知识编译理念，揭露那些教程不会告诉你的五大真实痛点——从规模天花板到惊人的API成本，同时带来突破性解决方案qmd的完整拆解。这是一篇给真正想建立可持续知识体系的工作者的避坑指南。

你有没有这种感觉——

收藏夹里躺着几百篇”以后要看”的文章，Obsidian 的知识图谱画得花花绿绿，但每次真正要用某个知识点，还是打开 Google 重新搜。折腾了好几年，结果什么都没真正沉淀下来，是吧

今年4月初，Karpathy 发了一条推文，1700 万阅读，8.8 万收藏。全网技术博主开始争相教你搭 LLM Wiki，热度传到国内丝毫不减。我看了看，跟着折腾了一段时间

发现有些东西确实值得学。但有些坑，没人告诉你

LLM Wiki 到底是什么

一句话：把知识管理变成编译过程。

传统笔记工具，不管是 Notion 还是 Obsidian，说到底是存储型的。你写进去什么就是什么，知识在里面是死的。RAG 加了一层检索，但每次提问都要重新翻一遍，翻完就忘，下次还得重来——像个得了健忘症的图书管理员，没有任何积累可言，挺没意思的

Karpathy 的做法不同。他让 LLM 在你丢资料进去的那一刻就完成”编译”：读懂内容、写摘要、与已有知识交叉引用、更新索引。新资料不只是多了一个条目，而是被织进了整张知识网络。100 篇资料的价值，不是 100 个摘要的简单加总，差远了

这套系统的结构分三层，清晰而克制：

第一层，Raw Sources（原始文档）——你丢进去的所有原材料，文章、论文、PDF、图片、数据文件。这层只读不改，是整个系统的事实基础，动不得

第二层，Wiki——由 LLM 全权维护的 Markdown 文件目录。来源摘要、实体页、概念页、综合分析，全部由 LLM 写入和维护。你只负责读，就这样

第三层，Schema（CLAUDE.md）——整套系统的约定文件。结构规范、命名规则、Ingest 流程、页面模板，全部写在这里。这是唯一需要你深度参与的部分，也是最值得花时间的地方

Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。你决定读什么、问什么，其余的，LLM 来就好了

设计本身没什么问题。Lint 机制让知识库能自我体检，纯 Markdown 文件让数据完全在你手中——这些洞察是真的有价值，不是噱头

为什么全网都在跟风

因为它戳中了所有知识工作者最深的痛点：你读了很多，但什么都没留下来，对吧

Karpathy 是 Tesla、OpenAI 的前核心研究员，他提出的东西自带信任背书。加上这套方案的理念足够优雅——让 LLM 做所有枯燥的书目维护，人类只负责输入和提问——听起来像是知识管理的终极解法，谁看了不心动呢

跟风是人之常情，能理解。但咱跟风之前，确实得留神这几件事

我实际用下来发现的几个问题

问题一：规模天花板，来得比你想象的早

原始方案的索引机制是一个叫 index.md 的 Markdown 文件，里面存着所有 Wiki 页面的一行摘要和链接。LLM 每次查询都要先把这个文件从头读到尾，再定位相关页面

Karpathy 自己管这个叫”穷人的向量库”（他原话）

但他低估了穷人的规模上限。大约 200~300 篇中等长度的技术文章，就能把它撑满。之后 index.md 越来越长，上下文窗口越来越拥挤，响应越来越慢，成本越来越高。认真做研究的人，半年阅读量就能把它撑爆，一点都不夸张

问题二：超长文档，原始方案根本没有出口

默认流程是一次性读完整篇文档。但你要是丢进去一份 200 页的技术报告或者一本书呢？LLM 的上下文窗口直接撑不住。截断——后半段信息全丢。硬塞——成本暴涨，幻觉频发

这个问题在原始方案里，压根没有解法，就这么摆着

问题三：成本，没人在教程里告诉你

想想，你每 Ingest 一篇文章，LLM 要读新资料、扫描现有 Wiki 页面、更新 10~15 个关联页面、写日志。一次完整的 Ingest，实际消耗大概需要 7.5 万到 25 万 token。按 Claude Opus 的 API 价格，每篇文章的摄入成本在 $1.5~3 美元之间好，一个月摄入 50 篇，光 Ingest 就要花 $75~150 美元。你又要说了，不能换便宜模型省钱？我跟你想法一样，然后我的Wiki直接崩了——摘要开始胡说，交叉引用开始乱指，Lint 形同虚设，真是省了钱废了库

问题四：冷启动，是个真实的门槛，别小看它

前 5~10 篇资料基本是调校期。你要反复迭代 CLAUDE.md，告诉 LLM 该怎么分类、怎么命名、怎么建立关联。这需要你对 LLM 的行为模式有足够深的理解，说实话，这不是一般人上手就能做好的事，这部分他原文里没具体分享，大部分实际根本不知道从哪下手，只能干瞪眼

Karpathy 能手拿把掐，因为他本人就是这个领域最顶尖的几个人之一。对大多数人来说，写 Schema 就像做卷子最后一道大题只会写个”解”字

问题五：Lint 机制本身，也会幻觉，绕不过去的

Lint 是让 LLM 检查 LLM 生成的内容。这个环节同样存在幻觉风险。最终的质量兜底，绕了一大圈，还是回到人工审阅。和你自己写笔记然后偶尔回头检查，底层逻辑上没什么本质区别，只是中间多了一堆复杂度罢了

Karpathy 原文，其实也提到了一些问题

值得一提的是，Karpathy 的原文本身并不是一份傻瓜教程。他写的是一份”想法文件”（idea file），有意设计得很抽象，目的是让你和 LLM 一起把它实例化成适合自己领域的版本，而不是照抄照搬

他在原文里直接提到了规模问题的解法：

“At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it’s a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device.”

他点名推荐了 qmd，方向给得很清楚

但原文只说了方向，仅此而已。超长文档的分块处理、CLAUDE.md 的具体 Schema 设计、CLI 命令的封装方式——这些全部需要你自己动手解决。这不是缺陷，是他有意留下的空间。只是大多数跟风教程，把这部分直接略过了，然后你照着做发现根本跑不起来，懵了

qmd 是什么？为什么它能解决这些问题

qmd 是一个专门为 LLM 工作流设计的本地 Markdown 搜索引擎，全程在本地跑，不依赖任何云端 API。

它的架构分三层，各司其职：FTS5 全文索引（BM25 精确匹配关键词）、向量嵌入（语义相似度检索）、LLM 重排序（理解查询意图后二次精排）。三层结果通过 RRF 融合算法合并，最终返回最相关的内容块，挺扎实的一套设计

更关键的是它的智能分块机制：按 Markdown 标题边界切割，每块约 900 token，15% 重叠。200 页的超长文档，不需要一次性塞进上下文——用不同主题词多次检索，每次只取 3~5 个块（约 3000~4500 token），精准定位到你需要的段落。跨会话续传，不丢失任何信息，这才是正经的处理方式

它还提供 CLI 接口和 MCP 服务器，LLM 可以直接调用它作为原生工具，不需要手动复制粘贴，真是省心不少

对照前面的问题，逐一来看：

• 规模天花板消失了——qmd 不依赖 index.md 那个穷人的向量库，有真正的混合检索索引，几千篇文章照样跑，响应速度不随规模退化，这才叫能用的东西
• 超长文档可以处理了——块级检索让 200 页文档变成可以分批消化的知识单元，每次只取相关的几个块，不再是一锅端或者截断二选一
• 成本大幅下降——每次查询不再需要把整个知识库塞进上下文，token 消耗压缩一个数量级，账单好看多了

qmd 做的事情，就是把 LLM Wiki 从”demo 级原型”变成能够真正长期运转的系统，这个差距不小

这才是真正值得投入的架构

大多数人搭 LLM Wiki 失败，不是因为不够努力，而是在一个有根本性缺陷的基础上堆砌复杂度，然后发现越堆越乱，最后放弃

2020 年 Notion 火的时候，多少人搭了精美绝伦的模板，一个月后再也没打开过。2022 年 Obsidian 双链笔记火了，知识图谱画得花花绿绿，三个月后变成一团彩色毛线球，自己都不知道哪根线连着哪根。现在轮到 LLM Wiki 了，结局会不同吗？不一定

工具崇拜解决不了输入匮乏的问题，这一点不会变。但一个扎实的架构，可以让你把有限的输入发挥出真正的价值，而不是白费功夫

下一篇，我会给出结合 qmd 的完整实现方案——包括wiki CLI 的具体封装代码、CLAUDE.md 的完整 Schema 设计、超长文档的分块 Ingest 流程、跨会话 WIP 续传机制，以及从用户操作层到文件系统层的完整架构链路图，一次说清楚

当然，建议你先把 qmd 先装上：bun install -g qmd

下篇见