自动化规则清单是一张逐条登记流程自动化规则的台账，核心信息分为四组：规则身份、触发条件、执行动作和运行治理。本文提供一张可直接复制到表格工具中的空白清单，并逐列说明填写口径、必填判断和完整示例，帮助团队把每条规则登记到可识别、可追责、可维护的程度。
要点总览（TL;DR）
- 自动化规则清单按四组信息组织：规则身份、触发条件、执行动作、运行治理，一行登记一条规则，编号全表唯一。
- 必填字段的判断标准是：缺了就无法判断规则何时触发，或出问题后找不到责任人；其余字段按规则成熟度分阶段补填。
- 通知类规则重点填通知对象与渠道，字段修改类规则重点填字段赋值，并在冲突处理中写明已有值时是否跳过。
- 清单需要配套准入检查、定期评审和停用归档机制，变更记录按日期、修改人、修改内容三段式追加。
- 规则清单可放在表格或文档协作工具中维护，ONES Wiki 的版本记录、权限控制和模板库可用于承载清单文档。
可复制空白模板：自动化规则清单表
下表可直接复制到 Excel、在线表格或文档表格中使用。列名按四组信息排列，一行登记一条规则，编号在全表内唯一。表格保留空白行，填写时从第一行开始逐条补充。
| 分组 | 列名 | 填写内容 |
|---|---|---|
| 规则身份 | 规则编号 | |
| 规则名称 | ||
| 所属流程/场景 | ||
| 业务负责人 | ||
| 技术负责人 | ||
| 触发条件 | 触发事件 | |
| 判断条件 | ||
| 数据来源 | ||
| 触发频率限制 | ||
| 执行动作 | 动作类型 | |
| 目标工作项/对象 | ||
| 字段赋值 | ||
| 通知对象与渠道 | ||
| 运行治理 | 生效范围 | |
| 优先级 | ||
| 冲突与重复触发处理 | ||
| 启用状态 | ||
| 验证方式 | ||
| 变更记录 | ||
| 规则身份 | 规则编号 | |
| 规则身份 | 规则名称 | |
| 触发条件 | 触发事件 | |
| 执行动作 | 动作类型 | |
| 运行治理 | 启用状态 |
最小填写约定有三条：一行只登记一条规则，不要把多个动作合并进同一行；规则编号采用“流程缩写-序号”的形式，例如“缺陷-001”，保证全表唯一；同一规则修改后保留原编号，在变更记录中追加版本说明，不另起新编号。
字段说明：每一列登记什么、怎么填
字段说明解决“不同角色填同一张表，口径是否一致”的问题。下表逐列给出含义、填写口径和常见错误，填写前建议先通读一遍。
| 字段名 | 含义 | 填写口径 | 易错点 |
|---|---|---|---|
| 规则编号 | 规则在全表内的唯一标识 | 流程缩写加三位序号，如“需求-003” | 修改规则时换新编号，导致历史记录断链 |
| 规则名称 | 用一句话说明规则做什么 | 采用“触发对象+动作”的写法，如“缺陷关闭后通知测试负责人” | 名称写成“自动化1”“测试规则”，无法辨认用途 |
| 所属流程/场景 | 规则服务的业务流程 | 填写流程名称或场景名，如“缺陷管理”“版本发布” | 只写部门名，后续无法按流程筛选 |
| 业务负责人 | 对规则业务效果负责的人 | 填写具体姓名，不填岗位统称 | 填“产品组”，出问题时找不到确认人 |
| 技术负责人 | 负责规则配置与排障的人 | 填写具体姓名，可与业务负责人为同一人 | 留空，规则失效后无人排查 |
| 触发事件 | 规则在什么事件发生时启动 | 写具体事件，如“工作项状态变更为已关闭” | 写“有更新时”，范围过宽导致误触发 |
| 判断条件 | 事件发生后还需满足的条件 | 写可判断的条件组合，如“优先级为高且经办人为空” | 把动作写进条件列，条件与动作混在一起 |
| 数据来源 | 判断条件读取的数据所在位置 | 写明字段或对象来源，如“工作项优先级字段” | 写“系统数据”，无法核对条件是否成立 |
| 触发频率限制 | 防止短时间重复触发的约束 | 写时间窗口或次数，如“同一工作项24小时内最多触发一次” | 留空且规则涉及通知，造成消息轰炸 |
| 动作类型 | 规则触发后执行的操作类别 | 写动作类别，如“修改字段”“发送通知”“创建子任务” | 一条规则登记多个不相关动作，难以验证 |
| 目标工作项/对象 | 动作作用在哪个对象上 | 写对象类型与范围，如“当前缺陷工作项” | 写“所有工作项”，影响面失控 |
| 字段赋值 | 动作修改字段时的具体取值 | 写字段名与新值，如“状态改为待验证” | 只写“更新状态”，不写目标值 |
| 通知对象与渠道 | 通知发给谁、通过什么方式 | 写角色或具体人，以及渠道，如“测试负责人，站内通知” | 写“相关人员”，实际无人收到 |
| 生效范围 | 规则在哪些项目或空间生效 | 写项目名或空间范围 | 默认全项目生效，影响其他团队流程 |
| 优先级 | 多条规则同时命中时的执行顺序 | 用数字或高/中/低标注，并说明排序依据 | 全部填“高”，冲突时无法裁决 |
| 冲突与重复触发处理 | 与已有规则重叠时的处理方式 | 写“跳过”“合并通知”或“人工确认”等约定 | 留空，两条规则同时改同一字段互相覆盖 |
| 启用状态 | 规则当前是否运行 | 填写启用、停用或草稿 | 停用后未更新状态，台账与实际不符 |
| 验证方式 | 如何确认规则按预期运行 | 写验证动作与观察点，如“用测试工作项走一遍状态流转，检查通知是否送达” | 写“已测试”，没有可复查的记录 |
| 变更记录 | 规则的修改历史 | 按“日期+修改人+修改内容”追加，不覆盖旧记录 | 直接改原内容，历史无法追溯 |
填写时有一个通用原则：条件列只写“什么情况下触发”，动作列只写“触发后做什么”，两者分开登记。这样在排查规则未生效时，可以先核对条件是否成立，再检查动作是否执行，缩小问题范围。
必填与选填：哪些列不能空
必填的判断依据是：缺了这一列，就无法判断规则何时触发，或者出问题后无法找到责任人。按这个标准，规则编号、规则名称、所属流程、业务负责人、触发事件、动作类型、目标对象、启用状态属于上线前必须填齐的字段。
| 类别 | 字段 | 判断理由 |
|---|---|---|
| 必填 | 规则编号、规则名称 | 保证规则可被唯一识别和引用 |
| 必填 | 所属流程/场景、业务负责人 | 明确规则归属，出问题能找到确认人 |
| 必填 | 触发事件、动作类型、目标工作项/对象 | 缺任一项都无法判断规则何时触发、作用于何处 |
| 必填 | 启用状态 | 台账与实际运行状态保持一致 |
| 选填 | 技术负责人 | 业务负责人兼任配置时可不单列，规则数量增多后建议补填 |
| 选填 | 判断条件、数据来源 | 无附加条件的规则可不填；涉及条件判断时必须补上 |
| 选填 | 触发频率限制 | 涉及通知或高频事件的规则建议填写 |
| 选填 | 字段赋值 | 动作类型为修改字段时必填，其他动作类型可不填 |
| 选填 | 通知对象与渠道 | 动作涉及通知时必填 |
| 选填 | 生效范围、优先级、冲突处理 | 单项目、单规则运行时可暂缓，规则增多后补填 |
| 选填 | 验证方式、变更记录 | 首次上线建议填写验证方式，之后每次修改追加变更记录 |
按规则成熟度分阶段补填比较实用。草稿阶段填齐身份类和触发、动作的核心列，先让规则可被识别；上线前补齐验证方式和生效范围；运行稳定、规则数量增加后，再补优先级、冲突处理和频率限制。这样既不会因为字段太多拖延上线，也能在规则变复杂时逐步补全治理信息。
必填项为空时的处理约定建议写进团队规范：提交评审时必填项为空，规则退回补充，不进入配置环节；已上线规则发现必填项缺失，由业务负责人在两个工作日内补齐，期间该规则标记为待确认；连续两次评审都因同一字段缺失被退回，由流程负责人确认该字段口径后再继续。
填写示例：一条完整规则长什么样
以下示例为演示情景，用于说明各字段如何配合，不代表任何真实团队的配置。示例一登记一条缺陷流程中的通知规则。
| 列名 | 示例取值 | 取值理由 |
|---|---|---|
| 规则编号 | 缺陷-001 | 流程缩写加序号，全表唯一，后续修改沿用 |
| 规则名称 | 高优缺陷关闭后通知测试负责人 | 名称包含触发对象和动作，一眼可辨用途 |
| 所属流程/场景 | 缺陷管理 | 便于按流程筛选和评审 |
| 业务负责人 | 张明（测试组） | 填写具体人，负责确认通知对象是否正确 |
| 技术负责人 | 李华（研发组） | 负责配置和排障 |
| 触发事件 | 缺陷工作项状态变更为已关闭 | 事件具体，避免“有更新”这类宽泛描述 |
| 判断条件 | 优先级为高或紧急 | 只对高优缺陷通知，减少无关消息 |
| 数据来源 | 缺陷工作项的优先级字段 | 条件读取位置明确，便于核对 |
| 触发频率限制 | 同一缺陷24小时内最多通知一次 | 防止反复打开关闭造成重复通知 |
| 动作类型 | 发送通知 | 单一动作，便于验证 |
| 目标工作项/对象 | 当前缺陷工作项 | 作用范围限定在当前对象 |
| 字段赋值 | 不涉及 | 本规则不修改字段，明确标注避免误解 |
| 通知对象与渠道 | 测试负责人，站内通知 | 对象和渠道都写清楚 |
| 生效范围 | 缺陷管理项目 | 限定项目，不影响其他团队 |
| 优先级 | 中 | 与同流程其他规则相比不抢占执行顺序 |
| 冲突与重复触发处理 | 与缺陷-002通知规则重叠时合并为一条通知 | 提前约定，避免同一事件发两条消息 |
| 启用状态 | 启用 | 与实际运行状态一致 |
| 验证方式 | 创建测试缺陷，将状态改为已关闭，确认测试负责人收到站内通知且24小时内不重复 | 验证动作可执行、观察点明确 |
| 变更记录 | 2025-03-10 李华 创建；2025-03-18 李华 判断条件由“优先级为高”改为“优先级为高或紧急” | 按日期追加，保留历史 |
示例二登记一条字段修改规则，用于对照不同类型规则的填法差异。
| 列名 | 示例取值 |
|---|---|
| 规则编号 | 需求-004 |
| 规则名称 | 需求进入开发时自动指派经办人 |
| 所属流程/场景 | 需求管理 |
| 业务负责人 | 王芳（产品组） |
| 技术负责人 | 李华（研发组） |
| 触发事件 | 需求工作项状态变更为开发中 |
| 判断条件 | 经办人字段为空 |
| 数据来源 | 需求工作项的经办人字段 |
| 触发频率限制 | 不涉及 |
| 动作类型 | 修改字段 |
| 目标工作项/对象 | 当前需求工作项 |
| 字段赋值 | 经办人赋值为需求所属模块的默认负责人 |
| 通知对象与渠道 | 不涉及 |
| 生效范围 | 需求管理项目 |
| 优先级 | 高 |
| 冲突与重复触发处理 | 经办人已有值时跳过，不覆盖人工指派 |
| 启用状态 | 启用 |
| 验证方式 | 新建需求并清空经办人，将状态改为开发中，确认经办人被自动填入 |
| 变更记录 | 2025-03-12 李华 创建 |
两条示例的差异集中在动作列：通知类规则重点填通知对象与渠道，字段修改类规则重点填字段赋值，并在冲突处理中写明“已有值时跳过”，避免覆盖人工操作。这个差异说明模板中的选填列并非可有可无，而是随动作类型决定是否必须填写。
调整与维护：清单如何随流程变化更新
规则清单的价值在于长期准确。流程调整、人员变动、规则叠加都会让台账与实际运行脱节，需要配套的准入、评审和归档机制。
新增规则前先做准入检查。在清单中按所属流程和触发事件筛选，确认是否已有规则覆盖同一事件；若已有规则，判断是修改原规则还是新增规则，并在冲突处理列写明两条规则的关系。准入检查还应确认目标对象和生效范围不与现有规则重叠，避免两条规则同时修改同一字段。
定期评审建议按固定节奏进行，例如每月一次或每个版本发布前一次。评审时由业务负责人逐条确认规则是否仍需要、通知对象是否仍在岗、生效范围是否随项目调整而变化。评审结论记录在变更记录列，未确认的规则标记为待确认，超过约定周期仍未确认的转为停用。
停用与归档的约定建议如下：规则不再需要时，将启用状态改为停用，并在变更记录中写明停用原因和日期；停用满一个评审周期后移入归档区，保留编号不重复使用；归档规则的历史记录随规则一并保留，便于日后追溯某次流程变更的依据。
变更记录字段的填写要求是“日期+修改人+修改内容”三段式，修改内容写清改前和改后的取值。涉及触发条件或动作的修改，同步更新验证方式，并重新执行一次验证。这样任何一条规则都能回答三个问题：谁在什么时候改过、改了什么、改完后是否验证过。
清单的承载工具会影响维护成本。放在普通表格中，版本和权限需要人工管理；放在文档协作工具中，可以利用版本记录和权限控制减少手工登记。ONES Wiki 支持文档实时同步并记录所有页面版本，可随时查看与回滚，也支持为不同角色配置读写权限，并提供页面模板库用于创建制式化文档模板，适合把规则清单作为团队共享文档维护。规则本身的配置与运行则在项目管理工具的自动化规则页面完成，ONES 中由 Project 管理员在「配置中心」的「自动化规则」页面管理团队使用的流程自动化规则，支持公有云与私有部署团队免费试用，试用范围以官网当期说明为准。清单登记与规则配置分处两个位置时，建议在变更记录中同时注明配置操作的日期，保持台账与系统状态一致。
常见问题
规则清单里的“判断条件”和“动作类型”容易混在一起，填写时怎么区分？
判断条件回答“什么情况下才执行动作”，动作类型回答“触发后做什么”。填写时把条件列限定为可判断真假的描述，例如“优先级为高且经办人为空”；动作列只写操作类别，例如“发送通知”或“修改字段”。如果一条规则需要多个动作，建议拆成多条规则分别登记，便于逐条验证和排查。
团队刚开始用清单，字段太多填不过来，可以先填哪些？
可以先填齐身份类和核心触发、动作列：规则编号、规则名称、所属流程、业务负责人、触发事件、动作类型、目标对象、启用状态。这些字段保证规则能被唯一识别、能判断触发时机、能找到责任人。验证方式、生效范围、优先级、冲突处理和频率限制可以在规则上线前或规则数量增加后逐步补填，避免字段过多拖延上线。
两条规则同时修改同一个字段，清单里怎么登记才不会互相覆盖？
在两条规则的“冲突与重复触发处理”列分别写明关系和处理方式，例如一条写“与需求-004重叠时跳过”，另一条写“经办人已有值时跳过，不覆盖人工指派”。同时用优先级列标注执行顺序，并在评审时确认两条规则不会对同一对象产生相反赋值。清单登记清楚后，配置规则时按同样约定设置，台账和系统行为才能保持一致。
规则停用后，清单里的记录要删除吗？
不建议删除。把启用状态改为停用，在变更记录中写明停用原因和日期；停用满一个评审周期后移入归档区，编号保留不重复使用。归档规则的历史记录随规则一并保留，便于日后追溯某次流程变更的依据。删除记录会让后续排查失去参照，也容易导致编号被重复分配。
清单放在表格里和放在文档工具里，维护上有什么区别？
放在普通表格中，版本和权限需要人工管理，多人同时修改时容易产生多份副本。放在文档协作工具中，可以利用版本记录和权限控制减少手工登记。ONES Wiki 支持文档实时同步并记录所有页面版本，可随时查看与回滚，也支持为不同角色配置读写权限，并提供页面模板库用于创建制式化文档模板，适合把规则清单作为团队共享文档维护。规则本身的配置与运行则在项目管理工具的自动化规则页面完成。
