自动流转规则上线前，需要先确认三件事：规则触发的条件能被唯一判定，规则执行的结果能被追溯，规则出错时能被发现并回退。这份清单面向流程自动化建设初期的环节筛选与规则上线评审，把候选环节按“条件可枚举、状态唯一、责任人明确、异常有出口”逐项核对，并为每条规则准备通过标准、证据和负责人。任何一条阻断项未通过，规则就不应上线。
要点总览（TL;DR）
- 上线前先确认三类前提：触发条件能被唯一判定、执行结果能被追溯、出错时能被发现并回退，三者缺一不应上线。
- 候选环节按“条件可枚举、状态唯一、责任人明确、异常有出口”四项筛选，任一项不满足即排除在首批自动化范围之外。
- 通过标准要写成可取证的结果：同一输入多次执行命中一致、每次流转可查到规则与前后状态、异常有记录且有人工接管路径。
- 条件不可枚举、状态不唯一、无异常出口、无审计记录、无回退方式属于阻断项，未通过时停止上线，不以审批豁免绕过。
- 整体上线需同时满足：阻断项全部通过并有证据、非阻断项有整改计划、每条规则责任到人、上线范围与回退方式书面确认。
谁在什么时点使用这份清单
这份清单解决的是“谁在哪个阶段查什么”的分工问题，检查内容本身放在后续章节。它适用于规则驱动的流程流转，包括状态变更、字段更新、通知触发、任务分派这类由条件判断自动执行的动作。AI 智能编排、跨系统接口对接与集成部署不在本清单范围内，需要另行评估。
使用对象包括四类角色：流程负责人对环节是否值得自动化负责；研发流程管理员维护流程定义与状态模型；自动化规则配置人负责规则的具体配置与试运行；审计或质量对接人核对记录完整性与异常处置路径。角色可以由同一人兼任，但每项检查必须有明确的责任人，不能出现无人认领的检查项。
使用时点有三个：环节筛选阶段，判断某个环节是否具备配置自动流转规则的基础条件；规则配置完成、待上线前，逐项核对确定性与审计前提；规则变更后重新上线前，按变更影响范围重跑相关检查项。三个时点的检查深度不同，筛选阶段重在排除不具备条件的环节，上线前评审重在取证。
| 角色 | 环节筛选阶段 | 配置完成待上线前 | 规则变更后重新上线前 |
|---|---|---|---|
| 流程负责人 | 确认环节业务价值与流转规则 | 确认规则与业务规则一致 | 确认变更必要性与影响范围 |
| 研发流程管理员 | 核对状态模型是否唯一、可枚举 | 核对触发条件与目标状态配置 | 核对变更后的状态与条件 |
| 规则配置人 | 初判条件是否可枚举 | 完成配置并提交试运行记录 | 重新配置并重跑试运行 |
| 审计或质量对接人 | 确认环节是否在审计范围内 | 核对操作记录与证据留存 | 核对变更审批与回退记录 |
上线前分阶段检查项
检查项按筛选、配置、试运行、上线四个阶段排列，每项都写成可以判断完成与否的表述。判断方式是：能拿出对应产物或记录即为完成，拿不出即为未完成，不用“基本满足”“大致清楚”这类模糊结论。
环节筛选阶段
- 条件可枚举：触发条件能写成有限个可判断的取值组合，例如状态等于某值且字段满足某范围；存在“其他情况”无法归类的，视为未通过。
- 状态唯一：同一业务含义只对应一个状态值，不存在两个状态表达同一进度、或一个状态在不同流程中含义不同的情况。
- 责任人明确：规则命中后每个目标状态或任务都有确定的承接角色，不出现“由相关人员处理”这类无主描述。
- 异常有出口：规则未命中、执行失败、状态冲突时，有指定的人工处理入口或兜底状态。
规则配置阶段
- 触发条件：条件表达式、字段来源、边界值（等于、大于、为空等）逐项写明，并与业务规则文档对照一致。
- 目标状态：规则执行后进入的状态、需要同步更新的字段、是否触发下游规则，逐项确认。
- 执行角色：规则以谁的身份执行、是否具备修改目标对象的权限，确认无权限缺口。
- 通知对象：规则执行后通知谁、通过什么渠道、通知内容包含哪些字段，确认无遗漏对象。
- 生效范围：规则适用的项目、工作项类型、时间范围明确，避免全量生效造成意外命中。
试运行阶段
- 命中样例：用历史数据或构造数据验证规则应当命中的场景确实命中，结果与预期一致。
- 不命中样例：验证不应命中的场景确实未命中，重点覆盖边界值和近似条件。
- 重复执行：同一输入多次执行，结果保持一致，不产生重复流转或状态抖动。
- 异常样例：构造条件缺失、状态冲突等异常输入，确认记录生成且人工接管路径可用。
上线阶段
- 灰度范围：首批生效范围限定在可控制的项目或工作项子集，并明确扩大范围的条件。
- 回退开关：规则可被停用，停用后已流转的数据有恢复或人工修正方案。
- 变更记录：规则上线、停用、修改均留有记录，包含操作人、时间、变更内容。
每项检查的通过标准
通过标准要写成可观察、可取证的结果，而不是“已确认”“已评估”这类动作描述。下面按确定性、审计、异常三类给出判定口径，与上一章的检查项对应使用。
确定性类通过标准
同一输入在多次执行中命中结果一致，是确定性的核心判据。具体表现为：用同一组测试数据连续执行三次以上，命中与不命中的结果完全相同；边界条件有明确定义，例如字段为空时是命中还是不命中、数值等于阈值时归入哪一侧，都在规则说明中写明并有对应测试样例；条件之间不存在互斥或重叠导致的二义性，若两条规则可能同时命中同一对象，明确优先级或合并方式。
审计类通过标准
每次自动流转都能查到四项信息：触发的是哪条规则、执行发生在什么时间、执行前后的状态分别是什么、操作来源是规则自动执行还是人工操作。四项信息缺一即视为未通过。审计核对时随机抽取若干条实际流转记录，逐条比对上述信息与规则配置是否一致，抽样中发现无法追溯的记录，按未通过处理。
异常类通过标准
规则未命中时，有记录说明该对象进入了哪个人工处理环节；执行失败时，失败原因被记录且对象停留在可恢复的状态，不出现半完成状态；状态冲突时，系统或流程层面有明确的处理规则，例如拒绝执行并提示冲突原因。三类异常都要有对应的测试样例和实际记录，仅有设计说明而无运行记录的不算通过。
| 维度 | 检查项 | 通过标准 |
|---|---|---|
| 确定性 | 条件可枚举 | 条件取值组合可完整列出，无“其他情况”兜底 |
| 确定性 | 结果一致 | 同一输入多次执行命中结果相同 |
| 确定性 | 边界明确 | 空值、阈值等边界有书面定义和测试样例 |
| 审计 | 流转可追溯 | 可查到规则、时间、前后状态、操作来源四项信息 |
| 审计 | 变更可追溯 | 规则上线与修改均有操作人、时间、内容记录 |
| 异常 | 未命中可接管 | 未命中对象进入指定人工环节并有记录 |
| 异常 | 失败可恢复 | 失败原因被记录，对象不处于半完成状态 |
证据留存与负责人分工
上线判断要有据可查，每类检查都对应具体证据和责任人。证据在检查完成时即留存，不等到上线评审再补，补记的记录无法证明当时的配置状态。
证据类型与留存时点
- 规则配置快照：配置完成时留存，包含触发条件、目标状态、执行角色、生效范围的完整内容，规则每次修改后重新留存。
- 试运行记录：试运行完成时留存，包含测试数据、预期结果、实际结果和异常样例的处理记录。
- 命中与未命中样例：与试运行记录同时留存，作为确定性判定的直接依据。
- 变更审批记录：规则上线、停用、修改时留存，包含审批人、审批时间和变更说明。
证据保存在团队可访问的统一位置，与规则本身建立对应关系，便于审计时按规则名称或编号检索。保存期限按团队审计要求确定，至少覆盖规则生效期间。
负责人分工
规则业务负责人确认规则与业务规则一致，对条件定义和异常处置方案负责；配置执行人完成规则配置并提交试运行记录；审计核对人抽查流转记录与证据完整性；异常接管人负责规则未命中或执行失败后的人工处理，并在处理完成后反馈规则是否需要调整。负责人空缺时，该项检查视为未完成，由流程负责人指定临时责任人并记录指定过程，不能以“暂由团队共同负责”代替。
| 检查项 | 证据名称 | 留存时点 | 责任人 |
|---|---|---|---|
| 条件可枚举 | 条件定义说明 | 环节筛选完成时 | 规则业务负责人 |
| 规则配置完整 | 规则配置快照 | 配置完成时 | 配置执行人 |
| 试运行通过 | 试运行记录与样例 | 试运行完成时 | 配置执行人 |
| 流转可追溯 | 流转记录抽样结果 | 上线评审前 | 审计核对人 |
| 异常可接管 | 异常处理记录 | 异常发生后 | 异常接管人 |
| 变更可追溯 | 变更审批记录 | 每次变更时 | 流程负责人 |
在研发管理平台中承载这类规则时，规则配置、状态流转和操作记录需要落在同一处，审计核对才能按规则追溯到具体工作项。ONES 的工作项状态流转与操作记录可以支撑流转前后状态、操作人和时间的查询，规则配置与变更也留有记录，便于按上述证据类型归档核对。具体配置方式以团队实际使用的平台能力为准。
阻断项与上线完成条件
阻断项是上线判断的硬边界，任何一条未通过，规则都不应上线，也不以“先上线再补”的方式处理。阻断项之外的检查项可以带条件上线，但要有整改计划和观察期。
阻断项清单
- 条件不可枚举：触发条件存在无法归类的兜底情况，规则命中范围不可预期。
- 状态不唯一：同一业务含义对应多个状态，或状态含义在不同流程中不一致。
- 无异常出口：规则未命中、执行失败或状态冲突时没有人工处理入口。
- 无审计记录：无法查到触发规则、执行时间、前后状态、操作来源中的任何一项。
- 无回退方式：规则无法停用，或停用后已流转数据无法恢复或修正。
阻断项未通过时的处置动作是：停止上线流程，由对应责任人给出整改方案，整改完成后重新执行相关检查项并补充证据，再进入上线评审。阻断项不允许以审批豁免的方式绕过。
非阻断项与整体完成条件
非阻断项包括通知对象不完整、灰度范围偏大、证据保存位置不统一等不影响流转正确性的问题。这类问题可以带条件上线，条件是明确整改责任人和完成时间，并在观察期内复查。观察期长度由团队根据规则影响范围确定，观察期内出现异常按阻断项处理。
整体上线完成条件的判定方式是：阻断项全部通过且有证据支撑；非阻断项有整改计划；每条规则都有明确的业务负责人、配置执行人和异常接管人；上线范围、回退方式和观察期已书面确认。四项同时满足，规则方可上线；任一项缺失，上线评审不通过。
常见问题
环节筛选阶段发现条件只能部分枚举，可以先配置规则再逐步补充条件吗？
不建议。条件不可枚举属于阻断项，规则命中范围不可预期，先上线再补会让未预期的对象被自动流转，事后修正的成本高于推迟上线。
可行的做法是把该环节拆小：先挑出条件能完整枚举的子场景单独配置规则，剩余部分保留人工处理，等条件定义清楚后再纳入自动化范围。拆分后的每条规则仍需独立通过全部检查项。
规则试运行时全部命中符合预期，是否还需要专门构造不命中和异常样例？
需要。只验证命中样例，无法证明规则不会误伤不该流转的对象，也无法确认异常路径可用。
试运行应覆盖四类样例：应当命中、不应命中、边界值（空值、等于阈值）、异常输入（条件缺失、状态冲突）。不命中和异常样例的记录同时是审计证据，缺失时审计类检查项按未通过处理。
规则上线后业务规则发生变化，需要重新走一遍完整检查吗？
按变更影响范围决定深度，但变更审批记录和重新试运行不可省略。若变更只涉及通知对象或生效范围，可只重跑相关检查项；若涉及触发条件、目标状态或状态模型，等同于新规则上线，需重新执行确定性与审计类检查并补充证据。
变更后的规则在扩大生效范围前，应先在原灰度范围内观察，确认命中结果与预期一致再放开。
团队人手紧张，审计核对人和异常接管人由配置执行人兼任可以吗？
角色可以兼任，但检查不能因此省略。配置执行人兼任审计核对人时，抽查流转记录仍需按抽样规则逐条比对规则、时间、前后状态和操作来源，并留下核对记录。
需要留意的是，兼任会削弱独立核对的效果，规则影响范围较大或处于审计范围内的流程，建议由流程负责人另行指定核对人，并在证据中记录指定过程。
非阻断项带条件上线后，观察期内出现问题怎么处理？
观察期内出现的异常按阻断项处理：先停用规则或缩小生效范围，由对应责任人定位原因并整改，整改后重新执行受影响的检查项并补充证据，再恢复上线。
观察期长度由团队根据规则影响范围确定，并在上线前书面写明；观察期结束时应复查非阻断项的整改完成情况，未完成的顺延观察或停用规则。
