07 构建方法（下）：定义动作与规则、绑定数据、验收与演进
第 06 篇产出了名词层的骨架：对象类型和关系。本篇在骨架上加上"动词"——动作、规则和权限；再把它绑定到真实数据上；最后讨论怎样验收、怎样持续演进，以及怎样用大模型辅助建模。概念定义见第 04 篇，这里聚焦做法。
1. 第六步：定义动作
1.1 从能力问题里找动作
动作的来源有两个：能力问题清单里的"动作类"问题，以及访谈时记下的动词。对示例商城 V1，可以整理出这样一份清单：
| 动作 | 作用对象 | 典型发起者 | 风险等级 |
|---|---|---|---|
| 创建售后单 | 订单行 | 客户、客服、AI 客服 | 低（可撤销） |
| 审核售后单 | 售后单 | 客服 | 中 |
| 确认退货验收 | 售后单、退货包裹 | 仓库验收员 | 中 |
| 发起退款 | 售后单 | 客服 | 高（涉及资金，渠道退款后难撤回） |
| 审批超阈值退款 | 处于"待审批"的发起退款动作实例 | 客服主管 | 高 |
| 关闭工单 | 客服工单 | 客服 | 低 |
风险等级决定后面的审批和自动化程度，必须由业务负责人确认。
1.2 为每个动作写定义卡
按第 04 篇的六要素（动作、对象、前置条件、执行者、结果、副作用）为每个动作写一张定义卡。写卡时最常被遗漏的是下面四个设计点：
- 审批绑定参数。主管批准的不是"这个售后单可以退款"，而是"由客服小林、对售后单 AS-2045、退款 899.00 元、原路退回、在今天 18:00 前有效"。参数一变，审批就失效。否则可能出现"批的是 899 元，退的是 8990 元"。审批本身不是一个独立的业务对象上的动作，而是这一次"发起退款"动作实例上的一个环节：实例先进入"待审批"，主管执行"审批"后才继续。
- 幂等。同一个请求重复提交时只生效一次。幂等键要标识"这一次退款决定"，而不是"这一次网络调用"：由动作引擎在创建动作实例时生成
action_instance_id（或由调用方在决定退款时生成一次request_id），之后所有重试和回调都带同一个键。不要把重试次数或金额放进键里——前者让每次重试都变成"新请求"，后者会把两笔金额相同的合法分次退款误判为重复。 - 失败、超时与补偿。退款动作要调用支付渠道、改售后单状态、发短信。这种"每一步都准备好撤销或补救办法"的设计，常被称为 Saga 模式。但要注意两点。第一，超时不等于失败：渠道超时只说明"不知道结果"，钱可能已经退出去了。正确做法是让动作实例进入"结果未知"，用同一个幂等键查询渠道：确认已成功就前滚（把售后单更新为已退款）；确认未受理才用同一个键重试；多次查询仍无法确认就转人工。期间售后单保持"退款中"，这笔金额在"可退金额"里先冻结。第二，资金步骤是"不可撤销的那一步"：渠道退款一旦成功基本撤不回来，它之前的步骤可以补偿（撤销），它之后的步骤（改状态、发短信）只能重试、向前完成，不能回滚。所以"渠道退款成功但改状态失败"时，补救办法是重试改状态，而不是再退一次或把售后单打回"待退款"。
- 两层状态。售后单有业务状态（待退款、退款中、已退款）；每一次"发起退款"本身也有执行状态（待执行、待审批、执行中、已完成、结果未知、补偿中、需人工）。两层分开记录，才能回答"这笔退款为什么卡住"。
2. 第六步（续）：定义规则与权限
2.1 规则表
规则独立登记，动作只引用规则编号：
| 编号 | 类型 | 内容 | 被哪些动作引用 | 版本 | 负责人 |
|---|---|---|---|---|---|
| R01 | 约束 | 订单行累计退款不超过实付金额 | 创建售后单、发起退款 | v1 | 财务 |
| R02 | 派生 | 自正向包裹签收次日起 7 天内具备无理由退货资格（法定底线，见《消费者权益保护法》第二十五条；平台可以放宽、不能收紧） | 创建售后单、审核售后单 | v1 | 客服运营 |
| R03 | 约束 | 生鲜类商品不适用无理由退货 | 创建售后单 | v1 | 客服运营 |
| R04 | 决策 | 单笔退款超过 500 元需主管审批（示例阈值） | 发起退款 | v2 | 客服运营 |
| R05 | 约束 | 同一订单行不能同时存在两个进行中的售后单 | 创建售后单 | v1 | 客服运营 |
几条经验：
- 每次执行都记录规则版本。R04 从 v1（300 元）改到 v2（500 元）后，事后追溯时要知道某笔退款是按哪一版判断的。
- 确定性的交给规则，模糊的才交给模型。有实践者提出"推理分级"：高频、确定的判断（金额上限、时间窗口）预先写成规则；只有低频、需要理解语义的判断（例如客户描述的"质量问题"是否成立）才交给大模型，并且标明置信度、保留人工复核；大模型的判断只能作为"建议"，要附上证据（图片、客户描述）。
- 规则要可读。业务人员应能看懂规则表，而不必读代码。
2.2 权限矩阵
| 动作 | AI 客服 | 一线客服 | 客服主管 | 仓库验收员 |
|---|---|---|---|---|
| 创建售后单 | 申请（客户确认后提交） | 执行 | 执行 | 查看 |
| 审核售后单 | 建议 | 执行 | 执行 | 查看 |
| 确认退货验收 | 查看 | 查看 | 查看 | 执行 |
| 发起退款 | 建议 | 申请（超阈值）/ 执行（阈值内） | 执行 | 无 |
| 审批超阈值退款 | 无 | 无 | 执行 | 无 |
注意权利是按动作分别授予的：AI 客服对"创建售后单"有申请权，对"发起退款"只有建议权，对审批没有任何权利。开放权利的顺序建议是：先查看，再建议，再申请，最后才是执行；高风险动作是否允许 Agent 执行，要用下文的影子模式数据说话。
2.3 一次规则变更的完整流程
以 R04 从 v1（示例：300 元）调整为 v2（示例：500 元）为例，一次规则变更应该这样走：
这里的关键在第 3、4、6 步：影响分析要列出所有引用 R04 的动作（本例只有"发起退款"），回归测试要覆盖 300 到 500 元之间的边界金额；发布后，生效时间之前提交的退款仍按 v1 解释，审计时不会混淆；生效时已经处于"待审批"的动作实例，按提交时的规则版本处理。如果规则写在代码里，这些事每一件都要靠人记着；写在规则表里，大部分可以自动完成。
3. 第七步：绑定数据
数据绑定是把本体里的对象类型和属性，对应到真实系统里的表、字段或接口。没有绑定，本体只是一张漂亮的图。
3.1 映射表
| 对象类型 | 来源 | 主键 | 关键属性映射 | 写入方式 |
|---|---|---|---|---|
| 客户 | 会员系统 member | member_no | 等级 ← level；手机号 ← mobile（脱敏） | 只读 |
| 订单行 | 订单系统 order_item | item_id | 实付 ← paid_amount；SKU ← sku_id | 只读 |
| 售后单 | 售后系统 refund_apply（拆分） | apply_id | 状态 ← status（按枚举映射表转换） | 经售后系统接口 |
| 退款单 | 支付系统 refund_txn | refund_no | 状态 ← refund_status | 经支付网关接口 |
| 发货单（正向与退货） | 物流系统 waybill | waybill_no | 签收时间 ← signed_at（权威来源）；方向 ← direction | 只读 |
| 装运关系（发货单—订单行） | 物流系统 waybill_item | waybill_no + item_id | 数量 ← qty | 只读 |
3.2 三个关键决定
- 数据放哪：是把数据同步进本体平台，还是只存映射、按需实时读取源系统？后者保持"当前值永远在源系统"，一致性更好；前者查询更快、便于分析。V1 建议对交易数据实时读取，对客户、商品等主数据建立轻量索引。
- 身份怎么合：客户的会员号、小程序编号、来电号码如何归并到同一个客户对象？优先引用主数据系统的标准编号；没有的话，制定明确的合并规则，并把低置信度的合并交给人工确认。
- 写入走哪：本体里的动作最终要改变业务系统的状态。原则是通过业务系统已有的接口写入，不直接改数据库，这样业务系统原有的校验和权限依然生效。
3.3 身份归并：一步一步来
"客户有两个账号"是示例商城最常见、也最容易出错的问题。身份归并可以按下面的顺序做：
- 定权威编号：裁决人确认以会员号为客户主键，其他编号都要归到会员号上。
- 用强关系归并：系统里已有明确绑定关系的（小程序账号绑定了会员号），直接归并，置信度最高。
- 用强属性候选：没有绑定关系、但手机号完全一致的，列为候选；同一手机号可能是家人共用，所以只作候选，不自动合并。
- 人工确认：候选交给客服或数据管家确认，确认结果写回绑定关系，下次就成为强关系。
- 对 Agent 透明：归并状态要让 Agent 知道。对于未确认的候选，"小售"不能把两个账号的订单混在一起回答，而应请客户提供订单号或在会员页绑定账号。只凭订单号和手机号核验身份偏弱（家人共用、订单号外泄），涉及售后办理时，最好再向该订单的收货手机发送验证码。
这个过程的要点是：能确定的自动做，不确定的交给人，所有结论都留痕。如果公司已有主数据系统，以上大部分工作应由它完成，本体直接引用结果（见第 05 篇）。
3.4 数据质量检查
绑定之后，第一件事是跑一遍质量检查：必填属性是否缺失、基数是否违反（一个售后单是否关联了两个订单行）、枚举值是否都能映射、金额是否为负。W3C 的 SHACL 标准就是做这类校验的：用"形状"描述数据应满足的条件，对照实际数据生成校验报告，并可区分违规、警告、提示等严重程度。不用 SHACL 也可以用其他工具实现同样的检查，关键是检查要自动化，并在每次数据或本体变更后运行。
如果平台支持从已有模型自动生成本体初稿（例如微软 Fabric IQ 可以从 Power BI 语义模型生成），也要留出时间手工补全主键、关系绑定等内容——自动生成只是起点。
4. 第八步：验收
验收不是看图"像不像"，而是用测试说话。
| 测试类型 | 怎么做 | 示例 |
|---|---|---|
| 能力问题测试 | 为每个能力问题准备标准答案，比对执行结果而非查询语句 | CQ3"还能退多少"在 30 个样例订单上全部正确 |
| 动作正向测试 | 正常参数下动作能否完成，结果是否符合定义卡 | 阈值内退款一次完成，状态和通知正确 |
| 动作负向测试 | 违规参数是否被拦截，拦截原因是否清楚 | 超额退款、重复申请、生鲜无理由退货均被拒 |
| 权限测试 | 不同角色执行同一动作，结果是否被正确限制 | AI 客服尝试直接执行退款被拒 |
| 故障测试 | 模拟外部系统失败，看补偿是否生效 | 支付渠道超时后进入"结果未知"，先查询再处理，不产生第二笔退款 |
| 拒答与澄清 | 超出范围的问题能否拒答或追问 | 客户问换货（V1 不包含）时转人工 |
上线前建议先跑影子模式：Agent 照常给出判断和动作建议，但不真正执行，由人工处理并对比结果。可以关注这些指标：对象误配率（找错客户或订单行）、重复申请率、审批驳回率、补偿触发率、人工接管率。指标稳定达到约定水平后，再逐步开放执行权。阈值要由业务负责人按风险来定，这里给一组示例值供参考：对象误配率低于 0.5%、动作建议与人工处理不一致率低于 3%，连续两周达标，并且覆盖过一次大促。
4.1 测试用例怎么写
建议用"前提—操作—预期"的格式写测试用例，业务人员也能看懂并参与：
| 编号 | 前提 | 操作 | 预期 |
|---|---|---|---|
| T01 | 订单行实付 299 元，已退 0 元；售后单待退款 | 客服发起退款 299 元 | 成功；售后单进入退款中；生成退款单 |
| T02 | 同上，已退 200 元 | 客服发起退款 120 元 | 被 R01 拦截，提示可退金额为 99 元 |
| T03 | 实付 899 元；售后单待退款 | 客服发起退款 899 元 | 进入待审批；审批卡片带金额与有效期 |
| T04 | T03 已获批 | 有人把金额改为 799 元后提交（仍不超过实付、仍超过 500 元） | 原审批失效，要求重新审批 |
| T04b | 同 T03 | 有人把金额改为 989 元后提交 | 被 R01 拦截：超过实付 899 元 |
| T05 | 商品为生鲜，已签收 2 天 | AI 客服为客户创建无理由退货售后单 | 被 R03 拦截，返回规则编号与原因 |
| T06 | 支付渠道模拟超时 | 发起退款 | 动作实例进入"结果未知"，售后单保持"退款中"并冻结这笔金额；按同一幂等键查询渠道后再前滚或重试，不产生第二笔退款 |
| T07 | AI 客服身份 | 直接调用提交退款动作 | 被权限拦截：AI 客服只有建议权 |
每条用例都对应至少一条规则或一个能力问题。用例集本身也要版本化：规则改了，相应用例的预期要一起改。
5. 第八步（续）：演进
本体上线只是开始。业务会变，规则会调，新的系统会接入。
- 版本管理：本体定义（对象、关系、动作、规则）都要有版本号和变更记录；旧版本不删除，按生效时间决定使用哪一版。
- 变更评审：改动按影响分级。新增属性影响小；修改关系基数、拆分对象类型影响大，需要评估对已有动作、报表、历史数据的影响——本体是"语义耦合"，牵一发会动全身（第 08 篇详述）。
- 回归测试：每次变更都在测试环境重新跑能力问题测试和动作测试，通过后才发布。
- 门控演进：一项关于数据 Agent 本体自演化的研究（EvoOntology，arXiv:2609.15779）采用"先诊断、再小步修补、评估改进后才采纳"的做法；论文自报，去掉这道评估门槛对效果的伤害最大。即使不做自动演化，"改动必须证明有改进"这个原则也值得照搬。
- 扩范围的时机：当 V1 的能力问题测试稳定通过、影子模式指标达标、业务方开始主动提出"换货能不能也接进来"时，才是扩展范围的好时机。扩展时回到第 06 篇的第一步，为新范围单独写范围卡和能力问题，并检查新对象能否复用已有的客户、订单行等定义，而不是另建一套。
6. 用大模型辅助建模
大模型已经能显著降低建模的体力活。有实践者估计，本体和图谱初稿的成本可降到过去的十分之一甚至更低（个别实践者的经验估计，未经独立核实）。分工可以这样划：
| 适合交给大模型 | 必须由人决定 |
|---|---|
| 从访谈记录和文档中抽取候选名词、动词 | "下单"是事件还是关系，"批次"是否独立成对象 |
| 生成同义词表、对象和关系初稿 | 部门之间定义冲突时听谁的 |
| 从表结构推测字段含义、生成映射草稿 | 某个例外是否升级为正式规则 |
| 为能力问题生成测试样例、边界用例 | 高风险动作的自动化程度 |
| 检查命名、断链、明显矛盾 | 出了问题由谁承担 |
需要警惕的问题：
- 属性误拆、对象误合并。有实践者用大模型把大量企业架构文档转成本体时，遇到过把"销售发货单"和"销售出库单"误当成同一个对象的情况。名字相近的概念，务必让领域专家逐一确认。
- 没有证据的映射。字段含义的推测要用真实数据验证，例如抽样查询看取值分布；只凭字段名推测，错误率很高。
- 改动要可审。好的做法是让建模助手先读懂现有模型，生成一份可审查的变更计划，经过校验、预览和人工确认后再应用，而不是直接改。
一个可以直接使用的提示词骨架：
你是本体建模助手。根据以下访谈记录，列出候选对象类型、关系和规则。
要求：
1. 每个候选标注它能帮助回答哪条能力问题（编号见附件）；回答不了的单独列出。
2. 区分"对象 / 属性 / 状态 / 角色 / 关系体"，并说明判断理由。
3. 对名称相近但可能不同的概念，列为"待确认"，不要合并。
4. 不要编造访谈中没有出现的规则；推测内容标注"推测"。
7. 常见问题
问：动作定义卡要写到多细？
以"另一个工程师拿到卡片就能实现、业务人员拿到卡片就能验收"为标准。参数的类型和单位、每条前置条件对应的规则编号、审批绑定哪些参数、失败后怎么办，这些必须写清；实现细节（调用哪个接口的哪个版本）可以留给技术文档。
问：所有动作都要做幂等和补偿吗？
涉及外部系统、可能被重试的动作都要做幂等；涉及多个步骤、中途失败会留下"半截状态"的动作都要设计补偿。像"关闭工单"这种单步、可撤销的低风险动作，可以简化。
问：影子模式要跑多久？
没有固定时长，看指标是否稳定，以及是否覆盖了业务的典型波动（比如大促、月底）。示例商城的演练里设定为两周，只是一个示意。
问：数据绑定时发现源系统的数据质量很差，要先治理再建本体吗？
不必等全部治理完。可以先把本体建起来，用校验规则把问题数据挡在 Agent 可用范围之外，同时把校验报告交给数据负责人逐步治理。本体反而能帮你把数据质量问题看得更清楚。
问：大模型生成的初稿能直接用吗？
不能直接用。初稿的价值在于节省体力活，但必须经过三道关：自动检查（命名、断链、追溯到能力问题）、领域专家评审、裁决人确认。尤其要警惕名字相近的概念被错误合并。
本篇要点
- 动作从能力问题和动词中来，按风险分级；定义卡要包含参数绑定的审批、幂等、失败补偿和两层状态。幂等键标识一次业务决定；渠道超时视为"结果未知"，先查询再前滚或同键重试。
- 规则独立登记、有版本、可读；确定性判断写成规则，模糊判断才交给模型并保留人工复核。
- 数据绑定要决定数据放哪、身份怎么合、写入走哪；写入走业务系统接口，校验自动化。
- 规则变更走"裁决—影响分析—回归测试—定生效时间—旧版保留"的流程；测试用例用"前提—操作—预期"格式书写。
- 验收用测试说话：能力问题、动作正负向、权限、故障、拒答；上线前跑影子模式，再逐步开放执行权。
- 大模型适合做抽取、初稿和检查，人负责语义裁决和风险决定；所有改动要可审、可回滚。
参考引用
- 《Ontology Development 101: A Guide to Creating Your First Ontology》，Natalya F. Noy、Deborah L. McGuinness，Stanford University。原文
- 《Shapes Constraint Language (SHACL)》，W3C Recommendation，2017-07-20。原文
- 《Action types: Overview》，Palantir Foundry 官方文档。原文
- 《Generate an ontology (preview) from a semantic model》，Microsoft Learn。原文
- 《Decision Model and Notation (DMN) 1.6》，Object Management Group (OMG)。原文
- 《Action Ontology：让企业 Agent 从“会调用”到“能负责”》，皓月惊鸿 Chatshouse。Cubox，原文
- 《Ontology本体论实践教程:很多人会问,用CRUD拆开写不也一样吗？》，月夜烛峰。Cubox，原文
- 《从本体论到本体建模，从本体建模到 AI 原生—我这一年关于本体的系统性复盘》，何明璐 人月聊IT。Cubox，原文
- 《EvoOntology 如何自动构建本体？（实战）》，王磊 噪声之下。Cubox，原文
- 《01-认识 Ontilio：把业务世界建模成可运行的本体》，OntologyHub。Cubox，原文
- 《准备上知识图谱和本体（Ontology）？要什么团队、选什么场景、花多少成本 | 人人都是产品经理》，叶小钗。Cubox，原文
- 《我做了一套本体Ontology工程系统，让Agent能读懂企业数据》，windom Yu 硅基斥候S01。Cubox，原文
- 《LLM Wiki + Ontology：让企业知识从“可检索”走向“可行动”》，划小船。Cubox，原文
- 《一文读懂本体四大核心技术：RDF、OWL、SPARQL、SHACL，看懂语义层完整工作流》，女王的专属领地 AI产品观察局。Cubox，原文
- 《分享一个 AI 本体智能应用开发平台设计方案》，月夜烛峰。Cubox，原文
- 《EvoOntology: A Self-Evolving Ontology Layer for Data Agents》，Chong 等（中国人民大学），arXiv:2609.15779，2026。原文
- 《Action types: Webhooks》，Palantir Foundry 官方文档。原文
- 《中华人民共和国消费者权益保护法》第二十五条，国家市场监督管理总局发布文本。原文