年认知底座：AI与传统行业从业者第三种知识库方案对比与排行

上一篇结尾，我们聚焦了第三种目标。它不同于Karpathy为研究者设计的“让知识积累成百科”，也不同于范凯为创作者设计的“让知识变成内容产出”。它的出发点更直接：把一个陌生而复杂的行业，逐步内化到自己的认知结构里。

几位读者私信说，这句话让他们产生了强烈的共鸣。但也有人追问：你说的这个“认知底座”，构型到底什么样？它跟前两种方案在底层逻辑上有什么不同？

这篇就来回答这个问题。

一、一个真实的场景

假设你是一家保险公司的AI架构师。团队技术能力过硬，RAG、Agent、Fine-tuning，样样都能落地。但有个场景总让人头疼：团队拿出的方案，技术上无可挑剔，可一给业务方看，对方沉默三秒，然后抛出这么一句——“你们没考虑再保分出的影响。”

你知道“再保分出”这个术语。但你不确定它在眼前这个具体场景里，会如何影响产品定价的下限；不确定监管对这一块的最新政策口径是什么；更不确定业务方真正的顾虑，到底是合规还是利润。概念查得到，但缺的是那种把概念串联成判断的“手感”。

这才是做AI+传统行业的真正难点。不是不懂AI，甚至不是不懂行业术语——关键在于，你作为架构师，必须在行业的灰度地带做出架构判断。这些判断没有标准答案，也没有任何教程能教给你。它们只能从大量碎片化的行业认知中慢慢生长出来：一段监管文件的言外之意、一次和精算师的午饭闲聊、一个竞品方案失败的真实原因。

更让人疲惫的是你的位置。你是整个公司里唯一一个需要同时深度理解AI能力边界和行业运作逻辑的人。AI团队觉得你太保守——“为什么不能直接上RAG？”；业务团队觉得你太激进——“你不懂这个行业。”你每天在两种语言之间做翻译，而两边都不觉得你是自己人。

你需要的不是一个“知识百科”，也不是一个“内容弹药库”。你需要的是一块地基——一块不断垫厚的行业认知层。让你在每一次架构决策的瞬间，能凭借对行业的真实理解做出判断，而不是凭技术直觉去猜。

这就是“认知底座”。

二、为什么前两种方案不够用

先看Karpathy的方案。

他的核心是Wiki——每个概念一篇笔记，AI自动维护交叉引用。这对研究者来说是完美的，因为研究者的知识是“概念→概念”的网状结构，一个概念可以独立存在。

但架构决策不是靠概念做的。

你要判断“核保环节该不该上RAG”，牵涉的不是某一个概念，而是一整个情境——再保分出的比例会影响哪些产品线、业务方的真实顾虑是合规还是利润、监管对AI辅助决策的口径最近有没有变。这些东西必须绑在一起看，才能形成一个可以指导架构的判断。

行业知识的最小单位不是“概念”，而是“情境”——谁、在什么条件下、为什么这么做、我基于此做了什么决策。Karpathy的Wiki模式天然倾向于把情境拆散成独立概念。拆散之后，链接再密，也补不回来那个“活的决策上下文”。

再来看范凯的方案。

他的核心是产出——知识必须变成文章、视频、SOP。弹药库存着不开枪，等于没有。

但作为架构师，你的“产出”不是内容，而是架构判断和技术决策。这些东西不需要写成文章发出去，它们需要的是在你脑子里慢慢变厚、变准、变快。你不是不产出，只是你的产出形态不是“内容”——是每一次技术评审里的那个关键判断，是每一份架构方案背后那个“为什么选A不选B”的考量。

三、两个反常识的设计

上一篇预告过，这套方案有一些“反Karpathy”的地方。这里展开说说。

反常识一：Raw不能“只进不改”

Karpathy的raw/是原始档案，只进不改。这对网页文章、论文来说没问题——原文就是原文，改了反而失真。

但行业素材不一样。

你存了一份监管文件的摘录。三个月后，你终于搞懂了那段话的真实含义——它表面上说的是“偿付能力充足率”，实际上约束的是产品定价策略。这个理解不写回原始记录，下次你翻到它，还是一脸茫然。

所以在认知底座里，Raw不叫Raw，叫sources/。原始素材进来之后，你可以——而且应该——在旁边加批注。批注用明确的标记隔开，比如 > [我的理解]，这样原文和你的认知层次分明，但又住在同一个屋檐下。

你的理解会变。三个月前的批注可能是错的。没关系，划掉旧的，写上新的，标上日期。这个“覆盖”的过程，本身就是认知在生长的证据。

反常识二：不追求“每个概念一篇笔记”

Karpathy的Wiki追求原子化——一个概念一个文件，方便AI维护和交叉引用。

认知底座反其道而行之。核心单位不是“概念”，而是“判断”。

什么是判断？就是你在工作中基于多个信息源形成的一个架构级结论。比如下面这段：

这段话涉及RAG、重疾险、核保、隐性知识、文档化缺失，最后落到了一个明确的技术路线选择。如果拆成五篇Wiki笔记，每篇都只剩下碎片，而最重要的东西——那个决定了整个项目走向的架构判断——反而无处安放。

所以认知底座的核心区不叫wiki/，叫insights/。每篇笔记是一个判断，而不是一个概念。标题不是名词（“再保分出”），而是句子（“重疾险核保的瓶颈不在模型能力，在隐性知识的采集”）。

这些判断积累到一定厚度，就是你做架构评审时的底气来源。

四、文件夹结构

MyBrain/
├── sources/                # 带批注的原始素材
│   ├── regulations/        # 监管文件、政策解读
│   ├── industry/           # 行业报告、竞品分析
│   ├── internal/           # 内部文档、会议纪要、口头经验
│   ├── tech/               # 技术文章、论文、工具评测
│   └── conversations/      # 与同事/业务方的关键对话
│
├── insights/               # 你的判断（核心区）
│   ├── validated/          # 已验证的判断
│   └── tentative/          # 暂时的判断，待验证
│
├── maps/                   # 认知地图
│   ├── domain.md           # 行业全景图：这个行业的关键环节是什么
│   ├── gaps.md             # 盲区清单：我还不懂什么
│   └── changelog.md        # 认知变更记录：我的理解哪里变了、为什么变了
│
└── schema.md               # 整体说明 + AI 协作规则

整体说明 + AI 协作规则

跟前两个方案做个对比——

重点说说maps/这个文件夹，它是认知底座独有的东西。

domain.md是你对整个行业的全景理解。刚开始可能只有五六个粗糙的方框，半年后会变成一张密密麻麻的地图。这张地图不是给别人看的，是给自己用的——每次做架构决策之前扫一眼，确认自己没有漏掉什么关键环节。

gaps.md是盲区清单。你随时往里扔“我不懂XXX”。AI会定期扫描这个清单，跟你已有的sources/和insights/做交叉比对，告诉你哪些盲区其实你已经有足够的素材可以攻破了——你只是还没坐下来想。

changelog.md是最容易被忽略、但最有价值的一个文件。每次你的理解发生重大变化，记一笔。比如：

2025-03-12：修正了对“再保分出影响产品定价下限”的理解。原来以为只影响定价模型，跟精算师聊完发现它同时影响合规层面的准备金计提，这意味着RAG系统里必须同时索引这两类文档。

半年后翻changelog，你会清晰地看到自己的认知是怎么一步步修正的。这种“看到自己在变”的感觉，是坚持下去最强的燃料。

一个必须讲清楚的副作用

做架构师的人读到这里会意识到一件事：你的insights/积累到一定厚度后，它们就是你给企业搭AI系统时的“架构草图”。

这不是比喻，是字面意义上的对应——

• 每一条validated判断，都可能直接变成规则引擎里的一条逻辑，或者RAG系统里一段高质量的System Prompt；
• domain.md的行业全景图，本质上就是系统的领域模型（Domain Model）的初稿；
• changelog.md里记录的“我的理解哪里变了”，对应着系统设计里最容易被忽略的东西：为什么我们上一版这样做，以及为什么现在必须改。

好的系统设计从来都建立在对领域的深度理解之上。DDD（领域驱动设计）讲了二十年的事，在AI系统上以一种更残酷的方式复现——你不理解领域，你的Prompt就是空的，你的检索就是乱的，你的Agent就是瞎跑的。

但顺序不能反。如果一开始就冲着“为系统积累素材”去做认知底座，你会不自觉地跳过那些“暂时没用但帮你理解行业全貌”的东西，最后搭出来的系统看似完整，实则只覆盖了你碰巧了解的局部。先有理解，再有系统。认知底座是因，架构草图是果。颠倒过来，就是另一个失败项目的起点。

五、日常动作与协作规则

落到日常，四个动作，每周不到两小时。

收集——随手，但带一句话

最有价值的素材往往不是文章和论文，而是最容易消失的东西：一个提案被毙掉的真实原因（通常不会写在会议纪要里）、一个业务老手随口说的半句话、一次技术评审后走廊里的补充说明。这些东西如果不在24小时内扔进sources/，就永远消失了。

丢进去的时候，在最上面写一句话——“我为什么存这个”。一句就够。比如“跟上周老王说的定价逻辑有关”。不写这句话，三个月后这篇文章就是一个孤儿。

消化——每周一次，跟AI对练

请基于我最近一周新增的sources/，对比我现有的insights/，找出：哪些新素材与现有判断一致（加固），哪些暗示旧判断需要修正（挑战），哪些覆盖了全新的盲区（新增）。针对每一条，给我一个具体的问题让我思考，而不是直接下结论。

这一步是整套系统的心脏。AI不是在“帮你做笔记”，它是在拿你自己的素材反过来考你。

修正——动手改insights

AI给出建议之后，你来决定：这个旧判断确实需要改，还是AI理解错了？这个新判断我同意吗？改完之后，在changelog.md记一笔。这20%的思考时间省不掉——但也只需要20%。

扫描——每月一次，更新全景图

根据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本地版）跑消化流程。你自己在合规上怎么做，就是在给团队立标准。

八、三种方案，三种人

写完三篇，做个总收束。

三种方案用的是同一组工具，解决的是三个完全不同的问题。

搭知识库的真正第一步，从来不是装软件，是认清自己是哪种人。这件事，上一篇已经说过了。这一篇把最后一块拼图补上。

最后一个问题

但我知道你心里还有一个问题，读到这里没有被回答。

“我花一周想清楚一条insight，同一时间模型可能已经爬了一百万条新数据。我这样辛苦建底座，值吗？”

这个问题大到需要单独一篇来写。所以把它留到下一篇——作为这个系列的番外，也是整个三篇方法论最底下的那块石头。

先给一个结论，供你不安的那几天用：跟AI比学习速度，是一场必输的赛跑。但你有另一场稳赢的比赛——只是赛道不同，大多数人还没意识到。

这一篇教你怎么建底座。下一篇告诉你，为什么值得建。

今天就做的一件事

打开你的Obsidian，建一个maps/文件夹，在里面新建gaps.md。然后做一件你可能会有点不舒服的事——

写下三个你上周刚给团队拍过板的决定，但今天想起来，你其实没有十足把握那个判断是对的。

不是“我不懂的三个概念”——那种清单老手随便能写一页。而是“我已经拍了板、团队已经在执行、但如果现在重来一次，我其实答不上来为什么是这个选择而不是另一个”的三个决定。

如果你写不出来，恭喜，说明你不需要认知底座。

如果你写出来了——那三条就是你认知底座的第一块砖。它们太烫手了，必须马上开始砌。