自动化触发条件通常由四部分组成：事件源、判断条件、生效范围和执行动作，必要时再加例外与排除条件。本文用一组虚构研发团队的填写样例，演示状态变更、字段变更、定时和关联事件四类触发条件怎么写，并逐项解释字段选择理由，方便你改造成自己的规则。文中团队、项目与工作项均为示例情景，不是真实客户案例。
要点总览（TL;DR）
- 自动化触发条件由事件源、判断条件、生效范围和执行动作四部分组成，必要时补充例外与排除条件。
- 示例覆盖状态流转、字段变更、定时检查和关联事件回写四类场景，每条规则按五栏填写，可直接对照改造。
- 条件设计宜先窄后宽：先限定项目、工作项类型、迭代和具体字段值，观察误触发与漏触发后再放宽。
- 规则上线前先以只记录不执行的方式试运行，核对触发记录后再正式启用。
- 需要人工评审、跨系统接口对接或智能判断编排的环节，不适合用规则触发条件硬套。
示例目标：一份能直接套用的触发条件
这篇示例要解决一个具体问题：拿到“状态变了就自动通知”这类模糊描述时，怎么把它写成一条可以配置、可以检查、可以复用的规则。示例覆盖四类常见触发场景，每类给出一条完整填写样例，读者可以对照自己流程中的节点，替换字段值和动作对象。
四类场景分别是：状态流转触发，对应工作项从一个阶段进入下一个阶段；字段变更触发，对应严重程度、优先级等关键属性被修改；定时触发，对应按时间点或周期检查遗留事项；关联事件触发，对应提交记录、关联工作项等外部动作发生后回写状态。这四类基本覆盖了研发流程中规则驱动自动化的常见入口。
示例的假设前提如下，读者套用时需要替换成自己的实际对象：
- 虚构团队：一个约十人的产品研发小组，按迭代推进需求与缺陷。
- 虚构项目：项目名为“示例项目”，下设需求、任务、缺陷三类工作项。
- 虚构角色：开发负责人、测试负责人、项目管理员各一名，均为演示角色。
- 虚构字段：状态（待处理、开发中、待测试、测试中、已完成）、严重程度（一般、严重、致命）、所属迭代、负责人、协作者。
需要说明的是，以下内容为演示情景，用于说明填写方式，不代表任何真实客户的身份、配置或效果数据。示例中的规则名称、字段值和动作描述都可以按自身流程调整。
完整示例：四条触发条件的填写样例
每条规则按“事件源—判断条件—生效范围—执行动作—例外”五栏填写。先看整体样例表，再逐条说明填写要点。
| 规则名称 | 事件源 | 判断条件 | 生效范围 | 执行动作 | 例外 |
|---|---|---|---|---|---|
| 开发完成转测试 | 工作项状态变更 | 状态由“开发中”变为“待测试” | 示例项目；工作项类型为需求、任务；所属迭代为当前迭代 | 将测试负责人加入协作者；创建一条“执行测试”子任务并指派给测试负责人 | 工作项带有“无需测试”标签时不触发 |
| 致命缺陷升级响应 | 工作项字段变更 | 严重程度字段由其他值变为“致命” | 示例项目；工作项类型为缺陷；状态不为“已完成” | 通知开发负责人与项目管理员；将缺陷优先级置为最高；在评论区写入升级说明 | 同一工作项 24 小时内已触发过升级时不重复通知 |
| 迭代收尾缺陷提醒 | 定时触发 | 迭代结束日前 2 天，每天 10:00 检查 | 示例项目；当前迭代；工作项类型为缺陷；状态不为“已完成” | 向缺陷负责人发送待办提醒，汇总未关闭缺陷数量写入迭代说明文档 | 缺陷已标记“延期处理”时只记录不提醒 |
| 提交后回写状态 | 关联事件：代码提交关联工作项 | 提交信息中关联了工作项编号，且该工作项状态为“开发中” | 示例项目；工作项类型为需求、任务 | 将工作项状态改为“待测试”；在评论区记录提交人与提交时间 | 提交被标记为回滚或撤销时不回写 |
第一条规则的动作包含两个结果：加人和建任务。填写时要把“谁被加入”“任务指派给谁”写清楚，避免只写“通知测试”这类无法执行的动作。第二条规则用“状态不为已完成”收窄范围，防止已关闭的缺陷被重新拉起。第三条规则的时间点写成“结束日前 2 天、每天 10:00”，比“临近结束时提醒”更容易核对是否按预期执行。第四条规则把回写条件绑定在“开发中”状态上，避免已进入测试或已完成的工作项被提交记录改回待测试。
逐项解释：每个字段为什么这样填
样例能直接套用的前提，是每个字段都有明确的选择理由。下面按字段拆开说明。
事件源：为什么选状态变更而不是手动触发
状态变更是一个客观发生的动作，工作项一旦流转就会产生事件，不依赖某个人记得去点按钮。手动触发适合低频、需要人为判断时机的操作，比如临时发起一次评审；流程节点的推进则更适合用状态变更作为事件源，因为触发时机与流程动作天然对齐。字段变更、定时、关联事件三类事件源同理，选择依据是“这件事在流程中由谁、在什么时刻自然发生”。
判断条件：比较值与多条件组合
判断条件要写成“字段＋比较值”的形式，例如“状态由开发中变为待测试”，同时写明变更前后的值，避免只写“状态变为待测试”而把从任何状态进入待测试的情况都纳入。多个条件之间用“且”组合时，每增加一个条件都会收窄触发面，代价是可能漏掉合理场景；用“或”组合则扩大触发面，容易误触发。示例中“所属迭代为当前迭代”就是一个收窄条件，把历史迭代中的同类流转排除在外。
生效范围：项目、类型、迭代的收窄作用
生效范围决定规则对哪些对象起作用。限定项目可以隔离不同业务的流程差异；限定工作项类型可以避免需求、缺陷共用同一套动作；限定迭代可以把规则约束在当前周期内。三者叠加后，规则的作用面从“全系统所有工作项”缩小到“当前迭代内的需求与任务”，误触发概率显著下降。范围过宽是规则上线后最常见的问题来源。
执行动作与通知对象的对应关系
动作要写清对象和结果：改哪个字段、改成什么值、把谁加入哪个角色、创建什么类型的工作项并指派给谁、通知发给哪个角色。通知对象应与责任归属一致，例如测试任务的通知发给测试负责人，升级通知发给开发负责人和管理员。动作写成“通知相关人”这类描述，执行时无法判断是否达成预期。
例外与排除条件的作用
例外条件处理流程中的合理特例：带“无需测试”标签的工作项不建测试任务，已标记延期的缺陷只记录不提醒，回滚提交不回写状态。例外写得越具体，规则在真实流程中的可用性越高。例外不宜过多，超过三四个例外时，通常说明判断条件本身需要重新拆分。
在规则落地环节，这类“状态流转后加人、建任务、发通知”的动作，可以借助 ONES 工作项的状态与字段变更、协作者与通知机制来承载，把上面表格中的判断条件和动作对应到具体配置项。具体支持的事件与动作类型以所用环境的实际配置为准。
可迁移规律：从示例到自己的规则
把示例改成自己的规则，可以按以下顺序操作，每一步都有可检查的产物。
- 从流程节点反推触发时机。先画出当前流程的关键节点，标出每个节点“谁在什么条件下把工作项推进到下一步”，这些推进动作就是候选事件源。产物是一张“节点—动作—事件源”对照表。
- 条件先窄后宽。第一版规则把项目、工作项类型、迭代、字段值都限定到最具体的范围，上线观察一段时间后，再根据漏触发记录逐项放宽。产物是每轮调整前后的条件对照。
- 动作与责任人、状态字段绑定。每个动作都要落到具体角色和具体字段值上，例如“把测试负责人加入协作者”“状态改为待测试”。产物是动作清单，每条都能回答“改什么、给谁”。
- 规则命名与描述保持可读。名称用“场景＋动作”的结构，如“开发完成转测试”；描述里写清触发条件、作用范围和例外，让后来维护的人不看配置也能理解意图。产物是规则清单文档。
- 上线前试运行并观察。先以只记录不执行的方式运行一段时间，核对触发记录是否符合预期，重点看误触发和漏触发两类情况，确认后再正式启用。产物是试运行期间的触发记录与调整结论。
这套顺序的核心是先控制影响面，再逐步扩大。规则数量增加后，建议按项目或流程阶段分组管理，并定期清理长期未触发的规则，避免维护成本随规则数量线性上升。
适用边界：哪些情况不适合用触发条件
规则驱动的触发条件适合判断标准明确、动作可枚举的流程环节。以下情况需要谨慎或改用其他方式。
- 需要人工评审或多角色协商的环节。例如方案评审、发布审批，结论取决于讨论内容而非字段值，用触发条件只能做到“发起评审”，评审结论仍应由人给出。
- 涉及跨系统接口对接的场景。与外部系统交换数据、同步状态属于集成配置范畴，触发条件本身不解决接口协议、鉴权和失败重试问题，这类需求应归入集成方案设计。
- 需要智能判断与动态编排的场景。例如根据缺陷描述自动判断影响范围、动态决定后续处理路径，依赖的是智能编排能力，规则条件难以穷举，不宜用触发条件硬套。
- 规则过多带来的维护风险。同一事件上挂多条规则时，容易出现动作重复执行或相互覆盖。建议控制单事件规则数量，合并动作相近的规则。
- 条件冲突与重复触发的排查方向。出现重复通知或状态被反复改写时，先检查是否有规则的作用范围重叠，再检查例外条件是否覆盖了特例，最后核对同一事件是否被多条规则同时监听。
判断一条流程环节是否适合自动化触发，可以问三个问题：触发时机是否由客观事件决定，判断条件能否用字段值表达，执行动作是否固定且可枚举。三个问题都答“是”，适合写成触发条件；任一问题答“否”，更适合保留人工处理或纳入集成与智能编排方案。
常见问题
触发条件里的“判断条件”只写变更后的值可以吗？
建议同时写清变更前后的值。只写“状态变为待测试”，会把从任何状态进入待测试的情况都纳入触发范围，包括从已完成回退、从待处理直接跳转等非预期路径。写成“状态由开发中变为待测试”，触发面与流程节点一一对应，排查时也更容易定位是哪一步流转引发了动作。
规则上线后出现重复通知，应该先查什么？
按三步排查：先看是否有两条以上规则的作用范围重叠，例如一条限定项目、另一条未限定类型；再检查例外条件是否覆盖了特例，比如已标记延期的缺陷仍被提醒；最后核对同一事件是否被多条规则同时监听。排查顺序从范围到例外再到事件，通常能较快定位重复来源。
定时触发和状态变更触发可以组合使用吗？
可以，但要分清主次。常见做法是用状态变更触发即时动作，用定时触发做周期性检查，例如迭代结束前提醒未关闭缺陷。组合时注意避免两条规则对同一工作项产生冲突动作，例如一条改状态、另一条又改回原状态。建议在规则描述中写明各自负责的动作范围，并控制同一工作项上的规则数量。
小团队规则不多，也需要先试运行吗？
建议保留试运行环节，规模可以简化。规则数量少时，可以先在一两个项目内以只记录不执行的方式运行几天，核对触发记录是否符合预期。试运行的价值在于发现条件过宽或例外遗漏，这类问题往往在配置阶段不易察觉，正式启用后才会以误通知或状态错乱的形式暴露。
规则长期没有触发，是删除还是保留？
先判断原因再决定。如果对应流程环节已经取消或合并，规则可以清理；如果是条件限定过窄导致漏触发，应调整条件而非直接删除。建议定期查看规则的触发记录，对连续多个周期零触发的规则逐条确认，避免规则清单随流程变化不断膨胀。
