业务规则澄清可以结束的判断标准是“可判定、可复算、可交接”：每条规则都能明确判定成立与否，同一输入按规则得到同一结果，开发与测试无需再向业务方追问即可实现和验证。本文围绕触发条件、约束、例外、优先级、执行结果五类规则，给出字段清单、覆盖率与样例通过率的计算口径，以及从规则清单到样例走查的评估步骤，并说明指标的适用边界。
要点总览（TL;DR）
- 业务规则澄清达到“可判定、可复算、可交接”即可视为完成：每条规则能明确判定成立与否，同一输入得到同一结果，开发与测试无需再追问业务方。
- 需要澄清五类规则：触发条件、约束、例外、优先级、执行结果；每条规则都要写明对象、字段、取值、时间窗、责任角色五项字段。
- 完成度用两个指标衡量：规则覆盖率＝已补齐五类字段的规则数÷规则清单总条数；样例通过率＝走查结果与预期一致的样例数÷样例总数。
- 存在阻断级未决项时不判定完成，即使覆盖率与通过率较高；分母为零时指标记为“不适用”，不按0%或100%处理。
- 指标只反映澄清的完整与一致程度，不证明规则本身正确；规则字段变更后需重新走查并重算指标。
澄清完成要回答的判断问题
判断一次业务规则澄清是否完成，先看三条线是否同时成立。可判定，指每条规则都有明确的判断对象和条件，业务方、开发、测试对“这条规则是否生效”能给出相同答案。可复算，指给定一组输入，按规则推导出的结果唯一，不因执行人不同而变化。可交接，指开发能据此设计逻辑、测试能据此设计用例，双方不需要再回到业务方确认同一件事。
这三条线与文档写完、会议开完是两回事。文档篇幅长、评审会开过，仍可能留下“大客户可以适当放宽”这类无法判定的表述；反过来，一份简短的规则清单如果字段齐全、样例走查通过，就可以判定完成。澄清完成是规则具备被实现和被验证的条件，文档和会议只是达成条件的过程。
澄清完成与相邻工作有分工边界。结构化表示与建模解决“规则用什么形式表达”，属于需求建模与表达的范畴；正式的需求评审与确认解决“相关方是否认可”，属于需求评审与确认的范畴。本文讨论的是两者之间的状态：规则内容本身已经清楚到可以被建模、被评审、被实现。澄清完成可以作为进入正式评审的前置条件，但不能替代评审结论。
与后续开发测试的衔接体现在交接物上。完成时，规则清单、样例与预期结果、未决项登记应当同时存在。开发从规则清单取实现依据，测试从样例取验证依据，未决项登记则说明哪些内容仍待确认、由谁负责、何时关闭。三者齐备，澄清结果才能被下游直接使用。
需要澄清的五类业务规则与字段
业务规则可以按作用拆成五类，每类回答一个不同的问题。触发条件回答“什么时候生效”，约束回答“必须满足什么限制”，例外回答“哪些情形不按常规处理”，优先级回答“多条规则同时命中时谁先谁后”，执行结果回答“生效后产生什么输出或状态变化”。五类规则分开澄清，可以避免把条件、限制和结果混在一句话里，导致实现时各取所需。
每类规则都要落到对象、字段、取值、时间窗、责任角色五项字段。对象是规则作用的业务实体，字段是判断所依据的数据项，取值是字段允许的枚举或区间，时间窗是规则生效或计算的时间范围，责任角色是这条规则的业务解释人。五项字段缺任何一项，都说明这条规则还没有澄清到可实现的颗粒度。
| 规则类型 | 要澄清的问题 | 必填字段示例 | 常见未澄清表现 |
|---|---|---|---|
| 触发条件 | 规则在什么事件或状态下生效 | 对象：订单；字段：支付状态；取值：已支付；时间窗：下单后24小时内；角色：交易运营 | 只写“满足条件时”，未说明条件字段和取值 |
| 约束 | 生效后必须满足哪些限制 | 对象：优惠券；字段：单笔订单金额；取值：≥100元；时间窗：活动期间；角色：营销负责人 | 写“金额较大”，没有阈值和单位 |
| 例外 | 哪些情形不适用常规处理 | 对象：退款单；字段：商品类型；取值：虚拟商品；时间窗：签收后7天内；角色：客服主管 | 例外靠口头约定，未进入规则清单 |
| 优先级 | 多条规则冲突时的先后顺序 | 对象：折扣规则；字段：规则等级；取值：专属活动高于通用活动；时间窗：活动重叠期；角色：业务负责人 | 只列规则，不写冲突时如何取舍 |
| 执行结果 | 规则生效后产生什么输出或状态 | 对象：订单；字段：应付金额；取值：按折扣后金额；时间窗：结算时；角色：财务对接人 | 结果描述模糊，未说明落到哪个字段 |
规则之间存在依赖和冲突时，要在清单中显式标注，而不是留给实现阶段临时判断。依赖指一条规则的输入来自另一条规则的输出，例如折扣结果影响运费计算；冲突指两条规则对同一对象给出不同结果，例如两张优惠券同时可用。标注方式可以是在规则条目上增加“依赖规则编号”和“冲突处理规则编号”两列，并确保被引用的规则在清单中存在。冲突无法通过优先级解决时，应登记为未决项，而不是默认取其一。
完成度的量化口径：覆盖率与样例通过率
完成度用两个指标衡量，口径固定后才能跨人、跨轮次比较。规则覆盖率反映规则清单的字段完整程度，样例通过率反映规则在具体输入下的可复算程度。两个指标都以规则清单和样例集为分母，统计时间窗建议与本次澄清轮次一致，例如从规则清单建立到走查结束。
规则覆盖率＝已补齐五类字段的规则数÷规则清单总条数×100%。分子中的“已补齐”指对象、字段、取值、时间窗、责任角色五项字段均有明确内容，且该规则涉及的依赖或冲突已标注；只写了部分字段的规则不计入分子。分母是本次澄清范围内登记的全部规则条数，包括尚未开始澄清的条目。单位为百分比，统计时点写明日期。
样例通过率＝走查结果与预期一致的样例数÷样例总数×100%。分子要求样例的输入、预期结果、实际走查结果三者齐全且一致；预期结果缺失的样例不计入分子，但仍计入分母。分母是本次为规则清单构造的全部样例数。若一条规则对应多个样例，按样例计数，不按规则计数。
未决项单独计数并分级。阻断级未决项指不解决就无法判断规则行为、开发无法实现或测试无法设计用例的事项；非阻断级指不影响当前行为判断、可在后续补充的事项。存在阻断级未决项时，即使覆盖率与通过率较高，也不判定澄清完成。未决项登记应包含事项描述、级别、负责人和截止时间。
分母为零时需要特殊处理。规则清单为空时，覆盖率记为“不适用”，不按0%或100%处理；样例集为空时，通过率同样记为“不适用”。数据不可比的情形包括：两轮澄清的规则清单范围不同、样例集构造标准不同、统计时间窗不一致。出现这些情况时，应重新界定范围后再比较，不能直接拿两个百分比下结论。
评估步骤：从规则清单到样例走查
评估按固定顺序推进，每一步都有明确产物，便于中途检查进度和交接。
- 建立规则清单并编号。把本次澄清范围内的业务规则逐条登记，每条分配唯一编号，记录规则名称、类型、来源和当前状态。清单范围要与澄清任务的范围一致，避免边评估边扩大。
- 逐条补齐五类字段。按触发条件、约束、例外、优先级、执行结果逐条填写对象、字段、取值、时间窗、责任角色，同时标注依赖规则编号和冲突处理规则编号。填写过程中发现无法确定的内容，直接登记为未决项。
- 构造样例并填写预期结果。为每条规则至少构造一个正常样例，对存在例外和冲突的规则补充边界样例。每个样例写明输入数据、适用规则编号和预期结果，预期结果要落到具体字段或状态。
- 走查比对并记录差异。由业务方、开发、测试共同按样例逐条走查，记录实际推导结果与预期结果是否一致。不一致时记录差异描述和涉及规则，判断是规则表述不清还是样例预期有误。
- 登记未决项并判定完成。汇总走查中发现的差异和此前登记的问题，按阻断级和非阻断级分类，指定负责人和截止时间。计算覆盖率与通过率，结合未决项级别给出完成判定：无阻断级未决项、两个指标达到团队约定口径时，判定为完成。
这套步骤的产物可以直接进入协作工具管理。规则清单和样例可以作为工作项逐条跟踪，字段补齐情况对应工作项状态，未决项作为独立工作项指派负责人和截止时间。ONES 支持将需求澄清中的待澄清问题提炼出来，并连接项目、Wiki 与测试用例，把规则条目、样例和未决项放在同一处追踪；基于权限体系的问答与操作过程可追踪，便于在交接时回看每条规则的确认记录。工具承载的是登记和流转动作，规则内容是否成立仍由业务方判断。
示例：一条折扣规则的澄清与验收
以下为演示情景，用于说明字段填写与指标计算方式，数据为构造值。
规则字段填写。规则编号R-017，类型为约束与执行结果的组合。触发条件：订单提交时支付状态为已支付，时间窗为活动期内。约束：订单中可折扣商品金额≥100元，字段为可折扣金额，取值为大于等于100的数值，单位为元。例外：虚拟商品不参与折扣，字段为商品类型，取值为虚拟商品。优先级：专属活动折扣高于通用活动折扣，冲突时按专属活动执行。执行结果：订单应付金额按折扣后金额计算，落到应付金额字段。责任角色：营销负责人解释规则，财务对接人确认金额口径。
样例与预期结果。样例A：可折扣金额120元，商品为实物，命中通用活动九折，预期应付108元。样例B：可折扣金额80元，未达约束阈值，预期不打折，应付80元。样例C：可折扣金额150元，商品为虚拟商品，命中例外，预期不打折，应付150元。样例D：可折扣金额200元，同时命中通用活动九折和专属活动八折，按优先级执行专属活动，预期应付160元。
指标计算。本次澄清范围内规则清单共20条，已补齐五项字段并标注依赖冲突的为17条，规则覆盖率为17÷20×100%＝85%。为这20条规则共构造样例40个，走查结果与预期一致的为36个，样例通过率为36÷40×100%＝90%。
未决项影响。走查中发现R-017的例外范围只写了虚拟商品，未说明虚拟商品中的充值类是否同样适用，登记为阻断级未决项，负责人为营销负责人，截止时间为下一工作日前。该未决项不解决，开发无法确定充值类订单的处理逻辑，因此即使覆盖率85%、通过率90%，本次仍不判定澄清完成。待该未决项关闭并补充对应样例后，重新走查并重算指标。
解读与限制：指标不能替代判断的部分
覆盖率和通过率反映的是澄清的完整程度和一致程度，不证明规则本身正确。字段填齐、样例通过，说明团队对规则的理解一致且可复算；如果业务规则本身与业务目标不符，指标仍然会显示较高。因此指标适合作为完成判定的必要条件，规则是否符合业务意图仍需业务负责人确认。
规则变更后需要重新评估。触发重评的条件包括：规则的触发条件、约束、例外、优先级或执行结果任一字段发生修改；依赖规则被调整；冲突处理方式变化；样例预期结果被修正。变更后应更新规则清单版本，对受影响规则重新构造或复核样例，并重算两个指标。只改文档不改样例，会导致通过率虚高。
跨团队口径不一致是常见风险。不同团队对“已补齐字段”的认定可能不同，例如有的团队把“待确认”也算作已填写；样例构造的覆盖范围也可能宽窄不一。降低风险的做法是固定字段判定规则和样例构造标准，并在指标旁注明统计范围、时间窗和口径版本。跨团队比较时先对齐口径，再比较数值。
不能把单一指标当作全部验收依据。覆盖率高的清单可能缺少关键例外，通过率高的样例集可能没有覆盖冲突场景。完成判定应同时看两个指标、未决项级别和样例覆盖的业务场景，三者结合才能支撑“可判定、可复算、可交接”的结论。
常见问题
规则清单里有一条规则暂时无法确定例外情形，可以先判定澄清完成、后续再补吗？
要看这条规则对开发与测试的影响。如果例外情形不明确会导致开发无法确定处理逻辑、测试无法设计用例，就属于阻断级未决项，此时即使其他规则都已澄清、覆盖率与通过率较高，也不判定完成。处理方式是把该事项登记为未决项，写明负责人和截止时间，关闭后补充对应样例并重新走查。
如果缺失的例外只影响边缘场景、当前迭代不涉及，可以登记为非阻断级未决项，在完成判定中注明其范围和后续处理计划。
两个团队各自算出的规则覆盖率差异很大，怎么判断哪个更可信？
先对齐口径再比较数值。差异通常来自三处：对“已补齐字段”的认定不同，例如有的团队把“待确认”也算作已填写；规则清单范围不同，有的只统计本轮新增规则；统计时间窗不同。建议固定字段判定规则，明确清单范围与统计截止日期，并在指标旁注明口径版本。口径一致后，两个数值才有可比性。
样例通过率达到100%，是否说明业务规则已经澄清到位？
不能直接下这个结论。通过率100%说明已构造的样例在走查中与预期一致，但样例集本身可能没有覆盖例外、冲突和边界场景。判定完成还要看规则覆盖率是否达标、是否存在阻断级未决项、样例是否覆盖了主要业务场景。三者结合，才能支撑“可判定、可复算、可交接”的结论。
规则在澄清完成后又被业务方调整了，之前的评估结果还能用吗？
需要重新评估。触发重评的条件包括：触发条件、约束、例外、优先级或执行结果任一字段发生修改；依赖规则被调整；冲突处理方式变化；样例预期结果被修正。变更后应更新规则清单版本，对受影响规则重新构造或复核样例，并重算覆盖率与通过率。只改规则文档而不更新样例，会让通过率失真。
规则清单和样例走查的结果放在哪里，才能让开发和测试直接接手？
关键是让规则条目、样例与预期结果、未决项登记三份产物同时可查，并且未决项带有负责人和截止时间。可以借助协作工具把规则清单和样例作为工作项逐条跟踪，字段补齐情况对应工作项状态。ONES 支持将需求澄清中的待澄清问题提炼出来，并连接项目、Wiki 与测试用例，把规则条目、样例和未决项放在同一处追踪；基于权限体系的问答与操作过程可追踪，便于交接时回看确认记录。工具承载登记和流转，规则内容是否成立仍由业务方判断。
