认知底座：AI + 传统行业从业者的第三种知识库方案
上一篇结尾我提到了第三种出发点——既不是 Karpathy 那种为研究者而生的”让知识积累成百科”，也不是范凯那种为创作者而生的”让知识变成内容产出”，而是：把一个陌生而复杂的行业，慢慢装进自己的脑子里。
有几个读者私信说，这一句话让他们突然对号入座。但更多的人问我：你说的这种”认知底座”，到底长什么样？跟前两种有什么不同？
这篇就来回答这个问题。
一、一个真实的场景
你是一家保险公司的 AI 架构师。团队技术能力没问题，RAG、Agent、Fine-tuning 都能做。但你发现一个反复出现的状况：团队交出来的方案，技术上无可挑剔，拿给业务方一看，对方沉默三秒，然后说：”你们没考虑再保分出的影响。”
你知道”再保分出”是什么。但你不确定它在这个具体场景下会怎样影响产品定价的下限，也不确定监管对这一块的最新口径是什么，更不确定业务方真正的顾虑到底是合规还是利润。你能查到概念，但你缺的是那个把概念串成判断的”手感”。
如果你不在保险行业，请把”再保分出”替换成你这个行业里那个——业务方随口一句、你听得懂每个字却接不住整句话——的概念。医疗 AI 里可能是”DRG 分组”，政务 AI 里可能是”跨部门事权”，制造 AI 里可能是”工艺窗口”。名词不同，位置一样。
这才是做 AI + 传统行业的真正难点。不是不懂 AI，甚至不是不懂行业术语——而是你作为架构师，必须在行业的灰度地带做出架构判断，而这些判断没有标准答案，也没有任何教程能教你。它们只能从大量碎片化的行业认知中慢慢长出来：一段监管文件的言外之意、一次和精算师的午饭闲聊、一个竞品方案失败的真实原因。
更让人疲惫的是你的位置。你是整个公司里唯一一个需要同时深度理解 AI 能力边界和行业运作逻辑的人。AI 团队觉得你太保守——”为什么不能直接上 RAG？”；业务团队觉得你太激进——”你不懂这个行业。”你每天在两种语言之间做翻译，而两边都不觉得你完全是自己人。
你需要的不是一个”知识百科”，也不是一个”内容弹药库”。你需要的是一块地基——不断垫厚的行业认知层，让你在每一个架构决策的瞬间，能凭借对行业的真实理解做出判断，而不是凭技术直觉猜。
这就是”认知底座”。
二、为什么前两种方案不够用
先说 Karpathy 的方案。
他的核心是 Wiki——每个概念一篇笔记，AI 自动维护交叉引用。这对研究者来说是完美的，因为研究者的知识是”概念 → 概念”的网状结构，一个概念可以独立存在。
但架构决策不是靠概念做的。
你要判断”核保环节该不该上 RAG”，涉及的不是某一个概念，而是一整个情境——再保分出的比例会影响哪些产品线、业务方的真实顾虑是合规还是利润、监管对 AI 辅助决策的口径最近有没有变。这些东西必须绑在一起看，才能形成一个可以指导架构的判断。行业知识的最小单位不是”概念”，而是”情境”——谁、在什么条件下、为什么这么做、我基于此做了什么决策。
Karpathy 的 Wiki 模式天然倾向于把情境拆散成独立概念。拆散之后，链接再密也补不回来那个”活的决策上下文”。
再说范凯的方案。
他的核心是产出——知识必须变成文章、视频、SOP。弹药库存着不开枪，等于没有。
但作为架构师，你的”产出”不是内容，而是架构判断和技术决策。这些东西不需要写成文章发出去，它们需要的是在你脑子里慢慢变厚、变准、变快。你不是不产出，而是你的产出形态不是”内容”——是每一次技术评审里的那个关键判断，是每一份架构方案背后的那个”为什么选 A 不选 B”。
认知底座的逻辑是：先把行业装进脑子里，让你的判断力本身成为产出。写文章、做分享是它的副产品，不是驱动力。
三、两个反常识的设计
上一篇预告过，这套方案有一些”反 Karpathy”的地方。这里展开说。
反常识一：Raw 不能”只进不改”
Karpathy 的 raw/ 是原始档案，只进不改。这对网页文章、论文来说没问题——原文就是原文，改了反而失真。
但行业素材不一样。
你存了一份监管文件的摘录。三个月后你终于搞懂了那段话的真实含义——它表面上说的是”偿付能力充足率”，实际上约束的是产品定价策略。这个理解不写回 Raw，下次你翻到它，还是一脸茫然。
所以在认知底座里，Raw 不叫 Raw，叫 sources/。原始素材进来之后，你可以——而且应该——在旁边加批注。批注用明确的标记隔开，比如 > [我的理解]，这样原文和你的认知层次分明，但住在同一个屋子里。
你的理解会变。三个月前的批注可能是错的。没关系，划掉旧的，写上新的，标上日期。这个”覆盖”的过程本身就是认知在生长的证据。
反常识二：不追求”每个概念一篇笔记”
Karpathy 的 Wiki 追求原子化——一个概念一个文件，方便 AI 维护和交叉引用。
认知底座反过来。核心单位不是”概念”，而是”判断”。
什么是判断？就是你在工作中基于多个信息源形成的一个架构级结论。比如：
“在重疾险产品上用 RAG 做智能核保，短期内不可行。原因不是技术，而是核保规则里有大量隐性经验（如地区差异、渠道差异），这些经验没有被文档化，现阶段 RAG 检索不到。技术路线应该先做核保知识的结构化采集，再谈智能化。”
这一段话涉及 RAG、重疾险、核保、隐性知识、文档化缺失，最后落到了一个明确的技术路线选择。如果拆成五篇 Wiki 笔记，每篇都只有碎片，最重要的东西——那个决定了你整个项目走向的架构判断——反而无处安放。
所以认知底座的核心区不叫 wiki/，叫 insights/。每篇笔记是一个判断，而不是一个概念。标题不是名词（”再保分出”），而是句子（”重疾险核保的瓶颈不在模型能力，在隐性知识的采集”）。 这些判断积累到一定厚度，就是你做架构评审时的底气来源。
四、文件夹结构
MyBrain/
├── sources/ # 带批注的原始素材
│ ├── regulations/ # 监管文件、政策解读
│ ├── industry/ # 行业报告、竞品分析
│ ├── internal/ # 内部文档、会议纪要、口头经验
│ ├── tech/ # 技术文章、论文、工具评测
│ └── conversations/# 与同事/业务方的关键对话
│
├── insights/ # 你的判断（核心区）
│ ├── validated/ # 已验证的判断
│ └── tentative/ # 暂时的判断，待验证
│
├── maps/ # 认知地图
│ ├── domain.md # 行业全景图：这个行业的关键环节是什么
│ ├── gaps.md # 盲区清单：我还不懂什么
│ └── changelog.md # 认知变更记录：我的理解哪里变了、为什么变了
│
└── schema.md # 整体说明 + AI 协作规则
跟前两个方案做个对比——
| Karpathy | 范凯 | 认知底座 | |
|---|---|---|---|
| 原始素材 | raw/ 只进不改 |
Notes/ 分三类 |
sources/ 带批注，可覆盖 |
| 核心区 | wiki/ 概念为单位 |
Knowledge/ + Writing/ |
insights/ 判断为单位 |
| 独有的层 | 无 | 产出层、行动层 | maps/ 认知地图 |
| AI 角色 | 主笔 | 参谋 | 陪练 |
| 核心动词 | 积累 | 产出 | 理解 |
重点说 maps/ 这个文件夹，它是认知底座独有的东西。
domain.md 是你对整个行业的全景理解。刚开始它可能只有五六个粗糙的方框，半年后它会变成一张密密麻麻的地图。这张地图不是给别人看的，是给你自己用的——每次做架构决策之前扫一眼，确认自己没有漏掉什么关键环节。
gaps.md 是盲区清单。你随时往里扔”我不懂 XXX”。AI 定期扫描这个清单，跟你已有的 sources/ 和 insights/ 做交叉比对，告诉你哪些盲区其实你已经有足够的素材可以攻破了——你只是还没坐下来想。
changelog.md 是最容易被忽略、但最有价值的一个文件。每次你的理解发生重大变化，记一笔。比如：
2026-03-15：之前以为核保规则是确定性的（if-else），今天跟资深核保师聊完才知道，至少 30% 的案例依赖经验判断，且不同核保师的判断会不一致。这意味着 RAG 方案的上限比我预估的低很多。架构需要调整：先做”核保经验结构化采集工具”，再做智能核保。跟 PM 同步了这个判断。
半年后翻 changelog，你会清晰地看到自己的认知是怎么一步步修正的。这种”看到自己在变”的感觉，是坚持下去最强的燃料。
一个必须讲清楚的副作用
做架构师的人读到这里会意识到一件事：你的 insights/ 积累到一定厚度后，它们就是你给企业搭 AI 系统时的”架构草图”。
这不是比喻，是字面意义上的对应——每一条 validated 判断，都可能直接变成规则引擎里的一条逻辑，或者 RAG 系统里一段高质量的 System Prompt；domain.md 的行业全景图，本质上就是系统的领域模型（Domain Model）的初稿；changelog.md 里记录的”我的理解哪里变了”，对应着系统设计里最容易被忽略的东西：为什么我们上一版这样做，以及为什么现在必须改。
但顺序不能反。 如果你一开始就冲着”为系统积累素材”去做认知底座，你会不自觉地跳过那些”暂时没用但帮你理解行业全貌”的东西，最后搭出来的系统看似完整，实则只覆盖了你碰巧了解的局部。先有理解，再有系统。认知底座是因，架构草图是果，颠倒过来就是另一个失败项目的起点。
五、日常动作与协作规则
落到日常，四个动作，每周不到两小时。
收集——随手，但带一句话。 最有价值的素材往往不是文章和论文，而是最容易消失的东西：一个提案被毙掉的真实原因（通常不会写在会议纪要里）、一个业务老手随口说的半句话、一次技术评审后走廊里的补充说明。这些东西如果不在 24 小时内扔进 sources/，就永远消失了。丢进去的时候，在最上面写一句话——”我为什么存这个”。一句就够。比如”跟上周老王说的定价逻辑有关”。不写这句话，三个月后这篇文章就是一个孤儿。
消化——每周一次，跟 AI 对练。 打开 Claude Code（或任何能读本地文件夹的工具），指向你的 MyBrain 目录，说：”请读取这周 sources/ 里的新素材，结合 insights/ 里已有的判断，告诉我：哪些旧判断需要更新？有没有新的判断可以形成？gaps.md 里的哪些盲区现在可以尝试填补？”
这一步是整套系统的心脏。AI 不是在”帮你做笔记”，它是在拿你自己的素材反过来考你。
修正——动手改 insights。 AI 给出建议之后，你来决定：这个旧判断确实需要改，还是 AI 理解错了？这个新判断我同意吗？改完之后，在 changelog.md 记一笔。这 20% 的思考时间省不掉——但也只需要 20%。
扫描——每月一次，更新全景图。 对 AI 说：”根据 insights/ 当前状态，重新审视 maps/domain.md，建议哪些区域需要补充细节、哪些连线需要修正。”然后你看着建议，手动改地图。做 AI + 传统行业最容易掉进的坑就是埋头在某个局部里出不来。每月一次全景扫描，是给自己拉一次远景。
AI 的角色：陪练，不是主笔
Karpathy 让 AI 主笔维护 Wiki，范凯让 AI 先报方案再执行。认知底座里，AI 的角色再退一步——它是陪练，不是助手。 你跟 AI 说”帮我理清这个逻辑链”，它把你已有的素材串起来，指出哪些环节你已经有材料支撑，哪些环节还是空白。它不替你下结论，它帮你看清自己的认知地图上哪里还有洞。
你可能会问：这种陪练，一个资深同事不是做得更好吗？
三个理由让这件事必须是 AI。
第一，规模。半年之后你的 sources/ 里会有两三百篇素材，insights/ 里会有几十条判断。你自己不可能每周全量扫一遍做交叉比对，任何同事也不会做这种苦差事。AI 可以。这不是”AI 帮你省时间”，是人根本做不到的事。
第二，主动性。好的 AI 陪练会主动说：”你在 validated/ 里的第 23 条判断，跟本周新存的那篇监管文件冲突了，是没注意还是有意忽略？”——或者：”你在’隐性知识采集’这个主题上过去半年改了 5 次判断，可能说明你对它的理解还不稳定。”这种跨时间、跨文件的模式发现，你自己身处其中反而看不见。
第三，无社交成本。你在 insights/ 里需要能写”这条核保规则大概率是老王拍脑袋定的，缺乏精算支撑”这种极其诚实的判断。这话在任何真人面前都说不出口——哪怕他是你最信任的同事。AI 是唯一一个可以让你诚实到这种程度的陪练对象。 认知底座一旦失去这种诚实，立刻就变成一份漂亮的自我欺骗。
它看起来不像前两种方案里 AI 那样”一直在干活”，但它干的活不可替代。
这个定位写进 schema.md，Claude Code 每次打开文件夹时就会遵守。核心几条：
## 你的角色
你是我的认知陪练，不是笔记助手。目标是帮我加深对行业的理解，
而不是帮我生产漂亮的笔记。
## 绝对不做的事
- 不替我下判断。可以说"素材 A 和 B 似乎指向 X"，
不能说"结论是 X"
- 不在我没确认的情况下修改 insights/
- 不删除 sources/ 里的任何东西
- 不编造 sources/ 里没有的行业知识。素材不足时，
直接说"现有 sources 无法支撑该判断"
## insights/ 规则
- 标题是判断句，不是名词
- 分 validated/ 和 tentative/ 两个状态
- 当 tentative 判断被至少三条独立素材支撑，建议我移到 validated/
- 当新素材与已有判断矛盾，立即提醒我
认知底座的全部意义在于：理解是你自己长出来的，AI 只是帮你看清哪里还没长。
六、它会长多大，怎么长
到这里有人会产生一个真实的怀疑：判断这么零散，真的能长成一个有用的东西吗？还是最后只是一堆砖头，永远垒不成房？
先给结论：零散不是缺陷，是起点。系统化不是靠你设计出来的，是从密度里浮现出来的。
量级
做 AI + 传统行业的架构师，真实面对的判断题来自至少六个层面——技术选型、数据边界、业务规则、组织诉求、监管口径、行业演化。六层交叉下来，光一个保险行业就能产生几百个独立判断题。
insights/ 的增长曲线大概是这样：第一年快速积累到 80-120 条，第二年慢增到 150-200 条但大量 tentative 转为 validated，第三年之后新增极少、每条持续变厚。这个形状是对数增长——跟下一节要讲的”判断力拐点”，是同一件事的两个侧面。
系统化发生的三个机制
机制一：聚类。 当 insights/ 到 30-50 条时，AI 每月扫一遍会发现簇。比如：”你过去三个月的 17 条判断里，有 6 条都指向同一个底层约束——保险业的隐性知识比显性知识多。场景完全不同，但都在说同一件事。”这个簇抽象出来就是一条上位判断，它不是你强行总结的，是自下而上浮现的。上位判断一旦成立，它就成了你这个领域的公理，后面所有新判断都会被它筛选。
机制二：冲突驱动的精化。 当两条判断打架时，系统化被迫发生。
- A（半年前）：”RAG 在重疾险核保不可行，瓶颈是隐性知识”
- B（上周）：”某医疗险客户用 RAG 做辅助核保，效果不错”
AI 指出冲突。你被迫想：是 A 错了，B 错了，还是两者都对但适用条件不同？你最终写出：
- C：”RAG 在保险核保里的可行性取决于该险种规则的显性化程度。重疾险 < 医疗险 < 车险，分界点在 X。”
C 比 A 和 B 都高一级——它不是并列的砖，它是梁。 梁出现之后，系统才开始有骨架。冲突越多，梁越多。两年之后，你的 insights/ 会从”一堆砖”变成”一栋房”。
机制三：domain.md 的反向牵引。 每次做架构决策前扫一眼全景图，你会发现某些区域判断密集（你在那里想得多），某些区域几乎空白（你从没深入想过）。空白区就是 gaps.md 的新增来源——你甚至不知道自己不知道的事，通过地图的不均匀暴露出来。没有 domain.md 的知识库，永远不知道自己偏科。
最终形态
两年之后，你不会得到一个”目录整齐的知识库”。你得到的是一个从底部长出来的行业理解框架。它看起来还是零散的砖和梁，但你站在里面，能一眼看清这个行业的承重结构。
这就是”系统性”真正的样子——不是目录整齐，而是判断之间互相承重。
七、三个冷静的提醒
第一，前三个月会觉得没用——直到那个拐点来临。
Karpathy 的方案搭完就能查，范凯的方案搭完就能写。认知底座不一样——前三个月你的 insights/ 里可能只有十几条半生不熟的判断，domain.md 像小学生画的地图一样粗糙。
行业认知不是翻倍增长的，是对数增长的。 一开始很慢，慢到你反复怀疑这套东西到底有没有用。然后某一天会发生这样的事：你坐在一个跨部门技术评审里，业务方抛出一个问题，过去的你会本能地看向精算师或者核保负责人求救，这次你在他们开口之前已经想明白了。你听见自己说：”这个方案不可行，不是因为技术，而是因为渠道差异会让它在三四线市场失真。我们应该先做 A，再做 B。”会议室安静了两秒，业务方点头。
那一刻你知道底座长出来了。 它不会在第一个月来，也不会以”啊哈时刻”的方式来。它是某天突然发现自己已经站在那里了。
第二，这套方案的天花板就是你的投入。
Karpathy 的天花板取决于 AI 的维护能力，范凯的天花板取决于产出频率。认知底座的天花板只取决于一件事：你每周有没有真的坐下来做那 20 分钟的消化。AI 能把素材摆在你面前，但那个”啊，原来是这样”的瞬间，只能你自己到达。
但也正因如此，认知底座是你手里最抗通胀的资产。 做 AI + 传统行业的人都有一种特殊的焦虑：AI 技术每周都在变，行业知识却要以年为单位积累，你觉得自己同时在追两条赛道，哪条都追不上。认知底座帮你把这两条赛道分开：sources/tech/ 里的东西会不断过时，但你 insights/ 里的行业判断——”核保的瓶颈不在模型能力，在隐性知识的采集”——不会因为模型从 GPT-4 换成 GPT-5 就失效。技术在变，但你对行业的理解是真正耐久的。
第三，合规是硬约束，不是可选项。
作为架构师，你比谁都清楚：传统行业最有价值的素材往往也是最敏感的——核保案例、赔付数据、内部决策纪要。如果你用的是公网大模型（包括 Claude Code 默认模式），这些内容会离开你的电脑。金融、医疗、政务行业对此零容忍。务实的做法是分层处理：sources/internal/ 里涉及真实业务数据的部分，要么脱敏后再喂给 AI，要么用本地部署的模型（Qwen、DeepSeek 本地版）跑消化流程。你自己在合规上怎么做，就是在给团队立标准。
（至于”你自己的底座建起来之后，怎么向团队辐射”——这是一个足够独立的题目，留到下一篇。简单说结论：你的底座必须是一个完全私密的空间，任何预期会被团队看到的笔记系统最终都会死于自我审查。 但你可以从中提炼脱敏版给团队。顺序不能反。）
八、三种方案，三种人
写完三篇，做个总收束。
| 你的身份 | 你的焦虑 | 你需要的 | 方案 | |
|---|---|---|---|---|
| 第一种 | 研究者、学习者 | 知识碎片化，每次从零开始 | 一本越来越厚的百科 | Karpathy 原版 |
| 第二种 | 创作者、运营者 | 知道很多却写不出来 | 一个能开枪的弹药库 | 范凯改造版 |
| 第三种 | AI + 传统行业架构师 | 要在行业灰度地带做架构判断 | 一块慢慢变厚的认知底座 | 本篇方案 |
三种方案用的是同一组工具，解决的是三个完全不同的问题。
搭知识库的真正第一步，从来不是装软件，是认清自己是哪种人。这件事，上一篇已经说过了。这一篇把最后一块拼图补上。
最后一个问题
但我知道你心里还有一个问题，读到这里没有被回答。
“我花一周想清楚一条 insight，同一时间模型可能已经爬了一百万条新数据。我这样辛苦建底座，值吗？”
这个问题大到需要单独一篇写。所以我把它留到下一篇——作为这个系列的番外，也是整个三篇方法论最底下的那块石头。
先给一个结论，供你不安的那几天用：跟 AI 比学习速度，是一场必输的赛跑。但你有另一场稳赢的比赛——只是赛道不同，大多数人还没意识到。
这一篇教你怎么建底座。下一篇告诉你，为什么值得建。
今天就做的一件事
打开你的 Obsidian，建一个 maps/ 文件夹，在里面新建 gaps.md。然后做一件你可能会有点不舒服的事——
写下三个你上周刚给团队拍过板的决定，但今天想起来，你其实没有十足把握那个判断是对的。
不是”我不懂的三个概念”——那种清单老手随便能写一页。而是”我已经拍了板、团队已经在执行、但如果现在重来一次，我其实答不上来为什么是这个选择而不是另一个”的三个决定。
如果你写不出来，恭喜，说明你不需要认知底座。 如果你写出来了——那三条就是你认知底座的第一块砖。它们太烫手了，必须马上开始砌。
在 AI 的喧嚣里，替你找到真正能用的东西。不搬运新闻，不贩卖焦虑。