认知底座：AI + 传统行业从业者的第三种知识库方案
上一篇结尾我提到了第三种出发点——既不是 Karpathy 的”让知识积累成百科”，也不是范凯的”让知识变成内容产出”，而是：把一个陌生而复杂的行业，慢慢装进自己的脑子里。
有几个读者私信说，这一句话让他们突然对号入座。但更多的人问我：你说的这种”认知底座”，到底长什么样？跟前两种有什么不同？
这篇就来回答这个问题。
同时兑现上一篇的承诺——认知底座有几个反常识的设计，其中有几条是反 Karpathy 的。
一、先说清楚：认知底座是什么，不是什么
我在 AI + 保险这个交叉地带工作。
这个位置有点特殊——一边是变化极快的 AI 技术，一边是变化极慢的传统保险行业。每天接触的信息极其碎片：监管新规的一段、某个模型新能力的技术细节、竞品功能的一次调研、跟精算师争执之后的复盘、一篇论文里关于理赔欺诈识别的工程设计……
这些东西单看都没意义，合在一起才是你对这个行业的真实理解。
所以我需要一个知识库。但我要的不是百科，也不是弹药库。
百科（Karpathy 的方向）的终点是”知识沉淀下来”。Wiki 里面的每一篇都是结论，链接越密越好，概念越完整越好。这适合研究者——研究者的工作本来就是产出知识本身。
弹药库（范凯的方向）的终点是”写出来、发出去”。输入是为了输出服务的。这适合内容创作者——他们的价值在于持续生产内容。
我需要的是第三种——认知底座。
认知底座的终点，不是”把知识存好”，也不是”把内容发出去”，而是——在这个行业里，每一次判断的质量比上一次更好。
这个”判断”可以是：要不要接这个项目？这个监管变化对我们的技术路线有多大影响？这个新模型的能力，能不能解决理赔复核那个卡点？产品说要做智能核保，我应该支持还是泼冷水？
它平时不怎么被翻，但每一个判断，都悄悄建立在它之上。
认知底座的特征，用一句话说：它不是档案馆，是你思考某个问题时大脑的延伸。
二、反常识设计一：Raw 不能”只进不改”
Karpathy 的原则之一，是 raw/ 这个文件夹只进不改——所有原始素材只收集，不编辑，让 AI 去整理、去升华。
我试了三个月。发现对做 AI + 保险的人来说，这条规则有一个致命的问题。
保险是一个监管驱动、时效性极强的行业。一份 2022 年的”健康险重疾定义修订征求意见稿”，到了 2025 年可能已经正式落地，甚至已经被再次修订。如果 raw/ 只进不改，这份文件会永远躺在那里，像一个已经失效的法律条文——但你每次向 AI 提问，它都还在参考这份”原始文件”。
我遇到过一个具体的坑——
某次我问知识库：”现在监管对 AI 辅助核保的态度是什么？”
AI 综合了我收藏的五份文件，给了我一个看起来非常完整的回答。其中引用的核心政策文件，是我两年前存进去的一份地方性试点文件。但这份文件早就被新的全国性指引覆盖了，试点结论甚至和正式方向相反。
这不是 AI 的错。是我的 raw/ 没维护。
所以认知底座的第一个反常识：raw/ 需要标注”有效期”，需要定期归档和标记”已过时”。
具体怎么做？我给每一条原始素材加一行元数据：
---
source: 银保监会官网
date: 2024-03
status: active # active / outdated / superseded
superseded_by: 2025-01-健康险AI应用指引.md
---
当 AI 读取 raw/ 的时候，我会在提示词里加一句：“请只参考 status: active 的文件。outdated 和 superseded 的文件仅供追溯，不作为结论依据。”
这条设计让 raw/ 从”档案堆”变成了”有血有肉的活文件夹”。代价是每隔几个月，你得花一两个小时扫描一遍，把该归档的归档。这是人该干的事，AI 帮你列清单，你来拍板。
三、反常识设计二：分类按”判断场景”，不按”内容主题”
主题分类是大多数知识库的默认逻辑。比如：
Knowledge/
├── 精算/
├── 监管/
├── 机器学习/
└── 产品设计/
这个结构看起来清晰，但有一个问题——当你需要做判断的时候，没有任何一个判断是单学科的。
比如我要判断”要不要投入资源做智能理赔”这件事，我需要：
- 技术判断：现在的 OCR + LLM 能力能不能满足理赔单证识别的精度要求？
- 监管判断：现行规定对 AI 辅助理赔的边界在哪里？
- 业务判断：这个方向在公司的战略优先级里排第几？竞品做到什么程度了？
- 资源判断：我们的技术团队有没有能力做，还是应该采购？
这四类信息分散在四个文件夹里。每次做判断，你都要穿越四个目录，把碎片手动拼在一起。
认知底座的分类逻辑不是”这条信息属于哪个学科”，而是”我在什么场景下会用到它”。
我现在的顶层结构是这样的：
Decisions/ （判断层） — 我做过的重要判断，以及当时的推理链
Landscape/ （全局层） — 行业地图、竞品状态、监管动态
Tech/ （技术层） — 模型能力边界、工程实现、踩过的坑
Tensions/ （矛盾层） — 还没想清楚的问题、悬而未决的判断
Inbox/ （输入层） — 新收进来的东西，还没有消化
其中最不寻常的是 Tensions/——这个目录专门存我还没想清楚的东西。
很多知识库的逻辑是”想清楚了再存进去”。但我发现，对于 AI + 保险这种复杂交叉地带，很多问题你永远不可能在短时间内”想清楚”，它需要六个月、一年的信息持续输入才能有个初步判断。
与其假装已经想清楚，不如把”还没想清楚”显式存起来，定期回来看看——上一次存进去的困惑，现在还是困惑吗？有没有新的信息让它变得更清晰了？
Tensions/ 是我的知识库里最有价值的一个目录。它记录的不是答案，是问题的演化轨迹。
四、反常识设计三：AI 是”陪你想”，不是”帮你记”
Karpathy 和范凯的方案里，AI 的核心角色都是整理者——把 raw 里的碎片，整理成结构化的笔记。
这个角色对我的场景不够用。
整理者假设的是”你收进来的东西是有价值的，只需要结构化”。但在 AI + 保险这种高度不确定的领域，很多信息的价值本身是有争议的。一篇文章说”大模型将在三年内替代传统核保”，另一篇说”保险监管的合规要求让 AI 核保在国内落地至少还需要五年”。这两个判断我都需要收进去——但不是为了整理，而是为了在这个张力里形成自己的判断。
我对 Claude Code 的使用方式，跟 Karpathy 不同。
Karpathy 的典型指令是：“读取 raw/ 里的新文件，为每个概念更新 wiki/”
我的典型指令是：“我最近在思考 AI + 健康险的智能核保方向。这是我最新的一些素材（附上 raw/ 里几篇）。告诉我：你看到了哪些判断，这些判断之间有什么张力，以及基于这些信息，你认为有哪些问题我应该更认真地思考？把这次对话的结论存到 Tensions/ai-underwriting-status.md。”
注意区别——我不是让它帮我整理，我是让它陪我完成一次思考过程。整理只是副产品。
这种使用方式有一个前提：你得有足够的行业 context 来判断 AI 说的哪些是对的，哪些是胡说八道。
这正是为什么认知底座要慢慢建、慢慢用——不是因为工具难，而是因为你自己需要时间成长到足以”驾驭这段对话”的位置。
所以认知底座有一个 Karpathy 和范凯都不太强调的维度：它是你自己判断力成长的记录。
你今天的一次判断，六个月后翻回来看，可能会发现当时遗漏了什么，或者当时的直觉其实是对的但理由说错了。这个”回看”本身，就是认知复利。
五、完整的结构和一段可以直接用的指令
把上面三个设计落下来，我的知识库长这样：
MyBrain/
├── Inbox/ 输入层——刚收进来的，还没消化
│ ├── Clippings/ 网页剪藏
│ ├── Docs/ 监管文件、研报（带 status 元数据）
│ └── Conversations/ 跟 AI 的有价值对话
│
├── Landscape/ 全局层——行业地图
│ ├── Regulation/ 监管动态（银保监、地方试点）
│ ├── Competitors/ 竞品追踪
│ └── Industry/ 行业趋势、资方视角
│
├── Tech/ 技术层——能力边界和工程细节
│ ├── Models/ 模型能力（OCR/LLM/多模态）
│ ├── Engineering/ 实现细节、踩坑记录
│ └── Vendors/ 供应商评估
│
├── Decisions/ 判断层——我做过的判断和推理链
│ └── YYYY-MM-DD-[主题].md
│
├── Tensions/ 矛盾层——还没想清楚的问题
│ └── [问题标题].md
│
└── schema.md 结构说明，AI 读这个来理解整个知识库
给 Claude Code 的初始化指令（可以直接粘贴）：
请帮我在当前文件夹搭建一个 AI + 保险行业的个人认知底座。
结构按照这个建：
Inbox/Clippings, Inbox/Docs, Inbox/Conversations
Landscape/Regulation, Landscape/Competitors, Landscape/Industry
Tech/Models, Tech/Engineering, Tech/Vendors
Decisions/
Tensions/
schema.md
几条特殊规定：
1. Inbox/Docs/ 里的每份文档顶部要有元数据区，包含 source, date, status（active/outdated/superseded），以及 superseded_by（如果有的话）
2. Tensions/ 里的每篇格式是：问题描述 → 当前已知信息 → 未解的张力 → 下一步需要什么信息才能推进
3. Decisions/ 里的每篇格式是：判断结论 → 当时依据 → 回顾标记（供未来自己批注）
建好结构和模板之后，告诉我每一层的用途和维护频率。
搭好之后的日常节奏，我建议这样分层：
| 频率 | 动作 |
|---|---|
| 随时 | 新内容丢进 Inbox/，不整理 |
| 每周 | 扫一遍 Inbox/，有价值的搬到对应层，顺便更新一次 Tensions/ |
| 每月 | 跑一次 AI 辅助的”status 扫描”，把过时文件标记为 outdated |
| 每季 | 把 Decisions/ 里上季度的判断回顾一遍，批注”现在看当时的判断，哪里对、哪里错” |
六、一个冷静的提醒：这不是效率工具
Karpathy 的方案省掉了整理的时间。范凯的方案加快了内容产出的速度。
认知底座干的事不一样——它不让你”更快”，它让你”更准”。
这个区别很重要，因为它影响你怎么评估这套系统有没有用。
如果你用了三个月，觉得”好像没省多少时间”——这可能是对的。认知底座的设计初衷，不是省时间，是避免在错误方向上浪费时间。如果它帮你在一个关键判断上少走了半年弯路，它的价值可能是任何一款”效率工具”都比不了的。但这种价值，三个月看不出来，要到做判断的那一刻你才能感受到。
所以评估认知底座的唯一标准，不是”我整理了多少笔记”，而是”我最近一次做重要判断的时候，知识库有没有派上用场”。
如果你的知识库在真实决策里缺席，那不管它有多少条笔记，它都没有在工作。
还有一个这套系统容易踩的坑：把”装进去”误认为”装进脑子”。
认知底座最大的风险，和所有知识管理工具一样——变成精美的信息仓库，但从不被用来推动真实的思考。Tensions/ 里的问题三个月没有任何更新，Decisions/ 里没有任何回顾批注——这种知识库，不管架构设计得多合理，都已经在慢慢死亡。
认知底座不是工具替代思考，是工具逼你把思考显式化。”我不知道”本身就是一条值得存进去的信息。
七、两个自检问题
用这套系统之前，先回答两个问题。
问题一：你在这个行业里，最近一次做”判断”是什么时候？
如果你已经很久没有做过需要调用深度行业认知的判断，那你目前可能不需要认知底座。认知底座是为了服务判断而存在的，如果没有判断的需求，这套系统会比任何知识库都更快死亡——因为它不只靠收集驱动，它靠”被真实问题拉着走”驱动。
问题二：你现在脑子里有没有一个”还没想清楚的问题”，让你觉得再不梳理就要在某件事上出岔子？
如果有，把它写进 Tensions/，这是认知底座最好的启动方式——不是先把所有笔记整理好，而是先把那一个最让你焦虑的问题，显式地写下来。
然后告诉 Claude Code：“这是我现在最困惑的问题，这是我目前掌握的信息，帮我整理目前已知的、还不知道的、以及我需要找什么信息来推进这个判断。”
系列的三篇到这里全了。
- 第一篇：Karpathy 的方法，停止收藏，让 AI 替你整理
- 第二篇：Karpathy vs 范凯——你的出发点决定你该抄哪一份
- 第三篇：第三种出发点——认知底座，把复杂行业装进脑子
如果你在做 AI + 保险、AI + 医疗、AI + 金融、AI + 政务，第三篇应该是最切中你处境的一篇。欢迎留言聊聊——你的 Tensions/ 里现在放着什么问题？
在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。