企业官网建设流程全解析

FDE岗位实务指南 · 第10篇

仓库主管说，批次 B-417 还有 1000kg；计划员说现在只能排 900kg；质检说其中 80kg 仍在待检；销售又说有 20kg 留样，不能动。四个人都在说“这批库存”，也都拿得出系统截图。问题不在谁看错了，而在“库存”这个词装进了不同的业务含义。

许多人第一次接触业务本体论，会把它想成一套很重的建模工作：画很多实体关系图，定一堆名词，再找一套新平台。对FDE而言，起点应该小得多：当业务、数据和Agent必须围绕同一件事协作时，怎样把这件事说清楚，并让后续的判断与动作有据可查。

本文沿用教学案例“澄川制造”的批次库存问题。所有名称、数量和规则均为教学设定。第09篇已经把两张表里的字段含义、单位与来源对齐；本篇再往前一步，把能够回答问题的最小业务模型搭出来。

从一个算不清的批次开始

先把争议放回业务现场。B-417 是一批原料，不是一列数字。它在 WH-A 仓库，有批次号，有重量，有质检结果，也有是否允许出库的状态。若只留一个“库存数量=1000”，后面任何人都得靠口头补充来判断能不能发货。

澄川的起始记录是：实物在库 1000kg，其中可用 900kg、待检 80kg、留样 20kg。这里的加总关系是 1000=900+80+20。可用量不是总量的别名，而是一个带状态条件的数量；留样也没有离开仓库，只是受业务规则限制，不能参与普通发货。

这类争议常被错误地交给报表开发：再加一列“可用库存”，或者让AI总结三个数字。列可以加，模型也能总结，但只要没有约定“待检”“留样”“可用”分别是什么、由什么事件改变，结果就无法解释。下次有人把“质检合格”理解成“已出库”，报表就会又少一次。

因此，本体论的第一项价值不是让图更漂亮，而是让提问有固定落点。面对 B-417，FDE不先问“表里还少哪个字段”，而先问：谁在什么时间，要基于什么证据判断什么，并准备采取什么动作。

先问模型需要回答什么

《企业本体建模方法与实战指南》建议先写能力问题：模型最终要回答、判断、执行或约束什么。这个顺序很重要。没有问题的“对象清单”很容易越列越长，最后既没有人维护，也没有任何决策依赖它。

对 B-417，第一轮只写四个问题：截至今天上午十点，实物还剩多少？现在可以承诺发货多少？某次待检释放为什么改变了可用量？要对客户订单出库时，系统该检查什么？

四个问题分别逼出不同内容。第一个需要批次、仓库、时间点和数量事实；第二个需要状态与限制；第三个需要发生过什么事件、谁确认；第四个才需要动作、权限和写回结果。把问题分开，就不会把“查数”“做判断”“执行出库”混成同一条含糊的需求。

能力问题还限定边界。本篇不处理全供应链的预测、跨仓调拨和成本计价，只处理 B-417 在一个仓库内的可用性与出库判断。边界不是缺陷，而是第一版能够被验证的前提。FDE可以把它写进需求卡：对象范围是批次库存；时间范围是库存事件发生后可追溯；业务结果是给出可解释的可用量与受控的出库建议。

接下来，把每个问题交给业务人员确认。不要问“我这样建模对不对”，要让对方回答具体反例：待检的 80kg 经过质检后，实物有没有变化？答案是没有，变化的是分类。客户要求 100kg 时，留样能不能借出？若能，谁有权批准、如何留痕？这些回答才是模型的验收依据。

逐步组织对象、关系、状态与动作

第一层是对象。这里至少有批次 B-417、物料、仓库 WH-A、库存位置、质检记录、客户订单和出库单。对象不是“数据库表名”的同义词；它是业务中可被识别、被讨论、被追踪的东西。批次号 B-417 要能稳定地指向同一批物料，即使系统记录迁移、名称调整，历史事件仍要能找到它。

第二层是关系。B-417 属于某物料，位于 WH-A，与一张质检记录关联，被某张订单申请使用。关系把“谁和谁有关”写出来，也避免把所有内容塞进批次的一堆字段里。比如“位于 WH-A”可能随调拨改变，“关联质检记录”可能不止一条；它们都不是简单的静态标签。

第三层是状态。对库存，最实用的做法不是给批次贴一个单一状态，而是把可用、待检、留样等作为数量分布来记录，并明确是否参与承诺。B-417 的状态快照可以是：实物总量 1000kg；可用 900kg；待检 80kg；留样 20kg。状态说明当前处境，不能代替事件记录。

第四层是动作。质量确认可以把一部分待检量重新分类；出库则减少实物总量并生成出库记录。动作要写清目标对象、输入、前提、权限、状态变化、外部影响和日志。否则“出库”只是一句动词，Agent无法知道自己该检查订单、扣哪种数量，还是只给出建议。

可以把第一版写成一张小卡片：

课程里常用“对象、属性、关系、状态、动作”五个元素帮助入门；指南的元模型还会区分对象、关系、判断、行动、治理。两套划分服务于不同层次，不能机械地一一对照。对当前问题，先把这张最小卡片做扎实，比争论术语更有价值。

业务本体论也不等于数据库模式、知识图谱或流程图。数据库负责保存，图谱擅长浏览连接，流程图说明步骤，本体论负责把对象及其可接受的关系、状态和动作含义约定清楚。它们可以共用同一套对象，但不互相替代。

用事件复算，并找出重复扣减

最小模型要经得住事件检验。澄川在上午九点完成一次质量确认：待检的 50kg 经授权释放为可用。此时实物总量仍是 1000kg，只是分类变为可用 950kg、待检 30kg、留样 20kg。

如果系统把“质量释放”错误地当作一次入库，实物总量会被加到 1050kg；如果又把它理解成“待检扣减”，却不增加可用量，可用量会少 50kg。两种错误都来自没有区分“状态重分类”和“物理流转”。

随后，一张已核准订单实际出库 100kg。此时才发生物理流转：实物总量 900kg，可用 850kg、待检 30kg、留样 20kg。复算式仍然成立：900=850+30+20。

FDE在现场可用一张事件表复查：每行写事件编号、发生时间、目标批次、事件前后各状态数量、依据、操作者和结果记录。遇到差异时，不要从最终数字倒猜；按事件顺序重放，先查哪一行把同一数量扣了两次，或把分类变化误当成物理变化。

事件表还帮助处理“同名不同物”。如果 B-417 在系统升级后生成了新记录ID，不能因为两个ID不同就把它视为两批货；也不能只因名称相似便直接合并。要看事件中是否存在明确的迁移或映射依据。对象身份、事件时间和来源记录要一起看。

判断何时值得使用本体方法

当一个业务跨多个系统、同一术语在不同角色口中含义不同、AI需要基于状态提出建议或触发动作时，本体方法通常值得投入。它把隐含的前提显性化，也让测试不只停在“模型回复像不像”，而能检查它是否引用了正确对象、状态和规则。

但不是每张表都要升级成一套本体。若是一个边界清楚、只有一位维护人、没有跨系统对齐、也不需要自动决策的临时台账，定义好字段、单位和责任人就够了。方法要服务问题，不能反过来制造工作量。

即使决定建模，也先从可复查的最小闭环开始：能力问题、对象卡、关系与状态、两个典型事件、一个反例、维护责任人。等这套东西真的被用于判断与复核，再扩展到更多批次、仓库和订单。

可以把练习迁到采购场景：把“批次”替换为“采购申请”，把“质量释放”替换为“资料核验完成”。问清申请对象、候选资料、已确认资料和最终订单之间的关系；再写出哪个动作只形成建议，哪个动作真的提交审批。这样做，FDE就不是在画抽象模型，而是在为业务动作准备可执行的共同语言。

下一篇会把这个共同语言继续落到动作上：当Agent准备执行“保存核验结果”时，一张完整的动作约定究竟要写什么。