我把 100 个思维模型连了一遍,发现 12 个是孤岛

我把 100 个思维模型连了一遍,发现 12 个是孤岛

上一篇说了网站的六个栏目各管什么事。这篇跑个题。 100 个思维模型写完之后,我自己回头翻了几篇,觉得不太对。有些模型之间的关系明明很明显——沉没成本和机会成本,一个说花掉的钱别惦记,一个说没选的那条路才是真代价,这俩放在一起才完整——但文章里居然没有互相链接。 100 篇文章逐个打开检查谁提到了谁、该连到哪篇,这种活我干不了。让 AI 跑了一遍。 AI 干了什么 扫全部 100 篇,把每篇提到的其他模型找出来,统计次数,生成链接。 跑完给我一堆数字。 第一性原理被引用 38 次,排第一。不意外,底层方法论,做什么决策都能扯上。同分类的模型互引密度也高,认知决策类 69%,执行效率类 80%。也不意外。 意外的是这几个。 意外的是这几个。 反脆弱被引用 35 次排第二,但它自己一篇都没引用过别的。只收不发。想了想也不奇怪,反脆弱太底层了,别的模型需要它来解释自己,但它不需要借别人。就像引力,什么都受它影响,但它不依赖任何东西。 然后是 12 个模型从来没被别人提到过。冯诺依曼、局部全局最优、不平衡性、时光机理论、煤气灯效应、护城河理论……7 个零引用,5 个只被提过 1 次。模型本身没问题。护城河做商业分析很好用,煤气灯效应在人际关系里很重要。但它们跟其他模型之间没连线。知道一个东西存在,和能把它跟你已经知道的东西联系起来,是两回事。 还有一点:分类之间几乎不来往。分类内部互引密度 60%-80%,跨分类只有 7.53%。决策类的模型跟系统类的模型,92% 的配对之间一条链接都没有。 聊到这 以前觉得知道 100 个模型就够了。现在发现不是。一个模型如果跟谁都不连着,真到用的时候根本想不起来。就像一个人能力很强但从来不跟别的部门打交道,价值就闷在那了。 这 12 个不是不好的模型,是我还没帮它们找到搭档。后面慢慢补。 这是第三篇。前两篇:为什么我开始写这个网站 · 网站的结构 · 下一篇:5000 个笔记吃灰之后

2026-08-04 · Gary
5000 个笔记吃灰之后,AI 教会我一件事

5000 个笔记吃灰之后,AI 教会我一件事

上一篇说了怎么把 100 个模型连成网。这篇说说这些知识怎么来的,以及为什么没有 AI 它们到现在还在硬盘里躺着。 5000 个文件 我试过很多笔记软件。Obsidian、Notion、SiYuan、语雀、NAS 的 note station,大概五六个。每个都用了一段时间,每个都觉得"这次应该行了"。 结果都一样:笔记越记越多,回去看的越来越少。 不是工具的问题。记下来的那个瞬间,大脑就觉得"这事处理过了",然后心安理得地忘掉。后来有一天打开 Obsidian,看着 5000 多个 md 文件,突然觉得它们对我来说已经死了。写的时候很认真,分类也清楚,但从来不翻。 第一次觉得笔记有用 转折其实很平淡。有次做某核心供应商的年度议价,我想参考半年前整理过的一段供应商比价分析。没刻意去翻,随口问了 AI。它从我知识库里把那段分析拉出来,还连带找到另一个相关的笔记——那个笔记我自己都忘了写过。 当时的感觉不是"AI 好厉害"。是"原来我记过这个东西"。 区别就在这:以前是我去找笔记,但我不找。现在笔记自己冒出来了。 RAG 技术细节不多说了。核心就一件事:把 5000 个文件切成小块,每块算一个向量存起来。问问题的时候,把问题也算成向量,找最相似的几块喂给 AI。 说白了就是给 AI 装了我的记忆。不是在互联网上搜,是在我自己的笔记里搜。 搭完之后加了个每天自动同步,这样知识库是活的,不是写完就冻住。 博客是怎么冒出来的 搭 RAG 的时候没想过写博客。博客是后来自然长出来的。 RAG 解决了"找得到",但没解决"用得上"。5000 个笔记里有很多好东西,但它们是碎片——一段分析、一个框架、几句感想。碎片能回答问题,但很难改变思维方式。 我想把碎片整理成完整的文章,有结构、有案例、有结论。整理的时候发现 AI 特别适合干这个——它能把散落在不同笔记里的相关内容找出来,帮我串到一起。 100 个思维模型就是这么来的。我有相关的笔记底稿,AI 帮我扩写、补案例、加关联。最终出来的东西,不是 AI 写的,也不是我写的,是一起整理的。 现在的状态 5000 个文件还在硬盘里,但不再吃灰了。 每天有新笔记写进去,RAG 自动同步。写博客的时候 AI 从里面找素材。读者问问题的时候 AI 从里面找答案。 回头看,这个网站——思维模型、AI 学习、决策洞察——全是这么来的。不是我先想好要做一个博客,是笔记积累到一定程度,需要一个出口。 这是第四篇。前几篇:为什么我开始写这个网站 · 网站的结构 · 100 个模型的孤岛 · 下一篇:知识不是用来收藏的

2026-08-04 · Gary
知识不是用来收藏的

知识不是用来收藏的

上一篇说了 RAG 怎么把我的死笔记救活。这篇想聊聊更底层的问题——我到底为什么需要一套"知识操作系统"。 先说一个丢人的事 我有个毛病,看到好东西就存。文章、视频截图、别人发的一段话,觉得有用就丢收藏夹。 十几年下来收藏夹堆了几千条,笔记软件换了六七个。每个都用过一阵。结果呢,存进去的那一刻觉得"学到了",之后再也没打开过。 我后来发现身边的人差不多都这样。收藏等于学会,标记等于掌握。 根子在哪 想了挺久。问题不在意志力,也不在工具。 我一直把"知识管理"等同于"知识收集"。收藏一篇文章,得到的是一种掌控感——“这东西在我手里了”。但这种掌控感是假的。你把一篇文章丢进收藏夹,跟你真正读懂了它、能用自己的话讲出来,差了十万八千里。 我需要的不是又一个收藏夹。我需要的是一套让知识从"进来"到"能用上"的完整流程。 我后来管这套流程叫"知识操作系统"。名字不重要。 就是把电脑操作系统的逻辑搬过来。Windows 管文件怎么存、程序怎么跑,知识操作系统管信息进来之后怎么加工、存哪、怎么找回来、什么时候该扔。 核心就一条闭环:输入 → 加工 → 存储 → 检索 → 应用 → 反馈 → 淘汰。 大部分人——包括之前的我——只做了第一步和第三步的一小半。中间的加工和后面的检索、应用、淘汰全跳了。笔记越堆越多,但没有一条变成"用过的知识"。 这个网站有一篇完整版的知识操作系统指南,47 篇文献,写得很系统。下面只说我自己的体会。 加工比收集重要 闭环里最容易被跳过的一步是"加工"。 光收藏不加工,等于食物塞满胃但不消化。加工就是消化,把别人写的东西嚼碎变成自己的。 我的方式是:读完一段合上,用自己的话讲一遍。讲不出来就是没懂——这一步对应九重知识阶梯的第 4 层"理解",很多人卡在 3-4 层就以为自己学会了。讲出来了,再问自己一句,这跟我已经知道的东西有什么关系? 就这么简单。但得做。 淘汰 另一个被跳过的环节是淘汰。 知识有保质期。三年前存的供应商分析,可能人家已经倒闭了。五年前记的技术方案,可能早过时了。但这些过期信息还躺在笔记里,占着位置,还给你一种"我知识面很广"的错觉。 我现在定期翻旧笔记,问自己"这条还有用吗"。有用就留或者更新,没把握就归档,确定过时了就删。删的时候有点舍不得。但留着一堆过期信息,跟冰箱里塞满了过期食品没什么两样。 这个网站 说了这么多,这个博客本身就是我知识操作系统的输出端。 写人类专栏是我自己在加工——写不出来的东西就是没想清楚,写得出来了就可以作为一个可视化的知识库,供我自己顺着思路回味,加强记忆。思维模型是 AI 帮我把散落的笔记串成体系。读者通过右下角的 AI 助手问问题,是在从我的知识库里检索。 输入、加工、存储、检索、应用,全在这个网站上跑着。淘汰暂时还手动,后面交给自动化。 闭环的每一步其实都能对到九重知识阶梯上——输入是 1-2 层,加工是 3-5 层,应用是第 6 层,反馈和淘汰是 7 层往上。知识真正"进去"了没有,最终还是要看第 9 层:有没有改变行为。 说到底这事儿没什么高深的。进来的东西得加工,加工完的得能用,用不上的定期清掉。就这么转着。 这是第五篇。前几篇:为什么我开始写这个网站 · 网站的结构 · 100 个模型的孤岛 · 5000 个笔记吃灰之后 · 下一篇:从凭感觉压价到凭数据压价

2026-08-04 · Gary
从凭感觉压价到凭数据压价

从凭感觉压价到凭数据压价

上一篇聊了知识操作系统。这篇说一个真用上的例子——我是怎么把这套系统套到采购成本分析上的。 先说一个尴尬的事 我刚接手现在这家制冷制造公司的供应链时,最怕老板问一句话:“我们一年到底花多少钱在哪些东西上?” 听起来是个简单问题。但真要回答,就发现谁都说不清楚。 采购系统里七八万条记录,跨三年半,几百个供应商,成千上万个物料编码。有人说"板材是大头",有人说"压缩机才是大头",但谁也拿不出一张表说"这是全部成本的分布"。 谈判的时候更糟。跟供应商谈降价,对方说"我们已经是最低价了",我没法反驳——因为我手上没有结构化的成本分布,不知道他报价在同类物料里处在什么分位。只能凭感觉压,压不动就算了。 这就是问题:没有成本地图,谈判就是瞎子摸象。 一张地图怎么搭起来 后来我干了一件事,给它起了个名字叫"成本 DNA"。 不是什么高深的模型,就是一件事:把所有采购记录按"功能"重新分类。原来系统里的分类是乱的——同一个物料在不同年份可能被归到不同类目,同名异码、异名同码到处都是。我把三年半的所有记录拉出来,一条一条重新归类,最后落到几个大功能块上。 比如制冷设备,拆完之后大头大概是这样的: 金属板材:占三成多(柜体的骨架和外壳) 制冷系统:占一成半(压缩机、冷凝器、蒸发器) 柜体内部结构:占一成(货架、隔板、照明) 电气与控制:占一成(电控板、传感器、线束) 前四个加起来快七成。这不是什么新发现,二八法则老早就说过了:少数关键品类吃掉了绝大部分成本。但知道这个道理是一回事,能拿着数据把"那 20% 到底是哪几个"指出来是另一回事。 以前只知道"板材是大头",现在知道板材比第二名高一倍。谈判精力该怎么分配、降本目标该往哪里砸,一目了然。后来我想明白一件事:做采购管理这么多年,本质上就是一个反复应用二八法则的过程——不是什么都管,是找到最关键的那几个点,把力气全砸上去。 Cost DNA 给了我一张分布图,让我每次都能找到那个"20%“在哪。 真用起来是什么感觉 地图搭好之后,几件事变了。 谈判不再凭感觉了。 以前供应商说"我这个价格在行业里算合理的”,我只能信。现在我可以拿数据回去核对:同类物料里你处在什么分位,年度均价是涨了还是跌了,跟其他供应商比你的溢价是多少。具体数字我不方便说,但有一家核心供应商,做完一次完整的成本比对之后,谈判结果比我预期好得多。 降本目标能落到具体物料上了。 以前定年度降本目标都是"今年再降百分之 X",然后平摊到每个采购员头上,每个人盯着自己的几个供应商瞎谈。现在反过来——先看 DNA 里哪块占比最高、哪块单价波动最大、哪块供应商集中度最高,然后把精力集中砸到二八法则指出的那几个交叉点上。砍掉一个低价值的供应商可能省的钱,远不如在头部供应商上磨出 1% 的让步。 能回答"为什么"了。 老板再问"我们为什么花这么多在板材上",我不再只能说"因为板材贵"。能说:板材占多少,是因为我们用的是 X 类不锈钢,单价比普通钢材高 Y 倍;供应商集中度是多少,前三家占了多少份额;过去三年的单价曲线是什么形状。每个数字都有出处。 怎么搭的 具体技术不多说,核心就一件事:把所有数据先拆散,再按功能重组。 采购系统里的原始分类是给会计和税务用的,跟实际业务的成本结构对不上。比如同一个不锈钢板材,可能有的记录归在"原材料",有的归在"外协加工"(因为是外协厂代采的),有的归在"模具"——但本质上它们都是同一类东西,应该一起看。 重组的过程很枯燥,但跑通了之后,那张地图就是活的——以后每个月新增的采购数据,按同样的规则归类,自动落到对应的功能块上。不需要每次重新分析。 这个过程最大的收获不是那张地图本身,是搞清楚了一件事:数据本身不会说话,得有人替它搭一个能说话的结构。 AI 时代,这些技能已经不算什么了 说到这要泼一盆冷水。 会做透视表、会写 Vlookup、会用 VBA——以前这些在采购圈子里算"会做数据",现在不算了。AI 一两分钟就能写出来。 真正值钱的是什么?是能在拿到一堆乱七八糟的数据之后,快速判断"应该从哪个维度切",然后搭出一个能回答具体业务问题的结构。Cost DNA 的本质不是 Excel 技能,是业务判断:我要回答什么问题、数据应该怎么分类、结论怎么落到行动上。 AI 能帮我把七万八千条数据按规则分类。但"按什么规则分"、“分完之后要回答什么问题”、“答案怎么变成下个月的行动计划”——这些是 AI 替不了的。 以前觉得"会用工具"就是能力。现在觉得工具人人会用,能基于数据做出有计划、能产出成果的方案出来,才是真正的本事。 这个网站之前整理过七项基础能力——逻辑、统计、修辞、研究、心理、投资、主体性。Cost DNA 这件事用到最多的其实是其中两项:统计(把数据切成有意义的维度)和主体性(敢于砍掉不合理的分类方式,按业务逻辑重新来)。还有麦肯锡的五种判断力——解构问题、建立假设、抓关键变量、验证逻辑、推动执行。从一堆采购流水搭出一张成本地图,五步全走了一遍。 以前觉得这些"能力"是写在培训手册里的概念。现在觉得,做成一个 Cost DNA 就是一次完整的实践。 跟知识库的关系 这个案例其实就是上一篇说的"知识操作系统"在一个具体业务上的落地。 ...

2026-08-05 · Gary

知识操作系统:从碎片到网络的完整指南

本文基于 47 篇核心研究文献构建。每一个建议都有研究依据,每一个指标都可以实际测量。 👉 阅读完整交互版(含图表、搜索、自评工具) 0. 导言:你真正的问题不是"信息不够" 你每天接触的信息量可能超过 100 条独立知识点——公众号、播客、视频、对话、邮件。问题不在于获取太少,而在于这些信息大部分从未被加工。 Ebbinghaus(1885)的经典遗忘曲线表明,无意义材料在学习后 20 分钟遗忘 42%,1 小时遗忘 56%,1 天遗忘 66%。即使是有意义的材料,如果没有主动加工,一周后也会遗忘大半。后续研究 Wixted(2004)用更严格的实验设计复现了这一基本规律。 关键洞察: 知识管理的本质不是"收集更多信息",而是"对已有信息进行有效加工"。收集是输入端,加工是处理端——大多数人把 90% 的精力放在输入上,只留 10% 给加工。这个比例应该反过来。 阅读指南: 第一遍:通读第 1 节(认知原理),理解 8 条原理 + 九重阶梯模型 第二遍:精读第 3 节(连接机制),选择 1-2 种最适合你的加工方式 持续使用:第 5 节(工作流)作为日常检查清单,第 6 节(质量评估)每月执行一次 ⚠️ 本手册的价值在于被使用,不在于被读完。 每读完一节,请立即执行该节末尾的"即时行动"。 1. 认知原理:大脑如何处理知识 理解大脑的记忆机制,是一切学习策略的根基。以下 8 条认知原理 + 1 套九重阶梯模型,构成整套系统的理论根基。 1.1 编码特异性原则 记忆不是独立存储的,而是与编码时的情境(地点、情绪、身体状态)绑定在一起。在与编码时相似的情境下,记忆最容易被提取。 🔬 研究基础:Tulving & Thomson(1973)的编码特异性实验表明,当提取情境与编码情境匹配时,回忆成绩显著优于不匹配情境。Godden & Baddeley(1975)在水下/陆地学习实验中复现了这一效应。 实践启示:多情境学习比单一情境学习更有利于知识的迁移应用。不要总在同一张桌子前学习——偶尔换个环境。 1.2 提取练习效应 主动从记忆中提取知识,比重复阅读更能强化记忆。每次成功提取都会加强该记忆的神经通路。 🔬 关键实验:Roediger & Karpicke(2006)让学生阅读一篇文章,一组在学习后立即测试(提取练习),另一组重复阅读。一周后测验:提取练习组保留约 80%,重复阅读组仅保留约 33%。提取比重读有效 2.4 倍。 Rowland(2014)的元分析(159 项研究)确认该效应在不同年龄段、不同材料类型中均稳健存在。 ...

2026-08-01 · Gary
知识库质量跃升:从 9.3 到 9.7

知识库 3.0:从 9.3 到 9.7 —— 一次质量跃升的完整路径

我给自己那个本地知识库打了两年多的分。 9 月 10 日晚上,它拿到 9.3 / 10。理由很充分:23 条死链、10 篇笔记缺 frontmatter、5 个收件箱积压、一个战略主题零覆盖。 三个小时后,同一套方法、同一套权重、同一批命令,再算一遍:9.7 / 10。 这三个小时里,我没有往库里加一行新知识。只是把已经烂掉的地方挖出来扔了。 但真正的故事不在 9.3 到 9.7。真正的故事是——第一份写着"9.7"的报告里,有一处举证是不实的,而且是复核的时候才发现的。 这是"本地 AI 知识库实践"系列的第五篇。前面四篇讲的是怎么搭(从零搭建本地 AI 知识库)、怎么更聪明、怎么让数字可信(卡片索引层)、2.0 时代改了哪些东西(知识库 2.0 升级全解)。这一篇讲的是怎么证明它真的好——以及为什么"它说自己好"这句话本身不可信。 本文全部数字来自 2026-09-10 的现场实测命令,可复现。你的库不必有相同的数字,方法相同即可。 一、三个小时:完整时间线 整件事从当天晚上 22:47 开始,到 23:58 结束。 时间 动作 结果 22:47 第一次审计(六维评分模型) 9.3 / 10,三项 P1/P2 弱点 23:00–23:18 弱点清零执行 死链 23→0、缺 frontmatter 10→0、收件箱积压 5→0 23:18–23:30 复审(同方法、同权重) 9.7 / 10,九项门槛全过 23:31–23:45 独立复核(另一个 Agent 重跑全部指标) 采信 9.7,但发现 1 项举证不实 + 2 项需修正 + 4 项缺口 23:40–23:58 缺口全量执行 7 项动作落地,向量块 121,951 → 122,120 收尾 稳态复核 死链 0 / frontmatter 0 / 漂移 0 / 积压 0 / 回归 21/21 注意中间那一行——复审和独立复核是两个不同的动作,由两个不同的角色做。 ...

2026-09-11 · Gary
供应商返点查询的知识库实战

当老板突然问「这几家供应商去年采购了多少」:一次 90 秒应答背后的知识库实战

一、下午三点,老板丢过来一张截图 截图上是一个手打的表格:五家供应商的名字、每家供什么货,旁边一行手写的折扣——94 折、93 折、87 折。配一句话:「这几家,去年 9 月到今年 8 月,一共采购了多少?」 看起来是个再简单不过的问题。 如果你手上有系统,标准动作是这样的:找导出文件、按供应商筛选、求和、检查一下财年有没有对上、再算一遍打折前的金额。顺利的话一小时,不顺利的话,一下午就没了。 而我花了 90 秒。 不是因为我手快,也不是因为我记得住这些数字。是因为这个问题里所有会卡住你的地方,我的知识库早就知道了。 二、这个"简单问题"里藏着五道关 我把它拆开,你就明白"导个表就行"是个错觉。 第一关:哪个文件才是权威源? 采购数据在我手上至少有两个来源:业务系统的导出,和财务部发的正式入库明细。更要命的是,从今年 1 月起财务口径替换了旧口径——旧的那套已经作废,但文件还好好地躺在硬盘上。选错文件,数字全错,而且错得特别像对的。 第二关:财年不等于自然年。 老板说的"去年 9 月到今年 8 月",是 2025-09-01 到 2026-08-31。但你的系统默认按自然年汇总,所以导出来的第一版一定是错的,而且往往要等你对完总数才发现。 第三关:一个窗口,两套数据源,不能重复算。 旧系统的数据到 2026 年 6 月截止,财务新数据从 2026 年 1 月开始。中间有大半年是重叠的。直接拼起来会重复计算,只用旧的又会少掉两个月。 第四关:老板给的名字,不一定是系统里的名字。 这次最典型的是压缩机——我按老板说的那个品牌名去筛供应商,结果是零。系统是零。后来才发现,它是品牌,不是供应商:量分散在四个不同的代理商名下,只能靠物料名称里的品牌词把它捞出来。如果当时就停在"查无此家",这个数就永久漏掉了。 第五关:要的是打折前还是打折后?含税还是不含税? 老板问"采购了多少",通常指实付。但一谈到返点(Rebate),双方真正博弈的是打折前的盘子——87 折的价目表里到底留了多少空间,才是谈判的战场。这两个数差了将近一成,答错一个,报价当场就漏了底。 五道关,每一道都不难。但每一道都要你自己"想起来",而想起来这件事,在下午三点被人追问的时候,是最不可靠的。 所以"导个表就行"的真相是:你根本不是在跟一个求和操作搏斗,你是在跟五个从来没人记录过的判断搏斗。每做一个判断都要停下来想、去翻记录、去问人,或者赌一把。更要命的是这些判断之间没有提示,错了也不会报错——只有最后总数对不上的时候,你才知道前面某一关塌了。 这就是为什么这件事"顺利一小时,不顺利一下午"。差别不在你的 Excel 熟不熟,在你有没有把这五个判断提前固化下来。 三、有知识库的人,这五道关变成了一句话 我实际做的事只有一句:「调这五家供应商 FY26 的采购数据」。 后面发生的一切,全靠知识库里早就写好的东西: 关卡 靠什么自动解决 存在哪 用哪个文件 数据目录的 README 写明正式口径、作废文件及作废原因 数据源目录 财年怎么算 项目策略文件写死"FY = 9 月到次年 8 月" 根目录策略文档 中间重叠期 口径切换点 + 覆盖范围 + 已知缺陷,全部标注 数据说明文件 名字对不上 品牌、代理商、供应商的对照关系 索引与实体表 含税/不含税 金额口径、明细条数、重复行留档状态 每条数据说明 所以 AI 做的事不是"猜",是照着已经固化好的口径去取数。这是本质区别——前者是概率,后者是流程。 ...

2026-09-09 · Gary
知识库 2.0 四层架构升级

知识库 2.0 升级全解:11 个升级点的逻辑与好处(附 AI 可执行搭建包)

这是"本地 AI 知识库实践"系列的第四篇。前面三篇分别讲了:怎么搭(v1 搭建)、怎么更聪明(v2 多跳检索 + 看板)、怎么让数字可信(知识库 2.0 卡片索引)。 这篇把 2.0 时代的全部升级点一次性讲透:每个点改了什么、为什么改、逻辑是什么、好处是什么——不是"我做了这些",而是"我为什么这么做"。 文末附一段可以直接复制给任何 AI 助手的搭建包:5 个可运行脚本 + 验收清单,AI 照着就能在一个全新目录里复刻整套架构。 本文数字均来自 2026-08-31 实测(记分卡 + 自动化清单交叉核验),非估算。你的数字不必相同,架构相同即可。 一、SPU 卡片索引层:知识库 2.0 的核心 改了什么:给每个物料编码(SPU)生成一张预聚合的标准答案卡(约 2KB JSON),把 AI 从"在 78,647 行长表里挑数"变成"读 1 张卡"。生产环境 23,743 张卡。 为什么改:RAG 的天花板是——能找文件、算不准数字。长表塞进上下文,模型挑数就像在电话簿里核对账单,看错行的概率永远不为零,而且错得理直气壮。我实测问过"铜管是不是涨价了",RAG 捞回几段话,一对原始数据,数字全错。 逻辑:四层分工,每层只干自己擅长的事: 1 2 3 4 5 6 7 8 9 ┌─────────────────────────────────────┐ │ L4 输出层 聚合报告(TOP10/预警/对标) │ ├─────────────────────────────────────┤ │ L3 分析层 粗筛→族归组→下钻(prompt链) │ ├─────────────────────────────────────┤ │ L2 索引层 SPU 卡片 × 23,743 │ ├─────────────────────────────────────┤ │ L1 数据层 行级明细 78,647 行(黄金源) │ └─────────────────────────────────────┘ 好处:铜管核查从 30-60 分钟人工透视压缩到 6 秒;上下文从全表 10.3MB 降到 59KB(-99.4%);每个数字带"数据行号"指针可一键回溯;结构性事实(5 个铜管编码全是同一家供应商)粗筛一眼可见——这是议价谈判里最值钱的信息,传统透视几乎发现不了。 ...

2026-08-31 · Gary
SPU 卡片索引层架构

知识库 2.0:给 10 万行采购数据建一层「卡片索引」,让 AI 算数不再靠猜

我有一个已经跑了一年多的本地知识库:PARA 结构、单索引 RAG + 卡片索引层、每日增量同步、21 题召回回归。检索能力经过验证——问"青春期孩子怎么沟通"它能从 300 问 Q&A 里精准捞出答案。 但上个月我问它一个问题,它露馅了。 我问:“铜管是不是涨价了?涨了多少?” RAG 给我捞回来几段文字,每段都说得像模像样。但我一对原始数据——数字对不上。模型从 78,647 行的采购长表里"挑"数字,挑错了行、错了口径,还挑得理直气壮。 这就是 RAG 的天花板:它能找到"哪份文件讲了什么",但它算不准"数字到底是多少"。 长表格塞进上下文窗口,模型挑数就像让人在电话簿里核对账单——看错行的概率永远不为零。 这篇文章记录我怎么解决这个问题:给知识库加一层「SPU 卡片索引」,让 AI 从"在长表里挑数"变成"读一张预聚合的小卡片"。文末有完整的搭建方法和踩坑清单。 一、核心思路:三层分工 升级后的知识库分三层,每层只干自己擅长的事: 1 2 3 4 5 6 7 8 9 ┌─────────────────────────────────────┐ │ L4 输出层 聚合报告(TOP10/预警/对标) │ ├─────────────────────────────────────┤ │ L3 分析层 粗筛→族归组→下钻(prompt链) │ ← 新增 ├─────────────────────────────────────┤ │ L2 索引层 SPU 卡片 × 23,743 │ ← 新增 ├─────────────────────────────────────┤ │ L1 数据层 行级明细 78,647 行 │ ← 已有(Cost-DNA) └─────────────────────────────────────┘ RAG 层(原有):负责"哪份文件讲了什么"——模糊知识、背景、方法论 卡片层(新增):负责"数字到底是多少"——每个 SPU 一张预聚合的标准答案 LLM 层:只负责"这意味着什么"——解读、判断、建议 关键设计:卡片是 JSON 格式,刻意不进 RAG 索引。RAG 擅长语义匹配,不擅长精确算数——让它俩各守边界,互不污染。 ...

2026-08-31 · Gary
多 Agent 协同治理架构

多 Agent 协同治理:从单写者到项目级授权读写

版本说明(2026-08-31):本文描述的"双索引 RAG"是 2026-07 的架构快照。2026-08 起知识库已简化为单索引 + SPU 卡片索引层——表格聚合的职责由「防爆块规则 + 排除清单」和「SPU 卡片层」承接(详见《从零搭建本地 AI 知识库》)。治理原则、权限矩阵与交接闭环不受影响,仍然完全有效。 你有没有遇到过这种场景:你让 AI 帮你改一个文件,改完发现另一个 AI 也在改同一个文件,两边改的内容互相覆盖,最后谁的都没保留? 这不是技术 bug,是治理缺失。 我有一个 5000+ 文件的知识库,用双索引 RAG(A 索引含表格聚合 / B 索引零表格,numpy 向量 + reranker)做检索。当我开始引入多个 AI Agent(Codex、WorkBuddy、ZCode、Kimi Work、MiniMax Code)协同工作时,新问题出现了:谁来写?谁来审?怎么协调?RAG 什么时候更新? 我要说一个大多数人不同意的观点:AI Agent 的能力不是瓶颈,治理才是。 大多数人以为"Agent 不够聪明"是问题——错了。真正的问题是"Agent 太自由了"——它们能写任何文件、改任何配置、跑任何命令,但没有人告诉它们"什么不该做"。这就像给 5 个实习生每人一把公司钥匙,但没有门禁系统——迟早出事。 本文拆解我从踩坑到成熟的三轮迭代:从"一个 Agent 垄断所有写入"到"项目级授权读写",最终找到一套稳定的多 Agent 治理架构。 一、问题:建完 RAG 之后的新困境 上篇写完时,我的知识库已经跑起来了:5000+ 文件、双索引 RAG(A 索引含表格聚合 / B 索引零表格)、每日增量同步、领域 wiki。技术层没问题。 但当我开始引入多个 AI Agent 协同工作时,新问题出现了: 谁来写? 如果 5 个 Agent 都能改同一个文件,冲突只是时间问题。 谁来审? Agent 写的东西不一定对,需要有人把关。 怎么协调? A Agent 改了配置,B Agent 不知道,继续按旧配置执行。 RAG 什么时候更新? 文件改了但索引没更新,检索结果就是旧的。 这不是技术问题,是治理问题。技术问题有标准答案,治理问题没有——它需要你根据实际情况不断迭代。 ...

2026-07-28 · Gary