企业官网建设流程全解析

如果把一批用户故事交给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才能回答“这个按钮改变了哪个业务事实”“这个接口失败影响哪个状态”，而不是把实现细节冒充领域事实。

五、不要迷信单条故事，要从故事集里找稳定重复的语义

一条用户故事只代表一个角色、一个目标和一次交付切片。本体需要跨故事寻找重复出现、相互约束并能被其他证据支持的语义。食味里可以先形成五类角色的故事集：

聚合后，有些概念才开始稳定。“食材物料”同时出现在供应来源、库存批次、可售判断和订单异常中；“门店可售关系”同时被适用范围、停售行动和顾客下单使用。重复不能证明正确，却说明它值得优先核实。

这也解释了为什么INVEST中的“独立”和“小”不能被机械搬到本体边界。为了排期，故事应尽量独立、可协商、有价值、可估算、小且可测试；为了理解业务，BA反而要把这些被切小的故事重新连接起来，查看它们共享哪些对象、规则和生命周期。故事为交付而切片，本体为理解而聚合。

《企业本体建模方法与实战指南》提出从业务事件和能力问题开始，再逐步识别对象、关系、状态、逻辑、行动和治理。故事集正好可以作为场景证据之一：角色目标帮助发现要支持的行动，跨故事重复帮助发现核心对象，验收示例帮助形成逻辑测试；但对象是否有稳定身份、关系是否带时间和来源、行动是否有权限与审计，仍需继续建模。

六、故事之间的冲突，比词频更有价值

把多条故事放到《故事—概念映射表》中，最值得看的往往不是高频词，而是同一个词在不同故事里做了不同的事。

食味里至少会遇到五类冲突：

其一，“产品”与“套餐”混用。商品管理员说“建立新品”，顾客说“购买产品套餐”，POS又把两者都叫SKU。业务裁决应保持：产品指菜品或饮料，套餐是独立对象，一个产品可以出现在多个套餐中。

第二，“物料映射对象”冲突。采购故事可能写成“供应商SKU关联产品”，但采购交易的规格、价格和供货对象实际对应食材物料。供应商SKU不能因为界面字段叫“商品”就直接映射菜品或套餐。

第三，“可用”同名异义。采购可用可能指有合格供应来源，库存可用还要考虑批次、质量、预留和效期，门店可售则要综合菜单、价格、培训、设备和关键物料。三个“可用”不能合并成一个布尔字段。

第四，“启用”与“可售”冲突。总部启用表示产品或套餐进入可经营范围；POS启用表示系统配置可被交易端识别；门店可售表示特定门店在特定时间满足销售条件。它们相关，但不是同一状态。

第五，“取消”与“退款”冲突。店长故事中取消订单后可能立即显示处理完成，顾客故事却要求资金退回。订单取消和退款是两个业务事件、两套状态及两份证据，不能用一个“已完成”覆盖。

AI很适合做冲突雷达：聚类同义表达，标记同名异义，比较Given条件和Then结果，指出某条故事改变了另一条故事保持不变的状态。但它只能提出候选冲突，不能代替语义裁决。真正的裁决需要回到原文、流程、规则、主数据和系统记录，并由相应责任人确认。

七、五步提炼：让用户故事进入本体候选区，而不是直接进入正式库

结合商业分析与本体工程方法，可以形成一条五步链。

步骤一：单条拆解

按角色、目标、对象、行为和价值拆Card，把Conversation中的定义、范围、例外和未决问题一起保留。每个候选项绑定故事编号和原文位置，避免AI生成一个看似合理却找不到出处的概念。

第二步：示例翻译

把Given—When—Then拆成前置事实、事件或行动、结果状态、约束和副作用。区分规则与例子，至少准备正常、反例和边界例。能力问题也可以转化为查询与测试：例如“某门店为何不可售某套餐”，答案必须能回到阻塞条件和证据。

第三步：去方案化

标出按钮、页面、接口、字段、颜色和操作顺序，追问它们背后的业务意图与事实。实现细节保留映射，但不直接升级为核心对象、关系或公理。

第四步：跨故事聚合

按同一候选对象连接不同角色故事，寻找稳定身份、生命周期、重复关系和互相矛盾的规则。不要只统计词频，还要比较每个词的上下文、角色、时间和结果。

第五步：跨证据裁决

用访谈证据账本、端到端流程、对象状态表、业务规则、数据字典和系统样例做三角核实。只有在定义、边界、正反例、权威来源、责任人和目标用途得到确认后，候选项才进入正式版本。

我们强调人机协同、逐层精炼，并通过专家把关和场景测试校验模型；这正适合故事提炼。AI负责批量抽取、归并、找冲突、生成问题和组织证据，BA负责把不同分析视图连接起来，领域专家负责规则与概念边界，语义负责人负责批准版本。AI输出的是待审清单，不是事实公告。

每条候选知识至少应带七项信息：陈述、类型、原文、正反例、不确定说明、待确认问题、裁决人与状态。缺少证据的推断可保留，但必须标记“AI推断”或“待确认”。

结语：把故事当作探针，不要当作本体代码

用户故事把团队拉回角色价值，验收标准把模糊需求变成可讨论、可测试的例子；本体则沉淀跨角色、流程和系统仍然成立的业务含义。三者目标不同，可以互补。

面对一批故事，正确的问题不是“AI能抽出多少实体”，而是：哪些角色只是当前分工？哪些动作只是界面实现？哪些对象在多条故事中保持同一身份？哪些状态和规则互相冲突？哪些结论能被流程、主数据和领域专家共同证明？

可以记住一句话：

Card给线索，Conversation补语境，Confirmation给例子；跨故事聚合形成候选，跨证据裁决才形成可信语义。

当用户故事被这样使用，它就不再只是开发待办，也不会被误当成完整领域模型，而会成为业务本体建设中一组有来源、有边界、可追溯的语义探针。