FDE岗位实务指南 · 第10篇仓库主管说批次 B-417 还有 1000kg计划员说现在只能排 900kg质检说其中 80kg 仍在待检销售又说有 20kg 留样不能动。四个人都在说“这批库存”也都拿得出系统截图。问题不在谁看错了而在“库存”这个词装进了不同的业务含义。许多人第一次接触业务本体论会把它想成一套很重的建模工作画很多实体关系图定一堆名词再找一套新平台。对FDE而言起点应该小得多当业务、数据和Agent必须围绕同一件事协作时怎样把这件事说清楚并让后续的判断与动作有据可查。本文沿用教学案例“澄川制造”的批次库存问题。所有名称、数量和规则均为教学设定。第09篇已经把两张表里的字段含义、单位与来源对齐本篇再往前一步把能够回答问题的最小业务模型搭出来。从一个算不清的批次开始先把争议放回业务现场。B-417 是一批原料不是一列数字。它在 WH-A 仓库有批次号有重量有质检结果也有是否允许出库的状态。若只留一个“库存数量1000”后面任何人都得靠口头补充来判断能不能发货。澄川的起始记录是实物在库 1000kg其中可用 900kg、待检 80kg、留样 20kg。这里的加总关系是 10009008020。可用量不是总量的别名而是一个带状态条件的数量留样也没有离开仓库只是受业务规则限制不能参与普通发货。这类争议常被错误地交给报表开发再加一列“可用库存”或者让AI总结三个数字。列可以加模型也能总结但只要没有约定“待检”“留样”“可用”分别是什么、由什么事件改变结果就无法解释。下次有人把“质检合格”理解成“已出库”报表就会又少一次。因此本体论的第一项价值不是让图更漂亮而是让提问有固定落点。面对 B-417FDE不先问“表里还少哪个字段”而先问谁在什么时间要基于什么证据判断什么并准备采取什么动作。先问模型需要回答什么《企业本体建模方法与实战指南》建议先写能力问题模型最终要回答、判断、执行或约束什么。这个顺序很重要。没有问题的“对象清单”很容易越列越长最后既没有人维护也没有任何决策依赖它。对 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无法知道自己该检查订单、扣哪种数量还是只给出建议。可以把第一版写成一张小卡片元素B-417 的最小定义需要确认的规则对象批次、仓库、订单、质检记录批次标识和版本怎样保持稳定关系批次位于仓库、批次关联质检、订单请求批次一次调拨是否保留原批次身份状态可用/待检/留样的数量分布各状态能否参与承诺动作质量释放、出库申请、实际出库谁可执行写回什么记录课程里常用“对象、属性、关系、状态、动作”五个元素帮助入门指南的元模型还会区分对象、关系、判断、行动、治理。两套划分服务于不同层次不能机械地一一对照。对当前问题先把这张最小卡片做扎实比争论术语更有价值。业务本体论也不等于数据库模式、知识图谱或流程图。数据库负责保存图谱擅长浏览连接流程图说明步骤本体论负责把对象及其可接受的关系、状态和动作含义约定清楚。它们可以共用同一套对象但不互相替代。用事件复算并找出重复扣减最小模型要经得住事件检验。澄川在上午九点完成一次质量确认待检的 50kg 经授权释放为可用。此时实物总量仍是 1000kg只是分类变为可用 950kg、待检 30kg、留样 20kg。如果系统把“质量释放”错误地当作一次入库实物总量会被加到 1050kg如果又把它理解成“待检扣减”却不增加可用量可用量会少 50kg。两种错误都来自没有区分“状态重分类”和“物理流转”。随后一张已核准订单实际出库 100kg。此时才发生物理流转实物总量 900kg可用 850kg、待检 30kg、留样 20kg。复算式仍然成立9008503020。FDE在现场可用一张事件表复查每行写事件编号、发生时间、目标批次、事件前后各状态数量、依据、操作者和结果记录。遇到差异时不要从最终数字倒猜按事件顺序重放先查哪一行把同一数量扣了两次或把分类变化误当成物理变化。事件表还帮助处理“同名不同物”。如果 B-417 在系统升级后生成了新记录ID不能因为两个ID不同就把它视为两批货也不能只因名称相似便直接合并。要看事件中是否存在明确的迁移或映射依据。对象身份、事件时间和来源记录要一起看。判断何时值得使用本体方法当一个业务跨多个系统、同一术语在不同角色口中含义不同、AI需要基于状态提出建议或触发动作时本体方法通常值得投入。它把隐含的前提显性化也让测试不只停在“模型回复像不像”而能检查它是否引用了正确对象、状态和规则。但不是每张表都要升级成一套本体。若是一个边界清楚、只有一位维护人、没有跨系统对齐、也不需要自动决策的临时台账定义好字段、单位和责任人就够了。方法要服务问题不能反过来制造工作量。即使决定建模也先从可复查的最小闭环开始能力问题、对象卡、关系与状态、两个典型事件、一个反例、维护责任人。等这套东西真的被用于判断与复核再扩展到更多批次、仓库和订单。可以把练习迁到采购场景把“批次”替换为“采购申请”把“质量释放”替换为“资料核验完成”。问清申请对象、候选资料、已确认资料和最终订单之间的关系再写出哪个动作只形成建议哪个动作真的提交审批。这样做FDE就不是在画抽象模型而是在为业务动作准备可执行的共同语言。下一篇会把这个共同语言继续落到动作上当Agent准备执行“保存核验结果”时一张完整的动作约定究竟要写什么。