制定自动流转规则，核心是把“谁在什么条件下把什么工作项推进到哪个状态”写成可判定的条件、动作与例外，并指定规则负责人、配置人、验证人和业务确认人。做法上先选一条高频、边界清晰的流程试跑，核对命中、误触发与漏触发，再补齐变更与停用机制。本文覆盖规则驱动的流程流转，规则需要工作项状态与字段承载，可自然落到ONES这类研发管理工具中。
要点总览（TL;DR）
- 先按触发频率、判断确定性、影响范围筛选候选流转，优先做高频、条件可判定、误触发可回退的流程。
- 一条规则写清六个字段：触发事件与前置条件、判断字段与取值口径、执行动作与目标状态、例外与人工兜底、生效范围与优先级、规则标识与变更记录。
- 按梳理现状、转字段条件、写动作与通知、小范围试跑、业务确认归档五步推进，每步都有输入、输出和完成标志。
- 流程负责人、规则配置人、业务验证人、规则维护人分工明确，流程负责人与业务验证人建议分开。
- 上线前逐项核对条件字段、动作结果、例外责任、试跑覆盖和版本记录，任一项不通过即阻断上线。
先定规则边界：哪些流转值得自动化
自动流转规则适合从“人工判断重复、判断标准明确、出错代价可控”的流转开始。一上来铺开全流程，往往在字段不全、状态定义模糊的阶段就卡住，规则上线后频繁误触发，反而增加维护负担。筛选候选流转时，可以按三个维度打分。
| 筛选维度 | 判断问题 | 高分特征 | 低分特征 |
|---|---|---|---|
| 触发频率 | 这类流转每周发生多少次 | 每天或每周多次，人工操作集中 | 每月零星几次，自动化收益有限 |
| 判断确定性 | 推进条件能否用字段取值判定 | 条件可写成明确的字段与取值组合 | 依赖经验判断、口头协商或外部信息 |
| 影响范围 | 误触发会造成多大返工 | 误触发可回退，影响单个工作项 | 误触发会触发下游交付或对外承诺 |
三个维度都偏高的流转优先进入清单；频率高但判断确定性低的，先补字段和状态定义，暂不配置规则；影响范围大的流转，即使条件明确，也应先小范围试跑再放开。
需要区分几类容易混淆的自动化。规则驱动流转依据预设条件和动作执行，行为可预期、可审计；AI智能编排根据上下文推断下一步动作，适合判断标准难以穷举的场景，但结果需要人工复核；系统接口对接解决的是不同系统之间的数据传递，不负责状态推进的业务判断。本文讨论的是第一类，后两类只在规则无法覆盖时作为补充手段考虑。
筛选完成后输出一份待自动化流转清单，字段包括：流转名称、当前人工操作方式、触发频率、判断依据、影响范围、优先级、排除原因。排除项要写明原因，例如“条件依赖客户确认邮件，暂无对应字段”，避免后续重复讨论。
核心答案：一条自动流转规则的六个组成字段
一条可执行的自动流转规则，需要写清六个部分。缺任何一项，规则在运行中都会出现“该触发没触发”或“不该触发却触发”的问题。下表可作为空白模板直接填写。
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 触发事件与前置条件 | 规则在什么事件发生时被检查，例如工作项创建、字段更新、状态变更 | 触发事件要单一明确；前置条件写清规则生效前必须满足的状态 |
| 判断字段与取值口径 | 用哪些字段、取什么值作为推进依据 | 字段必须真实存在；取值口径写清是等于、包含还是为空，避免“差不多完成”这类模糊描述 |
| 执行动作与目标状态 | 规则命中后做什么，工作项推进到哪个状态 | 动作与目标状态一一对应；一次规则只做一类推进，避免连锁变更难以排查 |
| 例外与人工兜底 | 哪些情况不自动推进，由谁处理 | 例外条件要可判定；兜底人要有名有岗，不能写“相关人员” |
| 生效范围与优先级 | 规则适用于哪些项目、工作项类型；与其他规则冲突时谁优先 | 范围尽量收窄；多条规则可能同时命中时，明确优先级顺序 |
| 规则标识与变更记录 | 规则编号、名称、创建人、版本、变更说明 | 每次修改留记录，停用规则保留历史，便于回溯 |
六个字段中，判断字段与取值口径最容易出问题。常见情况是规则写“测试完成后流转”，但系统中没有“测试完成”这个字段，只能靠人工改状态，规则实际无法运行。编写时要把每个判断点落到具体字段名和取值上，字段不存在就先补字段规范，再回来写规则。
编写步骤：从草稿到可上线规则
规则编写按五步推进，每步都有明确的输入、动作、输出和完成标志，避免写到一半发现条件无法落地。
第一步：梳理现状流转路径与人工判断点
输入是当前流程的状态定义和最近一段时间的真实单据。动作是画出工作项从创建到关闭的实际路径，标出哪些节点靠人工判断推进、判断依据是什么、由谁判断。输出是一张现状流转图，人工判断点用标记注明。完成标志是每个判断点都能对应到具体的人和判断依据。
第二步：把判断点转成字段条件并核对字段是否存在
输入是上一步的判断点清单。动作是逐条把判断依据翻译成“字段+取值”的条件表达式，并到系统中核对字段是否真实存在、取值是否规范。输出是条件对照表，字段缺失的标注为待补。完成标志是所有条件字段都能在系统中找到，且取值口径唯一。
第三步：写动作与通知，明确状态变更后的责任转移
输入是条件对照表。动作是为每条规则写明命中后的目标状态、通知对象和新的责任人。状态推进意味着责任转移，规则要写清推进后由谁接手，通知发给接手人而非原处理人。输出是规则草稿，包含动作、通知对象和责任归属。完成标志是每条规则都能回答“推进后谁负责下一步”。
第四步：配置后小范围试跑并记录命中情况
输入是规则草稿和一批真实单据。动作是在单个项目或单个工作项类型上启用规则，用真实单据运行一段时间，记录每次触发是否命中、是否误触发、是否漏触发。输出是试跑记录表，字段包括单据编号、预期结果、实际结果、偏差原因。完成标志是正常单据和边界单据都有覆盖，偏差原因已逐条分析。
| 试跑记录字段 | 填写示例 |
|---|---|
| 单据编号 | 缺陷-1024 |
| 预期结果 | 严重程度为致命且指派给开发后，自动流转到“待修复” |
| 实际结果 | 已流转到“待修复”，通知发送给开发负责人 |
| 偏差原因 | 无；或“严重程度字段为空，规则未触发” |
第五步：上线前完成业务确认与规则归档
输入是试跑记录和规则草稿。动作是由业务确认人核对规则是否符合实际流转要求，确认后把规则编号、版本、生效范围、负责人归档。输出是已确认的规则清单和归档记录。完成标志是业务确认人签字或书面确认，规则在系统中处于启用状态且有版本记录。
在ONES这类研发管理工具中，工作项状态、字段和通知是规则运行的承载基础，规则配置通常围绕工作项类型和状态流转展开。具体支持的条件类型和动作类型，建议在配置前对照产品当前文档确认，避免按旧版本能力设计规则。
角色与交付物分工
规则无人负责是自动流转失效的常见原因。制定过程中至少涉及四类角色，各自交付物和交接时点要提前约定。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 流程负责人 | 定义流转目标与验收标准，决定哪些流转进入自动化 | 待自动化流转清单、验收标准 | 规则编写启动前 |
| 规则配置人 | 完成条件与动作配置，处理字段缺失问题 | 规则配置、条件对照表 | 试跑开始前 |
| 业务验证人 | 用真实单据核对命中与结果，确认责任转移合理 | 试跑记录表、业务确认意见 | 上线前 |
| 规则维护人 | 处理变更、停用与规则冲突，保留版本记录 | 变更记录、停用说明 | 上线后持续 |
小团队中一人可兼多个角色，但流程负责人和业务验证人建议分开，避免自己定标准自己验收。规则维护人要在上线时就指定，不能等规则出问题再找人。
示例：一条缺陷修复流转规则怎么写
以下示例为演示情景，用于说明字段填写方式，读者可迁移到自己的缺陷管理流程。
示例场景与触发事件：缺陷工作项在测试环节被确认，严重程度为致命或严重，且已指派给开发人员。触发事件为“指派人字段更新”。
条件字段与取值写法：严重程度等于“致命”或“严重”；当前状态等于“待修复”；指派人字段不为空。三个条件同时满足才触发。
动作、目标状态与通知对象：动作是把状态从“待修复”推进到“修复中”，通知对象为指派的开发人员和其直属负责人，通知内容包含缺陷编号和严重程度。
例外情况与人工介入方式：严重程度字段为空时不触发，由测试人员补填后重新检查；指派人离职或为空时，规则不推进，通知测试负责人手动指派。例外路径的责任人写进规则说明。
试跑结果如何判断规则可用：用最近两周的真实缺陷单据试跑，核对三类情况：符合条件的单据是否全部流转、严重程度为一般的单据是否未被误触发、字段为空的边界单据是否按例外处理。三类都符合预期，且偏差原因已分析清楚，规则可进入业务确认。
完成检查：规则上线前逐项核对
上线前按下表逐项核对，任何一项不通过都应阻断上线，修正后重新检查。
| 检查项 | 通过标准 | 阻断条件 |
|---|---|---|
| 条件字段存在且取值可判定 | 每个条件字段在系统中存在，取值口径唯一 | 存在字段缺失或取值依赖人工描述 |
| 动作结果与目标状态一致 | 规则命中的动作与预期目标状态一一对应 | 动作会引发未预期的连锁状态变更 |
| 例外路径有人负责 | 每条例外都写明处理人和处理方式 | 例外处理人写“相关人员”或空缺 |
| 试跑覆盖正常与边界单据 | 正常单据、边界单据、异常单据均有试跑记录 | 只用正常单据试跑，边界情况未验证 |
| 规则有负责人、有版本记录、可停用 | 规则维护人已指定，版本和停用方式已记录 | 规则无维护人或无法单独停用 |
检查通过后，规则进入启用状态，维护人按变更记录管理后续调整。规则的价值在于减少状态推进中的人工判断和口头催促，因此每条规则都要保留明确的输入字段、输出状态和完成标志，定期回看命中率和误触发情况，条件变化时及时修订或停用。
常见问题
规则试跑多久、用多少单据才算够？
试跑时长和单据量取决于流转频率，判断标准是覆盖三类情况：正常单据、边界单据（如字段为空、取值处于临界）、异常单据（如指派人离职）。高频流转通常一到两周的真实单据即可覆盖；低频流转需要按发生次数累积，直到三类情况都出现过。试跑记录表里每类至少有几条可分析的样本，偏差原因逐条写清，就可以进入业务确认。
多条规则同时命中同一个工作项时怎么处理？
在规则字段的“生效范围与优先级”中提前约定顺序，例如按规则编号或业务优先级排序，并规定同一工作项一次只执行一条推进规则。配置完成后用一条可能同时满足多条规则的单据专门验证，确认实际执行结果与约定顺序一致。若两条规则的目标状态互相冲突，应合并为一条规则或拆开生效范围，避免依赖优先级掩盖设计问题。
流程调整后，已上线的规则怎么维护？
由规则维护人按变更记录处理：状态定义或字段口径变化时，先停用受影响规则，再修改条件并重新试跑，通过后启用新版本，旧版本保留记录。规则停用期间，原来自动推进的节点回到人工处理，需要提前通知相关处理人，避免工作项停滞。建议每次流程评审时同步回看规则命中率和误触发情况，把不再适用的规则停用，而不是长期挂着。
条件依赖的字段在系统里不存在，规则还能做吗？
先补字段再写规则。把判断依据翻译成“字段+取值”时，如果系统中找不到对应字段，说明现状流转依赖的是口头或外部信息，此时配置规则也无法稳定触发。做法是把缺失字段列入字段规范待补清单，明确字段类型、取值枚举和填写责任人，字段上线并积累一段真实数据后，再回到规则编写。字段补齐前，该流转暂不进入自动化清单。
小团队人手有限，角色可以合并吗？
可以合并配置人和维护人，也可以由流程负责人兼任配置人，但流程负责人和业务验证人建议分开，避免自己定验收标准自己确认。合并角色时要在规则归档中写清每个角色由谁承担，交接时点仍按原约定执行，尤其是上线前的业务确认和上线后的维护责任，需要有明确的人承接。
