规则保存成功只说明配置被系统接收，执行时是否命中还要看触发条件、执行顺序、对象范围和权限。排查时按这四层逐级推进，每层用一条可复现的测试记录留下证据，确认原因后再改配置，改完用同一路径复跑验证。
要点总览（TL;DR）
- 规则保存成功只代表配置被系统接收，执行时是否命中还要看触发条件、执行顺序、对象范围和权限，排查按这四层从易到难推进。
- 每层都要用一条可复现的测试记录和执行日志留证据：日志无命中先查触发条件，有命中但动作未执行再查顺序与权限。
- 对象范围不匹配的典型表现是部分记录生效、部分不生效，需逐项核对对象类型、状态区间、项目空间范围和发布状态。
- 修复后回到原测试记录用相同路径复跑，比对状态、字段值、通知和日志，并把原因写入规则说明或检查清单防止复发。
先分清“保存成功”和“执行生效”是两件事
保存成功验证的是配置写入链路：表单校验通过、必填项齐全、规则记录已落库。执行生效验证的是另一条链路：业务事件发生、规则被匹配、动作被允许、结果被写回。两条链路之间任何一环断开，都会出现“规则在列表里好好的，流程就是不动”的现象。
这类问题的典型症状有四种：记录状态停在原处没有流转；目标字段值没有按规则改写；应发的通知没有发出；执行日志里查不到这条规则的命中记录。前三种是结果层面的表现，第四种是过程层面的线索，排查时优先看日志，能快速区分“没触发”和“触发了但没执行”。
在动手改任何配置之前，先把现场信息收集齐，避免凭印象复现：
- 记录编号与所在项目、空间，确认排查对象唯一；
- 触发时间点，精确到分钟，便于和日志时间对齐；
- 操作人及其账号，后续核对权限时要用；
- 期望结果与实际结果，分别写清楚，例如“期望状态从待处理变为处理中，实际仍为待处理”；
- 规则名称、保存时间、最近一次修改人和修改内容。
这份清单的作用是让后续每一层的验证都有对照基准。缺少现场信息时，容易把“这次没生效”误判成“规则一直有问题”，改错方向。
按四层顺序排查：触发条件、执行顺序、对象范围、权限
四层顺序的依据是验证成本和出错概率：触发条件最容易用一条测试记录直接观察，执行顺序次之，对象范围和权限需要对照配置逐项核对。从易到难推进，可以在最短时间内排除大部分常见原因，也避免一上来就大改配置。
| 层级 | 检查点 | 验证证据 | 判定结论 |
|---|---|---|---|
| 触发条件 | 事件类型是否匹配、字段值是否满足阈值、前置条件是否叠加抵消 | 手动制造一次触发事件后的执行日志记录 | 日志无命中记录，问题在本层；有命中记录，进入下一层 |
| 执行顺序 | 是否有更靠前的规则先命中、互斥或终止动作是否拦截、循环保护是否跳过 | 规则列表的优先级顺序与本次执行日志中的命中规则 | 日志显示命中的是另一条规则，问题在本层 |
| 对象范围 | 对象类型、状态区间、项目空间范围、生效时间与发布状态 | 规则配置详情与当前记录属性的逐项对照 | 任一项不覆盖当前记录，问题在本层 |
| 权限 | 触发人修改权限、执行人操作权限、配置者创建权限 | 权限配置页与日志中的权限拒绝或跳过线索 | 存在缺失权限项，问题在本层 |
每层的停止点是：一旦找到能解释现象的证据，就停在该层处理，不再往下猜。例如日志显示规则已命中但动作未执行，触发条件层就可以排除，直接进入执行顺序和权限的核对。反过来，如果日志完全没有记录，先不要怀疑权限，回到触发条件层验证事件是否真的发生。
修改配置前先导出或截图当前规则快照，记录修改前的状态。涉及删除规则、调整优先级、变更作用范围的操作影响面较大，建议先在测试项目或单条测试记录上验证，确认无误后再应用到正式范围。
触发条件：事件发生了吗，字段值满足阈值吗
这一层要回答两个问题：规则监听的事件是否真的发生，事件发生时的字段值是否满足规则设定的条件。两者任一不成立，规则都不会被触发，日志里自然没有记录。
先核对事件类型。规则配置的是状态变更、字段修改、记录创建还是定时触发，实际发生的操作必须与之一致。常见偏差是：规则监听“状态变更”，但操作人只改了字段没改状态；规则监听“字段修改”，但该字段是通过批量导入或接口写入的，事件类型与手工编辑不同。
再核对字段值的比较方式。不同字段类型的判定逻辑差异较大：
- 文本字段的“等于”和“包含”结果不同，前后空格、大小写也可能影响匹配；
- 空值判断要区分“字段为空”和“字段不存在”，新建记录未填写的字段属于哪种情况需要实际验证；
- 多选字段的比较通常按集合判断，要求“包含某一项”和“完全等于所选集合”是两种条件；
- 日期字段要注意比较基准是当天、具体时刻还是区间，跨时区场景下日期可能偏移一天；
- 人员字段比较的是具体人员、角色还是当前操作人，配置时容易选错对象。
还要检查多个前置条件叠加后的效果。规则里同时设置了“状态为处理中”和“优先级为高”，只有两个条件同时满足才会触发；如果其中一个条件在测试记录上不成立，规则就不会执行。条件之间是“且”还是“或”，需要在规则详情里逐条确认。
验证方法是选一条测试记录，按规则设定的路径手动制造触发事件，然后立即查看执行日志。日志有命中记录，说明触发条件层通过；没有记录，就在本层继续缩小范围，逐条放宽条件做对照测试，定位是哪一条条件未满足。
执行顺序：是否有更靠前的规则先命中或互相拦截
同一对象上往往配置了多条规则，系统按优先级顺序依次匹配。当前规则没有生效，可能是另一条更靠前的规则先命中并改变了记录状态，导致当前规则的条件不再成立；也可能是某条规则执行了终止类动作，后续规则被直接跳过。
排查时先拉出该对象类型上的全部规则，按优先级排序，确认当前规则的位置。然后对照执行日志，看本次事件实际命中的是哪一条规则、执行了哪些动作。如果日志显示命中的是另一条规则，问题就在顺序层，处理方向是调整优先级或合并重复规则，而不是修改当前规则的条件。
需要重点检查的几种交互情形：
- 抢先命中：前序规则已经把状态改成了目标值，当前规则的“从某状态流转”条件不再满足；
- 互斥规则：两条规则对同一字段设置了不同的目标值，后执行的规则可能覆盖或冲突；
- 终止类动作：前序规则执行了关闭、归档或锁定操作，记录进入不可编辑状态，后续规则无法再改动；
- 循环触发保护：规则 A 的动作为规则 B 创造了触发条件，B 又反过来触发 A，系统为防止死循环会抑制重复触发，表现为某次执行被跳过。
判定证据是执行日志中的规则命中顺序和动作记录。日志只显示最终结果、不显示中间过程时，可以用简化测试：临时停用可疑的前序规则，用同一条测试记录复跑，观察当前规则是否恢复执行。测试完成后立即恢复原配置，避免影响其他业务。
对象范围：规则作用的对象和当前记录对得上吗
对象范围不匹配时，规则本身配置正确、日志也可能显示规则处于启用状态，但当前记录根本不在规则的作用域内，执行时被直接过滤。这类问题的表现是“规则对某些记录生效、对另一些不生效”，容易误判为偶发故障。
逐项核对以下范围限定：
| 核对项 | 核对内容 | 不匹配时的现象 |
|---|---|---|
| 对象类型 | 规则绑定的对象类型与当前记录的类型是否一致，工作项的具体类型（需求、任务、缺陷等）是否在规则覆盖范围内 | 同项目其他类型记录正常流转，当前类型不动 |
| 状态区间 | 规则的流转起点是否包含记录当前所处状态，目标状态是否在允许的流转路径内 | 记录停在某个特定状态时规则不触发，其他状态正常 |
| 项目与空间范围 | 规则限定的项目、空间、迭代、分组是否覆盖当前记录所在位置 | 部分项目生效、部分项目不生效，新项目尤其容易遗漏 |
| 生效时间与发布状态 | 规则是否已发布到当前环境，生效时间是否已到，是否存在草稿或待发布版本 | 配置界面显示已保存，实际运行环境仍是旧版本 |
核对方法是以当前记录为基准，反向对照规则配置的每一项限定，而不是从规则出发去猜记录。发现不匹配后，处理方向是扩大规则范围或为当前场景单独建规则，两种做法的影响面不同：扩大范围可能让原本不该触发的记录被纳入，需要评估后再改。
权限：触发人、执行人和规则配置权限是否放行
权限不足时，规则可能被触发但动作被静默跳过，日志里只留下一条失败或跳过记录，甚至没有任何提示。这类问题最容易被忽略，因为配置界面通常不校验运行时权限。
需要核对三个主体的权限：
- 触发人：实际执行操作的人是否有权修改规则涉及的目标字段或目标状态。例如规则要把状态改为“已关闭”，但触发人没有关闭权限，动作就会被拒绝；
- 执行人：规则以系统账号或指定角色身份执行动作时，该身份是否具备目标操作权限。系统账号权限被收紧、角色成员变动，都可能导致原本正常的规则失效；
- 配置者：创建和修改规则的人是否有权在该项目或空间内配置自动化规则。权限被回收后，规则可能保留但无法正常维护。
权限不足的线索通常在日志的失败原因里，表现为“无权限”“操作被拒绝”或动作状态为跳过。日志不记录具体原因时，可以用对照法验证：换一个有完整权限的账号，用同样的测试记录复跑同一操作，如果规则正常执行，基本可以定位为权限问题。确认后补齐对应权限，并复查该权限变更是否影响其他规则。
在 ONES 这类研发管理平台中，规则配置、执行日志和权限设置分布在不同的管理入口，排查时需要在规则详情、执行记录和项目权限配置之间来回对照。把四层检查结果记录在同一份排查表中，能减少反复切换配置页面的次数。
改完怎么验证，怎么防止再次失效
确认原因并修改配置后，验证要回到最初那条测试记录，用完全相同的操作路径复跑一次，比对实际结果与期望结果是否一致。只换一条新记录测试不够，因为原记录的状态、字段值和权限上下文才是问题发生的真实条件。
验证时逐项确认：
- 记录状态是否按规则流转到目标状态；
- 规则涉及的字段值是否被正确改写；
- 应发的通知是否送达对应人员；
- 执行日志中是否出现本次规则的命中记录，动作状态是否为成功；
- 同一对象上的其他规则是否仍正常执行，没有被本次修改影响。
验证通过后，把本次原因写入规则说明或团队检查清单，例如“该规则依赖前序规则先执行，调整优先级需同步评估”“新项目接入时需手动把规则范围加入项目列表”。这类说明能让下一位维护者少走一遍排查路径。
复发预防从两个动作入手：对关键流转规则设置定期巡检，按季度或项目里程碑节点核对规则启用状态、作用范围和执行日志中的失败率；对规则的优先级调整、范围扩大、删除等变更执行评审，变更前留快照、变更后跑一条回归测试记录。规则数量较多的团队，可以把四层检查表固化为新规则上线前的自检项，在配置阶段就排除大部分失效风险。
常见问题
执行日志里完全没有这条规则的记录，还需要继续查权限吗？
不需要先查权限。日志无命中记录说明规则在匹配阶段就没有被选中，问题更可能出在触发条件或对象范围。此时应回到触发条件层，用测试记录手动制造一次事件，确认事件类型和字段值是否满足规则设定；若触发条件确认无误，再核对规则绑定的对象类型、状态区间和项目范围是否覆盖当前记录。权限问题通常表现为规则已命中但动作被拒绝或跳过，日志里会留下失败线索，与完全无记录是两种不同现象。
临时停用前序规则来验证执行顺序，会不会影响正在进行的业务？
会有影响，需要控制范围和时间。停用前序规则期间，依赖该规则流转的记录可能停在原状态，因此建议在测试项目或单条测试记录上操作，避开业务高峰，并提前记录原配置快照。验证完成后立即恢复原配置，再用一条正式记录确认前序规则恢复正常。如果无法停用，可以改为查看执行日志中的规则命中顺序，或复制一份规则到测试范围做对照，减少对生产环境的影响。
规则对新建记录不生效、对已有记录正常，最可能是什么原因？
优先核对对象范围和触发条件两处。新建记录的类型、所属项目或状态可能与规则限定的范围不一致，例如规则只覆盖部分工作项类型，或状态区间不包含新建时的初始状态。触发条件方面，新建记录上部分字段尚未填写，若规则要求某字段等于特定值，空值状态下条件不成立。排查时取一条新建记录，对照规则配置逐项核对，再用一条已有记录做对照，确认差异点后再调整范围或条件。
规则修改后需要观察多久才能确认稳定？
没有统一时长，取决于规则的触发频率和业务节奏。基本做法是：修改后用原测试记录复跑一次确认即时生效，再覆盖至少一个完整业务周期，观察执行日志中的命中次数、失败率和是否有其他规则受影响。触发频率低的规则，可以按项目里程碑或季度巡检节点复核。规则数量较多时，把关键规则列入定期巡检清单，比单次观察更可靠。
多条规则同时满足条件时，怎么判断最终执行哪一条？
先看规则列表中的优先级顺序，系统通常按顺序依次匹配，靠前的规则先执行。再看执行日志中实际命中的规则和动作记录，日志显示的命中项才是判定依据。如果前序规则改变了记录状态或字段值，后续规则的条件可能不再成立，表现为只有一条规则生效。需要多条规则共同作用时，要评估它们之间是否存在字段覆盖、状态互斥或终止类动作的冲突，必要时合并规则或调整优先级，而不是让它们并行竞争。
