自动化规则上线一段时间后，常见的问题往往出在清单本身：规则散落在不同项目里，负责人调岗后无人接手，触发条件随流程调整而失效，重复规则互相干扰。本文围绕一份可维护的规则台账，给出字段结构、变更入口、复核节奏、责任分工和验收检查，帮助团队把清单从一次性文档变成持续更新的管理载体。
要点总览（TL;DR）
- 规则台账先定字段：规则标识、触发条件、执行动作、生效范围、负责人、状态、版本号、最近验证结果，缺一项后续就难追溯。
- 新增、修改、停用统一走申请与评审路径，回写台账作为完成标志；已运行过的规则只停用不删除，保留历史记录。
- 复核按影响范围分节奏：关键环节每月、日常提醒每季度，流程调整或负责人变更时触发例外复核，用触发次数、失败率、人工干预次数判断保留、调整还是停用。
- 流程负责人、规则维护人、平台管理员、评审角色各自绑定交付物和交接时点，负责人变动时同步更新台账。
- 用季度检查表核对负责人、验证时间、变更闭环、复核结论和平台配置一致性，连续两个周期通过说明机制可运转。
清单先定字段：一条自动化规则要记什么
台账字段决定了后续能不能查、能不能追、能不能判断有效性。字段设计的原则是：任何一条规则，只看台账就能回答“它做什么、对谁生效、谁负责、现在是否有效”。建议按下表建立字段，其中必填项在规则登记时即完成填写，选填项在运行过程中补充。
| 字段名 | 填写要求 | 是否必填 |
|---|---|---|
| 规则标识 | 全局唯一编号，建议采用“流程缩写-序号”格式，登记后不再变更 | 必填 |
| 规则名称 | 用一句话说明触发什么、做什么，避免“自动提醒1”这类无法辨识的命名 | 必填 |
| 所属流程环节 | 对应到具体流程阶段，如需求评审、开发提测、发布上线 | 必填 |
| 触发条件 | 写清判断对象、比较方式和阈值，例如“工作项状态变为已完成且超过计划完成时间3天” | 必填 |
| 执行动作 | 写清动作类型、接收对象和内容模板，例如“向负责人发送提醒并抄送项目经理” | 必填 |
| 生效范围 | 限定项目、团队、工作项类型，范围为空视为全组织生效，需特别标注 | 必填 |
| 规则负责人 | 对规则配置和验证负责的具体人员，须为在岗人员 | 必填 |
| 业务归属人 | 对规则业务合理性负责的流程角色，通常是流程负责人 | 必填 |
| 状态 | 启用、暂停、停用、待评审四选一，状态变更须记录时间 | 必填 |
| 版本号 | 每次修改触发条件、动作或范围时递增，初始版本记为V1 | 必填 |
| 生效日期 | 当前版本开始生效的日期 | 必填 |
| 最近修改人 | 记录最近一次变更的执行人及修改时间 | 必填 |
| 最近验证时间与结果 | 记录最近一次回归验证的日期和结论，结论分为通过、部分通过、未通过 | 必填 |
| 失败或异常处理方式 | 说明动作执行失败时的兜底做法，如重试、转人工、通知维护人 | 选填，涉及关键流程时必填 |
字段确定后，台账的载体应与团队日常协作工具一致。若团队使用ONES，可以把每条规则登记为一个工作项，用自定义字段承载上述信息，变更记录和验证结论作为工作项下的记录留存；规则清单本身则用一篇文档汇总展示，便于按流程环节筛选查看。这样台账与执行记录在同一处，减少两套数据对不上的情况。
更新入口：规则新增、修改、停用怎么走
规则失效的常见原因之一是变更没有统一入口：有人直接在平台里改了配置，台账没有同步；有人口头通知停用，实际规则仍在运行。解决办法是让所有变更走同一条申请与评审路径，并把回写台账作为流程的完成标志。
变更申请需要写清四个问题：当前流程存在什么问题、希望规则达到什么效果、影响哪些项目和团队、如何判断规则生效。缺少预期效果的申请，评审时无法判断是否值得上线，也难以在复核阶段评估价值。
| 变更类型 | 提出人 | 评审人 | 执行人 | 完成标志 |
|---|---|---|---|---|
| 新增规则 | 流程负责人或业务归属人 | 流程负责人与平台管理员 | 规则维护人 | 规则在测试范围验证通过，台账登记完成并状态置为启用 |
| 修改触发条件或动作 | 规则维护人或业务归属人 | 业务归属人 | 规则维护人 | 回归验证通过，版本号递增，变更记录回写台账 |
| 调整生效范围 | 规则维护人 | 业务归属人 | 规则维护人 | 新范围抽样验证通过，台账范围字段更新 |
| 暂停 | 规则维护人或业务归属人 | 业务归属人确认 | 规则维护人 | 平台配置暂停，台账状态改为暂停并注明原因与预计恢复时间 |
| 停用 | 业务归属人 | 流程负责人 | 规则维护人 | 平台配置关闭，台账状态改为停用，保留全部历史记录 |
修改触发条件或执行动作时，回归验证是必须环节。验证范围至少覆盖原生效范围中的典型场景，确认新条件不会造成误触发或漏触发。验证结论写入台账的“最近验证时间与结果”字段，未通过验证的变更不得上线。
停用与删除要区分开。停用是保留规则记录、关闭平台配置，台账中仍可查到这条规则的历史；删除是从台账中移除记录，只在规则从未生效或登记错误时使用。已经运行过的规则原则上只停用不删除，否则后续排查历史通知来源时会失去依据。
变更完成后，执行人需要在同一工作日内把变更内容、评审结论、验证结果回写台账。回写动作本身也应留下记录，便于检查变更是否闭环。
定期复核：按什么节奏检查规则是否仍然有效
复核的目的是用运行数据回答一个问题：这条规则现在还在解决它当初要解决的问题吗。建议按规则影响范围设定复核周期：影响发布、质量门禁等关键环节的规则每月复核一次；影响日常提醒、状态同步的规则每季度复核一次；低频规则可在每次流程调整后复核。
除固定周期外，以下情形应触发例外复核：流程阶段或审批环节发生调整、组织架构或团队归属变化、平台配置迁移、连续出现规则误触发投诉、负责人变更。
复核时重点看三类数据：触发次数反映规则是否仍在发挥作用，长期零触发需要确认是条件过严还是场景已消失；失败率反映动作执行是否稳定，失败率持续偏高说明配置或权限存在问题；人工干预次数反映规则是否真正减少了手工操作，干预频繁说明规则设计需要调整。
| 复核结论 | 适用情形 | 处置动作 |
|---|---|---|
| 保留 | 触发次数正常、失败率低、无频繁人工干预 | 更新最近复核时间，无需修改配置 |
| 调整 | 触发过多或过少、失败率偏高、范围不再匹配 | 发起变更申请，按变更流程修改并回归验证 |
| 停用 | 场景已消失、与其他规则重复、长期零触发且无保留价值 | 按停用流程关闭配置，台账保留历史记录 |
复核结论和依据数据应记录在台账对应规则下，形成“复核日期—数据摘要—结论—后续动作”的记录结构。重复规则的处理优先合并而非简单停用：先确认两条规则的触发条件和动作重叠部分，保留覆盖更完整的一条，另一条停用并在记录中注明被哪条规则替代。
角色与交付物：谁对清单的准确性负责
台账无人更新，通常不是态度问题，而是职责没有落到具体交付物上。把每个角色的责任绑定到可检查的产物，维护工作才有抓手。
| 角色 | 核心责任 | 交付物 | 交接时点 |
|---|---|---|---|
| 流程负责人 | 判断规则是否符合当前流程设计，决定规则保留或下线 | 复核结论、停用审批意见 | 每次复核结束后 |
| 规则维护人 | 执行配置、回归验证、回写台账 | 变更记录、验证结果 | 变更完成当日 |
| 平台管理员 | 保障规则运行所需的权限、环境和执行稳定性 | 权限变更记录、运行异常说明 | 权限调整或故障处理后 |
| 评审角色 | 在变更中把关业务合理性与影响范围 | 评审意见 | 变更申请提交后两个工作日内 |
规则维护人发生岗位变动时，交接内容应包括：名下所有启用规则的清单、未闭环的变更申请、最近一次验证记录。交接完成后由业务归属人确认台账中的负责人字段已更新，避免出现规则仍在运行但负责人已离岗的情况。
在ONES中，这些交付物可以分别落在工作项和文档上：变更申请作为工作项流转评审状态，验证结果记录在规则工作项下，复核结论汇总到规则清单文档。角色权限通过项目成员配置区分，评审意见随工作项状态变更留存，交接时直接移交工作项负责人即可。
示例：一条超期提醒规则从上线到下线
以下为演示情景，用于说明台账在规则全生命周期中的填写方式。
初始登记。某团队发现需求评审通过后，开发任务经常超过计划完成时间才被发现。流程负责人提出新增规则，登记信息为：规则标识“DEV-012”，名称“开发任务超期3天提醒”，所属环节“开发执行”，触发条件“工作项类型为开发任务且当前日期超过计划完成时间3天且状态未完成”，执行动作“向任务负责人发送提醒，抄送项目经理”，生效范围“A产品项目组”，负责人为规则维护人张某，业务归属人为流程负责人李某，状态启用，版本V1，生效日期3月1日，验证结果为通过。
一次条件调整。运行一个月后，团队反馈提醒在周末频繁发出，干扰休息。张某提交变更申请，说明问题背景和预期效果，将触发条件改为“超过计划完成时间3个工作日”。李某评审通过后，张某在测试项目验证，确认周末不再触发，版本升至V2，变更记录回写台账，注明修改人、修改时间和验证结论。
复核中的处置。季度复核时发现该规则月均触发超过200次，人工干预次数高，说明提醒发出后任务仍未及时处理。复核结论为“调整”：将提醒对象从任务负责人扩展为任务负责人及其直属主管，并在提醒内容中附上任务链接。调整后次月触发次数下降，人工干预明显减少，复核记录中注明调整前后数据对比。
下线保留记录。半年后项目组调整，开发任务改由另一套流程管理，该规则不再适用。李某审批停用，张某关闭平台配置，台账状态改为停用，保留内容包括：全部版本变更记录、历次复核结论、停用原因和停用日期。后续如需追溯历史提醒来源，仍可在台账中查到这条规则。
完成检查：清单维护机制是否可运转
机制是否落地，可以用下面这份检查表逐项核对。建议每季度执行一次，检查结果作为流程改进的输入。
| 检查项 | 核对方法 | 通过标准 |
|---|---|---|
| 每条启用规则都有负责人和最近验证时间 | 按状态筛选启用规则，检查两个字段是否为空 | 无空缺，负责人均为在岗人员 |
| 变更均有评审记录且已回写台账 | 抽取近三个月变更，对照平台配置与台账版本号 | 版本号连续，评审意见可查 |
| 复核按周期执行并有结论 | 检查每条规则的最近复核日期是否在周期内 | 超期规则数量为零或有明确说明 |
| 停用规则保留历史记录 | 筛选停用状态规则，查看变更与复核记录 | 记录完整，停用原因清晰 |
| 清单与平台实际配置一致 | 随机抽取若干规则，比对触发条件、动作和生效范围 | 抽样一致率达到约定标准，差异项已修正 |
检查中发现的问题应转化为具体的整改动作，指定责任人和完成时间，并在下一轮检查时复核整改结果。当这份检查表能够连续两个周期全部通过，说明规则清单已经从静态文档转为可运转的维护机制。
常见问题
规则清单里已经停用的规则，过多久可以删除？
已经运行过的规则建议长期保留停用记录，不设删除时限。停用记录的价值在于追溯：后续排查历史通知来源、复盘流程调整影响、确认某类提醒是否曾经存在，都需要查这条规则。只有从未生效或登记错误的规则才适合从台账中删除。如果台账条目过多影响查阅，可以用状态筛选和归档视图管理，把停用规则收进单独视图，而不是删除记录。
规则负责人调岗或离职，台账应该怎么交接？
交接内容至少包括三部分：名下所有启用规则的清单、未闭环的变更申请、最近一次验证记录。交接完成后由业务归属人确认台账中的负责人字段已更新为接手人。建议把负责人变更本身也作为一次台账变更记录留存，注明原负责人、新负责人和交接日期，这样后续追溯规则配置责任时有据可查。若团队使用ONES，规则工作项的负责人直接移交即可，历史记录随工作项保留。
复核时发现规则长期零触发，应该直接停用吗？
先判断零触发的原因再决定。可能的情况有三种：触发条件设置过严，实际场景存在但从未满足；对应业务场景已经消失；规则被其他规则覆盖。第一种应调整条件后继续观察一个周期；第二种按停用流程处理；第三种优先合并，保留覆盖更完整的一条。直接停用的风险在于，场景可能只是暂时低频，停用后问题重新出现时无人察觉。复核记录中应写明零触发的判断依据和处置理由。
平台配置和台账对不上，以哪个为准？
以平台实际配置为准来修正台账，同时追查差异产生的原因。常见原因是有人绕过变更流程直接改了配置，或者变更后未按时回写。修正时先核对差异项涉及哪些规则，把台账更新为实际状态，再补记一次变更说明。如果差异来自未评审的配置修改，需要按变更流程补做评审和验证。检查表中“清单与平台实际配置一致”这一项就是用来发现这类问题的，建议抽样比对而不是全量核对，把精力放在关键流程规则上。
小团队规则数量不多，也需要这么完整的台账和复核机制吗？
可以按规则数量和影响范围简化，但几个核心要素建议保留：每条规则有负责人、有状态、有最近验证时间，变更后回写台账。规则少于十条时，复核周期可以放宽到每季度一次，检查表也可以只保留负责人、验证时间和配置一致性三项。随着规则数量增加，再逐步补齐版本号、失败处理和评审记录。机制的目的是让规则可追溯，形式可以随团队规模调整。
