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原始架构是三层（Raw Sources / Wiki / Schema）。范凯拆成五层：

• Notes/（输入层）— 网页剪藏、碎片想法、AI对话
• Knowledge/（知识层）— 方法论、读书笔记、原创思考
• Software/（技能层） — 工具技巧、开发笔记
• LifeOS/（行动层）— 投资、健康、保险等落地事项
• Writing/（产出层）— 视频脚本、文章、运营SOP

中间三层是并行管线，各自管理不同领域。底部的Writing/产出层是Karpathy方案中完全没有的。范凯的原话：

在Karpathy那里，弹药库就是目的；在范凯这里，弹药库只是中间站，开枪才是目的。

LifeOS/（行动层）也容易被忽视。范凯认为，投资笔记不是写完就完，要指导实际交易决策；健康计划必须转化为每周的训练安排。知识不仅需要“产出”，更需要“落地”。

调整二：输入层中增加了Conversation子目录。

Karpathy的Raw Sources是一个统一容器。范凯将输入拆分为三类：Clippings（网页剪藏）、Inbox（碎片想法）、Conversation（与AI的有价值对话）。

范凯的原话：

调整三：AI先提方案，人再决策。

这是范凯自己所说的“与Karpathy最大的分歧”。

Karpathy的模式是让LLM主导维护Wiki，人类参与审阅。范凯实践后发现，AI对“这篇文章应该放哪个分类”的判断经常失准——比如把内容创作方法论放到了Knowledge/而非Writing/Knowledge/，或者本应合并到已有文档的内容被新建了一个文件。

所以他增加了一条规则：AI先列出分类建议，人类确认后再执行。用他的话说，分类反映的是你自己的思维结构，AI可以提议，但最终由你决定。成本很低——看个表格而已——但能避免大量返工。

这三个调整背后的统一逻辑：知识必须流动起来，必须转化为实际成果，必须能落地执行。

三、两套方案，同一张对照表

你的目标决定了你该采用哪一套。

四、还有第三种动机

除了“让知识积累”和“让知识开枪”，是否存在第三种？
有。

笔者自己就属于第三种。所做的是AI + 保险这个交叉领域——一侧是快速迭代的AI技术，另一侧是变化缓慢的传统行业。这种位置的人，每天接触的信息极其碎片：监管文件的一段文字、某个模型的新能力、竞品的一个功能、一次与业务方的争议、一篇论文中的工程细节。这些内容单独看都没有意义，组合在一起才是你对这个行业的真实理解。

动机既不是“让知识积累成百科”，也不是“让知识转化为内容”，而是——把一个陌生且复杂的行业，慢慢装进自己的大脑。

这种知识库更像一块逐渐厚实的“认知底座”。平时不常被翻动，但每个架构决策、每次与业务方对齐，都悄然建立在它的基础之上。

为什么做AI + 传统行业的人需要这种特殊形态？因为仅靠公司文档无法真正装入大脑。公司文档能告诉你“我们现在怎么做”，但无法解答“为什么这么做、下次遇到变化该怎么判断”。这种“为什么”和“如何判断”，只能靠自己在日积月累中慢慢对齐、消化、沉淀。

这种“认知底座”带有几个反常识的设计，有些甚至与Karpathy相悖（比如Raw不能“只进不改”）。下一篇单独展开。

如果你也在做AI + 传统行业（保险、医疗、金融、政务），下一篇应该能引发共鸣。

五、两个自检问题

在动手改造你的知识库之前，花一分钟回答两个问题。

问题一：你希望这个知识库最终呈现什么形态？
→ 一本越来越厚的“个人百科”——动机接近Karpathy，直接沿用上一篇的方案
→ 一个持续产出的“弹药库”——动机接近范凯，需要增加产出层和行动层
→ 一块让你对复杂行业越看越透的“认知底座”——第三种，下一篇详解

问题二：半年后，这个知识库如果失败了，你会如何描述它？
→ “它没能帮我想得更深”——你是积累型
→ “它没能帮我写得更多”——你是产出型
→ “它没能帮我把这个行业真正装进脑子”——你是第三种

答案大概率指向同一个方向。这就是搭建知识库的真正第一步——不是选Obsidian还是Notion，是先看清自己的动机。

· · ·

“搭好了然后呢”——这是上一篇发布后最常被问到的问题。答案不是再装一个插件，而是退一步，看清自己到底要用知识库做什么。

工具是中性的，方法是有立场的。你的动机，决定了这两样东西在你手中会变成什么。

下一篇见。