自动流转规则把流程中反复出现的判断写成可执行条件，让工作项在满足条件时自动进入下一状态，减少人工催办和漏转。一条完整规则需要说清触发事件、判断条件、执行动作、目标状态、负责人和例外处理。本文按规则要素、建立步骤、角色分工、完整示例和上线检查展开，范围限于规则驱动的流程流转。
要点总览（TL;DR）
- 一条完整的自动流转规则要写清触发事件、判断条件、执行动作与目标状态、负责人与通知记录、例外与人工兜底五类要素，填不出的格子就是规则还没想清楚的地方。
- 建立规则按选试点流程、梳理状态与流转节点、编写条件与动作、小范围试跑校验、发布并纳入变更管理的顺序推进，每步都留下输入、动作、输出和完成标志。
- 角色上区分流程负责人、规则编写人、审批复核人和日常维护人，审批与编写分开，规则台账记录负责人，人员变动时同步移交。
- 上线前逐项检查条件覆盖与冲突、例外路径、记录追溯、回退与停用方式，每项都有可核对的通过标准，启用后前几周重点观察误判和漏判。
一条自动流转规则由哪些要素组成
一条规则能否稳定运行，取决于它是否把“什么时候判断、判断什么、判断后做什么、出了问题找谁”写全。四类要素缺一项，规则就容易在试跑阶段暴露问题：条件写不清会导致误触发，动作不完整会导致状态卡住，责任人不明确会导致异常无人处理。
可以把规则拆成下面这张字段表。编写时逐格填写，填不出来的格子就是规则尚未想清楚的地方。
| 要素 | 要回答的问题 | 填写示例 |
|---|---|---|
| 触发事件 | 规则在什么时点被检查？是创建、字段变更、状态变更，还是定时检查？ | 缺陷工作项被保存时触发检查 |
| 判断条件 | 满足哪些字段组合才执行动作？条件之间是“且”还是“或”？ | 严重程度为“致命”且当前状态为“待处理” |
| 执行动作与目标状态 | 规则命中后改什么字段、把状态推进到哪一步、是否指派处理人？ | 状态改为“处理中”，指派给模块负责人 |
| 负责人、通知对象与记录 | 谁对这条规则负责？动作发生后通知谁？留下什么记录？ | 通知模块负责人与测试提交人，记录触发时间与规则名称 |
| 例外与人工兜底 | 条件不满足、负责人空缺或规则误判时，走哪条人工路径？ | 负责人为空时转交测试负责人手工指派 |
判断条件是最容易写含糊的部分。建议把条件写成可核验的字段比较，例如“优先级等于高”“所属模块属于支付”“距创建时间超过 2 个工作日”，避免使用“重要”“紧急处理”这类需要人再解释的描述。条件数量也要控制，一条规则承担一个判断主题，多个判断主题拆成多条规则，后续排查冲突会容易得多。
执行动作要写明目标状态，而不只是“推进流程”。目标状态是试跑时判断规则是否生效的直接依据：规则命中后状态是否真的变了、指派是否落到预期的人身上、通知是否发给了正确的对象。记录部分则决定事后能否追溯，至少应保留规则名称、触发时间、命中条件和执行结果。
例外与人工兜底常被省略，却是规则长期可用的前提。负责人离职、字段为空、条件互相矛盾都属于正常会出现的情况，规则需要一条明确的人工出口，让工作项回到可处理状态，而不是停在某个中间状态无人认领。
从选流程到上线：自动流转规则的建立步骤
建立规则建议按“先小后大”的顺序推进：先用一条高频、判断标准清晰的流程验证方法，再复制到其他环节。每一步都应有明确输入、动作、输出和完成标志，避免规则写到一半发现状态定义本身就不清楚。
第一步：选试点流程
输入是候选流程清单和近几个月的流转记录。动作是按三个标准筛选：发生频率高、判断标准能用字段表达、流转后的处理人相对固定。输出是一条试点流程及其选择理由。完成标志是能说清“这条流程每月发生多少次、卡在哪个环节、由哪些字段决定去向”。判断标准依赖口头经验的流程暂不适合作为试点，先把字段补齐再纳入。
第二步：梳理状态与流转节点
输入是试点流程的现有状态定义。动作是画出状态清单和允许的流转路径，标出哪些流转由人判断、哪些可以由条件决定。输出是一张状态流转图，包含每个状态的处理人和退出条件。完成标志是每个状态都有明确进入条件、责任人和下一步去向，不存在“其他”“待定”这类模糊状态。
第三步：编写条件与动作
输入是状态流转图和字段清单。动作是按上一节的字段表逐条填写规则，一条规则对应一个判断主题，并为每条规则编号。输出是规则清单，包含规则编号、触发事件、条件、动作、目标状态、通知对象和例外路径。完成标志是每条规则都能被第三个人读懂，并能据此判断某条具体工作项是否会命中。
第四步：小范围试跑与校验
输入是规则清单和一小批真实或构造的工作项。动作是让规则在受限范围内运行，逐条核对命中结果与预期是否一致，重点检查边界情况：条件刚好满足、条件差一个字段、负责人为空。输出是试跑记录，列出每条规则的命中次数、误判和漏判。完成标志是试跑样本覆盖了主要条件分支，且没有出现状态卡死或错误指派。
第五步：发布与变更管理
输入是试跑通过的规则清单。动作是正式启用规则，登记规则负责人和生效范围，并约定变更方式：修改条件、停用规则、新增分支都需要记录原因和影响范围。输出是规则台账，包含版本、生效时间、负责人和变更历史。完成标志是团队知道规则已生效、异常时找谁、以及如何申请调整。
谁负责写规则、谁负责审批、谁负责维护
规则上线后失效，常见原因是没人对它负责。建议把角色拆成四类，每类角色对应明确交付物，避免“大家一起管”变成无人维护。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 流程负责人 | 决定流程目标、状态定义和规则范围，对规则是否符合业务意图负责 | 流程说明、状态定义、规则范围确认 |
| 规则编写人 | 把流程判断翻译成条件与动作，维护规则清单 | 规则清单、条件字段说明、试跑记录 |
| 审批与复核人 | 检查条件覆盖、冲突和例外路径，确认规则可以启用 | 评审意见、上线检查记录 |
| 日常维护人 | 处理规则异常、接收变更申请、更新台账并跟踪生效情况 | 规则台账、变更记录、异常处理记录 |
小团队可以由同一人兼任多个角色，但审批与编写建议分开，让规则在启用前经过一次独立检查。规则数量增多后，维护人需要定期回看命中率和异常记录，把长期不命中或频繁误判的规则列入调整清单。规则台账应记录每条规则的负责人，人员变动时同步移交，避免规则随人员离开而失去维护。
规则落地需要工作项状态和流转记录作为承载。ONES 支持工作项状态流转与流程配置，规则命中后的状态变化、指派和操作记录可以在工作项中留存，便于维护人按台账核对规则是否按预期运行；具体配置方式和适用范围以团队实际使用的版本为准。
一个缺陷流转规则的完整示例
下面以缺陷处理为例，演示一条规则从条件到试跑判断的完整写法。示例为演示情景，字段名称和取值可按团队实际配置调整。
场景与触发条件
测试人员提交缺陷后，严重程度为“致命”的缺陷需要尽快进入修复环节，避免停留在待处理队列。规则在缺陷工作项保存时触发检查，判断条件为：严重程度等于“致命”，且当前状态为“待处理”，且所属模块已配置负责人。
条件分支与动作
规则命中后执行三个动作：状态改为“处理中”，处理人指派为该模块负责人，并向模块负责人和提交人发送通知。若所属模块负责人为空，规则不执行指派，改为将缺陷转交测试负责人，并标记“待人工指派”。这一分支保证条件不完整时工作项仍有明确去向。
状态变化与通知
规则执行后，缺陷从“待处理”进入“处理中”，处理人字段被写入模块负责人，通知内容包含缺陷编号、严重程度和规则名称。工作项记录中保留触发时间与命中条件，便于后续核对。
试跑结果如何判断
试跑时准备三类样本：完全满足条件的缺陷、模块负责人为空的缺陷、严重程度为“严重”的缺陷。预期结果是第一类进入“处理中”并完成指派，第二类转交测试负责人并标记待人工指派，第三类不触发规则、保持原状态。三类结果都符合预期，且记录中能查到触发信息，才可判断这条规则生效。若出现状态改变但指派未写入，说明动作配置不完整，需要回到规则清单修正。
上线前的完成检查
规则正式启用前，建议按下面清单逐项核对。每一项都给出通过标准，避免“看起来没问题”就上线。
| 检查项 | 检查内容 | 通过标准 |
|---|---|---|
| 条件覆盖 | 主要字段组合是否都有对应规则，是否存在无人处理的状态 | 每个状态都有明确的进入条件和处理人，抽样工作项均能落到某条规则或人工路径 |
| 条件冲突 | 多条规则是否会对同一工作项给出不同目标状态 | 冲突规则已合并或设定优先级，试跑中未出现同一工作项被反复改写状态 |
| 例外路径 | 负责人为空、字段缺失、条件不满足时能否走通 | 每类例外都有明确出口，工作项不会停在中间状态 |
| 记录与追溯 | 是否保留规则名称、触发时间、命中条件和执行结果 | 任取一条命中记录，能还原规则为何触发、改了什么、通知了谁 |
| 回退与停用 | 规则误判时能否快速停用并恢复人工处理 | 停用方式已登记，停用后流程仍可人工推进，历史记录不受影响 |
检查完成后，把检查记录与规则台账一并归档，并约定首次回看时间。规则启用后的前几周重点观察误判和漏判，把异常样本补充进试跑用例，再决定是否扩展到其他流程。规则设计是一个持续校准的过程，先让一条规则稳定运行，比一次铺开多条规则更容易发现问题。
常见问题
规则试跑要准备多少样本，怎么判断可以正式启用？
样本量没有统一标准，关键是覆盖主要条件分支。以缺陷流转为例，至少准备三类：完全满足条件的、关键字段为空的、条件差一项不满足的。每类样本都要核对状态是否按预期变化、指派是否落到预期的人、通知是否发给正确对象、记录中能否查到触发信息。三类结果都符合预期，且没有出现状态卡死或错误指派，才可判断规则可以启用。试跑中发现的问题应回到规则清单修正，修正后重新跑一遍受影响的分支。
多条规则同时命中同一条工作项，状态被反复改写怎么办？
这属于条件冲突，通常来自多条规则覆盖了同一字段组合。处理方式有两种：把判断主题相同的规则合并成一条，用条件分支区分；或者为规则设定优先级，明确哪条先执行、哪条不再执行。合并或设定优先级后，用之前出现冲突的工作项重新试跑，确认状态只被改写一次。上线检查中的“条件冲突”一项就是为此设置的，试跑阶段没有暴露冲突，不代表规则数量增加后不会出现，新增规则时需要回看与既有规则的重叠部分。
规则上线后负责人离职或转岗，规则怎么交接？
交接依赖规则台账。台账中每条规则应记录负责人、生效范围、版本和变更历史，人员变动时按台账逐条移交，并同步更新负责人字段。接手人需要能看懂规则的条件和动作，因此规则清单要写得让第三个人可以据此判断某条工作项是否会命中。移交后建议对新负责人做一次小范围复核，确认其能处理异常和变更申请。规则长期无人维护往往不是技术问题，而是台账没有随人员变动更新。
规则误判造成状态错误，怎么快速恢复？
上线前就应登记停用方式，并确认停用后流程仍可人工推进、历史记录不受影响。发生误判时，先停用对应规则，把受影响的工作项按人工路径恢复到正确状态，再排查是条件写错、字段取值变化还是规则之间冲突。排查结论记入变更记录，修正后重新试跑再启用。停用和恢复的过程同样要留痕，便于后续回看这类问题出现的频率，判断是否需要调整字段定义或拆分规则。
哪些流程适合先做自动流转规则，哪些先放一放？
适合先做的是发生频率高、判断标准能用字段表达、流转后处理人相对固定的流程，例如严重程度明确的缺陷流转、字段齐全的审批流转。判断标准依赖口头经验、状态定义本身还含糊的流程，建议先把字段和状态补齐再纳入。试点阶段选一条流程做透，比同时铺开多条更容易发现问题，也便于把试跑用例和检查记录沉淀下来，复用到后续流程。
