自动化规则清单把每条规则的触发条件、判断条件、执行动作、作用对象、异常处理和负责人逐项登记下来，便于评审、上线和后续维护。本文先给一张可直接复制到表格工具的空白清单，再说明每个字段怎么填、哪些必填、用一条完整示例对照检查，最后讲清单上线后的调整与复核方法。
要点总览（TL;DR）
- 自动化规则清单按“一条规则一行”组织，核心字段包括规则编号、名称、触发条件、判断条件、执行动作、作用对象、生效范围、异常处理、负责人与复核信息。
- 触发条件写“什么时候检查”，判断条件写“满足什么才执行”，执行动作与作用对象成对填写，生效范围有例外时必须显式写出。
- 必填字段建议为规则编号、名称、触发条件、执行动作、作用对象、负责人和状态；判断条件、生效范围、异常处理等可按成熟度逐步补齐，必填缺失时先登记为草稿。
- 填写示例覆盖触发、判断、动作、异常与维护各字段，常见错误包括条件混写、动作含糊、范围留空和负责人填部门。
- 清单上线后按周期复核，停用与删除保留行记录，字段增删与批量调整同步更新版本号，保证变更可追溯。
可复制空白自动化规则清单模板
下面这张表按“一条规则一行”组织，共十六列，覆盖规则登记、触发与判断、执行动作、作用范围、异常处理和维护复核六组信息。可以直接复制到电子表格中，保留表头，从第二行开始逐条填写。
| 规则编号 | 规则名称 | 所属流程 | 触发条件 | 判断条件 | 执行动作 | 作用对象 | 生效范围 | 优先级 | 异常处理 | 负责人 | 状态 | 上线日期 | 复核周期 | 最近复核日期 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
复制时建议同时保留两行空白行，方便先批量录入再逐条补齐。如果团队规则数量较多，可以在表头下方冻结首行，并把“状态”列设置为下拉选项，取值为草稿、启用、停用、已删除，减少手工输入造成的不一致。
表格列的顺序本身不影响使用，但建议保持“先登记、再条件、后动作、最后维护”的排列，评审时从左往右读一遍就能判断一条规则是否写完整。规则数量增长后，可以按“所属流程”或“负责人”筛选出子集，分别组织评审，不必每次通读全表。
每个字段填什么：自动化规则清单字段说明
字段说明的作用是让不同的人填同一张表时口径一致。下面按六组逐项解释，重点区分容易混淆的几组字段。
登记信息：规则编号、名称、所属流程
规则编号是规则的唯一标识，建议采用“流程缩写-序号”的形式，例如“需求-001”，编号一经使用不再复用，规则删除后编号保留。规则名称用一句话说明这条规则做什么，写成“条件+动作”的结构，例如“需求优先级为高时通知产品负责人”，避免只写“通知规则”这类无法辨认的名称。所属流程填写规则服务的业务流程，便于按流程归集和评审。
触发条件与判断条件：什么时候检查，满足什么才执行
这两个字段最容易写混。触发条件回答“什么时候检查这条规则”，通常是某个事件发生，例如工作项创建、状态变更、字段被修改、到达某个日期。判断条件回答“检查之后满足什么才真正执行”，是对字段值或关联关系的比较，例如优先级等于高、经办人为空、距截止日期不足两天。
一条规则可以只有触发条件而没有判断条件，表示事件一发生就执行；反过来只有判断条件没有触发条件则无法确定检查时机。填写时把触发条件写成事件描述，把判断条件写成可判真假的表达式，两者分开写，评审时就能看出规则会不会被误触发。
执行动作与作用对象：改什么，改成什么
执行动作写清具体操作和结果值，例如“将状态改为待评审”“给指定角色发送通知”“把截止日期顺延三个工作日”。作用对象写清动作落在哪类记录或哪个字段上，例如“当前工作项的状态字段”“该需求关联的全部子任务”。动作和对象要成对出现，只写“自动流转”无法判断改的是哪个对象、流转到哪个状态。
生效范围：规则在哪些条件下适用
生效范围界定规则的适用边界，常见写法包括适用的项目或空间、工作项类型、时间区间、例外清单。例如“仅适用于A项目下的缺陷类工作项，试点期为本季度”。范围写得越具体，越容易在规则冲突时判断哪条优先。范围为空时默认理解为全流程适用，因此如果确实只针对部分对象，应显式写出，不要留空。
异常处理：规则没按预期执行时记录什么
异常处理字段记录规则执行失败或结果异常时的处置方式，包括失败后是否重试、通知谁、是否需要人工补做、在何处留痕。填写时写成可执行的处置说明，例如“执行失败时通知规则负责人，由负责人在当日手工调整状态并记录原因”。这一列在规则刚上线时尤为重要，能避免异常发生后无人跟进。
维护字段：负责人、状态、复核与变更
负责人是这条规则的日常维护人，负责复核、修改和停用决策，应填写具体人员而非部门。状态标记规则当前处于草稿、启用、停用还是已删除。复核周期和最近复核日期配合使用，用来提醒到期检查。变更记录简要写明每次修改的日期、内容和修改人，保证规则历史可追溯。
必填与选填：规则清单的填写底线
全部字段都填当然最完整，但实际录入时可以先守住底线，再逐步补齐。下表给出必填与选填的划分建议，团队可以在此基础上按自身成熟度调整。
| 字段 | 建议 | 说明 |
|---|---|---|
| 规则编号 | 必填 | 唯一标识，评审和变更记录都依赖它 |
| 规则名称 | 必填 | 让人不看内容也能大致判断规则用途 |
| 触发条件 | 必填 | 缺少则无法确定检查时机 |
| 执行动作 | 必填 | 缺少则规则没有实际效果 |
| 作用对象 | 必填 | 缺少则无法判断动作落在哪里 |
| 负责人 | 必填 | 缺少则异常和复核无人承接 |
| 状态 | 必填 | 区分草稿与启用，避免未完成规则被误用 |
| 判断条件 | 选填 | 事件触发即执行时可留空 |
| 所属流程 | 选填 | 规则少时可后补，规则多时建议填写便于归集 |
| 生效范围 | 选填 | 留空视为全流程适用，有例外时必须填写 |
| 优先级 | 选填 | 存在多条规则作用于同一对象时建议填写 |
| 异常处理 | 选填 | 建议启用前补齐，草稿阶段可暂缺 |
| 上线日期、复核周期、最近复核日期 | 选填 | 启用后补齐，用于到期提醒 |
| 变更记录 | 选填 | 首次修改起开始记录 |
必填字段缺失时，不要把规则直接置为启用。可行的做法是先登记为草稿，在变更记录或备注中标注待补项和补齐期限，由负责人跟进；补齐并通过评审后再改为启用。这样既保留了规则线索，也避免半成品规则进入实际流程。
字段可以按团队情况增删。规则数量少、流程简单的团队，可以暂时去掉优先级和所属流程；跨项目使用、规则之间存在覆盖关系的团队，则建议增加“冲突规则编号”“关联需求编号”等列。增删字段时同步更新字段说明，保证模板、说明和示例三处一致。
填写示例：一条完整的自动化规则
下面用一条演示情景中的规则展示各字段如何配合。该示例仅用于说明填写方式，不代表任何真实团队的配置。
| 字段 | 示例取值 |
|---|---|
| 规则编号 | 需求-003 |
| 规则名称 | 需求进入开发后经办人为空时提醒产品负责人 |
| 所属流程 | 需求管理 |
| 触发条件 | 需求类工作项状态变更为“开发中” |
| 判断条件 | 经办人字段为空 |
| 执行动作 | 向产品负责人发送提醒，并在工作项上添加“待指派”标签 |
| 作用对象 | 当前需求工作项及其经办人字段 |
| 生效范围 | 适用于A项目下的需求类工作项，试点期为本季度 |
| 优先级 | 中 |
| 异常处理 | 提醒发送失败时通知规则负责人，由负责人在当日手工指派并记录原因 |
| 负责人 | 需求管理流程负责人 |
| 状态 | 启用 |
| 上线日期 | 本季度首日 |
| 复核周期 | 每季度一次 |
| 最近复核日期 | 本季度末 |
| 变更记录 | 首次登记；后续修改在此追加日期与内容 |
逐项对照字段说明可以看出：触发条件写的是事件“状态变更为开发中”，判断条件写的是可判真假的“经办人为空”，两者分工清楚；执行动作包含通知和打标签两个具体结果，作用对象指明落在当前工作项和经办人字段上；生效范围限定了项目、工作项类型和时间区间，避免规则扩散到未试点的范围；异常处理给出了失败后的承接人和处置动作；维护字段则保证这条规则到期有人复核。
常见填写错误有几类。一是把判断条件写进触发条件，例如触发条件写成“状态变为开发中且经办人为空”，导致后续无法单独调整判断逻辑。二是执行动作只写“自动处理”，没有说明改哪个字段、改成什么值。三是生效范围留空却实际只想覆盖一个项目，规则上线后影响到其他项目。四是负责人填成部门名称，异常发生时找不到具体承接人。五是修改规则后不更新变更记录和最近复核日期，清单逐渐与实际配置脱节。
规则清单落到工作项流转时，需要工具侧承接这些动作。以ONES为例，工作项状态变更可以作为触发时机的管理对象，状态流转和字段变更可以在同一套工作项模型里配置，规则执行结果也体现在工作项的状态和字段上，清单中的触发条件、作用对象与工具中的配置项能够对应起来，评审时可以直接核对。具体可配置的触发类型和动作范围以ONES官方资料为准，本文不展开配置细节。
规则清单的调整与维护方法
清单建好只是开始，规则会随流程变化而增删改，维护方法决定了这张表能否长期可用。
新增字段的判断标准
新增字段前先问三个问题：这个信息是否会被反复查询或用于评审决策；是否无法从已有字段推导出来；是否有明确的填写人和填写时机。三个问题都成立时再增加列，否则优先写入变更记录或备注。新增字段后，同步在字段说明中补充含义和填写口径，并把历史规则中能补的值补齐，补不齐的标注为待补，避免新旧规则口径分裂。
规则复核周期与责任人
每条启用状态的规则都应有复核周期和负责人。复核周期按规则影响面设定：影响面广、涉及多个项目的规则可以按月或按季度复核，局部试点规则可以按季度或半年复核。复核时检查四件事：触发条件和判断条件是否仍与当前流程一致，执行动作的结果是否符合预期，生效范围是否需要收窄或扩大，异常处理是否发生过实际案例。复核完成后更新最近复核日期，并在变更记录中写明结论，即使结论是“无需修改”也建议留一行记录。
规则停用与删除的记录方式
规则不再需要时，优先改为停用状态而不是直接删除行。停用表示规则保留在清单中但不再执行，便于日后恢复或作为历史参考；确需删除时，把状态改为已删除并保留该行，同时在变更记录中写明删除原因和日期。规则编号不复用，这样历史评审记录、异常记录中引用的编号始终能对应到具体规则。
清单版本与变更留痕
建议为清单本身设置版本号，在表头或单独的版本记录区标注每次调整的日期、调整内容和调整人。字段增删、必填规则变化、批量停用等结构性调整都应升一个版本；单条规则的日常修改记在该行的变更记录中即可。版本记录与行级变更记录配合，既能看清清单整体演进，也能追溯到某条规则的具体改动。
当规则数量增长到几十条以上，靠人工比对容易遗漏冲突。此时可以按作用对象分组检查是否存在多条规则修改同一字段，并用优先级字段明确覆盖顺序；在ONES这类承载工作项流转的工具中，规则配置与清单条目保持一一对应，复核时逐条核对配置与登记是否一致，能把清单维护落到具体的管理动作上。
常见问题
规则数量很少时，还需要维护完整的十六列清单吗？
规则数量少、流程简单的团队可以先保留必填字段，把优先级、所属流程、复核周期等列暂时省略，等规则增长后再补。需要守住的是规则编号、名称、触发条件、执行动作、作用对象、负责人和状态这几列，它们决定了规则能否被评审和追责。字段增删时同步更新字段说明，避免模板与说明口径不一致。
多条规则同时作用于同一个工作项字段时，清单里怎么处理？
建议在清单中保留优先级列，并增加“冲突规则编号”一列，把可能修改同一字段的规则互相标注。评审时按作用对象分组检查，明确哪条规则优先执行、哪些条件互斥。规则数量增长到几十条以上后，人工比对容易遗漏，可以借助承载工作项流转的工具让配置与清单条目一一对应，复核时逐条核对。
规则停用后，历史异常记录里引用的编号怎么对应？
规则编号一经使用不再复用，停用时把状态改为停用并保留该行，确需删除时改为已删除同样保留行，并在变更记录中写明原因和日期。这样历史评审记录和异常记录中引用的编号始终能定位到具体规则。直接删除整行会让旧记录失去对应关系，后续排查时难以还原当时的规则内容。
规则上线后触发条件没有命中，应该先改规则还是先改清单？
先确认实际流程是否发生了变化：如果流程本身调整了，先更新清单中的触发条件和生效范围，再按新登记内容修改工具配置；如果流程没变而规则未命中，检查触发事件是否被其他条件拦截，把排查结论写入该行的变更记录。无论哪种情况，都建议保持清单与工具配置同步修改，避免清单记录与实际执行脱节。
复核时发现规则长期没有触发过，应该直接删除吗？
先判断是规则失效还是业务场景本身减少。可以查看该规则对应的流程环节是否仍在运行、生效范围是否过窄。确认不再需要的规则优先改为停用，保留行和编号作为历史参考；连续多个复核周期都无触发且业务已取消的，再改为已删除并记录原因。直接删除会丢失判断依据，也不利于后续恢复。
