把企业变成 AI 能理解的世界#05:别从数据表开始,先找到那个必须处理的事件

数据团队打开数据库目录，屏幕上列着客户表、订单表、库存表、物料表、供应商表。大家从主键、字段和表关系讲起，试图回答三个问题：哪些表应该变成对象？字段怎样变成属性？外键怎样变成关系？

这种方式很自然。数据就在眼前，表结构也比业务讨论更具体。几轮会议之后，团队通常能得到一张规模可观的模型图。

问题是，当业务人员问“它现在能帮我处理什么”时，答案往往并不清楚。

库存表可以被包装成库存对象，供应商表可以被包装成供应商对象，表之间也能画出很多连线。但这些结构本身不会告诉 AI：哪个物料即将短缺，短缺会在什么时候发生，需要补多少，应该通过什么方式补货，又该由谁批准。

这就是从数据表开始的隐患：团队很容易得到一个大而静态的模型，却没有得到一条可以运行的业务链路。

敲黑板：本体建模的起点不是名词、系统或数据表，而是一个必须被业务处理的事件。

所谓事件，就是某件值得关注的事情已经发生，企业必须理解它、判断它，或者采取行动。例如：关键物料的库存覆盖天数跌破阈值；设备出现高等级告警；客户连续三个月活跃度下降；一批来料检验不合格；一份重要合同即将到期，但续约状态仍不明确。

事件会给本体一个明确的存在理由：企业为什么需要这套模型，它要支持什么判断，最终又要改变什么业务结果。

一、从表开始，为什么容易把本体做“静”

数据表是应用系统为了记录和处理数据而设计的。它的边界通常受系统功能、性能、开发习惯和历史建设影响，而不是由一个完整的业务任务决定。

同一个业务对象可能分散在多个系统里。库存数量在 WMS，安全库存参数在计划系统，在途采购在 ERP，需求预测在供应链计划平台，供应商临时承诺却可能还留在邮件或人员沟通中。反过来，一张表里也可能混合多个业务概念，或者只保存某个对象在特定环节的局部投影。

如果团队直接照着表建模，就会不自觉地接受现有系统的切割方式：有表的先建，没有表的暂缓；有字段的被认为是事实，没有字段的规则、责任和人工判断则容易被忽略。

这样得到的模型通常有三个特征。

第一，对象很多，但不知道哪些对象真正服务当前任务。

第二，属性很多，但缺少会改变业务判断的关键证据。

第三，关系很多，却没有判断、行动和结果回写。

它可能是一张更漂亮的数据地图，却还不是业务运行模型。

从事件开始，提问顺序会完全不同。团队不再先问“库存表有哪些字段”，而会先问：发生了什么？影响了谁？依据什么判断？判断之后谁要做什么？结果记录在哪里？

表结构告诉我们数据在哪里，业务事件告诉我们为什么需要这些数据。顺序一旦改变，模型的边界也会随之改变。

二、什么样的事件适合作为第一个场景

并不是所有业务动态都值得启动一轮本体建设。一个适合作为首个场景的事件，至少应具备四个特征。

1. 可观察：知道它何时发生

事件必须能够被业务事实识别。它可以来自系统消息、状态变化、指标越界、设备告警或人工确认，但要有相对明确的发生时间、影响对象和证据来源。

“库存管理有问题”不是事件，它只是一个模糊判断；“物料 M-1024 在华东一号仓的预计库存覆盖天数降到五天”才是可以被观察和处理的事件。

2. 有责任人：有人必须接住它

事件发生后，应该能找到对处理结果负责的业务角色。可能是补货计划员、采购负责人、设备工程师、客户经理，也可能是一组带有审批关系的角色。

如果一件事发生之后，没有人必须接手，也没有明确的处理时限，它更像一条供参考的信息，而不是一个业务场景的起点。

3. 会触发判断：不能只靠转发消息

合格事件会引出一个需要综合事实、关系和规则才能回答的问题。

库存覆盖天数下降，并不必然等于立即采购。还要判断未来需求是否确定，在途物料能否按时到达，是否已有未关闭的补货单，有没有替代料，短缺会影响哪些生产计划。事件负责叫醒场景，判断负责决定如何响应。

4. 存在行动后果：处理前后应有所不同

判断之后，需要出现一个有业务意义的动作：创建补货建议、生成待确认任务、提交审批、调整交付节奏、通知责任人，或者明确记录“无需处理”。

更重要的是，动作必须留下结果。处理完成后，对象的状态、关联单据、负责人或后续观察任务应该发生可追踪的变化。否则，事件只是被分析了一遍，并没有真正被企业接住。

可观察、有责任人、触发判断、产生行动后果，这四个条件把“值得关注的消息”变成了“可以运行的业务场景”。

三、事件驱动六步法：从异常出现到结果回流

为了让业务、数据和技术团队在同一张纸上讨论场景，我把原书中的能力问题、事实—逻辑—行动链路，以及新增资料中的执行反馈机制，重新组织成一个“事件驱动六步法”：

事件 → 业务问题 → 证据 → 判断 → 行动 → 反馈。

下面用一次库存变化来演示。

第一步：事件——究竟发生了什么

场景不以“建设库存本体”开始，而以一件具体的事开始：需求计划更新后，系统发现物料 M-1024 在华东一号仓未来七天的预计可用库存将低于安全库存。

这句话至少要说清事件名称、触发条件、发生时间、影响对象、来源系统和业务影响。事件描述越具体，后续范围越容易收住。

第二步：业务问题——企业必须回答什么

围绕事件，不要马上罗列数据字段，而要先列出模型必须具备的能力：

• 会不会缺？

• 什么时候开始缺？

• 缺口有多大？

• 为什么会缺？

• 可以怎么补？

• 谁需要批准？

这些问题不是会议中的随口提问，而是第一版本体的范围约束，也是未来的验收用例。一个问题如果不在本轮范围内，就不必因为“以后可能有用”而提前扩张模型。

第三步：证据——用什么事实支持判断

要回答这些问题，需要找到真正会改变结论的事实：当前可用库存、已分配数量、未来需求、在途数量及预计到货日、供应提前期、安全库存、最小订货量、未关闭补货单和可用替代料。

同时要标明每项证据的权威来源、更新时间和可信状态。库存数量以哪个系统为准？需求预测是哪一个版本？供应商承诺是系统记录还是人工确认？在途单虽然存在，是否已经延迟？

证据不是把所有可获得的数据都塞进模型，而是回答：没有哪一项事实，判断就会发生变化？这能显著减少无关数据给模型和 AI 推理带来的负担。

第四步：判断——形成可检验的业务结论

接下来，把证据变成结构化结论。系统需要计算未来各时间点的预计可用库存，识别首次低于安全库存的日期，测算缺口，判断主要原因，并检查是否存在重复补货或替代方案。

输出不应只有一句“建议尽快补货”，而应包括风险等级、预计短缺日期、缺口数量、原因说明、可选方案及证据路径。

判断还必须能够被测试。正常库存、临界库存、在途延迟、需求突然增加、已有补货单等历史或模拟样例，都应能用于回放。只有可验证的逻辑，才适合成为 AI 可调用的判断能力。

第五步：行动——谁在什么边界内做什么

当缺货风险成立时，系统可以生成补货建议，预填数量和到货日期，检查是否重复，并根据金额、风险等级和物料类别决定后续动作。

低风险场景可以自动创建待确认的补货草稿；超过额度的采购申请进入人工审批；涉及供应商切换或关键物料的动作，则进入更严格的流程。AI 是否自动执行，不应由技术能力决定，而应由业务责任和风险边界决定。

这里要区分“生成一段建议”和“执行一个业务动作”。前者停留在对话里，后者会创建任务或单据、改变对象状态、通知责任人，并得到成功或失败的明确结果。

第六步：反馈——结果是否回到业务世界

补货建议被确认后，系统应把补货单号、审批状态、负责人和计划到货日期写回，并把库存风险状态从“待处理”更新为“处理中”。到货发生后，再重新计算风险是否解除。

如果实际到货晚于预期、建议数量不合理或风险判断出现偏差，这些结果也应成为下一轮校验的输入。反馈不是简单保存日志，而是让企业能够继续观察：动作有没有执行，事件有没有被解决，规则是否需要调整。

走完这一步，场景才从“AI 给出答案”变成“企业完成了一次可追踪的处理”。

四、能力问题不是需求清单，而是场景剪刀

本体建模容易失控，是因为任何对象都能继续向外连接。库存会牵出采购、生产、销售、物流、质量、供应商绩效和资金预算。如果团队把“相关”理解成“都要纳入”，第一个场景很快就会变成整个供应链工程。

能力问题的作用，是把这张无限扩张的网络剪成一个可以验证的闭环。

“会不会缺”拉出物料、库存项、仓库、需求和安全库存；“何时缺”拉出时间、在途到货和供应提前期；“缺多少”拉出需求曲线、可用库存、最小订货量和补货逻辑；“怎么补”拉出补货单、替代料、供应方式和行动条件；“谁批准”拉出责任人、权限、金额与风险等级。

每一个能力问题，都应该对应需要的对象、关系、证据、判断或行动。如果一个候选对象不能帮助回答任何能力问题，也不影响行动与责任，它就可以暂时留在模型之外。

能力问题还要带上业务语境。同样是“库存”，财务关注账面价值，仓储关注实物数量，计划人员关注未来可用量。企业本体不需要强行消灭这些差异，而要说明本场景采用哪个含义、事实来自哪里，以及与其他语境如何映射。

这样做还有一个实际好处：问题天然就是验收条件。项目不再用建了多少对象、配置了多少字段来证明完成，而是用真实样例回答：能否识别风险，能否解释原因，能否给出数量，能否触发受控动作，能否留下处理结果。

五、换个角度看：场景边界由责任闭环决定

很多团队习惯按系统划分场景：WMS 里的算仓储场景，ERP 里的算采购场景，计划系统里的算计划场景。这样做便于分工，却未必符合业务事件的真实边界。

一次缺货风险可能从计划系统中的需求变化开始，到 WMS 获取库存事实，到 ERP 检查在途采购，再到工作流完成审批。它跨越多个系统，但业务上仍然是同一件事：企业能否及时识别并处理这个物料的短缺风险。

因此，场景边界不应由某个系统能提供什么决定，而应由责任闭环决定：事件发生后，谁必须接住；他需要什么证据；有权做出什么判断；可以触发什么行动；结果由谁确认；处理状态在哪里留下。

这也意味着，闭环不等于所有动作都自动化。第一阶段只要 AI 能生成结构化草稿，由责任人确认后进入正式流程，并把结果写回，就已经形成闭环。自动化程度可以逐步扩大，但责任不能悬空。

场景的终点也不是“生成建议”。真正的终点是结果进入业务系统，责任人和状态得到更新，后续事件仍然可以被观察。只输出建议、不进入系统，业务还要靠人复制、转述和追踪；这条链路就没有真正闭合。

六、不从表开始，不等于不看表

强调事件先行，并不是否定数据表。没有可靠数据，本体只是业务愿景；完全被表结构决定，本体又会退化成数据模型。

更合理的顺序是：先用事件和能力问题定义业务需求，再回到数据源验证实现路径。

团队需要检查：核心对象有没有稳定标识，关键属性以哪个系统为准，跨系统关系能否构造，数据延迟能否满足判断时效，缺失事实由谁补充，行动结果写回哪个系统。

如果发现某项关键证据不存在，不应偷偷用一个看似相关的字段代替。要么补充人工确认和证据记录，要么降低本轮能力目标，要么承认这个场景还不适合作为试点。

业务问题说明“为什么需要它”，数据事实证明“能否可靠实现它”。先后有别，但两者最终必须互相对上。

带走一张卡：事件驱动六步场景卡

选择第一个本体场景时，可以让业务、数据、系统和治理人员共同填写下面这张卡。

填写完成后，再做四项检查：

• 事件是否可观察，并且有明确的处理责任人；

• 每个候选对象是否服务至少一个能力问题；

• 行动是否进入业务系统，而不只是停留在对话中；

• 执行结果是否会改变对象状态，并能被下一轮观察。

如果这四项还答不清，先不要急着画完整本体图。问题通常不在建模工具，而在场景尚未形成责任闭环。

结语：先找到企业不能不处理的那件事

数据表很重要，但它只告诉我们企业记录了什么。业务事件告诉我们，企业为什么必须在此刻理解这些记录、形成判断并采取行动。

从事件开始，团队才会自然地找到关键问题、必要证据、判断逻辑、行动边界和反馈机制；本体也才会从一张静态结构图，变成承接真实业务任务的运行模型。

第一个场景不必覆盖整个领域。它只需要抓住一件业务不能不处理的事，让相关对象可以被定位，证据可以被组织，判断可以被验证，动作可以被控制，结果可以被继续观察。

但即使方向正确，第一版本体仍然面临一个现实问题：多小才算“最小”？如果只做几个对象和一张演示图，它不能运行；如果把所有相关内容都纳入，又会重新失控。

留一道思考题：

怎样设计一个可运行、而不是只能展示的最小本体。