之前我们聊过 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/（产出层）— 视频脚本、文章创作、运营标准流程

中间三个层级是并行运行的管线，各自管理自己的领域。最底部的 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 模型的新能力、竞争对手的一个新功能、与业务方的一次争论、一篇论文里的工程细节。这些东西单独看似乎都没有太大意义，但组合在一起，才是你对这个行业的真实认知。

这种出发点既不是“将知识积累成百科全书”，也不是“将知识转化为内容产出”，而是——将一个陌生且复杂的行业，逐步装入自己的认知体系之中。

这种知识库更像一块不断积累、不断变厚的“认知底座”。平时可能并不频繁翻阅，但每一次关键的结构判断、每一次与业务方的对齐沟通，都悄然建立在这个基础之上。

为什么从事 AI + 传统行业的人需要这种特殊形态？因为仅靠公司提供的文档，很难真正装进自己的脑子。公司文档能够告诉你“我们目前是怎么做事的”，但无法告诉你“为什么这样做、下次遇到变化时应该如何判断”。这种“为什么”和“如何判断”的能力，只能通过自己在每一天的实践中慢慢对齐、消化和沉淀。

这种“认知底座”有几个反常规的设计思路，甚至有些是与 Karpathy 的方案相悖的（例如 Raw 层不能“只进不出”）。我们会在下一篇中单独详细讨论。

如果你也在从事 AI + 传统行业（保险、医疗、金融、政务），那么下一篇内容应该会引起你的共鸣。

五、两个自检问题

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

问题一：你希望这个知识库最终变成什么样的存在？
→ 一本越写越厚的“个人百科全书”——你的出发点接近 Karpathy，可以直接沿用上一篇的方案
→ 一个能够持续产出内容的“弹药库”——你的出发点接近范凯，需要增加产出层和行动层
→ 一块让你对复杂行业理解越来越透彻的“认知底座”——属于第三种，敬请期待下一篇

问题二：如果半年后这个知识库失败了，你会如何描述它失败的原因？
→ “它没有帮助我思考得更深入”——你是积累型用户
→ “它没有帮助我写出更多内容”——你是产出型用户
→ “它没能帮助我把这个行业真正装入脑子里”——你是第三种用户

答案大概率会指向同一个方向。这就是搭建知识库真正意义上的第一步——不是选择使用 Obsidian 还是 Notion，而是先认清自己的真实出发点和根本需求。

· · ·

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

工具本身是中性的，但不同的方法背后有不同的立场。你的出发点，决定了这些工具和方法在你手中会呈现出怎样的价值。

下一篇再见。