自动化规则长期运行后，数量往往只增不减：新需求不断加规则，旧规则没人复查，几条规则触发条件重叠，出了问题也说不清是谁改的。本文给出一套可落地的治理方法：先建规则台账，再让每次变更走版本记录、评审和回滚，最后按固定周期盘点存量规则，用触发记录和业务状态判断保留、合并、停用或删除。
要点总览（TL;DR）
- 先建规则台账：每条规则有唯一编号、负责人、生效范围、触发条件、执行动作和状态，状态限定为草稿、生效、停用、待删除四类，台账与实际配置定期核对。
- 变更走版本流程：触发条件、执行动作、生效范围变化时升主版本并走评审，仅文案类小修记录后直接发布；发布前保留上一版本配置，写清回滚触发条件和操作人。
- 定期清理按季度全量加月度新增复核执行，用触发次数、命中后人工干预比例、关联流程是否在用、负责人是否在岗等证据判断保留、合并、停用观察或删除。
- 删除前设不少于一个完整业务周期的观察期并通知受影响团队，观察期满无恢复需求再执行删除并归档。
- 用台账覆盖率、变更留痕、盘点执行、数量趋势等检查项验收，连续两个周期不达标的环节需要调整责任人或流程。
先给规则建立可管理的台账
版本管理和定期清理都需要一份共同的底账。没有台账，规则散落在各个项目的配置里，负责人凭记忆维护，盘点时连“一共有多少条、分别管什么”都答不上来。台账的作用是把每条规则变成一条可检索、可追责的记录。
台账字段不必多，但要覆盖定位、责任和状态三类信息。建议至少包含下表字段：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 规则编号 | 全局唯一，建议“流程缩写-序号”，如 CRM-012 | 变更记录、盘点结论都引用此编号 |
| 规则名称 | 用“触发条件+动作”描述，避免“规则1”这类命名 | 快速识别规则用途 |
| 负责人 | 具体到人，写清所属团队 | 变更评审、盘点问询的第一联系人 |
| 所属流程/项目范围 | 写明生效的项目、工作项类型或流程节点 | 判断规则是否仍被业务使用 |
| 触发条件 | 照配置原文摘录，不用概括 | 识别重复或冲突规则 |
| 执行动作 | 改状态、分配负责人、发通知等具体动作 | 评估误触发的影响面 |
| 状态 | 草稿、生效、停用、待删除 | 盘点和清理的操作依据 |
| 当前版本号 | 与变更记录对应 | 追溯最近一次改动 |
| 最近变更日期 | 精确到日 | 识别长期未维护的规则 |
状态取值要严格限定为四类。“草稿”表示已登记但尚未发布；“生效”表示正在运行；“停用”表示暂时关闭、保留配置以备恢复；“待删除”表示已进入观察期、等待最终确认。状态字段是后续盘点的操作入口，随意增加“测试中”“优化中”等模糊状态会让清理判断失去依据。
建账有两种起步方式。存量规则较多时，先从自动化配置中导出全部规则清单，再按上表补齐负责人、所属流程和状态，一次性完成初版台账；规则数量少或分散在多个团队时，按流程分批登记，每个流程由负责人认领本流程的规则，登记完成后合并成总表。两种方式都要指定一名台账维护人，负责合并和格式统一。
台账最容易出的问题是与实际配置脱节：有人在配置里直接改了规则，台账没有同步。解决办法是把核对动作固定下来，例如每次盘点前用配置中的规则清单与台账逐条比对，数量不一致或条件不一致的，当场修正并记录差异原因。台账失真一旦积累，后续的版本记录和盘点结论都会失去参考价值。
在ONES Project中，Project管理员可以在「配置中心」的「自动化规则」页面统一管理团队使用的流程自动化规则，规则清单有集中入口，便于导出后建账。台账本身可以作为一份文档或一组工作项维护，把规则编号、负责人和状态字段固化下来，盘点时按状态筛选即可。
版本管理：变更怎么记录、评审和回滚
版本管理解决的是“这条规则什么时候被谁改过、改成什么样、出问题能不能退回去”。做法是把每次改动当作一次受控发布，而不是在配置页面随手保存。
版本号与变更说明
版本号建议采用“主版本.次版本”两段式：触发条件、执行动作、生效范围发生变化时升主版本，如1.0升到2.0；仅调整通知文案、补充说明等不影响行为的改动升次版本，如1.1升到1.2。每次变更必须写变更说明，包含三项内容：改了什么（对照旧配置描述差异）、为什么改（对应哪条业务需求或问题）、影响哪些流程和团队。变更说明写在版本记录里，与规则编号、版本号、变更人、变更日期放在同一条记录中。
评审角色与判断依据
变更评审不需要固定开会，但要明确谁必须知情、谁有权否决。规则负责人对规则内容负责，提出变更并保证说明完整；流程负责人判断这次改动是否符合流程设计意图、是否影响其他环节；受影响团队代表确认改动不会给本团队的日常工作项带来意外状态变化。三方中任何一方提出异议，变更暂缓，由规则负责人补充说明或调整方案。
发布与回滚
发布前保留上一版本的完整配置，包括触发条件、动作和生效范围，存放在版本记录中或单独的配置备份里。回滚触发条件建议写清楚，例如：发布后出现非预期的状态批量变更、受影响团队反馈误触发、关键流程节点被错误跳过。回滚操作人默认为平台管理员，规则负责人确认回滚范围，回滚后在版本记录中注明回滚原因和恢复的版本号。
哪些改动可以直接发布
区分改动级别能减少不必要的评审负担。仅修改通知文案、补充规则描述、调整负责人显示名称等不影响触发与执行结果的改动，由规则负责人记录版本后直接发布；触发条件、执行动作、生效项目范围、优先级顺序发生变化，以及停用或删除规则，必须走评审。判断标准只有一条：改动是否可能改变规则对工作项的实际处理结果。
ONES 自动化规则提供详细的运行日志，展示规则运行状态，便于在变更发布后观察是否出现异常触发，为回滚判断提供依据。规则变更记录可以与台账放在同一处维护，保证版本号、变更说明和当前状态互相对应。
定期清理：按什么周期、用什么证据判断去留
清理的目标是让规则数量与业务价值保持同步，而不是追求规则越少越好。判断一条规则该不该留，要看它是否仍在产生预期效果，以及维护它的成本是否合理。
盘点周期
建议采用“季度全量+月度新增复核”的节奏。季度盘点覆盖台账中全部生效和停用规则，逐条给出处置结论；月度复核只针对当月新增和当月变更过的规则，确认新规则运行正常、变更达到预期。此外设置触发式盘点：关联流程下线或重构、规则负责人离职或转岗、出现批量误触发事件时，立即对相关规则做专项盘点，不等季度节点。
判断证据
盘点结论要建立在证据上，避免凭印象决定去留。常用证据包括：
- 触发次数：统计周期内规则实际触发的次数，长期为零是重点排查对象；
- 命中后人工干预比例：规则触发后，工作项被人工改回或调整的比例，比例偏高说明规则动作与实际需要不符；
- 关联流程是否仍在使用：规则服务的项目、工作项类型或流程节点是否仍在运行；
- 负责人是否在岗：负责人是否仍在原团队，能否继续承担维护责任；
- 与其他规则的重叠情况：是否存在触发条件和动作高度相似的规则。
四种处置及适用条件
| 处置 | 适用条件 | 后续动作 |
|---|---|---|
| 保留 | 有稳定触发记录，人工干预比例低，关联流程在用，负责人明确 | 更新台账的最近核对日期 |
| 合并 | 两条及以上规则触发条件重叠、动作可被一条规则覆盖 | 新建合并后的规则并走变更评审，原规则停用 |
| 停用观察 | 触发次数低但关联流程仍在用，或负责人暂不明确 | 关闭规则，设置观察期，期间如有人反馈缺失再恢复 |
| 删除 | 关联流程已下线，或观察期满无恢复需求，且无团队依赖 | 进入待删除状态，通知后执行删除 |
删除前的观察期与通知
删除是不可逆动作，需要留出缓冲。建议停用后设置不少于一个完整业务周期的观察期，例如一个迭代或一个月，期间在台账中标记“待删除”并注明观察截止日期。通知范围覆盖规则所属流程的全部受影响团队，说明停用原因、观察期长度和恢复申请方式。观察期内无人提出恢复需求，方可执行删除并在台账中归档记录。
ONES 自动化规则提供统一的管理平台，管理者可以对规则进行实时监测和管控，配合运行日志查看规则的运行状态，为触发次数和异常情况的核查提供入口。盘点结论、观察期截止日期和删除确认可以作为工作项或文档记录，与台账保持同一套编号体系。
角色分工与各环节交付物
治理机制能否持续，取决于每个环节是否有人负责、有明确产出。下表把四类角色与主要环节对应起来：
| 角色 | 主要职责 | 环节交付物 |
|---|---|---|
| 规则负责人 | 维护规则内容，提出变更，编写变更说明，响应盘点问询 | 规则登记信息、变更说明、盘点反馈 |
| 流程负责人 | 判断规则是否符合流程设计，确认规则去留对流程的影响 | 变更评审意见、盘点处置确认 |
| 平台管理员 | 执行配置发布与回滚，维护台账与配置一致，执行停用和删除 | 发布记录、回滚记录、台账核对结果、删除执行记录 |
| 受影响团队 | 反馈规则实际效果，提出恢复或调整需求 | 使用反馈、恢复申请 |
各环节的输入输出要能衔接。建账环节的输入是现有规则配置，输出是完整台账；变更环节的输入是变更申请和变更说明，输出是评审结论、新版本配置和版本记录；盘点环节的输入是台账、运行日志和团队反馈，输出是逐条处置结论；删除环节的输入是观察期结果和通知记录，输出是删除确认和台账归档。
跨团队规则出现争议时，先由规则负责人和流程负责人协商；协商不成，提交到共同上级流程负责人或研发效能负责人裁决，裁决结论写入台账备注，作为后续同类争议的参考。争议期间规则维持现状，不做停用或删除，避免治理动作本身影响业务运行。
一个季度盘点的完整示例
以下为演示情景，用于说明判断过程，不对应真实团队数据。
某研发团队的需求管理流程下累计登记了三十余条自动化规则，季度盘点时发现其中一部分长期没有触发记录。盘点人按台账逐条核对，先查运行日志中的触发情况，再联系规则负责人确认业务背景，最后对照关联流程的当前状态。
其中一条规则负责在需求评审通过后自动将状态改为“待开发”并通知开发负责人。日志显示该规则本季度触发四十余次，人工干预比例很低，关联流程仍在运行，负责人也在岗，处置结论为保留，台账更新核对日期。
另一条规则负责在缺陷关闭时自动通知测试负责人，与另一条“缺陷状态变更通知”规则触发条件重叠。两条规则分别由不同成员登记，动作几乎一致。盘点结论为合并：新建一条覆盖两类通知的规则，走变更评审后发布，原两条规则停用并进入观察期。
还有一条规则服务于一个已下线的旧项目，本季度触发次数为零，关联流程已停止使用。处置结论为停用观察，观察期一个月，通知原项目相关团队。观察期满无人提出恢复，规则状态改为待删除，平台管理员执行删除并在台账中归档。
合并操作本身也产生了版本记录：新规则编号沿用主规则编号并升主版本，变更说明写明合并了哪两条规则、覆盖哪些通知场景；发布前保留了原两条规则的配置，若合并后出现通知遗漏，可按回滚条件恢复原规则。季度盘点结束后，台账中生效规则数量下降，每条规则都有明确的负责人和最近核对日期。
完成检查：治理机制是否真的运转
机制建立后，用下面这份清单逐项核对，判断版本管理和定期清理是否真正落地，而不是停留在文档里。
- 台账覆盖率：配置中存在的规则是否全部登记在台账中，有无遗漏；
- 台账准确率：抽查若干条规则，触发条件、执行动作、状态是否与配置一致；
- 变更留痕：本周期内的每次规则改动是否都有版本号、变更说明和变更人记录；
- 评审痕迹：应走评审的变更是否都有评审结论，直接发布的改动是否符合小修标准；
- 盘点执行：季度全量和月度复核是否按计划完成，是否产出逐条处置结论；
- 停用与删除合规：停用规则是否有观察期记录，删除前是否有通知记录和确认人；
- 数量趋势：规则总量和新增速度是否与业务需求增长匹配，合并和删除是否在持续发生；
- 回滚可用性：抽查最近一次变更，上一版本配置是否可查、回滚操作人是否明确。
清单中任何一项连续两个周期不达标，说明对应环节的责任人或流程需要调整。治理机制的价值体现在规则数量可控、每条规则有人负责、每次改动可追溯，检查结果应作为下一周期盘点的输入，形成持续运转的闭环。
常见问题
规则数量不多、分散在几个团队时，台账还要一次性建全吗？
可以按流程分批登记，不必等全部规则收齐再启动。做法是每个流程由规则负责人认领本流程的规则，登记完成后合并成总表，并指定一名台账维护人负责合并和格式统一。分批登记期间，已登记的流程先按台账执行变更记录和盘点，未登记的流程在下一批补齐。需要注意的是，分批不等于长期缺账，建议给每批登记设定完成时间，避免台账覆盖率长期停留在部分流程。
停用观察期内有团队提出恢复，规则应该怎么处理？
恢复规则按一次变更处理，不能直接把状态改回生效。规则负责人需要补充变更说明，写清恢复原因和观察期内反馈的具体问题，走评审确认后再发布，版本号相应升级。如果恢复时同时调整了触发条件或执行动作，按主版本变更处理；仅恢复原配置的，可在版本记录中注明恢复的版本号。恢复后台账更新状态和最近变更日期，观察期记录保留在历史中，便于后续盘点追溯。
两条规则合并后，原规则的编号和历史记录怎么处理？
建议保留主规则编号并升主版本，变更说明中写明合并了哪几条规则、覆盖哪些场景，被合并的规则状态改为停用并注明“已合并至某编号”。这样历史触发记录和变更记录仍可按原编号查到，不会因为合并丢失追溯线索。合并后的新配置发布前保留原规则配置，若出现通知遗漏或动作缺失，可按回滚条件恢复原规则。台账中为被合并规则保留一行归档记录，盘点时不再计入生效规则数量。
季度盘点时发现某条规则触发次数很高，但人工干预比例也高，该保留还是调整？
这种情况说明规则确实在被使用，但执行结果与实际需要存在偏差，处置方向是调整而非直接停用或删除。盘点时先查运行日志确认触发场景，再与规则负责人和受影响团队核对人工改回的具体原因：是触发条件过宽、执行动作不符合当前流程，还是通知对象有误。确认原因后按变更流程修改规则并走评审，修改后在下一个月度复核中观察人工干预比例是否下降。若调整后比例仍居高不下，再考虑停用观察。
规则负责人离职或转岗后，台账里的规则由谁接手？
负责人变动应作为触发式盘点的场景之一，不等季度节点。流程负责人在人员变动时梳理其名下规则，逐条指定新负责人或判断是否随业务调整停用；新负责人确认接手后，台账更新负责人字段和核对日期。暂时找不到合适负责人的规则，可先停用观察并在台账中标注待认领，避免无人维护的规则继续运行产生误触发。跨团队规则的新负责人由流程负责人与相关团队协商确定，协商结果写入台账备注。
