自动流转规则通常由触发条件、判断条件、执行动作和通知对象四部分组成。本文以缺陷处理流程为演示情景，给出一条填写完整的规则样例，并逐项解释字段选择与易错点，帮助你把同样的结构迁移到需求评审、任务转派等场景。示例可在ONES工作项流程中参照落地，用于理解状态、指派与通知如何衔接。
要点总览（TL;DR）
- 自动流转规则由触发条件、判断条件、执行动作和通知对象四部分组成，四者齐全才能保证规则可触发、结果可预期。
- 演示示例把缺陷修复拆成两条规则：规则A在指派后自动进入“修复中”并写入处理时限，规则B在填写修复说明后自动转“待验证”并指派回原提交人。
- 填写时先改状态、再写关联字段、最后留记录，并配置失败回滚与重复触发防护，避免工作项停在半完成状态。
- 迁移到需求评审、任务转派时保持四要素完整，条件落在取值明确的字段上；需要人工审批、语义判断或跨系统接口对接的环节不交给规则驱动。
示例目标：这条规则要解决什么流转问题
本示例设定一个常见的缺陷处理流程：测试人员提交缺陷单，开发负责人分派修复，开发完成修复后交回测试验证。流程中有两个环节容易因人工操作而延迟：一是缺陷被指派后，开发人员未及时把状态从“待修复”改为“修复中”，导致看板上的进度失真；二是修复完成后，缺陷停留在“修复中”，测试人员不知道可以开始验证。
规则要达成的目标有三个：缺陷进入可修复状态时，自动推进状态并写入处理时限，让责任人和时限同时可见；开发提交修复说明后，自动流转到“待验证”并指派回原提交人，减少口头通知；整个过程留下可追溯的状态变化记录，便于复盘流转耗时。
示例涉及的角色包括测试提交人、开发负责人和测试负责人。涉及的工作项字段包括：状态、严重程度、指派对象、修复说明、处理时限、提交人。规则的输入是缺陷单的字段取值与状态变化事件，期望结果是状态按预定路径推进、责任人正确交接、相关角色收到通知。
需要说明的是，以下内容为演示情景，用于说明规则填写方法，并非真实客户案例，也不代表任何量化效果。
完整示例：一条缺陷自动流转规则的全貌
下面给出这条规则的完整填写样例。为便于参照，将规则拆成两段：规则A负责“待修复→修复中”的推进，规则B负责“修复中→待验证”的交接。两段规则合起来覆盖一次完整的缺陷修复流转。
| 填写项 | 规则A：缺陷进入修复 | 规则B：修复完成交回验证 |
|---|---|---|
| 规则名称 | 缺陷-严重缺陷自动进入修复中 | 缺陷-修复完成自动转待验证 |
| 适用范围 | 缺陷类型工作项，所属项目为当前研发项目 | 同左，仅作用于缺陷类型工作项 |
| 触发事件 | 工作项字段更新事件：指派对象发生变化 | 工作项字段更新事件：修复说明由空变为非空 |
| 触发时机 | 字段更新保存成功后立即执行 | 字段更新保存成功后立即执行 |
| 判断条件 | 状态等于“待修复” 且 严重程度属于“致命、严重” 且 指派对象非空 | 状态等于“修复中” 且 修复说明非空 且 当前处理人为开发侧成员 |
| 执行动作（按顺序） | 1. 状态改为“修复中”；2. 写入处理时限字段；3. 记录一次流转备注 | 1. 状态改为“待验证”；2. 指派对象改为原提交人；3. 记录一次流转备注 |
| 通知对象与内容 | 通知测试负责人：某缺陷已进入修复中，处理时限为某时间 | 通知原提交人：某缺陷已修复，请安排验证 |
| 异常兜底 | 任一动作执行失败则回滚本次变更，保留原状态，并向规则维护人发送失败提醒 | 同左；若原提交人字段为空，则改为通知测试负责人 |
| 重复触发防护 | 同一工作项在10分钟内仅执行一次；状态已为“修复中”时跳过 | 同一工作项在10分钟内仅执行一次；状态已为“待验证”时跳过 |
这张表可以直接作为填写模板使用。规则A解决“指派后状态不推进”的问题，规则B解决“修复后无人知晓”的问题。两条规则都以字段更新为触发点，判断条件都包含状态校验，动作都按“先改状态、再改关联字段、最后留记录”的顺序排列。
逐项解释：每个字段为什么这样填
触发事件选择依据。规则A选择“指派对象变化”而不是“状态变为待修复”，原因是缺陷单创建时可能尚未指派，若以状态为触发点，会在无人负责时提前推进状态。以指派为触发点，能保证规则执行时责任人已经明确。规则B选择“修复说明由空变为非空”，因为修复说明是开发完成修复的直接证据，比手动改状态更可靠。
条件组合的与或关系。规则A的三个条件用“且”连接：状态为待修复、严重程度为致命或严重、指派对象非空。三者同时满足才执行，避免轻微缺陷也触发时限写入。严重程度内部用“或”关系，表示命中任一取值即可。填写时要区分条件之间的“且”和同一字段多值之间的“或”，否则容易出现条件过宽或过窄。
动作顺序对状态一致性的影响。先改状态、再写时限、最后留备注，是因为后续动作依赖状态已经变更。如果先写时限再改状态，中途失败会留下“有时限但状态未变”的不一致数据。把状态变更放在第一步，配合失败回滚，能让工作项始终处于可解释的状态。
通知对象与责任边界。规则A通知测试负责人而非开发本人，因为开发本人是执行者，测试负责人需要掌握修复进度和时限。规则B通知原提交人，因为验证工作由提交缺陷的测试人员承担。通知对象按“谁需要据此行动”来确定，避免把通知发给无关角色造成打扰。
兜底策略的必要性。规则执行可能因字段缺失、权限不足或并发修改而失败。设置失败回滚和提醒，可以防止工作项停在半完成状态。规则B额外处理了原提交人为空的情况，把通知转给测试负责人，保证交接不中断。重复触发防护则针对短时间内多次字段更新，避免状态被反复改写或通知重复发送。
可迁移规律：换一个流程如何套用
从上面的示例可以提炼出一组通用规律，适用于大多数规则驱动的流程流转。
- 四要素结构。任何一条规则都写清触发事件、判断条件、执行动作和通知对象。四者缺一，规则要么无法触发，要么执行结果不可预期。
- 条件粒度与字段可判定性。判断条件应落在取值明确、可被系统判定的字段上，例如枚举型的状态、严重程度、指派对象。自由文本字段适合作为触发信号（如修复说明非空），不适合作为精确匹配条件。
- 动作与状态机一致。动作只能推动状态沿既定路径前进，不跳过中间状态。示例中“待修复→修复中→待验证”是单向路径，规则不承担回退职责，回退由人工操作完成。
- 规则命名与版本维护。名称采用“对象-场景-动作”的结构，便于在规则列表中检索。规则修改后保留版本说明，记录改动原因和生效时间，避免多人维护时相互覆盖。
- 单条规则只做一件事。把“进入修复”和“交回验证”拆成两条规则，比合并成一条更容易排查问题，也便于单独停用。
迁移到需求评审场景时，可以把触发事件改为“评审状态变为待评审”，条件设为“评审类型为技术评审且参与人已齐”，动作改为“状态改为评审中并写入评审截止时间”，通知发给评审发起人。迁移到任务转派场景时，触发事件可设为“指派对象变化”，条件为“任务状态为进行中”，动作包括“更新处理人、写入交接说明”，通知发给原处理人和新处理人。改写时保持四要素完整，条件仍落在可判定字段上。
适用边界：哪些情况不该交给自动流转
规则驱动适合路径固定、判断依据明确的流转环节。以下情况需要谨慎，或应交由人工处理。
| 情况 | 建议处理方式 |
|---|---|
| 需要人工判断或审批的节点，如缺陷是否关闭、需求是否上线 | 保留人工审批，规则只负责把工作项送到审批人面前并通知 |
| 条件字段缺失或取值不稳定，如严重程度经常留空、指派人频繁变动 | 先补齐字段规范和数据填写要求，再配置规则；否则规则会频繁跳过或误触发 |
| 需要根据内容语义做判断的环节，如自动归类缺陷原因 | 属于智能编排与自动化决策的范畴，本文不展开；规则驱动只处理取值明确的字段判断 |
| 跨系统的数据同步与接口对接 | 属于接口对接与集成实施范围，不在本文讨论 |
规则上线后需要观察一段时间。重点关注三类信号：规则触发次数是否符合预期、失败提醒是否频繁出现、状态是否出现跳级或停滞。若发现条件过宽导致误触发，先收窄条件；若发现兜底提醒集中出现，检查字段填写规范。调整规则时保留旧版本记录，便于对比效果。
在ONES中落地这条规则的协作路径
把示例放到ONES的工作项流程中，可以按角色和动作串成一条协作路径。首先由项目管理员在缺陷工作项上设置状态集合，至少包含“待修复、修复中、待验证”三个状态，并配置严重程度、指派对象、修复说明、处理时限等字段，字段类型与示例中的判定需求对应。
规则配置完成后，测试人员提交缺陷并指派给开发负责人，字段更新触发规则A，工作项状态变为“修复中”，处理时限写入，测试负责人收到通知。开发完成修复并填写修复说明，触发规则B，状态变为“待验证”，指派回原提交人，原提交人收到验证提醒。评审与交接环节通过通知和状态变化完成，相关人员在工作项上查看流转备注，了解每次变更的时间和原因。
结果追溯依赖工作项的状态变化记录和规则执行记录。团队可以在复盘时查看缺陷从提交到验证的流转路径，识别停留时间较长的环节，再决定是否调整规则条件或时限设置。这样，示例中的规则设计就转化为ONES中可执行、可观察的协作流程。
常见问题
规则A和规则B能不能合并成一条规则？
可以合并，但排查和停用会更麻烦。两条规则的触发事件不同：规则A以指派对象变化为触发点，规则B以修复说明由空变为非空为触发点。合并后需要在一条规则里区分两种触发来源，条件组合变复杂，一旦某次流转异常，很难判断是哪段逻辑出了问题。建议按“单条规则只做一件事”拆分，需要整体停用时再统一处理。
严重程度字段经常留空，规则还能正常执行吗？
规则A的判断条件要求严重程度属于“致命、严重”，字段留空时条件不成立，规则会跳过，缺陷不会自动进入修复中。这种情况下先补齐字段填写规范，把严重程度设为必填或给出默认值，再配置规则。条件字段取值不稳定时，规则会频繁跳过或误触发，调整字段规范比反复修改规则更有效。
规则执行失败后，工作项会停在什么状态？
示例中设置了失败回滚：任一动作执行失败，本次变更整体回滚，工作项保留原状态，同时向规则维护人发送失败提醒。这样工作项不会出现“状态已改但时限未写”的半完成情况。收到提醒后，维护人需要检查失败原因，常见的是字段缺失、权限不足或并发修改，处理完再让规则重新触发。
重复触发防护的时间窗口怎么定？
示例取10分钟，目的是覆盖短时间内多次字段更新，比如指派人连续调整、修复说明反复编辑。窗口太短，防护效果有限；窗口太长，正常的二次流转可能被误挡。可以先按团队实际操作节奏设定一个初始值，上线后观察触发记录，若发现正常流转被跳过就缩短窗口，若发现重复通知较多就适当延长。
规则上线后，怎么判断该收窄还是放宽条件？
看两类信号：规则触发次数与预期是否一致，失败提醒是否集中出现。触发次数明显偏多，通常是条件过宽，比如严重程度范围设得太大，应收窄条件；触发次数偏少且失败提醒频繁，多半是字段填写不规范或权限配置有问题，应先修数据再调规则。调整时保留旧版本记录，便于对比调整前后的流转情况。
