8 月 18 号晚上九点五十六，我跟人在语音里对课程排序。

前面五分钟聊的都是内容：三个数字员工先讲哪个，经营智能体放第一位，市场调研放第二位，第三个可能没时间就不讲。这些定得很快。

然后从二十二点零七分开始，接下来十几分钟，话题一次都没回到内容上。全在聊两件事：规则库怎么建，数据会不会出去。

这一篇讲的就是这两件事。它是我这次四个完整任务里的最后一个，也是决定前面三个到底能不能真上生产的那个地基。

前三篇讲的是对内、对外、对流程。这一篇讲对底座。四件事到这里就齐了，不重叠，也没有第五件。

规则库：这才是经营智能体真正的门槛

我先纠正一个普遍的误解。很多人以为让 AI 做经营分析，难点在模型够不够聪明、接口能不能通。

都不是。难点在规则库。

规则库这个词听起来很技术，其实它就是一份用大白话写下来的、你们公司算账的规矩。里面装四类东西，我一条一条说：

第一类，同义词对齐。

你们 OA 系统里叫「专项支出」的那个东西，在 ERP 里叫「项目费用」，在财务口里叫「直接成本」。人知道这三个是一回事，AI 不知道。你不告诉它，它会当成三笔钱，或者只认得其中一笔。

这一类条目最琐碎，最没成就感，但它是整个规则库里最不能省的。因为口径对不上，后面所有计算都是在错的基础上做的精确运算。

第二类，取数位置。

同一个「成本」，你到底要从哪个系统的哪张表取。是取 ERP 的计划成本，还是实际出库成本。是取财务已入账的，还是包含在途的。

这件事你不写清楚，AI 会挑一个它认为最合理的。而它认为最合理的，通常是最容易拿到的那个，不是最正确的那个。

第三类，计算口径和公式。

毛利怎么算，分母是折前还是折后。提成挂合同额还是挂贡献利润。售后费用算市场费用还是算项目成本。

我上一篇讲那个 390 万的洞，本质上就是这一类规则缺失造成的。费用原则如果不写死「谁受益谁承担，因交付承诺产生的售后进项目、不进市场」，那 41.6 万就会一直躺在市场费用里，永远不会回到那个项目头上。

第四类，限制条件。

有些数据只能取最近三个月，超出范围的口径就变了。有些指标跨事业部不可比。有些期间不能混算。

这一类是防止它「算得又快又错」的护栏。

四类写齐，这套规则库对 AI 起两个作用：对齐口径，以及告诉它到哪拿数据、拿哪个数据、范围到哪儿。

我在课上展示的是一个模拟版的规则库，几十条。我当场说清楚了：真实落地时，这一定是一大张非常完善的表，不是几十条能覆盖的。规则库的完备程度，直接决定这个智能体的可用程度。

一个诚实的期望值：80% 到 85%

这里我要把话说得很直。

我给这套东西定的目标准确率是 80% 到 85%。不是 99%，也不是「取代财务」。

意思是：你随时随地在电脑上、手机上，甚至通过微信问它一个经营问题，它去公司内部各个系统和文档里抓数据，按你写的规则算完，给你一个决策建议。这个建议有八成到八成五的可靠度。

八成五够用吗。对老板做决策来说，绝对够用。因为你现在的替代方案不是「100% 准确的报表」，而是「三天后才拿到、口径还得再问一遍的人工汇总」。一个八成五准确但一分钟给你的答案，比一个九成九准确但三天后给你的答案，经营价值高得多。

但你必须知道那一成五在哪。所以证据链是硬要求——每个数指得回去，你才知道该怀疑哪一段。

数据边界：三档，一档一档说清楚

这是那晚聊得最久的部分，也是所有客户真正在意的部分。

上一次有企业直接提出来：数据泄密怎么办。这不是杠精问题。合同、审批、组织架构、大客户名单，这些东西不可避免地要被读到。技术上能不能实现从来不是问题，安全边界才是。

我把可选的形态分成三档，互斥，且穷尽：

第一档，共享 SaaS。

就是现在最普遍的形态，一个月不到两百块的那种。平台是大家一起用的，你的数据会进平台方的服务器，也会进云端的大模型。

优点是成本几乎可以忽略，今天就能开始用。适合：内部管理数据、经营分析、非核心机密。

第二档，VPC 独享。

平台方在云上卖你一台虚拟服务器，把整套系统部署在你自己的那台上，你独享。这跟第一档的区别是实打实的——不再是「大家一起用」，是「你自己一套」。

但这里有个坑必须讲明白：独享的是应用，不是模型。 大模型那一层，你还是连的云端模型，数据还是要进去。VPC 解决的是「应用层和存储层不跟别人混」，不解决「推理不出本地」。

很多人以为买了 VPC 就等于私有化了。不是。这是我在那晚反复强调的一句。

第三档，纯私有。

纯私有 = 私有模型 + 私有应用服务器，全部部署在你自己的机房里，数据一步都不出门。

这一档目前的状况我也说得很直白：我专门问过平台侧的负责人，这块目前还没开放。

而如果你自己搭一套私有大模型，硬件投入是几十万到几百万这个量级，还要配得起维护它的人。这不是每家公司能承受的。

所以结论是：对安全要求特别高的场景，今天还达不到。 除非你像某些制造业客户那样，有自己完整的技术团队从头搭，成本相当高。

我为什么要在课上把这个说出来。因为如果我只讲「技术上完全可以实现」，那是在骗人。技术可行和现在能上生产，是两回事。把这句话说清楚，客户反而更信你后面讲的东西。

知识库和审批流：一个容易被高估，一个容易被低估

顺便把那晚聊到的另外两件事说完。

知识库其实好建，难在删。

流程很简单：把过去的文档划分清楚，按划分在知识库里建不同目录放进去，系统自动向量化。技术上没有任何难度。

真正的难点是定规矩：哪些能进，哪些不能进。

因为进得越多，噪音越多，检索出来的干扰项就越多，反而拉低回答质量。很多公司建知识库的做法是「把公司所有文档一次全传上去」，然后抱怨 AI 答得不准。不是 AI 不准，是你给它塞了一屋子废纸让它找那一张。

至于更进一步的「做成本体」——把概念、关系、层级都结构化——那需要长得多的数据清洗和数据治理周期，不是现阶段该碰的事。分门别类传进去，先把八成的价值拿到手。

审批流是被低估的那一块。

自建 OA、钉钉、飞书，各家不同。做法是拿一个统一入口去对接不同系统。技术上完全可行，也没什么玄学。

它被低估的地方在于：一旦审批能从这个入口发起，AI 就从「一个会分析的顾问」变成了「一个能推动事情的同事」。分析出问题、当场发起变更单或督办单，这是闭环和不闭环的区别。

四件事到这里齐了

回头看这四篇，我做的是四个完整任务，四个不同的方向：

对内——经营智能体，把 520 万的账面利润还原成 130 万的真实贡献，靠四零件加三次对照实验加证据链。

对外——调研智能体，五步流程，两边都看，一页报告出做不做的结论。

对流程——会议闭环，说订记写发，按角色改写 N 版，最后一下人确认。

对底座——规则库四类条目，数据边界三档，知识库定进出，审批流做闭环。

前三个是能力，第四个是能不能用的前提。很多公司卡住的地方不是前三个做不出来，是第四个从来没有人认真想过——规则库没人愿意写，数据边界没人敢拍板，于是三个能力就永远停在演示里。

如果你只从这四篇里带走一句话，我希望是这句：先跑通一次，把跑通的方式固化成资产，再去解决它敢不敢上生产的问题。 顺序反了，你会在选型和安全评估里耗掉一整年，什么都没跑起来。

你只做决策和指挥，剩下的，交给它们去跑。但你得先把规矩写下来。