规则保存成功只说明配置被写入，流程是否按预期流转还要看触发、执行、范围和权限是否同时成立。排查时先用一条测试工作项复现问题，记录规则有没有被触发、触发了哪条、是否被其他规则覆盖、在哪一步被拦截，再按“触发条件—执行顺序—对象范围—权限与状态”四条线索逐项验证。本文围绕规则驱动的流程展开，ONES 的自动化规则配置与运行日志可作为排查入口，AI 智能编排和接口对接问题不在讨论范围内。
要点总览（TL;DR）
- 规则保存成功只代表配置写入，流程是否流转取决于触发条件、执行顺序、对象范围、权限与状态是否同时成立。
- 排查顺序固定为：先确认规则是否被触发，再确认是否被其他规则覆盖，最后确认是否在范围或权限环节被拦截。
- 每条原因假设都要有规则命中记录、状态变更记录或测试工作项字段变化作为证据，确认后再改配置，改一处验一处。
- 修正后验证通过的标准是规则命中记录、状态变更记录与动作结果三者一致，并覆盖正常路径和边界条件。
- 把规则配置纳入变更评审、保留修改记录、上线前用测试工作项验证，可减少同类问题再次出现。
症状与范围：先界定“未按预期流转”具体指什么
“没生效”这个描述太笼统，直接开始改配置容易改错地方。先把现象拆成可观察的四类，每类对应的排查方向不同，记录清楚才能判断问题出在配置、执行还是权限环节。
| 症状类型 | 可观察现象 | 初步指向 |
|---|---|---|
| 规则完全未触发 | 规则命中记录中没有该条规则的执行痕迹，工作项状态和字段均未变化 | 触发条件、规则启用状态、对象范围 |
| 触发了但动作未执行 | 有命中记录，但目标动作没有发生，如状态未迁移、负责人未变更 | 动作配置、执行权限、必填字段阻断 |
| 执行了但结果与预期不同 | 动作发生了，结果值或目标对象与设计不一致 | 动作参数、多条规则覆盖、字段取值来源 |
| 只在部分工作项上失效 | 同类操作在部分项目、工作项类型或操作人下正常，另一些失效 | 对象范围、角色权限、状态机差异 |
确定症状类型后，固定复现条件：使用同一工作项类型、从同一状态出发、由同一操作人执行同一操作，并尽量控制在同一时间窗口内。复现时记录工作项编号、操作时间、操作人和操作前后的字段值，这些信息是后续比对规则命中记录的基础。如果换一个操作人或换一个项目就恢复正常，说明问题更可能出在范围或权限，而不是规则逻辑本身。
还需要确认问题是否稳定复现。偶发失效要留意是否存在并发操作、定时触发的时间差或多人同时修改配置的情况。把复现条件和症状类型整理成一张记录表，后续每验证一条原因假设，都在表上补充证据和结论，避免凭印象判断。
原因假设与排除证据：四条线索逐项验证
排查顺序建议固定为：先确认规则是否被触发，再确认是否被其他规则覆盖，最后确认是否在范围和权限环节被拦截。这个顺序的依据是，未触发时后面的检查都没有意义；已触发但结果不对，才需要看覆盖和拦截。每验证一条假设，都要有规则命中记录、状态变更记录或测试工作项的字段变化作为证据，确认后再动配置。
线索一：触发条件是否命中
触发条件是规则生效的第一道门。核对事件类型是否匹配，例如配置的是“状态变更时触发”，实际操作却是“字段更新”；核对字段条件是否满足，例如规则要求“优先级为高”才执行，测试工作项的优先级实际为中；核对状态迁移方向是否一致，从“进行中”到“已完成”和从“待处理”到“进行中”是不同的事件。验证方法是查看规则命中记录中该条规则是否出现，或用一条满足全部条件的最小测试工作项单独触发一次。命中记录为空，问题基本锁定在触发条件或规则启用状态。
线索二：执行顺序是否被覆盖
多条规则同时命中同一工作项时，后执行的规则可能改写前一条的结果。典型表现是规则 A 把状态改为“已完成”，规则 B 随后又把状态改回“进行中”，或者两条规则分别设置负责人，最终留下的是后一条的值。验证方法是列出当前工作项类型和项目下所有可能命中的规则，对照命中记录中的执行顺序，看结果值是否由另一条规则写入。如果两条规则的条件高度重叠、动作互相冲突，就属于配置层面的覆盖问题，需要在修正阶段处理。
线索三：对象范围是否包含当前工作项
规则适用范围通常按项目、工作项类型、字段范围限定。保存成功但流程不动，常见原因是规则只配置在某个项目或某类工作项上，而测试对象不在范围内。核对时把规则的适用范围与当前工作项的项目、类型、字段逐项比对，特别留意复制项目或新建工作项类型后范围没有同步更新。范围遗漏的表现往往是“部分工作项失效”，与症状分类中的第四类对应。
线索四：权限与状态是否放行
规则被触发、也没有被覆盖，动作仍可能执行失败。检查操作人是否具备执行该动作的权限，例如修改状态、变更负责人、编辑某字段的权限；检查当前状态是否允许目标迁移，状态机中未配置的迁移路径会直接阻断；检查是否存在必填字段未填写导致动作无法完成。这类问题的证据通常在动作执行失败记录或工作项上缺失的字段值中，表现为“有命中记录但结果未变化”。
| 排查顺序 | 原因假设 | 验证证据 | 典型表现 |
|---|---|---|---|
| 第一步 | 触发条件未命中 | 规则命中记录为空；最小测试工作项单独触发仍无记录 | 规则完全未触发 |
| 第二步 | 被其他规则覆盖 | 命中记录显示多条规则先后执行，结果值由后一条写入 | 执行了但结果与预期不同 |
| 第三步 | 对象范围遗漏 | 规则适用范围与工作项的项目、类型、字段比对不一致 | 只在部分工作项上失效 |
| 第四步 | 权限或状态阻断 | 有命中记录但动作失败；状态机无对应迁移；必填字段为空 | 触发了但动作未执行 |
四条线索验证完毕后，通常能定位到一个或两个具体原因。如果多条线索同时存在问题，按上述顺序逐条修正并逐条验证，不要一次改完再统一测试，否则无法判断是哪一处改动起了作用。
处置步骤：按验证结果修正配置
修正动作对应已确认的原因，改一处、验一处。涉及范围扩大、权限调整和规则删除的操作，先备份原配置并确认影响面，再执行修改。
触发条件不符
根据验证结果修正事件类型、字段条件或状态迁移方向，保存后用同一条测试工作项重新触发。重新触发前确认工作项处于规则要求的起始状态，必要时先回退状态再操作。修正后命中记录中应出现该条规则的执行痕迹，这是触发条件恢复的直接证据。
顺序冲突
处理方式有两种：调整规则优先级，让期望的结果最后写入；或合并条件重叠、动作重复的规则，减少同时命中的数量。改动前记录原规则的触发条件、动作和顺序，保留回退依据。合并规则时要确认合并后的条件覆盖原来两条规则的全部场景，避免修好一处、漏掉另一处。
范围遗漏
补齐规则适用的项目、工作项类型或字段范围。扩大范围会影响范围内所有工作项，修改前先评估新增范围内是否已有其他规则在跑，避免扩大后产生新的覆盖冲突。如果只是个别工作项类型需要纳入，优先按类型精确补充，不做全项目放开。
权限或状态阻断
权限问题调整对应角色的动作权限，状态问题在状态机中补充允许的迁移路径，必填字段问题补齐字段值或调整规则的赋值动作。权限变更影响面较大，修改前确认该角色下的其他成员是否会因此获得额外操作能力，必要时先在小范围角色上验证。所有破坏性操作，包括删除规则、重置状态机、批量调整权限，执行前备份原配置，并明确回退方式和回退责任人。
验证与复发预防：确认恢复并减少再次失效
修正完成不等于问题解决，需要用覆盖典型场景的测试工作项走完整流程。验证通过的标准是三项记录一致：规则命中记录显示规则按预期触发和执行，状态变更记录显示工作项状态按设计迁移，通知或动作结果与配置目标一致。三项中任何一项对不上，说明还有未排除的原因，回到对应线索继续查。
验证范围至少覆盖：正常路径一次、边界条件一次（如必填字段为空、状态不允许迁移）、以及此前失效的那类工作项。边界条件验证能提前暴露权限和状态机的遗留问题，避免上线后再次出现同类故障。
复发预防落在配置管理上。规则变更保留修改记录，写清修改人、修改内容和修改原因，便于下次排查时对照时间线；规则上线前用测试工作项验证，不直接在生产项目上试；定期检查规则优先级和范围重叠情况，尤其是项目复制、工作项类型新增之后。把规则配置纳入变更评审，多人协作时由一人统一提交修改，减少同时编辑造成的冲突和覆盖。
在 ONES 中，自动化规则提供统一的配置管理入口和运行日志，规则是否触发、执行到哪一步可以在日志中对照查看，适合把上述验证动作固化为日常检查。规则模板覆盖状态联动、负责人自动分配等常见场景，新建规则时可从模板起步再按项目调整，减少从零配置带来的条件遗漏。日志的具体字段和保留方式以实际界面为准，排查时以界面记录为证据。
常见问题
规则命中记录为空，是否就能确定是触发条件配置错了？
命中记录为空说明规则没有被触发，但原因不一定只在触发条件本身。需要同时核对三件事：规则是否处于启用状态；事件类型、字段条件和状态迁移方向是否与实际操作一致；当前工作项是否落在规则的对象范围内。范围外的规则同样不会产生命中记录。验证方法是用一条满足全部条件的最小测试工作项单独触发一次，如果仍无记录，再逐项比对条件配置。
多条规则同时命中时，怎么判断最终结果是被哪条规则写入的？
先列出当前项目和工作项类型下所有可能命中的规则，对照命中记录中的执行先后顺序，看结果值是否由后执行的那条规则写入。典型表现是规则 A 把状态改为“已完成”，规则 B 随后又改回“进行中”，或两条规则分别设置负责人、最终留下后一条的值。如果两条规则条件高度重叠、动作互相冲突，就属于配置层面的覆盖问题，需要在修正阶段调整优先级或合并规则。
权限和状态机问题为什么表现为“有命中记录但结果没变化”？
规则被触发、也没有被其他规则覆盖，动作仍可能执行失败。操作人缺少修改状态、变更负责人或编辑某字段的权限，状态机中没有配置目标迁移路径，或者存在必填字段未填写，都会让动作在最后一步被阻断。这类情况的证据通常在动作执行失败记录或工作项上缺失的字段值中。排查时先确认操作人权限，再核对状态机迁移路径，最后检查必填字段。
扩大规则适用范围时需要注意什么？
扩大范围会影响范围内所有工作项，修改前先评估新增范围内是否已有其他规则在运行，避免扩大后产生新的覆盖冲突。如果只是个别工作项类型需要纳入，优先按类型精确补充，不做全项目放开。修改前备份原配置，修改后用新增范围内的测试工作项验证一次，确认没有触发意外的规则联动。
偶发失效、换个人操作就正常，应该优先查哪里？
这类现象更可能出在范围或权限环节，而不是规则逻辑本身。先确认失效时的工作项是否在规则适用范围内，再核对操作人的角色权限是否允许执行对应动作。同时留意是否存在并发操作、定时触发的时间差或多人同时修改配置的情况。建议固定复现条件：同一工作项类型、同一状态、同一操作人、同一时间窗口，记录工作项编号和操作前后字段值，再与命中记录比对。
