优惠券规则怎么检查？用决策表找出满减冲突与遗漏

“满100元减10元，满200元减25元”看起来很清楚，写成两条“金额大于等于门槛”的规则后，200元却会同时命中两条。优惠券规则决策表要解决的正是这类问题：把资格、金额、互斥条件和结果放在一起，检查同一笔订单是否得到明确且一致的答案。

做这张表之前，先确定金额怎么算、优惠能否叠加，以及不满足条件时返回什么。产品、运营和测试可以在Boardmix 产品团队协作白板上并排放置业务原话、规则表与边界订单，逐条讨论，而不是各自按一句活动文案理解需求。

先统一“满100元”的金额口径

以一家商户的阶梯优惠活动为例：一单评估一张已经选中的活动券，满100元减10元，满200元减25元；达到多档时取最高一档，不把两档优惠相加。这些是本案例的业务约定，其他活动应先确认自己的规则。

这里的门槛金额，是参与活动商品在本券抵扣前、商品自身折扣后的应计金额之和，不包含不参与活动的商品和运费。先算对这个输入，再判断档位。

同一订单中，支付前合计与优惠门槛金额不是一回事

订单项目	金额	计入本券门槛
参与活动商品A	60元	是
参与活动商品B	50元	是
不参与活动商品	45元	否
运费	6元	否
合计	161元	门槛金额为110元，可进入100元档判断

再看一笔更容易暴露错误的订单：参与商品90元，不参与商品30元，运费10元。订单合计130元，但门槛金额只有90元，不能使用本券。若直接把订单总额传进规则表，表格写得再严密，也会算错。

评审时还要确认两个输入：“券可用”是否已经包含所属账户、有效期、未核销等核验；“已选互斥活动”具体指哪些活动。本表接收这些核验后的结论，不代替发券、领券或核销流程。金额进入计算时统一用整数分，展示时再换成元；未知状态或缺失金额应先报输入问题，不能默认为“否”或0元。

用三笔订单找出错表中的重叠与遗漏

最初的规则表往往只有两行：

• D1：券可用、未选互斥活动、门槛金额≥100元，优惠10元。
• D2：券可用、未选互斥活动、门槛金额≥200元，优惠25元。

先不要讨论表格颜色。把99.99元、150元和200元依次代进去，其他条件均为“券可用、未选互斥活动”。150元只命中D1；99.99元没有命中；200元同时命中D1和D2。后两种情况不是同一个问题：前者缺少明确的“不满足门槛”结果，后者给出了冲突答案。

在DMN的命中策略中，Unique（U）要求至多一条规则匹配，多条匹配会违反该策略；它允许没有规则匹配，并不自动保证规则覆盖完整。本案例另外要求每组合法输入都有明确结果，所以还要检查遗漏。相关定义可参阅Camunda的命中策略说明。

因此，评审要分开问两件事：有没有输入能同时满足多行？有没有合法输入不属于任何一行？只测一笔能正常优惠的订单，回答不了这两个问题。

把资格、互斥和金额区间写成五行规则

本例约定只向用户展示一个主结果：先说明券是否可用，再判断是否有互斥活动，最后判断金额档位。这个次序通过互不重叠的条件表达，不靠规则在表格中的上下位置决定。

阶梯优惠的完整规则表：每组合法输入对应一个结果

规则	券可用	已选互斥活动	门槛金额	本券结果
R1	否	任意	任意合法金额	不可用，优惠0元；原因：券不可用
R2	是	是	任意合法金额	不可用，优惠0元；原因：互斥活动
R3	是	否	0≤金额<100元	不可用，优惠0元；原因：未达门槛
R4	是	否	100≤金额<200元	可用，优惠10元
R5	是	否	金额≥200元	可用，优惠25元

“任意”表示该字段在合法范围内不影响本行，不是接受缺失或格式错误的数据。R1覆盖券不可用的情况；R2限定券可用但存在互斥活动；剩余订单再按三个互不相交的金额区间分开。这样，即使调整五行的排列顺序，结果也不变。

最值得复核的是R2。若把它的“券可用”改成“任意”，一笔券已失效且选择了互斥活动的订单就会同时命中R1和R2。虽然两行都优惠0元，返回的原因却不同，仍然没有得到约定的唯一结果。

200元为什么是25元，而不是35元？因为案例一开始已经明确只取最高一档。决策表把业务选择表达出来，不能反过来用表格的计算方式替业务做决定。

边界用例不仅要测“刚好满额”

围绕每个门槛，取低一分、正好到达和高一分；再加入资格不满足、互斥活动以及金额输入错误的情况。用例中的金额均指门槛金额，而非订单合计。

可直接用于规则评审的边界订单

输入	预期结果	主要检查点
券可用、无互斥，99.99元	R3，优惠0元	门槛以下有明确拒绝结果
券可用、无互斥，100元及100.01元	R4，优惠10元	包含100元边界
券可用、无互斥，199.99元	R4，优惠10元	低档区间不提前结束
券可用、无互斥，200元及200.01元	R5，优惠25元	高档生效，且不与R4重叠
券可用、有互斥，200元	R2，优惠0元	金额足够不代表资格满足
券不可用、有互斥，200元	R1，优惠0元	同时存在两个拒绝条件时，主结果明确
券状态未知，或金额缺失、为负数	先处理输入错误，不进入规则匹配	异常数据不能伪装成正常不优惠

“没有命中”“命中一条不优惠规则”“输入不合法”应分别记录。若都显示成“优惠0元”，测试人员很难判断是正常拒绝，还是漏了一段条件。

金额分档完整，也不代表整个优惠系统已经正确。活动时间、商品范围计算、多人同时核销等各有自己的规则。本表完成的是给定输入下的优惠判断；评审结束时，应把上游提供哪些字段、由谁保证字段含义写清楚。

在评审画布上，怎样把争议落到具体规则

准备一个Boardmix画布，按阅读顺序安排三个区域：左侧放活动原话和已经确认的金额口径，中间放R1—R5规则表，右侧放边界订单。不要把尚未确认的政策直接写进结果列；先单独列成问题，例如“商品折扣后金额是否含运费”。

1. 给输入和规则编号。一单评估一张券、最高档不叠加记为B1，金额口径记为B2，券可用条件记为B3，互斥约定记为B4；规则沿用R1—R5。编号让讨论能指向具体内容。
2. 拿一笔订单逐列核对。先核对券状态，再核对互斥活动，最后核对金额；在命中行旁写出优惠金额和原因，不能只说“应该能用”。
3. 把不同意见变成条件差异。有人认为200元应减35元，就回到B1确认叠加政策；有人认为订单130元应享优惠，就检查参与商品金额是否只有90元。
4. 记录政策变更影响。若高档门槛改为180元，需要一起修改R4上限、R5下限、相邻边界订单以及活动文案，不能只改一个单元格。

规则表适合让团队共同看清逻辑，实际结算仍需由业务系统实现和校验。把这份规则表附到产品需求评审清单之后，便能用具体输入与预期结果回答“规则是否明确”，而不是只勾选一个“已评审”。

最应避免的修补，是在底部加一行“任意情况都优惠0元”，或改成“先命中谁就用谁”。前者会与正常优惠行重叠，后者可能让行序掩盖条件冲突。先修清业务口径和区间，再考虑实现，才不会把含糊的活动文字变成更难发现的系统问题。