周期任务触发规则要解决的是重复工作能否按时、按内容、按责任人稳定发生。制定时先把工作拆成触发条件、生成内容、责任人与交付物、完成检查四段，再为每段写明判断标准和处置方式。规则宜从高频、低争议的工作起步，运行一段时间后再扩展范围。
要点总览（TL;DR）
- 触发条件按固定周期、事件、状态变化三类划分：日历决定节奏的工作用周期触发，由另一件事决定的工作用事件触发，需要跟随对象状态反应的工作用状态触发。
- 制定规则按五步走：盘点重复工作、定义触发时点与提前量、绑定任务模板、指定责任人与交接对象、设置生效范围与例外处理，每步都写明输入和完成标志。
- 规则运行需要三类角色：规则负责人维护触发条件与模板版本，任务执行人完成交付物，检查人核对质量与逾期；规则变更走提出、评审、生效的固定流程。
- 规则上线后按周期检查触发是否按时、有无漏触发与重复生成、完成率与逾期分布；连续两个周期漏触发或逾期明显上升时启动规则调整并记录原因。
- ONES Project 的自动化规则提供运行日志和统一管理平台，可用于查看规则运行状态、排查触发异常；文档类模板可借助 ONES Wiki 页面模板库统一格式。
先定触发条件：时间、事件与状态三类规则怎么选
触发条件决定周期任务在什么时点被启动。常见做法是分成按固定周期、按事件、按状态变化三类，再根据工作的确定性程度选择。判断依据可以归结为一句：这项工作什么时候该发生，是由日历决定、由另一件事决定，还是由某个对象的状态决定。
按固定周期触发适用于节奏稳定、内容结构变化不大的工作，例如每日站会记录整理、每周巡检、月度数据汇总、季度复盘准备。这类工作的触发时点可以提前写死，便于排期和统计。按事件触发适用于发生时间不固定、但一旦发生就必须跟进的工作，例如版本发布后启动回归检查、评审通过后启动文档归档、交付节点到达前启动验收准备。按状态变化触发适用于需要根据对象当前情况作出反应的工作，例如任务进入逾期状态后启动升级提醒、状态流转到待评审后启动评审排期。
三类规则混用时，需要先定优先级再去重。一个实用顺序是：状态变化优先于事件，事件优先于固定周期，因为前两类更贴近当下事实。去重原则可以写成两条：同一工作项在同一周期内只生成一次任务；当多条规则同时命中时，保留触发条件更具体的那条，并在规则说明中记录被抑制的规则名称，便于后续排查。
| 工作类型 | 触发方式 | 触发时点 | 去重规则 |
|---|---|---|---|
| 每日站会记录整理 | 固定周期 | 每个工作日固定时间 | 同一工作日只生成一次 |
| 每周巡检 | 固定周期 | 每周固定日期，可设提前量 | 同一周只生成一次，节假日按例外处理 |
| 月度数据汇总 | 固定周期 | 每月固定日期，预留准备提前量 | 同一月份只生成一次 |
| 版本发布后回归检查 | 事件 | 发布完成事件发生时 | 同一版本只生成一次 |
| 评审通过后文档归档 | 事件 | 评审通过事件发生时 | 同一评审单只生成一次 |
| 任务逾期升级提醒 | 状态变化 | 任务进入逾期状态时 | 同一任务在同一逾期周期内只提醒一次 |
| 待评审任务排期 | 状态变化 | 状态流转到待评审时 | 同一任务每次流转只生成一次 |
选择触发方式时还要考虑误触发成本。固定周期规则的误触发通常表现为“没有实际工作也生成任务”，处理方式是允许执行人标记“本期无需执行”并填写原因；事件和状态规则的误触发往往来自条件写得过宽，应把触发条件收窄到具体对象和具体状态，避免一次变更引发大量重复任务。
核心操作步骤：从工作清单到可执行触发规则
把触发规则落到可执行状态，需要按顺序完成五步。每一步都应有明确的输入、动作、输出和完成标志，避免规则停留在口头约定。
第一步：盘点重复工作并筛选适合规则化的对象
输入是团队近一到两个月的任务记录、会议纪要和交接记录。动作是列出所有重复出现的工作，标注发生频率、参与角色、是否有固定交付物。输出是一张重复工作清单。完成标志是清单中每项工作都写明了频率和交付物，并筛出高频、低争议、流程稳定的工作作为首批规则化对象。争议大、每次做法都不同的工作暂不纳入。
第二步：为每项工作定义触发时点与提前量
输入是上一步的清单。动作是为每项工作选定触发方式，写明具体时点和提前量，例如“每周一上午生成，提前一天提醒责任人”。提前量要覆盖准备所需时间，太短会导致任务一生成就临近截止。输出是每项工作的触发条件说明。完成标志是任何人读到这条说明，都能判断任务会在什么时候出现。
第三步：绑定任务模板，固定标题、字段、检查项与附件
输入是触发条件说明和该类工作的历史交付物。动作是把任务标题格式、必填字段、检查项清单和参考附件整理成模板，让每次生成的任务结构一致。检查项要写成可勾选、可判断的条目，例如“巡检记录已填写”“异常项已登记责任人”。输出是一份任务模板。完成标志是用模板生成一条样例任务，字段完整、检查项可执行。
第四步：指定责任人与交接对象
输入是任务模板和团队分工。动作是为每类任务指定默认执行人、检查人和交接对象，并写明交接发生在什么状态之后。输出是责任分配记录。完成标志是每条规则都能回答“谁来做、做完交给谁、谁确认”。
第五步：设置生效范围、暂停与例外处理
输入是前四步的成果。动作是明确规则适用的团队或项目范围，约定暂停条件（如长假、项目冻结）和例外处理方式（如本期无需执行、临时改期）。输出是规则配置说明。完成标志是规则在约定范围内生效，且暂停和例外都有记录位置。
在工具承载上，ONES Project 提供自动化规则能力，管理者可以自定义规则，并通过统一的管理平台查看规则运行情况；规则运行日志可用于排查触发异常。任务模板与检查项的组织方式需结合团队实际配置确定，文档类模板可借助 ONES Wiki 的页面模板库统一格式。
角色与交付物：谁维护规则、谁执行任务、谁检查结果
规则能否长期运行，取决于维护、执行、检查三类角色是否清楚。规则无人维护时，触发条件会随组织变化逐渐失真；执行与检查不分时，完成质量难以判断。
| 角色 | 职责 | 交付物 | 检查时点 |
|---|---|---|---|
| 规则负责人 | 维护触发条件、任务模板和规则版本，处理暂停与例外 | 规则说明、模板版本记录、变更记录 | 每次规则变更前后 |
| 任务执行人 | 按生成任务完成交付物，填写字段与检查项 | 任务交付物、检查项勾选结果 | 任务截止前 |
| 检查人 | 核对完成质量、逾期情况和异常项处置 | 检查记录、异常项处理结论 | 每个周期结束后 |
| 规则变更提出人 | 提出触发条件或模板调整需求并说明原因 | 变更申请 | 发现规则不适用时 |
规则变更应有固定流程：提出人写明变更内容和原因，规则负责人评估影响范围，涉及多团队时由检查人参与评审，确认后更新规则版本并记录生效时间。变更生效后保留旧版本说明，便于对照历史任务的生成情况。规则负责人宜定期复核触发条件是否仍与工作实际一致，复核周期可与规则的检查周期一致。
示例：一份周度巡检周期任务的触发规则
以下示例为演示情景，用于说明一条完整规则的写法，团队可根据实际工作改写。
工作背景与触发方式。某团队每周需要对办公区域设备做一次巡检，工作内容固定、频率稳定，适合按固定周期触发。选择固定周期而非事件触发，是因为巡检节奏由管理要求决定，不依赖某次具体事件。
触发条件与提前量。规则写为：每周一上午九点生成巡检任务，提前一天向执行人发送提醒；遇法定节假日顺延至下一个工作日，顺延情况由规则负责人提前登记。
任务模板字段与检查项。任务标题格式为“设备巡检-第X周”；必填字段包括巡检区域、巡检人、巡检日期、异常数量；检查项包括“设备运行状态已逐项确认”“异常设备已拍照登记”“异常项已指定处理人”“巡检记录已归档”。附件区放置巡检记录表和上期异常处理记录。
责任人与交付物。默认执行人为当周值班人员，检查人为团队负责人，交接对象为设备维护组。执行人交付填写完整的巡检记录和异常清单，检查人确认异常项均有处理人后关闭任务。
运行一周后的检查记录示例。第一周记录显示：任务按计划生成，执行人在截止前完成巡检，检查项全部勾选；发现两台设备异常，已登记处理人；检查人复核后确认异常项进入处理流程；本周无重复生成，无漏触发。记录中同时注明“下期需补充备用设备检查项”，作为模板调整依据。
完成检查：验证触发规则是否按预期运行
规则上线后需要验证它是否按设计运行。检查重点包括触发是否按时、是否出现重复或错误生成、任务完成情况如何，以及规则是否需要调整。
| 检查项 | 检查方法 | 判断标准 | 异常处置 |
|---|---|---|---|
| 触发是否按时发生 | 对照规则说明核对生成时间 | 生成时间与约定时点一致 | 记录偏差，检查触发条件设置 |
| 有无漏触发 | 按周期核对应生成任务数量与实际数量 | 数量一致，无缺失周期 | 排查规则生效范围与暂停记录 |
| 有无重复生成 | 检查同一周期同一工作的任务数量 | 同一周期只有一条有效任务 | 收窄触发条件，补充去重规则 |
| 有无错误生成 | 抽查生成任务的内容与模板一致性 | 标题、字段、检查项符合模板 | 修正模板或触发对象范围 |
| 完成率与逾期分布 | 统计各周期完成数量和逾期任务 | 完成率稳定，逾期集中在可解释环节 | 调整提前量或责任分配 |
检查频率可与任务周期匹配：周任务按周检查，月任务按月检查，规则上线首月适当加密。检查结果应形成记录，写明检查日期、检查人、发现的问题和处置结论。规则调整需要设定触发条件，例如连续两个周期出现漏触发、逾期率明显上升、工作内容发生结构性变化，或执行人反馈模板字段不再适用。每次调整都记录调整原因、调整内容和生效时间，保留调整前的规则说明，便于回溯任务生成差异。
借助 ONES Project 的自动化规则运行日志，可以查看规则运行状态，辅助定位漏触发和异常生成；统一的管理平台便于集中查看多条规则的运行情况。检查记录和规则说明可沉淀在 ONES Wiki 的文档模板中，与任务关联，形成可追溯的规则维护记录。
常见问题
团队第一次制定周期任务触发规则，应该从哪类工作开始？
优先选择高频、低争议、流程稳定的工作，例如每周巡检、每日记录整理、月度数据汇总。这类工作的发生频率和交付物相对固定，触发条件和模板容易写清楚，运行后也便于判断规则是否有效。争议大、每次做法都不同的工作先不纳入，等做法稳定后再补规则。
首批规则数量控制在团队能逐条检查的范围内，运行一到两个周期后再扩展，比一次性铺开更容易发现触发条件写得过宽或提前量不足的问题。
固定周期触发和事件触发同时命中同一项工作时怎么处理？
先定优先级再去重。一个实用顺序是状态变化优先于事件，事件优先于固定周期，因为前两类更贴近当下事实。去重原则写成两条：同一工作项在同一周期内只生成一次任务；多条规则同时命中时保留触发条件更具体的那条，并在规则说明中记录被抑制的规则名称。
如果固定周期规则经常被事件规则抑制，说明这项工作的节奏实际上由事件决定，可以考虑把触发方式改为事件触发，减少无效生成。
规则上线后发现任务生成时间不准或漏生成，先查什么？
按顺序排查三处：一是规则生效范围，确认目标团队或项目在规则覆盖范围内；二是暂停与例外记录，确认当期没有因长假或项目冻结被暂停；三是触发条件本身，核对时点、提前量和触发对象是否写得过窄或过宽。
ONES Project 的自动化规则提供运行日志，可以查看规则的运行状态，辅助定位漏触发和异常生成。排查结论记入检查记录，写明检查日期、问题和处置方式，便于后续对照。
规则负责人多久复核一次触发条件比较合适？
复核周期与任务的检查周期保持一致即可：周任务按周看，月任务按月看，规则上线首月适当加密。复核内容不只是触发是否按时，还包括模板字段是否仍适用、责任人是否发生变动、提前量是否还够准备时间。
出现以下情况时不必等复核周期，直接启动调整：连续两个周期漏触发、逾期率明显上升、工作内容发生结构性变化、执行人反馈模板字段不再适用。每次调整记录原因、内容和生效时间，保留调整前的规则说明。
任务模板里的检查项应该写多细？
检查项写到可勾选、可判断的程度即可，例如“巡检记录已填写”“异常项已登记责任人”，避免写成“做好巡检”这类无法判断是否完成的表述。检查项数量控制在执行人能在任务截止前逐项确认的范围内，过多会让勾选流于形式。
模板调整可以从运行记录中找依据，例如示例中第一周检查记录注明“下期需补充备用设备检查项”，就属于由实际运行反馈推动的模板修订。
