业务规则澄清要解决的问题，是把需求里“看情况处理”的部分问清楚：什么条件下触发、按什么规则判断、结果和例外怎么处理、数据从哪里来、由谁负责。本文给出一张可直接填写的规则条目表、从需求文本到确认版规则条目的五步流程、各角色分工，以及判断澄清是否到位的检查清单。文中示例为演示情景，用于说明填写方式。
要点总览（TL;DR）
- 业务规则澄清的交付物是一张规则条目表，每条规则按触发条件、判断规则、结果与例外、数据来源、责任人五个字段填写，缺项即代表仍有问题未问清。
- 操作按五步推进：圈出需求中含判断、计算、状态变化的语句，按五字段逐条追问，单独追问空值与边界等例外，组织业务方确认并由研发、测试复核，最后形成带版本记录的确认版。
- 需求分析人员负责提问与整理，业务方确认判断规则与例外处理，研发复核可实现性，测试复核能否直接写出用例；三方意见不一致时回到追问环节。
- 判断澄清是否到位，可看每条规则能否直接写出至少一条测试用例、例外是否都有结论、未决问题是否登记了责任人与期限。
- 规则条目和未决问题需要在需求条目下持续跟踪时，可借助 ONES 的工作项与 Wiki 页面承载，具体字段配置以实际产品版本为准。
业务规则澄清要产出什么：规则条目的五个字段
业务规则澄清的落点是一张规则条目表，会议记录只是过程材料。规则条目把散落在需求描述、口头说明和聊天记录里的判断逻辑，整理成一条条可确认、可开发、可测试的记录。澄清阶段处理的是判断条件、触发时机、例外情况和处理结果；结构化建模、正式评审流程、技术实现方案属于后续环节，不在本文展开。
每条规则按五个字段填写，缺一项就意味着还有问题没问清。
| 字段 | 填写要求 | 常见空缺 |
|---|---|---|
| 触发条件 | 写清规则在什么业务动作或时点生效，例如“提交订单时”“每月账单生成时”“状态从待审变为通过时” | 只写“下单时”，未说明是点击提交、支付成功还是发货后 |
| 判断规则 | 用可判断真假的语句描述条件组合，明确比较对象、阈值和逻辑关系 | 写“满足条件的用户”，未说明条件具体指什么 |
| 结果与例外 | 写正常结果，再单独列出例外情形及各自处理方式 | 只写主流程结果，空值、超限、重复操作没有结论 |
| 数据来源 | 指明判断所依赖的数据来自哪个系统、哪张表或哪个业务单据，以及取数时点 | 写“根据用户等级”，未说明等级从哪里取、何时生效 |
| 责任人 | 写明该规则的业务确认人和维护人，便于后续变更时找到决策者 | 只写部门名称，没有具体到人 |
规则条目与上下游文档的衔接关系是：需求描述提供原始语句，规则条目把其中的判断逻辑逐条拆开并确认，测试用例直接从规则条目派生。一条规则条目通常能对应一条或多条测试用例；如果写不出测试用例，说明判断规则或结果仍有模糊之处。规则条目编号建议与需求条目编号建立对应，便于追溯。
澄清的操作步骤：从需求文本到确认版规则条目
澄清按五步推进，每一步都有明确的输入、动作、输出和完成标志。团队可按需求复杂度裁剪追问深度，步骤顺序保持不变。
第一步：圈出待澄清语句
输入是需求文档、原型说明和业务方提供的背景材料。动作是逐段阅读，标出所有含判断、计算、状态变化、时限和权限差异的语句，例如“符合条件的客户可享受优惠”“超过期限自动关闭”“根据等级展示不同内容”。输出是一份待澄清清单，每条注明原文位置和初步疑问。完成标志是需求文本中不再有未被标记的判断类语句。
第二步：按五字段逐条追问
输入是待澄清清单。动作是逐条向业务方提问，按触发条件、判断规则、结果与例外、数据来源、责任人五个字段填写；业务方的回答尽量记录原话，暂时答不上来的记为未决问题，注明需要谁在什么时间前给出结论。输出是规则条目的初稿和未决问题列表。完成标志是每条待澄清语句都已进入规则条目初稿，或已登记为未决问题。
第三步：单独追问例外与边界
输入是规则条目初稿。动作是围绕每条规则追问边界情形：数据为空或缺失时怎么处理，数值超出上下限时怎么处理，同一操作重复提交时怎么处理，跨期、跨组织或跨状态变更时怎么处理，规则之间冲突时以哪条为准。输出是补充了例外处理的规则条目。完成标志是每条规则至少经过一轮边界追问，例外情形有明确结论或登记为未决。
第四步：业务确认与研发测试复核
输入是补充后的规则条目。动作是组织业务方逐条确认判断规则和例外处理，确认其符合业务实际；研发复核规则能否在现有系统中实现、是否与已有逻辑冲突；测试复核每条规则能否直接写出测试用例。三方意见不一致时回到第二步继续追问，直到形成一致结论。输出是评审意见记录和修订后的规则条目。完成标志是业务方、研发、测试三方均给出明确意见，分歧项已关闭或登记。
第五步：形成确认版并记录变更
输入是修订后的规则条目和评审意见。动作是整理成确认版规则条目表，标注版本号、确认日期和确认人；后续任何规则调整都在表中记录变更内容、变更原因和影响范围。输出是确认版规则条目表及变更记录。完成标志是确认版发布给研发和测试，变更记录机制开始运转。
当规则条目和未决问题需要在需求条目下持续跟踪时，可以借助 ONES 承载管理动作：ONES Assistant 可围绕 PRD 质量检查提炼待澄清问题与拆解建议，并将自然语言指令转化为 ONES 中可追踪的工作；规则条目和未决问题可作为工作项或 Wiki 页面挂在对应需求下，基于权限体系执行，过程可追踪。具体字段配置以实际产品版本为准。
角色分工与交付物：谁提问、谁确认、谁复核
澄清过程涉及四类角色，各自承担不同的提问、确认和复核职责。规则只有经过业务确认和研发、测试复核，才算脱离口头共识。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 需求分析人员 | 圈出待澄清语句，组织追问，整理规则条目，维护待澄清清单和未决问题 | 待澄清清单、规则条目初稿、未决问题列表 | 第二步开始前提供清单；第四步前提供可评审的规则条目 |
| 业务方 | 确认判断规则与例外处理，说明业务依据，对未决问题给出结论 | 规则确认意见、例外处理结论、业务依据说明 | 第四步确认会上逐条确认；未决问题按约定时间反馈 |
| 研发 | 复核规则的可实现性，指出与现有逻辑的冲突和实现代价 | 可实现性意见、冲突项说明 | 第四步复核时提出；冲突项在确认版发布前关闭 |
| 测试 | 复核规则能否直接转化为测试用例，指出不可测的表述 | 可测性意见、由规则条目派生的测试用例草案 | 第四步复核时提出；确认版发布后完善用例 |
交接的关键在于规则条目的状态清晰：初稿、待确认、已确认、有未决。需求分析人员负责推动状态流转，业务方对确认结论负责，研发和测试的复核意见作为确认版的组成部分留存。
示例：一条折扣规则的澄清过程
以下为演示情景，用于说明五字段如何从模糊需求填写为确认版规则条目。
原始需求描述为：“会员下单时可以享受折扣。”这句话包含多个模糊点：什么算会员、折扣是多少、什么时候计算折扣、折扣与其他优惠能否叠加、退款后如何处理。
按五字段逐条追问的过程如下：触发条件方面，业务方确认折扣在订单提交时计算，支付成功后生效；判断规则方面，会员等级分为普通、银卡、金卡三档，分别对应九五折、九折、八五折，等级以订单提交时的有效等级为准；结果与例外方面，折扣作用于商品金额，运费不参与折扣，折扣可与优惠券叠加但叠加后不低于成本价，退款时按退款商品的原折扣价重算；数据来源方面，会员等级取自会员系统，订单提交时实时读取；责任人方面，业务确认人为运营负责人，规则维护人为会员运营岗。
例外条件补充追问后，业务方明确：会员等级在订单提交后降级的不影响已提交订单；同一订单重复提交以首次成功提交为准；跨月退款按原订单折扣重算，不按退款时等级重算。
确认版规则条目填写为：触发条件——订单提交时计算，支付成功后生效；判断规则——按提交时有效会员等级取对应折扣率，普通九五折、银卡九折、金卡八五折；结果与例外——折扣作用于商品金额不含运费，可与优惠券叠加且叠加后不低于成本价，退款按原折扣价重算，重复提交以首次成功为准；数据来源——会员系统实时读取等级；责任人——运营负责人确认，会员运营岗维护。
由这条规则可直接写出测试用例，例如：金卡会员提交含运费订单，验证商品金额按八五折计算且运费不打折；银卡会员叠加优惠券后金额低于成本价，验证系统按成本价兜底；金卡会员下单后降级再退款，验证按原八五折重算。
完成检查：规则条目何时算澄清到位
澄清是否可以结束，按以下清单逐项核对。全部满足即可发布确认版；存在未满足项时，明确责任人和完成期限后再推进。
- 每条规则五个字段均已填写，没有空白项；确实不适用的字段注明原因。
- 例外与边界条件已单独列出，空值、超限、重复提交、跨期处理均有明确结论。
- 业务方已逐条确认判断规则和例外处理，确认人和确认日期已记录。
- 研发已复核可实现性，与现有逻辑的冲突项已关闭或有处理方案。
- 测试已复核可测性，每条规则至少能直接写出一条测试用例。
- 未决问题已登记，注明责任人、需要的信息和答复期限。
- 规则条目有版本号和变更记录，后续调整可追溯。
这张清单同时可作为澄清会议的收尾依据：逐项过一遍，把未满足项转为待办，规则条目即可进入开发和测试环节。
常见问题
业务方在澄清会上答不上来的问题，应该怎么处理？
当场答不上来的问题不要用“后续再议”带过，而是登记为未决问题：写明问题内容、需要哪方面的信息、由谁负责给出结论、期望答复时间。规则条目中对应字段先标注“待定”，其余字段照常填写，避免整条规则停滞。未决问题清单在每次澄清会开始时先过一遍，已关闭的更新结论，超期未答复的升级给业务方负责人。
规则条目和需求描述、测试用例之间怎么保持同步？
建议让规则条目编号与需求条目编号建立对应关系，需求描述变更时能定位到受影响的规则条目。测试用例从规则条目派生，并在用例中回填规则编号；规则条目升版时，按编号找出关联用例一并复核。这样规则调整的影响范围可以沿着编号追溯，不必靠记忆判断哪些用例需要改。
需求比较简单，还需要走完整的五步流程吗？
可以裁剪追问深度，步骤顺序建议保留。简单需求可以合并确认与复核环节，例如业务方与研发、测试在同一次短会中完成确认和复核；边界追问也可以只覆盖与本次需求直接相关的空值、重复提交等情形。判断标准不变：每条规则五个字段填全，例外有结论，能写出测试用例。
研发复核时提出规则与现有系统逻辑冲突，应该由谁决定？
冲突的处理结论由业务方拍板，研发负责说明冲突点、实现代价和可选方案。需求分析人员把冲突项、可选方案和各自影响记录在规则条目下，业务方选择方案后更新判断规则或例外处理，再交由研发和测试复核。冲突项在确认版发布前应关闭，确实无法关闭的登记为未决问题并明确期限。
ONES 在业务规则澄清环节能承担哪些管理动作？
ONES Assistant 可围绕 PRD 质量检查提炼待澄清问题与拆解建议，并把自然语言指令转化为 ONES 中可追踪的工作；规则条目和未决问题可以作为工作项或 Wiki 页面挂在对应需求下，基于权限体系执行，过程可追踪。具体字段配置与可用范围以实际产品版本为准。
