04｜用户故事和验收标准，能不能成为本体建模的输入？

如果把一批用户故事交给AI让它抽取角色、对象、动作和规则再自动生成业务本体会发生什么食味里公司的新品项目组做过一次试验。AI从十五条故事中识别出“用户”“产品”“套餐”“门店”“物料”“按钮”“页面”“接口”等几十个名词又把“配置”“查询”“启用”“停售”全部变成关系。图很快就画出来了问题也随之出现商品管理员被建成了一个部门“可售”被当成产品属性“点击启用按钮”成了业务动作“POS同步成功”甚至被推断成门店已经具备销售条件。这些词都来自需求材料却不等于它们都属于业务世界的稳定语义。用户故事和验收标准可以成为本体建模的输入。前者暴露角色、目标、对象、行为和价值后者暴露条件、事件、结果、状态、约束和异常。但它们只描述一个交付切片中的局部需要不是可以直接发布的本体。这一篇用食味里公司的“川香鸡腿饭套餐”案例看看怎样把敏捷需求材料变成可核实的候选知识。一、先看一条故事门店到底在配置什么先看看食味里公司的一条用户故事Card作为门店运营人员我希望为指定门店配置产品、套餐及生效时间以便新品按试点范围准确上线。Conversation总部产品或套餐存在不等于所有门店都销售门店可售关系包含计划、准备中、可售、临时停售和终止状态门店临时停售不应改变总部产品或套餐状态。为了便于讨论把其中三条验收标准改写成Given—When—Then场景A试点门店满足准备条件Given 产品或套餐已启用门店属于批准的试点范围关键准备项均已完成 When 有权限的门店运营人员确认开放销售 Then 该门店与该产品或套餐之间的可售关系进入“可售”并记录生效时间、操作人和判断依据。场景B门店尚未准备完成Given POS已经配置新品但门店培训或关键物料准备未完成 When 门店运营人员尝试开放销售 Then 可售关系不得进入“可售”并返回未满足的准备项。场景C单店关键物料不足Given 某门店的关键物料不可用且没有已批准的替代物料 When 店长确认临时停售建议 Then 该门店的可售关系进入“临时停售”总部产品或套餐仍保持原状态。表面看这是一项“配置功能”。换一个观察角度它已经露出了一个小型业务世界门店运营人员是角色门店、产品和套餐是对象三者之间存在带时间和状态的可售关系准备完成是条件确认开放是事件可售和临时停售是关系状态授权、试点范围和物料条件共同约束转换。真正重要的发现不是“配置”这个动词而是门店可售不是产品自己的一个开关而是一家门店与一个产品或套餐在某段时间内形成的业务关系。这条语义能解释为什么总部启用、POS配置和门店可售不能互相替代。二、拆故事正文五类线索五种不同处理BABOK 3.0把用户故事定义为面向特定相关方价值的短小陈述常见结构就是“谁—想要什么—为什么”。它同时提醒故事本身不包含需要的全部信息必须通过交谈和其他分析模型补充用户故事通常适合短期启发、排序和交付不适合单独承担长期知识保存。因此起手不是抽名词而是拆开故事里的五类线索。线索食味里的业务描述可以提示什么不能直接断言什么角色门店运营人员一类责任、权限或使用者它就是组织部门或本体核心类目标配置指定门店的可售范围需要形成或改变某种业务事实当前页面和按钮就是永久业务动作对象门店、产品、套餐候选对象及其身份边界三者已经有正确分类和关系行为配置、开放销售、停售事件、行动或状态转换线索每个动词都是本体关系价值新品按试点范围准确上线能力问题、评价指标和范围依据“准确”已经有可计算定义“门店运营人员”首先是业务角色不等于“门店运营部”。同一个人可以承担多个角色同一角色也可能由总部员工、区域经理或授权运营方承担。若直接按句式抽取AI很容易把角色、岗位、部门和系统账号混成一类。“配置”也需要继续追问。它可能只是界面操作背后真正稳定的业务意图是“建立、变更或终止门店可售关系”。本体建模要求先列出重要术语和关系线索再判断哪些应成为类、属性或关系名词和动词是发现入口不是自动建模规则。“准确上线”属于价值线索可反推能力问题哪些门店在某时点允许销售某产品或套餐为什么哪些准备项仍在阻塞价值本身通常不成为对象而进入项目目标、能力问题或成功指标。三、翻译Given—When—Then从验收示例看到条件、事件和结果验收标准给出的细节比Card更多。PMI《商业分析指南》把定义验收标准、核实需求和确认需求分开处理验收标准说明怎样判断交付是否可接受核实检查需求是否正确、完整和一致确认则判断它是否真正支持商业目的。换句话说“可以测试”不等于“已经成为真实、完整、稳定的业务知识”。将Given—When—Then用于语义分析时可以这样读Given当前有哪些对象、关系、状态和前置事实When发生了什么事件或谁执行了什么受控行动Then哪个对象或关系发生什么结果、进入什么状态、留下什么证据And/But还有哪些约束、例外、并行结果和不应发生的副作用。以场景C为例“关键物料不可用”暴露物料可用状态“没有已批准替代物料”暴露替代关系及批准状态“店长确认”暴露授权行动“可售关系进入临时停售”暴露状态转换“总部产品仍保持原状态”则是一条非常重要的否定约束。但不能反过来把一条例子直接升级为普遍规则。一个验收场景只是若干具体条件的组合。它可能漏掉加盟门店、外卖渠道、预售订单、库存数据过期、质量冻结或人工例外。Specification by Example强调用真实例子建立业务与交付团队的共同理解Example Mapping进一步把故事、规则、例子和未回答问题分开。对本体建设而言这个区分尤其重要例子用于验证规则边界问题用于暴露未知不应把绿色例子卡直接当成蓝色规则卡。因此《用户故事语义拆解表》要同时保留原始标准、候选规则和待确认问题。AI可以结构化句子BA仍要追问这是普遍约束还是本迭代的测试数据条件变化后是否仍成立谁来裁决四、先做一次“去方案化”按钮、页面和接口不是业务本体用户故事经常混入解决方案偏向“点击新品启用按钮”“在BOH页面选择门店组”“调用POS接口后显示成功”“在看板上把状态改成绿色”。这些描述对交互设计、接口设计和测试很重要却未必适合进入业务本体核心。可以做一个简单的去方案化测试如果食味里明年更换BOH、POS或界面业务事实还成立吗“点击按钮”会消失“有权限的角色确认开放销售”仍然成立“页面显示绿色”会改变“门店可售关系当前处于可售”仍然成立“POS接口返回200”是技术结果“门店满足业务可售条件”则需要结合产品、套餐、配方、物料、培训和门店条件判断。Palantir Model Studio的资料提供了一个很好的对照。界面上有“Start training run”但其文档同时把模型、训练任务、配置版本、输入、参数、状态、输出模型版本和数据血缘分别追踪。按钮是触发方式训练运行和配置版本才是需要长期识别、审计和复现的业务工件。食味里也一样界面操作属于解决方案视图可售关系、状态转换、授权与证据才是跨系统仍需保持的语义。去方案化并不是删除所有系统信息。接口、页面和按钮仍应留在需求与设计模型中并与业务语义建立映射。这样AI才能回答“这个按钮改变了哪个业务事实”“这个接口失败影响哪个状态”而不是把实现细节冒充领域事实。五、不要迷信单条故事要从故事集里找稳定重复的语义一条用户故事只代表一个角色、一个目标和一次交付切片。本体需要跨故事寻找重复出现、相互约束并能被其他证据支持的语义。食味里可以先形成五类角色的故事集角色故事局部目标暴露的主要候选语义商品管理员维护产品、套餐及适用范围产品是菜品或饮料套餐通过组成关系引用产品商品管理员是市场部承担的角色采购员为食材物料维护合格供应来源供应商SKU映射食材物料供应资格带区域、时间和状态仓库人员判断库存批次能否分配库存批次关联食材物料和库位数量可用不等于质量可用店长根据关键物料情况处理临时停售门店可售关系有独立状态停售建议需要事实、规则和人工确认顾客选择套餐允许的组成或替代方案套餐组成、允许替代、顾客确认、订单实际履约组成相互关联聚合后有些概念才开始稳定。“食材物料”同时出现在供应来源、库存批次、可售判断和订单异常中“门店可售关系”同时被适用范围、停售行动和顾客下单使用。重复不能证明正确却说明它值得优先核实。这也解释了为什么INVEST中的“独立”和“小”不能被机械搬到本体边界。为了排期故事应尽量独立、可协商、有价值、可估算、小且可测试为了理解业务BA反而要把这些被切小的故事重新连接起来查看它们共享哪些对象、规则和生命周期。故事为交付而切片本体为理解而聚合。《企业本体建模方法与实战指南》提出从业务事件和能力问题开始再逐步识别对象、关系、状态、逻辑、行动和治理。故事集正好可以作为场景证据之一角色目标帮助发现要支持的行动跨故事重复帮助发现核心对象验收示例帮助形成逻辑测试但对象是否有稳定身份、关系是否带时间和来源、行动是否有权限与审计仍需继续建模。六、故事之间的冲突比词频更有价值把多条故事放到《故事—概念映射表》中最值得看的往往不是高频词而是同一个词在不同故事里做了不同的事。食味里至少会遇到五类冲突其一“产品”与“套餐”混用。商品管理员说“建立新品”顾客说“购买产品套餐”POS又把两者都叫SKU。业务裁决应保持产品指菜品或饮料套餐是独立对象一个产品可以出现在多个套餐中。第二“物料映射对象”冲突。采购故事可能写成“供应商SKU关联产品”但采购交易的规格、价格和供货对象实际对应食材物料。供应商SKU不能因为界面字段叫“商品”就直接映射菜品或套餐。第三“可用”同名异义。采购可用可能指有合格供应来源库存可用还要考虑批次、质量、预留和效期门店可售则要综合菜单、价格、培训、设备和关键物料。三个“可用”不能合并成一个布尔字段。第四“启用”与“可售”冲突。总部启用表示产品或套餐进入可经营范围POS启用表示系统配置可被交易端识别门店可售表示特定门店在特定时间满足销售条件。它们相关但不是同一状态。第五“取消”与“退款”冲突。店长故事中取消订单后可能立即显示处理完成顾客故事却要求资金退回。订单取消和退款是两个业务事件、两套状态及两份证据不能用一个“已完成”覆盖。AI很适合做冲突雷达聚类同义表达标记同名异义比较Given条件和Then结果指出某条故事改变了另一条故事保持不变的状态。但它只能提出候选冲突不能代替语义裁决。真正的裁决需要回到原文、流程、规则、主数据和系统记录并由相应责任人确认。七、五步提炼让用户故事进入本体候选区而不是直接进入正式库结合商业分析与本体工程方法可以形成一条五步链。步骤一单条拆解按角色、目标、对象、行为和价值拆Card把Conversation中的定义、范围、例外和未决问题一起保留。每个候选项绑定故事编号和原文位置避免AI生成一个看似合理却找不到出处的概念。第二步示例翻译把Given—When—Then拆成前置事实、事件或行动、结果状态、约束和副作用。区分规则与例子至少准备正常、反例和边界例。能力问题也可以转化为查询与测试例如“某门店为何不可售某套餐”答案必须能回到阻塞条件和证据。第三步去方案化标出按钮、页面、接口、字段、颜色和操作顺序追问它们背后的业务意图与事实。实现细节保留映射但不直接升级为核心对象、关系或公理。第四步跨故事聚合按同一候选对象连接不同角色故事寻找稳定身份、生命周期、重复关系和互相矛盾的规则。不要只统计词频还要比较每个词的上下文、角色、时间和结果。第五步跨证据裁决用访谈证据账本、端到端流程、对象状态表、业务规则、数据字典和系统样例做三角核实。只有在定义、边界、正反例、权威来源、责任人和目标用途得到确认后候选项才进入正式版本。我们强调人机协同、逐层精炼并通过专家把关和场景测试校验模型这正适合故事提炼。AI负责批量抽取、归并、找冲突、生成问题和组织证据BA负责把不同分析视图连接起来领域专家负责规则与概念边界语义负责人负责批准版本。AI输出的是待审清单不是事实公告。每条候选知识至少应带七项信息陈述、类型、原文、正反例、不确定说明、待确认问题、裁决人与状态。缺少证据的推断可保留但必须标记“AI推断”或“待确认”。结语把故事当作探针不要当作本体代码用户故事把团队拉回角色价值验收标准把模糊需求变成可讨论、可测试的例子本体则沉淀跨角色、流程和系统仍然成立的业务含义。三者目标不同可以互补。面对一批故事正确的问题不是“AI能抽出多少实体”而是哪些角色只是当前分工哪些动作只是界面实现哪些对象在多条故事中保持同一身份哪些状态和规则互相冲突哪些结论能被流程、主数据和领域专家共同证明可以记住一句话Card给线索Conversation补语境Confirmation给例子跨故事聚合形成候选跨证据裁决才形成可信语义。当用户故事被这样使用它就不再只是开发待办也不会被误当成完整领域模型而会成为业务本体建设中一组有来源、有边界、可追溯的语义探针。