你的知识库是怎么死的，多半死于记账

深度思想，谈 AI 与向往 —— 字节深思圈

多数人的知识库，生命周期长得差不多。第一个月热情高涨，建目录、打标签、分类归档。第三个月只剩收藏，不再整理。半年之后，连自己都不想点开。

死因通常被归结为懒。真实的死因更具体：更新交叉引用，修订被新资料推翻的旧观点，在几十个页面之间保持说法一致。这些活可以统称记账。它无聊，耗时，而且资料越多负担越重。人受不了这个，库就死了。

这个诊断是 Andrej Karpathy 在一篇笔记里给出的，他顺着诊断开出的药方，比药方本身更值得琢磨。

检索救不了它，因为每次都从零开始

现在主流的用法是什么。把文件传上去，问问题的时候检索相关片段，拼出一个答案。NotebookLM 是这个逻辑，各家文件上传和问答也是这个逻辑，市面上绝大多数知识库产品还是这个逻辑。

这套方法能用，但有个根本缺陷：每次都在从零开始。你问一个需要综合五份文档的问题，模型就重新找、重新拼、重新推导一遍。上次的推导结果去哪了？消失在聊天记录里。两次问同一个问题，得到两份平行且互不相认的推导。用了一年，什么都没积累下来。

两种范式的差别，摆在一起看更清楚：

换个方向：写入时编译，查询时直接读

Karpathy 的思路是换范式。别在查询时检索，在写入时编译。每加一份新资料，模型不把它存起来等你问，而是直接读、直接消化，把信息整合进一个持续维护的 wiki：更新相关页面，标注和旧内容的矛盾，建立交叉引用，补上综合结论。查询的时候，问的是这个已经消化完的库，答案带着引用，好的答案还可以归档回库里。

结构分三层。底层是原始资料，文章、论文、数据，只读不改，这是事实的源头，模型不能动它。中间层是 wiki 本体，全部由 LLM 写作和维护，你只负责读。顶层是一份配置文档，告诉 LLM 这个库的结构是什么、约定是什么、遇到新资料按什么规则处理，在 Claude Code 里是 CLAUDE.md，在 Codex 里是 AGENTS.md。

他打过一个比方：Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。知识库应该像代码仓库一样管理，有输入，有编译，有产物，有测试。

这件事的思想源头可以追到 1945 年。Vannevar Bush 设想的 Memex，就是一种个人的、经过策划的知识系统，文档之间的关联路径和文档本身同样有价值。他没解决的问题只有一个：谁来维护。八十年里答案一直是没有合适的人，现在答案变成了 LLM。它不会厌倦，不会忘记更新某个引用，维护成本压到近零，知识库第一次在经济上活得住。

别高兴太早：编译器会静默地写错答案

这是我认为整套方案里最被低估的风险。人手写的库，错误是散的、看得见的；LLM 编译的库，错误是成体系的、排版精美的。模型整理资料时混进一个幻觉，它会被写进某个概念页，加上规范的交叉引用，从此成为这个库里的“权威结论”。库越整齐，错得越自信。

所以方案里那个定期健康检查不是装饰。让模型定期扫全库，找矛盾、找孤儿页面、找数据空白，相当于给知识库跑 lint 和测试。照代码库的思路走下去，还应该有版本回退：某次摄入之后库整体质量掉了，能退回上一版。没有检查环节的编译式知识库，比手写的更危险，因为它把错误包上了可信的外壳。

还有一条要提前想清楚：编译解决的是维护成本，不解决信噪比。资料本身是垃圾，编译产物就是结构化的垃圾。入库这道闸门还是人把着，把不住，后面全白干。

照抄必死，三个被实践修正的地方

Karpathy 自己也承认，这套东西目前像一堆 hacky 脚本，能跑通的人本来就是少数。顺着这个思路实践的人，往往会在三个地方动刀，每一处动的都是机制而非口味。

其一，工具无所谓。有人嫌现成笔记工具难用，直接用 AI 搭一个只有自己懂的极简工具，一上午就能跑起来，放什么、索引怎么设计完全按自己的工作方式。机制在于，工具该从你自己的工作流里长出来，别人的方案搬过来必错，包括 Karpathy 的。

其二，收藏这一步可以砍掉。收藏满足的是收藏欲，一个当下没法快速理解的东西，收藏了大概率也不会再看。更狠的做法是只对话不收藏：看到有价值的内容，直接开窗口聊透，有用的结论落库，原始链接不留。先过滤再入库，比攒一堆原料再批量编译，信噪比高得多。

其三，大库换成项目库。所有主题塞一个库，维护成本随规模指数上升；按项目分库，范围有界，成本可控，冗余可以接受。知识的归宿是具体项目，就好比编译出来的应用最后都跑在具体容器里。

最小闭环，今天就能搭

起步不需要任何仪式。一个目录，raw 和 wiki 两层，一份写清结构和约定的配置文档。每次摄入新资料，让模型更新相关页面和索引；每月做一次健康检查，让它自己找矛盾和空白。判断库里缺什么，让它基于现有内容推荐下一步该挖的方向。

这套打法最有想象力的场景其实在团队。会议记录、客户通话、项目文档，这些东西今天基本都是沉没成本，没有任何组织会安排人力去整理它们，历史上也从来没有成立过。当维护成本降到近零，这笔账第一次算得过来。

最后一个判断留给你自己：该不该进库的资料，标准其实简单，理解它需要的力气你现在愿不愿出。不愿意的，收了也是坟场的一部分。

要点：知识库死因是记账式维护的摩擦，不是懒；检索式问答每次从零开始，无积累；编译式把消化放在写入时，靠 LLM 当维护者；LLM 编译会静默写错，健康检查是必需的测试环节；工具、粒度、库的切分没有标准答案，由你的工作流决定；团队沉没数据是这套范式最大的增量场景。