自动化规则清单把研发流程中反复出现的流转动作逐条登记下来，写明触发条件、判断条件、执行动作、通知对象、生效范围和负责人，让规则可执行、可复核。本文提供可直接复制到表格工具的空白清单、字段填写说明、必填与选填划分、一条完整示例，以及规则上线后的维护方法。
要点总览（TL;DR）
- 模板主表包含规则编号、规则名称、触发事件、判断条件、执行动作、通知对象、生效范围、优先级、冲突处理、负责人、复核人、状态、生效时间、备注 14 个字段，另配一张变更记录表。
- 必填字段为规则编号、规则名称、触发事件、判断条件、执行动作、生效范围、负责人、状态八项；通知对象在执行动作含通知时必填，优先级、冲突处理、复核人、生效时间按规则复杂度启用。
- 一条完整示例是“需求评审通过后流转至开发中并通知开发负责人”，判断条件写状态迁移方向而非状态值，通知对象引用字段值而非固定人名。
- 规则上线后按季度复核触发条件、执行动作和通知对象是否仍有效，长期未触发的规则评估停用或归档，变更同步登记到变更记录表。
- 规则清单作为设计底稿，工具中的配置作为执行实现，调整时先改清单再改配置，排查时从规则编号回溯。
可复制空白自动化规则清单模板
下面的主表可以直接复制到 Excel、飞书表格、在线文档或需求管理工具的自定义表格中。表头保持不动，从第 2 行开始逐条填写规则。模板预留两行空白行，实际使用时按规则数量向下扩展即可。
| 规则编号 | 规则名称 | 触发事件 | 判断条件 | 执行动作 | 通知对象 | 生效范围 | 优先级 | 冲突处理 | 负责人 | 复核人 | 状态 | 生效时间 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
规则编号建议采用“模块缩写-两位序号”的格式，例如 REQ-01、BUG-03、REL-02，模块缩写与团队现有的工作项类型或流程阶段对应。编号一经分配不再复用，规则停用后编号保留，避免历史记录指向混乱。规则名称用“触发场景 + 执行结果”的动宾结构，例如“需求评审通过后自动流转至开发中并通知开发负责人”，名称本身就能说明这条规则做什么，减少翻查字段的成本。
规则清单需要配套一张变更记录表，与主表放在同一文件的不同工作表或同一文档的末尾。主表记录规则当前的样子，变更记录表记录规则怎么变成现在这样。
| 变更日期 | 规则编号 | 变更类型 | 变更内容 | 变更原因 | 操作人 | 复核人 | 生效版本 |
|---|---|---|---|---|---|---|---|
变更类型限定为新增、修改、停用、恢复、归档五种，变更内容写清改了哪个字段、从什么改成什么，例如“判断条件由‘优先级=高’改为‘优先级=高且影响版本=当前迭代’”。变更原因写触发这次调整的具体事件，例如流程评审结论、线上误触发、负责人转岗。这两列是后续排查规则失效时最有用的信息。
每个字段填什么：规则清单字段说明
字段说明按“触发—判断—执行”的主线组织，再补充范围、优先级、责任人等管理字段。填写时以同一口径为准，不同角色填出来的清单才能互相对照。
| 字段 | 含义 | 取值方式 | 常见填错点 |
|---|---|---|---|
| 规则编号 | 规则的唯一标识 | 模块缩写-两位序号，如 REQ-01 | 停用后编号被新规则复用，历史记录对不上 |
| 规则名称 | 一句话说明规则做什么 | 触发场景 + 执行结果 | 只写“需求规则”“自动通知”这类无法区分用途的名称 |
| 触发事件 | 系统在什么时点检查这条规则 | 工作项创建、状态变更、字段更新、定时检查等事件 | 把判断条件写进触发事件，导致规则永远不触发 |
| 判断条件 | 触发后满足什么才执行动作 | 字段值比较、状态区间、角色或分组条件，多个条件写明且/或关系 | 条件写得过宽导致误触发，或条件之间关系未写明 |
| 执行动作 | 条件满足后系统做什么 | 变更状态、修改字段、指派处理人、发送通知、创建关联工作项 | 一条规则塞入多个不相关动作，出问题时难以定位 |
| 通知对象 | 动作执行后谁需要知道 | 具体角色、分组或字段引用的人，如“当前处理人”“测试负责人” | 写成人名，人员变动后通知失效 |
| 生效范围 | 规则作用于哪些项目、工作项类型或状态区间 | 项目名、工作项类型、状态范围 | 范围留空，规则在全组织生效，波及无关项目 |
| 优先级 | 多条规则同时命中时的执行顺序 | 数字，数值越小越先执行，或高/中/低三档 | 所有规则填同一优先级，冲突时无法判断先后 |
| 冲突处理 | 与其他规则互斥时的处理约定 | 写明互斥规则编号与处理方式，如“与 BUG-02 互斥，以本条为准” | 只写“有冲突时人工处理”，未指明由谁处理 |
| 负责人 | 对规则正确性负责的人 | 岗位或角色，如“需求管理流程负责人” | 填成工具管理员，业务规则变化时无人跟进 |
| 复核人 | 规则上线或变更前的审核人 | 流程负责人或质量角色 | 与负责人为同一人，失去复核意义 |
| 状态 | 规则当前所处阶段 | 草稿、待复核、生效、停用、归档 | 规则已下线但状态仍为生效，排查时被误导 |
| 生效时间 | 规则开始或停止起作用的时间 | 日期，配合迭代或版本节点 | 填写计划时间但未与实际配置时间核对 |
三类核心字段之间存在依赖关系：触发事件决定规则在什么时点被检查，判断条件决定这次检查是否值得执行动作，执行动作和通知对象决定规则产生的结果。填写时先确定触发事件，再写判断条件，最后写动作和通知，顺序反过来容易出现“想通知某人所以硬造一个触发点”的情况。
生效范围、优先级和冲突处理三个字段共同解决规则之间的边界问题。生效范围回答“这条规则管哪里”，优先级回答“同时命中时谁先执行”，冲突处理回答“两条规则结论相反时听谁的”。团队规则数量在十条以内时，冲突处理可以只登记明显互斥的规则对；规则数量增长后，建议每条规则都填写优先级，并在新增规则时主动检查与已有规则的重叠。
必填与选填怎么划分
必填字段的最小集合覆盖规则能被识别、执行和追溯三个要求：规则编号、规则名称、触发事件、判断条件、执行动作、生效范围、负责人、状态。这八项缺任何一项，清单都会出现具体问题。
| 字段 | 填写要求 | 缺失后果 | 启用条件 |
|---|---|---|---|
| 规则编号 | 必填 | 无法在变更记录和排查记录中引用 | — |
| 规则名称 | 必填 | 清单难以快速浏览，规则用途靠猜 | — |
| 触发事件 | 必填 | 规则不知道何时检查，等于未定义 | — |
| 判断条件 | 必填 | 规则对所有情况生效，误触发风险高 | — |
| 执行动作 | 必填 | 规则触发后无结果，形同虚设 | — |
| 生效范围 | 必填 | 规则波及范围不可控 | — |
| 负责人 | 必填 | 规则失效或需调整时无人响应 | — |
| 状态 | 必填 | 无法区分草稿与生效规则，执行口径混乱 | — |
| 通知对象 | 条件必填 | 执行动作含通知时缺失，结果无人知晓 | 执行动作中包含通知、提醒、待办时必填 |
| 优先级 | 选填 | 多条规则同时命中时执行顺序不确定 | 同一触发事件下存在两条及以上规则时启用 |
| 冲突处理 | 选填 | 互斥规则同时命中时结果不可预期 | 存在作用对象重叠且结论相反的规则时启用 |
| 复核人 | 选填 | 规则变更缺少第二人确认 | 规则影响跨团队流程或涉及对外交付节点时启用 |
| 生效时间 | 选填 | 无法判断规则从哪个版本开始起作用 | 规则与迭代、版本或流程切换节点绑定时启用 |
| 备注 | 选填 | 特殊约定缺少记录位置 | 规则存在临时约定或已知限制时填写 |
填写深度可以按规则复杂度分三档。简单规则只涉及单一触发事件、单一条件和单一动作，填齐八项必填字段即可，例如“缺陷创建时若严重程度为致命则通知测试负责人”。中等规则包含多个条件或动作，建议补填优先级和生效时间，把条件之间的且/或关系写清楚。复杂规则跨项目、跨工作项类型联动，建议填满全部字段，并在备注中写明设计意图和已知限制，方便后续接手的人理解。
填写示例：一条需求流转规则
下面这条规则演示“需求评审通过后自动流转并通知”的完整填写方式，各字段与空白模板一一对应。
| 字段 | 示例取值 | 取值理由 |
|---|---|---|
| 规则编号 | REQ-01 | 需求模块第一条规则，编号固定不复用 |
| 规则名称 | 需求评审通过后流转至开发中并通知开发负责人 | 名称包含触发场景和执行结果，浏览清单即可理解用途 |
| 触发事件 | 需求工作项状态变更 | 评审结论通过体现为状态变更，以此为检查时点 |
| 判断条件 | 状态由“评审中”变为“评审通过”，且需求类型为“产品需求” | 限定状态迁移方向和需求类型，避免子需求或缺陷误触发 |
| 执行动作 | 将状态更新为“开发中”，并将处理人指派为开发负责人字段的值 | 动作与判断条件直接衔接，一步完成流转和指派 |
| 通知对象 | 开发负责人、需求提出人 | 用字段引用的人而非固定人名，人员变动后通知仍有效 |
| 生效范围 | 产品研发项目组下的全部项目，工作项类型为产品需求 | 限定项目组和类型，不影响其他团队的需求流程 |
| 优先级 | 10 | 数值小优先执行，为后续同触发事件的规则留出排序空间 |
| 冲突处理 | 与 REQ-03（评审驳回后回退）互斥，以状态迁移方向区分，不重复执行 | 两条规则监听同一状态变更，用迁移方向区分，避免同时命中 |
| 负责人 | 需求管理流程负责人 | 对需求流程规则负责的岗位，而非工具管理员 |
| 复核人 | 研发效能负责人 | 规则影响跨角色交接，需要第二人确认 |
| 状态 | 生效 | 已完成复核并配置上线 |
| 生效时间 | 2025-03-03（当前迭代开始日） | 与迭代节点对齐，便于回溯规则从哪个版本开始起作用 |
| 备注 | 评审通过但开发负责人字段为空时，暂不流转，通知流程负责人补填 | 记录边界情况的处理约定，避免规则静默失败 |
这条示例体现了几个填写要点。判断条件写的是状态迁移方向，而不是“状态等于评审通过”，因为后者在需求后续再次进入该状态时会重复触发。通知对象引用字段值，规则不依赖具体人员。备注记录了字段为空时的处理方式，这类边界情况如果不写，规则在数据不完整时会静默不执行，排查时很难定位。
把示例行与空白模板对照，可以看到每个字段都有对应位置，示例没有引入模板之外的字段。团队可以先把这条规则抄进自己的清单，替换项目名、角色名和状态名称，再按同样格式补充其他规则。
规则清单的调整与维护方法
规则清单建立后，维护工作集中在新增评审、停用归档、定期复核和冲突排查四件事上。每件事都对应清单中的字段和变更记录表中的一行。
新增与变更走同一条评审流程：提出人填写规则行或修改内容，状态置为“待复核”；复核人核对触发事件是否与现有流程节点一致、判断条件是否覆盖边界情况、执行动作是否指向有效对象；通过后状态改为“生效”，同时在变更记录表登记一行。涉及跨团队流程的规则，复核人应包含受影响团队的代表。修改已有规则时，变更记录表要写清修改前后的取值，主表只保留当前版本。
停用与归档按以下条件判断：流程节点取消或合并，规则失去触发场景；规则连续一个季度以上未触发，且确认不是配置问题；规则被新规则完全替代。停用后状态改为“停用”，保留在清单中；确认不再恢复时改为“归档”，从日常浏览视图中隐藏，但编号和记录保留。停用和归档都要在变更记录表登记原因。
定期复核建议按季度执行，由各规则的负责人逐条确认三件事：触发条件是否仍与当前流程一致，执行动作指向的工作项类型、状态和字段是否仍然存在，通知对象引用的角色是否仍有人承担。复核结果记录复核日期，长期未触发的规则在复核时重点评估是否停用。
规则冲突和失效的排查可以按以下检查项逐条过：
- 同一触发事件下是否存在多条规则，优先级是否已填写且不重复；
- 判断条件之间是否存在重叠区间，重叠部分是否有冲突处理约定；
- 执行动作引用的字段是否被删除或改名，状态是否已从流程中移除；
- 通知对象引用的角色或字段是否仍能解析到具体人员；
- 规则状态与实际配置是否一致，是否存在已停用但仍在校验的规则；
- 变更记录表中最近一次修改是否与主表当前内容一致。
规则清单最终要落到实际的工作项流转和通知上。当团队在 ONES 中管理需求、任务和缺陷时，工作项的状态变更、字段更新和通知可以作为规则执行动作的承载对象，清单中登记的触发事件、判断条件和执行动作也能与工作项的实际流转逐项对照。把清单作为规则的设计底稿，把工具中的配置作为执行实现，两者保持同步，规则调整时先改清单再改配置，排查问题时从清单编号回溯到具体规则，维护成本会明显降低。
常见问题
团队规则只有三五条，还需要建变更记录表吗？
建议从第一条规则起就建。变更记录表的价值在规则出问题时才体现，而规则数量少的时候恰恰容易忽略记录，等到规则增加到十几条、出现误触发时，已经无法回溯每条规则当初为什么这样写。初期可以只登记新增和修改两类变更，格式保持简单，随规则数量增长再补充停用、恢复、归档的记录。
判断条件里多个条件之间用“且”还是“或”，清单里怎么写清楚？
清单中要把逻辑关系显式写出来，例如“优先级=高 且 影响版本=当前迭代”，不要只罗列条件项。混合逻辑时用括号标明分组，例如“（类型=产品需求 或 类型=技术需求）且 状态=评审通过”。如果条件超过三个，建议在备注中补一句自然语言说明，方便复核人快速核对，也降低后续修改时理解偏差的风险。
规则停用后编号能不能给新规则用？
不建议复用。编号是变更记录、排查记录和沟通中的引用锚点，复用会让历史记录指向两条不同的规则。停用和归档的规则保留原编号，新规则顺延分配新序号。如果模块整体下线，可以在编号前加模块前缀区分，例如把旧模块的规则统一归档，新模块从新的缩写开始编号。
规则清单和工具里实际配置的自动化规则如何保持同步？
把清单当作设计底稿，工具配置当作执行实现，两者以规则编号对应。调整时先在清单中修改并走复核，复核通过后再改工具配置，最后在变更记录表登记生效时间。定期复核时逐条对照清单字段与工具中的实际配置，重点检查判断条件、执行动作指向的字段和通知对象，发现不一致以清单为准回改配置，或反过来修正清单并记录原因。
跨项目使用的规则，生效范围和负责人怎么填？
生效范围写到项目组或项目清单级别，避免留空导致全组织生效。负责人按流程归属确定，跨项目规则由主导该流程的岗位担任负责人，受影响团队各指定一名复核人参与上线评审。冲突处理字段要写明与其他项目同类规则的重叠关系，例如两条规则都监听同一状态变更时，用优先级或状态迁移方向区分，避免同时命中产生相反结果。
