试了各种笔记软件，我最终选择了 Obsidian，用 Markdown 文件来装载过去十几年的备忘录、上千篇公众号文章、各种随手记的素材。
按理说，这应该是一座金矿。但实际体验是——我知道矿在里面，就是挖不出来。
最困扰我的问题是，知识库的知识是死的，检索系统也是死的。限于人类的脑力容量，有些问题我可能经常问，反复问。知识库每次都会重新检索，给出答案。由于幻觉的存在，答案不尽相同。我还没办法在自己的知识库做到 Notebooklm 那样低幻觉的效果。
我给它加了一个前端——一个活在对话框里的 AI 助手，小椒。前端的问题解决了，但后端还是一堆静态的 markdown 文件，知识不会自己生长，检索也不会自己进化。
在我的计划里，下一步是上向量数据库，给检索再升一级。
直到我看到 Karpathy 那条推文。
Karpathy 的方案：让知识自己长出来
他的核心想法不复杂。不是「用 AI 搜笔记」，而是「用 AI 养知识库」：
raw/ ← 原始资料
notes/ ← LLM 编译的笔记
concepts/ ← 提炼出的稳定概念
outputs/ ← 输出物（文章、memo、图表）
关键在回写：每次研究的产出——一次好的总结、一个有价值的比较——都写回知识库，成为下一次研究的起点。
它把聊天式消费，变成了资产式积累。
这正好击中了我最大的痛点：知识是死的。Karpathy 给出了一条让它活过来的路。
所以我立刻动手做了一套本地实现。
为什么是文件系统，不是聊天记录？
因为聊天记录有三个致命缺陷：
- • 不可复用——下一个 Agent 读不到你之前的上下文
文件系统天然解决这些。内容可改、可链接、可被任何工具读取。
而且 Karpathy 有一个经常被忽略的观点：中小规模下，先把知识组织好，比先把检索堆复杂更重要。目录结构清晰、有索引页、有摘要层——markdown + 目录就够跑了。不需要一上来就搞向量库。
先写对，再检索。顺序不能反。
这句话让我暂停了上向量数据库的计划。
但是，落地之后我踩了 4 个坑
理论很美，现实很糙。真正跑起来之后，我发现 Karpathy 没提到的东西，恰恰才是最要命的。
坑 1：知识库会「腐烂」
这是最大的风险，也是最隐蔽的。
举个真实的例子：我让 AI 把一篇长文编译成笔记，它在总结里写了一句「该研究表明 X 方法比 Y 方法效率提升 40%」。原文其实说的是「在特定条件下有提升的可能性」。这条笔记后来被引用进了一个概念页，又被另一条总结引用。等我偶然发现的时候，一个不确定的推测已经变成了三个页面里的「确定事实」。
这就是腐烂的过程：
- • 最后你面对的是一个看起来很丰富、但越来越不可信的知识库
我以为你在积累知识，其实我在培养幻觉。
坑 2：全交给 LLM，你会丢掉「主编权」
Karpathy 说他很少直接改 wiki。这听起来效率很高，但有个问题：
LLM 很擅长整理，但它不知道——
完全放手的结果：知识库变成模型的语料堆，而不是你的脑外脑。面面俱到，但没有重点；什么都有，但没有立场。
坑 3：memory 和 wiki 会混成一团
不画边界的话，知识库很快变成杂交体：一半是专题知识，一半是任务状态、偏好设置、协作约定。我问它一个专业问题，它可能把我的待办事项也检索出来。
如果要我井井有条，那就增加了知识库的使用成本。如果要 llm 当勤杂工，系统可能会失控。
坑 4：工具癖
这不是理论的问题，但几乎是实践者的通病：
工具越来越复杂，知识内容反而没长多少。那不是在搭系统，而是在玩工具。
怎么办：5 条修正规则
这些坑不是劝退我的理由，而是设计约束。我在本地实现时，针对每个坑加了一道保险。
① 分两层，不混放
| | |
|---|
协作记忆层MEMORY.md | | |
专题知识层knowledge/ | | |
memory 是「怎么协作」，knowledge 是「知道什么」。这条线必须先画。
② 用编译链，不一锅炖
raw/ → notes/ → concepts/ → outputs/
原始资料不能直接冒充结论。编译笔记不能直接冒充稳定概念。每一层都是一道防腐墙。
③ 给知识库装「免疫系统」
定期跑健康检查，重点查：
不做巡检的知识库，半年必腐。
④ LLM 当编辑部，人类当总编
- • 人类保留：主题方向、结论升级、可信度判断的最终决定权
自动化的部分越多，人工把关的节点就越不能省。
⑤ 输出必须回写
一次好回答、一篇好总结、一个高价值 memo——不能只留在聊天记录里。
回写成 note / concept / workflow rule，这才是「会生长」的真正机制。不然只是「会聊天」，不是「会积累」。
最新进展：Karpathy 自己也补了一版
写这篇文章的时候，Karpathy 刚好对自己的方法做了一次完整的 follow-up。对照之下，有几个点让我觉得挺有意思：
一致的部分——
他明确描述了自己的实践流程：原始资料索引进 raw/，LLM 增量编译成 wiki，输出物回写进知识库增强后续查询。这和我实现的 raw → notes → concepts → outputs编译链本质上是同一条路。
他也确认了一个我自己踩坑后才想明白的判断：
I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries…
——中小规模下，先组织好，比先检索好更重要。
我选择不跟的部分——
Karpathy 的原话是：
Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly.
这正是我上面说的「坑 2：丢掉主编权」。对于他那种以研究探索为主的场景，全自动也许可以。但对于需要长期依赖这个知识库做判断的人来说，我仍然认为人类必须保留总编角色。
他说的下一步，我选择先不走——
The natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights.
方向没问题，但这属于「坑 4：工具癖」的典型诱惑。在知识库的质量控制还没跑顺之前，上微调只会把幻觉固化进模型权重。先养好知识，再考虑内化。
最后
做完这件事之后，我对“知识库”的理解更新了。
以前我觉得知识管理的核心问题是存储和检索——东西够多、搜得够快，就是好知识库。所以我花了几年时间往 Obsidian 里塞东西，然后计划上向量数据库让搜索更准。
现在我觉得核心问题其实是编译和维护。
一条信息被我读过，不代表它是我的知识。它被整理成笔记，也不一定是。只有当它被提炼成一个经过我思考的判断，能指导我下一次行动，并且我知道这个判断从哪来、有多可靠——它才真正是知识。
而维护，是知识库和收藏夹之间真正的分界线。文件夹会自己变乱，笔记会自己过时，AI 总结会自己产生幻觉。我不主动对抗熵增，知识库就会退化成收藏夹。
所以 Karpathy 给出的不是一个工具建议，而是一个关于知识的判断：
知识不是收藏了什么，而是编译了什么。
我只是在这个判断的基础上，补了适合自己的另一半：
编译了还不够，你还得持续维护它，否则编译的产物也会腐烂。
好在有了 llm，维护这件事的成本会越来越低。未来是人类和 AI 协作的时代。
粤ICP备14082021号
免费POC，
零成本试错
