Karpathy 的知识库方案很好，但它不是为你设计的
上一篇我介绍了 Karpathy 的个人知识库方法，不少读者照着搭了。但搭完之后，有人跟我说了一句话：
“搭是搭好了，但不知道往里塞什么。”
这个困惑不是工具的问题，是一个更前置的问题没想清楚。
最近国内的范凯——JavaEye 的创始人，早年写博客的人应该都知道他——在 Karpathy 方案的基础上做了一次大改造。改完之后反响很大，很多人觉得”比原版更能用”。
我把两个方案放在一起看了很久，发现一件事——
它们根本不是同一类方案。
表面上用的是同一组工具（Obsidian + LLM + Markdown），但两者背后的出发点完全不同。而”搭好了不知道往里塞什么”这种困惑，几乎都来自一个没人问过的前置问题：这个方案，是为谁设计的。
搭知识库的第一步，从来不是选工具，是看清自己。
一、Karpathy 的出发点：让知识积累，而非每次从零开始
上一篇讲了 Karpathy 方案的操作层。这一篇往下挖一层：他为什么要这么设计。
先回忆一个所有用 AI 的人都经历过的瞬间——
你上周和 AI 认真讨论过一个问题，讨论得很深。这周你换了个新对话，想接着上次的思路往下走，结果 AI 一脸陌生，从零开始给你讲基础概念。上次聊的上下文全丢了。
Karpathy 说的就是这件事。他的解法很直接：让 LLM 把每次对话里产生的知识，沉淀成 Markdown 文件。下次再问，AI 先翻已有的笔记，在之前的基础上往前推。知识像滚雪球一样越攒越多，交叉引用越来越密。
上一篇讲的三层架构和四个动作，都是在这个底层逻辑上长出来的。其中最精妙的是 Lint——让 AI 定期扫描知识库，找矛盾、找孤岛、找过时。用 Karpathy 的话说（大意）：维护知识库最累的不是阅读和思考，而是记账（bookkeeping）。读文章、判断价值是人该干的事；整理格式、更新链接、检查过时——这些交给 AI。
在这个出发点下，知识库的终点是 Wiki 本身。AI 越维护得好，Wiki 就越完整；Wiki 越完整，AI 下次回答就越有基础。Wiki 就是目的。
这套方案对 Karpathy 这种研究者来说，几乎无懈可击——研究者的工作本来就是”让知识沉淀下来”。
但问题来了——对于不是研究者的人，”知识沉淀在 Wiki 里”就是终点了吗？
二、范凯的出发点：知识存着不用，等于没有
你可能也有过这种感觉——
你辛辛苦苦攒了几百条笔记，做了完美的目录。但一个月后你打开 Obsidian，突然问自己：这些东西我最近用过吗？大多数答案是没有。笔记安静地躺在硬盘里，像一座永远装修不完的房子，你从来没真正住进去过。
范凯在他的改造文章里开门见山：
Karpathy 的 Wiki 是个终点——知识沉淀下来就完了。但我做内容创作，知识存着不用等于没有。
基于这个出发点，范凯做了三个关键改动。
改动一：从三层变成五层
Karpathy 原版是三层架构（Raw Sources / Wiki / Schema）。范凯拆成了五层：
Notes/ （输入层） — 网页剪藏、碎片想法、AI 对话
Knowledge/ （知识层） — 方法论、读书笔记、原创思考
Software/ （技能层） — 工具技巧、开发笔记
LifeOS/ （行动层） — 投资、健康、保险等落地事项
Writing/ （产出层） — 视频脚本、文章、运营 SOP
中间三层是并行的管线，各管各的领域。最下面的 Writing/ 产出层是 Karpathy 完全没有的。范凯的原话：
知识库是弹药库，写作才是开枪。
在 Karpathy 那里，弹药库就是目的；在范凯这里，弹药库只是中间站，开枪才是目的。
而 LifeOS/（行动层）也容易被忽略。范凯说，投资笔记不是写完就完，要指导真实的交易决策；健康计划要变成每周的训练安排。知识不只要”产出”，还要”落地”。
改动二：输入层里多了一个 Conversation 子目录
Karpathy 的 Raw Sources 是一个统一容器。范凯把输入拆成了三类：Clippings（网页剪藏）、Inbox（碎片想法）、Conversation（跟 AI 的有价值对话）。
范凯的原话：
我有个设计是 Karpathy 没提到的——
Notes/Conversation，专门存跟 AI 的对话。你跟 AI 认真讨论一个问题的时候，对话过程本身就在生产知识。比如这篇文章的雏形，就是我跟 Claude 讨论 Karpathy 方案时聊出来的。把它丢掉太可惜了。
改动三：AI 先报方案，人再拍板
这是范凯自己说的”跟 Karpathy 最大的分歧”。
Karpathy 的模式是让 LLM 主笔维护 Wiki，人参与审阅。范凯试过之后发现，AI 对”这篇文章应该放哪”的判断经常不靠谱——比如把内容创作方法论放到了 Knowledge/ 而不是 Writing/Knowledge/，或者本该合并到已有文档的内容被新建了一个文件。
所以他加了一条规则：AI 先列方案，人确认了再动手。 用他的话说，分类反映的是你自己的思维结构，AI 可以建议，但最终得你来定。成本很低——看个表格而已——但能避免很多返工。
这三个改动背后是同一个出发点——知识必须流动起来，必须能变成东西，必须能落地。
三、两种方案，同一张桌子
| Karpathy · 让知识积累 | 范凯 · 让知识开枪 | |
|---|---|---|
| 出发点 | 别让 AI 每次从零开始，让知识攒起来 | 知识存着不用，等于没有 |
| 终点 | Wiki 本身 | Wiki 之后的产出和行动 |
| 架构 | 三层（Raw / Wiki / Schema） | 五层（输入 / 知识 / 技能 / 行动 / 产出） |
| AI 的角色 | 主笔维护，人参与审阅 | 参谋报方案，人拍板执行 |
| 最怕什么 | 矛盾、孤岛、过时 | 积压、不产出、吃灰 |
| 典型提问 | “X 和 Y 的关系是什么” | “这些素材能写什么” |
| 交叉引用 | 密集链接，AI 自动维护 | 少即是多，只留强关联 |
你的出发点决定了你该抄哪一份。
四、还有第三种出发点
除了”让知识积累”和”让知识开枪”，还有没有第三种？
有。
我自己就属于第三种。我做的是 AI + 保险这个交叉地带——一边是变化极快的 AI 技术，一边是变化极慢的传统行业。这种位置的人，每天接触到的信息极其碎片：监管文件的一段、某个模型的新能力、竞品的一个功能、一次和业务方的争执、一篇论文里的工程细节。这些东西单看都没意义，合在一起才是你对这个行业的真实理解。
我的出发点既不是”让知识积累成百科”，也不是”让知识变成内容”，而是——把一个陌生而复杂的行业，慢慢装进自己的脑子里。
这种知识库更像一块慢慢变厚的“认知底座”。它平时不怎么被翻，但每一个架构判断、每一次和业务方对齐，都悄悄建立在它之上。
为什么做 AI + 传统行业的人需要这种特殊形态？因为光靠公司文档装不进脑子。公司文档能告诉你”我们现在是怎么做的”，但告诉不了你”为什么这么做、下次遇到变化该怎么判断”。这种”为什么”和”怎么判断”，只能靠自己一天一天慢慢对齐、消化、沉淀。
这种”认知底座”有几个反常识设计，甚至有一些是反 Karpathy 的（比如 Raw 不能”只进不改”）。下一篇单独写。
如果你也在做 AI + 传统行业（保险、医疗、金融、政务），下一篇应该会有共鸣。
五、两个自检问题
在动手改造你的知识库之前，花一分钟回答两个问题。
问题一：你希望这个知识库最后变成什么？
- 一本越长越厚的”个人百科”——出发点接近 Karpathy，上一篇的方案直接用
- 一个持续产出的”弹药库”——出发点接近范凯，加产出层和行动层
- 一块让你对复杂行业越看越透的”认知底座”——第三种，下一篇讲
问题二：半年后，这个知识库如果失败了，你会怎么形容它？
- “它没能帮我想得更深”——你是积累型
- “它没能帮我写得更多”——你是产出型
- “它没能帮我把这个行业真正装进脑子”——你是第三种
答案大概率指向同一个方向。这就是搭知识库的真正第一步——不是选 Obsidian 还是 Notion，是先看清自己的出发点。
“搭好了然后呢”——这是上一篇发出来之后最多的一个问题。答案不是再装一个插件，而是退一步，看清自己到底要用知识库干什么。
工具是中性的，方法是有立场的。你的出发点，决定了这两样东西在你手里会变成什么。
下一篇见。
在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。