自动流转规则通常由触发条件、判断条件、执行动作和异常处理四部分组成。本文用一个缺陷单流转的演示情景，完整填写一份规则配置，演示状态变更后如何自动分派处理人、同步关联需求并记录异常，再逐项说明字段取值理由和换场景时的改写方法。示例为演示情景，非真实客户案例。ONES 工作项规则可承载这类状态流转与分派动作，下文在相应环节自然衔接。
要点总览（TL;DR）
- 自动流转规则由触发条件、判断条件、执行动作和异常处理四部分组成，缺一项规则就容易误触发或中断后无从排查。
- 示例以缺陷单状态由“待处理”变为“处理中”为触发，仅对致命和严重缺陷自动分派处理人，并同步关联需求状态、写入流转记录。
- 异常分支按“能降级则降级、不能降级则留痕”设计：负责人为空时改派测试负责人，关联需求缺失时记录后继续，执行失败时保留原状态。
- 换场景时保持“对象+事件→条件→动作序列→异常兜底”的结构，替换具体取值即可，例如需求评审通过后转为待开发。
- 判断条件无法写成明确字段比较、动作涉及跨系统写入或需要模型决定路径时，应保留人工环节或归入其他主题处理。
示例目标：这条规则要解决什么问题
先设定一个具体情景：某研发团队在缺陷管理中发现，缺陷单从“待处理”进入“处理中”之后，处理人经常需要手工确认两件事——这条缺陷该由谁跟进，以及它关联的需求是否要同步标记为受阻。手工操作容易漏，漏了之后又很难回溯是谁在什么时候改的状态。本示例要配置一条规则，把这三个动作串起来。
这条规则要达成三个目标：
- 自动分派：缺陷单进入“处理中”时，按严重程度决定是否立即指定处理人，减少等待分派的时间。
- 跨对象同步：缺陷单关联了需求时，把需求状态同步为“受阻”，让需求负责人看到下游问题。
- 异常留痕：当处理人无法确定或关联需求缺失时，不静默跳过，而是写入一条流转记录，供后续人工处理。
规则范围限定在缺陷单这一种工作项类型，只响应状态变更事件。本文不涉及接口对接、跨系统数据同步，也不讨论由模型自动生成规则逻辑的智能编排方式。读者看完后，应能照着表格填出一份结构相同的规则，并理解每个字段为什么这样取值。
完整示例：一条缺陷单自动流转规则
下表是一份填写完成的规则配置。字段名称采用通用命名，便于对照不同工具的配置界面理解结构；实际填写时以所用工具的字段命名为准。
| 配置项 | 填写内容 | 说明 |
|---|---|---|
| 规则名称 | 缺陷进入处理中-分派并同步需求 | 名称包含触发事件和主要动作，便于在规则列表中识别 |
| 适用对象 | 缺陷单 | 只对缺陷单生效，不影响需求、任务等其他类型 |
| 启用状态 | 启用 | 配置完成后开启；调试阶段可先设为停用 |
| 触发条件 | 缺陷单状态由“待处理”变更为“处理中” | 监听状态字段的变更事件，并限定变更前后的具体值 |
| 判断条件 | 严重程度 属于 {致命, 严重} | 只有高严重程度缺陷才走自动分派，一般缺陷保留人工判断 |
| 执行动作 1 | 将处理人设置为缺陷所属模块的负责人 | 先确定责任人，后续通知和记录都依赖这个字段 |
| 执行动作 2 | 若存在关联需求，将关联需求状态更新为“受阻” | 跨对象写入，依赖动作 1 已完成、上下文已确定 |
| 执行动作 3 | 写入流转记录：规则名称、触发时间、执行结果 | 无论成功或进入异常分支都记录，形成可追溯轨迹 |
| 异常分支 A | 模块负责人为空 → 跳过动作 1，将缺陷指派给测试负责人，并记录“处理人待确认” | 避免缺陷停留在无人负责的状态 |
| 异常分支 B | 关联需求缺失 → 跳过动作 2，记录“无关联需求，未同步” | 关联对象不存在属于正常情况，记录即可，不视为失败 |
| 异常分支 C | 动作执行失败 → 记录失败原因，保留缺陷原状态，不重复触发 | 防止规则反复执行造成状态抖动 |
这份配置的关键在于：触发条件决定规则何时被唤起，判断条件决定是否继续执行，执行动作按依赖顺序排列，异常分支覆盖每个动作可能落空的情况。四部分缺一，规则要么误触发，要么执行到一半中断且无从排查。
逐项解释：每个字段为什么这样填
触发条件为什么选状态变更
缺陷单在创建时信息往往不完整，严重程度、所属模块可能还没填，此时触发分派容易分错人。选择“状态由待处理变为处理中”作为触发点，意味着有人已经确认这条缺陷需要处理，上下文相对完整。触发条件同时限定了变更前后的值，避免缺陷从其他状态跳回“处理中”时被重复触发。如果只写“状态等于处理中”，规则会在每次保存时都可能命中，产生重复执行。
判断条件为什么限定严重程度
自动分派的价值在于缩短高优先级缺陷的响应时间。致命和严重缺陷通常需要立即有人接手，而一般和轻微缺陷可以由测试或模块负责人按排期处理，保留人工判断空间。把判断条件收紧到两个严重程度，规则覆盖面变小，但误分派带来的返工也少。如果团队缺陷量不大、模块负责人划分清晰，也可以去掉这个条件，让所有进入处理中的缺陷都自动分派，代价是需要更可靠的负责人映射关系。
执行动作的顺序与依赖
三个动作有明确的先后关系。动作 1 确定处理人，是后续通知和记录的基础；动作 2 写关联需求，依赖缺陷单已经处于有效处理上下文；动作 3 写流转记录，放在最后，才能把前两个动作的执行结果一并记下。如果顺序颠倒，记录里就缺少处理人信息，排查时无法判断当时分派给了谁。配置时把有依赖的动作排在前面，是规则可维护的基本要求。
异常分支的兜底设计
异常分支不是可选项。处理人为空、关联需求缺失、动作执行失败，这三种情况在真实数据里都会出现。兜底设计的原则是：能降级的降级，不能降级的留痕。负责人为空时降级指派给测试负责人，保证缺陷有人看；关联需求缺失时记录后继续，因为这不是错误；动作执行失败时保留原状态并记录原因，避免规则与人工操作互相覆盖。每个分支都要有对应的记录内容，否则异常发生了也无从发现。
常见填写错误与修正
- 触发条件只写目标状态，不写来源状态：改为限定“由某状态变更为某状态”，减少重复触发。
- 判断条件用模糊描述，如“严重程度较高”：改为枚举具体值，规则才能稳定判断。
- 动作顺序随意排列：按依赖关系重排，先确定对象字段，再做跨对象写入，最后记录。
- 异常分支只写“忽略”：改为“跳过并记录”，保留可追溯信息。
- 规则名称过于笼统，如“缺陷规则1”：改为包含触发事件和动作的命名，方便日后维护。
在 ONES 中承载这类规则时，状态变更、字段判断、分派与记录对应的是工作项规则里的触发、条件与动作配置；具体字段名称和配置入口以实际界面为准。规则执行后留下的流转记录，也为上面提到的异常排查提供了依据。
可迁移规律：换一个场景怎么改
把上面的示例抽象一层，可以得到一个通用结构：对象 + 事件 → 条件 → 动作序列 → 异常兜底。换场景时，只需要替换这四部分中的具体取值，结构保持不变。
按对象和事件替换触发条件，是最直接的改法。缺陷单对应“状态变更”，需求可以对应“评审状态变更”，任务可以对应“完成时间变更”。先确定要监听哪个对象的哪个字段，再确定字段从什么值变到什么值，触发条件就写好了。判断条件则回答“哪些情况值得自动处理”，通常用枚举字段收窄范围，比如需求类型、优先级、所属项目。
条件收紧与动作拆分需要权衡。条件越严，规则越安全但覆盖越窄；动作越多，单条规则越省事但失败点也越多。经验做法是：一条规则只做一件有明确结果的事，跨对象的写入单独成条，通过触发条件串联。这样某条规则出问题时，影响范围可控。
下面是一个变体示例：需求评审通过后自动流转。
| 配置项 | 填写内容 |
|---|---|
| 规则名称 | 需求评审通过-转开发并通知负责人 |
| 适用对象 | 需求 |
| 触发条件 | 需求评审状态由“评审中”变更为“已通过” |
| 判断条件 | 需求类型 属于 {产品需求, 技术需求} |
| 执行动作 1 | 将需求状态更新为“待开发” |
| 执行动作 2 | 将处理人设置为需求负责人 |
| 执行动作 3 | 写入流转记录：评审结论、通过时间、执行结果 |
| 异常分支 | 负责人为空 → 指派给项目负责人并记录；评审结论缺失 → 保留原状态并记录 |
规则上线后还需要维护。建议为每条规则保留版本记录：记录修改时间、修改人、改动内容，停用旧版本前先观察新版本的执行记录。规则数量增长后，按对象或业务环节分组命名，定期清理长期未触发的规则，避免规则列表变成无人能读懂的配置堆积。
适用边界：哪些情况不该用自动流转
自动流转适合判断条件能写成明确枚举值、执行动作有确定结果的场景。以下情况需要谨慎或改由人工处理：
| 情况 | 是否适合自动流转 | 原因与替代做法 |
|---|---|---|
| 判断依据是明确字段值，如严重程度、需求类型 | 适合 | 条件可稳定判断，执行结果可预期 |
| 判断依据需要综合多份文档或主观评估 | 不适合 | 条件无法确定化，规则会频繁误判；改为人工评审后触发 |
| 动作涉及跨系统写入，如同步到外部工单系统 | 不在本文范围 | 需要接口对接与失败重试设计，属于集成话题 |
| 希望由模型根据内容自动决定流转路径 | 不在本文范围 | 属于智能编排话题，与规则驱动的确定性流转是两种思路 |
| 规则数量持续增长、多人各自配置 | 需评估维护成本 | 规则之间可能互相触发或冲突，应建立命名规范、分组和定期审查机制 |
判断一条流程是否该自动化，可以先问三个问题：触发事件是否单一且可识别，判断条件是否能写成字段比较，执行结果是否能在系统内验证。三个问题都能明确回答，规则就值得配置；有一个含糊，就先保留人工环节，等流程稳定后再收紧条件。规则数量增长后，维护成本会从配置工作转移到排查和治理上，这时更需要版本记录和定期清理，而不是继续叠加新规则。
常见问题
触发条件只写“状态等于处理中”会有什么问题？
只限定目标状态，规则在每次保存缺陷单时都可能命中，包括从其他状态跳回“处理中”的情况，容易造成重复分派和重复记录。更稳妥的写法是同时限定来源状态和目标状态，即“由待处理变更为处理中”，让规则只在一次明确的状态迁移时执行。如果工具支持记录上次执行时间或去重机制，也可以作为补充，但触发条件本身写清楚是第一步。
判断条件收紧后漏掉了部分缺陷，应该放宽还是另建一条规则？
先看漏掉的是哪类缺陷。如果是一般和轻微缺陷，保留人工判断通常更合适，因为自动分派依赖可靠的负责人映射，映射不准时返工成本高于节省的时间。如果漏掉的是某类严重缺陷，例如特定模块的致命问题，建议另建一条规则单独处理，而不是放宽原规则的条件。一条规则只覆盖一类明确场景，出问题时影响范围可控，排查也更容易。
关联需求缺失时，规则应该报错还是静默跳过？
两种都不理想。报错会让规则执行失败，缺陷单可能停留在中间状态；静默跳过则丢失了“当时没有关联需求”这一信息，后续排查时无法区分是规则没执行还是确实没有关联对象。推荐的做法是跳过同步动作，同时写入一条流转记录，说明关联需求缺失、未执行同步。这样缺陷单继续正常流转，追溯时也能看到完整轨迹。
规则上线后修改了字段或状态值，旧规则会怎样？
这取决于工具的规则解析方式，没有统一答案。稳妥的做法是在修改字段枚举值或状态名称前，先梳理哪些规则引用了这些值，逐条确认是否需要同步调整。建议为每条规则保留版本记录，写明修改时间、修改人和改动内容；新版本启用后先观察一段时间的执行记录，确认触发和动作都符合预期，再停用旧版本。规则数量较多时，按对象或业务环节分组命名，定期清理长期未触发的规则。
一条规则里放多个动作，还是拆成多条规则？
看动作之间是否存在依赖。像“先确定处理人、再同步关联需求、最后写记录”这种有先后依赖的动作，放在同一条规则里更容易保证顺序和上下文一致。如果动作彼此独立，例如分别通知两个不同角色，拆成多条规则更利于单独排查和停用。拆分后可以通过触发条件串联，让后一条规则监听前一条规则产生的状态变化，但要注意避免形成循环触发。
