制定周期任务触发规则，核心是把重复工作按发生依据分类，再为每类写清触发条件、生成对象、负责人和异常处理，最后登记成规则表并试运行校验。本文按识别、定参、分派、异常处理、角色分工到上线检查的顺序展开，适合正在梳理巡检、报表、复盘等重复性工作的团队参考。
要点总览（TL;DR）
- 一条周期任务触发规则要写清六项：触发依据、触发条件与周期或阈值、生成对象与所属项目、负责人或分派方式、重复跳过补发约定、生效范围与失效条件。
- 先按发生依据把重复工作分成日历型、事件型、状态型三类，再逐条设定周期、时间点、阈值和提前滞后量，参数应来自业务节奏和历史数据。
- 规则触发后必须落到具体任务对象和具体人，固定人、角色、轮值各有适用条件，事件型规则要关联触发事件以便追溯。
- 异常路径要提前约定：用去重键防止同周期重复生成，维护跳过日历，明确漏发判定与补发流程，规则变更只影响新周期。
- 上线前完成至少两周试运行，核对触发可复现、责任清晰、异常有约定、登记与变更记录完整，再固化纳入规则清单。
先给答案：一条周期任务触发规则要写清哪几项
一条可执行的周期任务触发规则，至少要能回答六个问题：为什么触发、什么时候触发、生成什么、交给谁、出问题怎么办、什么时候失效。把这六项写成固定字段，规则才能被配置、被检查、被交接，而不是停留在某个人的记忆里。
| 字段 | 填写内容 | 填写要求 |
|---|---|---|
| 触发依据 | 日历型、事件型或状态型 | 一项规则只选一种主依据，混合依据拆成多条规则 |
| 触发条件与周期/阈值 | 具体日期、间隔、时间点、阈值取值 | 写可复现的参数，不写“定期”“及时”这类模糊表述 |
| 生成的任务对象与所属项目 | 任务类型、标题格式、所属项目或工作项层级 | 标题带周期标识，便于按周期检索和去重 |
| 默认负责人或分派方式 | 固定人、角色或轮值表 | 角色和轮值需附对应名单或排班来源 |
| 重复、跳过、补发约定 | 去重键、跳过条件、补发与确认方式 | 三类情形各写一条处理动作 |
| 生效范围与失效条件 | 适用项目、团队、起止时间、停用触发条件 | 明确规则由谁批准停用、停用后存量任务如何处理 |
这六个字段构成后续所有步骤的落点：分类解决第一项，参数解决第二项，对象与责任解决第三、四项，异常约定解决第五项，治理分工和上线检查保证第六项被持续维护。
第一步：把重复工作分成三类触发依据
并非所有重复工作都适合按固定日历生成。按发生依据分类，可以避免把“上游没交付也要开会”这类工作硬塞进日历规则，也能让事件型和状态型工作获得更准确的触发时机。
| 类型 | 适用工作 | 判断提问 | 常见误判 |
|---|---|---|---|
| 日历型 | 按固定日期或间隔发生：周报汇总、月度对账、季度复盘、例行巡检 | 这项工作是否无论上游进展如何都必须按期发生？ | 把依赖上游交付的测试任务设成每周固定生成，导致任务空转 |
| 事件型 | 由上游交付或外部事件引发：版本发布后的回归测试、合同签署后的建档、客户投诉受理后的回访 | 这项工作是否在某件事完成或发生后才有意义？ | 把发布后动作写成日历规则，发布延期时任务提前出现 |
| 状态型 | 由任务或对象状态变化引发：任务进入待验收后通知评审、需求状态变为已完成后触发文档归档 | 这项工作是否只在某个状态出现时才需要做？ | 用日历规则模拟状态触发，造成同一状态反复生成任务 |
分类时逐项问三个问题：这项工作的时间点由日历决定，还是由某件事决定？如果上游没有发生，任务是否仍有必要？同一项工作在一个周期内可能被触发几次？三个问题的答案指向同一类型时即可定类；指向不同类型时，说明这项工作是复合流程，应拆成多条规则分别承载。
第二步：逐条确定触发条件与周期参数
分类确定后，要把类型翻译成可执行的参数。参数取值应来自业务节奏和历史记录，例如过去半年的实际完成时间分布、上游交付的平均间隔，而不是凭感觉设定。
周期与间隔的设定依据
日历型规则先确定业务节拍：财务对账跟随结账周期，设备巡检跟随保养手册要求，团队周报跟随例会节奏。节拍确定后再选间隔，间隔应等于业务要求的最大间隔，缩短间隔会增加无效任务，拉长间隔会漏掉必要检查。事件型规则以事件完成为起点，写明事件发生后多久生成任务。状态型规则以状态进入为条件，写明状态需保持多久才触发，避免瞬时状态抖动造成误触发。
触发时间点与截止时间的配合
触发时间点决定任务何时出现，截止时间决定任务何时应完成，两者之间要留出实际作业时间。例如周一上午九点生成周报任务、周三下班前截止，中间两个工作日用于收集数据。触发时间点还应避开休息日和系统低峰以外的时段，保证负责人能在任务出现后及时看到。
阈值型条件的取值来源
状态型或数量型规则常涉及阈值，例如“待处理任务超过二十条时生成清理任务”。阈值应来自历史数据的正常波动区间，取明显偏离正常值的水平，并在规则中注明取值依据和复核时间。阈值过低会频繁触发，过高则失去预警意义。
提前量与滞后量的处理
提前量用于需要在截止前启动的工作，例如合同到期前三十天生成续签提醒；滞后量用于允许宽限的场景，例如上游交付后延迟一天生成下游任务，给交接留出缓冲。提前量和滞后量都应按业务容忍度设定，并在规则中写明计算基准日期。
第三步：定义生成对象、负责人和交接方式
规则触发后生成的任务必须落到具体对象和具体人，否则规则越自动，积压越隐蔽。这一步要确定任务长什么样、归谁做、和上下游怎么衔接。
| 要素 | 可选方式 | 适用条件 |
|---|---|---|
| 任务类型与字段 | 标准任务、子任务、检查项；标题含周期标识，描述附作业说明 | 周期标识用于检索和去重，描述应包含完成标准 |
| 负责人指派 | 固定人、角色、轮值表 | 固定人适合职责稳定的岗位；角色适合人员会调整的团队；轮值适合需要多人分担的值守类工作 |
| 上下游交接 | 设置前置依赖、关联上游工作项、指定验收人 | 事件型规则必须关联触发事件，便于追溯任务来源 |
| 与项目模板的边界 | 模板负责一次性项目的结构，触发规则负责重复工作的生成 | 项目模板的设计与维护属于项目计划管理范畴，规则中只引用模板，不在规则内定义模板结构 |
指派方式确定后要验证可执行性：固定人休假时由谁代理，角色对应的成员是否都在岗，轮值表由谁维护。这些答案应写入规则备注，而不是等任务无人认领时再临时协调。任务生成后进入哪个状态、由谁确认接收，也应在规则中写明，形成从生成到认领的闭环。
第四步：处理重复、跳过与补发
规则长期运行，异常路径的处理约定比正常路径更影响可用性。以下四类情形应在规则上线前逐条写明。
- 同一周期内重复触发：为每条规则设定去重键，例如“规则标识＋周期标识”，生成前检查该键是否已存在任务；存在则跳过生成并记录日志。状态型规则还需设置最小触发间隔，防止状态反复变化造成连续生成。
- 节假日或暂停期跳过：维护一份跳过日历，包含法定假日、团队集中休假和业务暂停期。规则命中跳过日时，按约定选择顺延到下一个工作日或直接跳过本周期，两种处理要在规则中固定一种，不能每次临时决定。
- 漏触发后的补发与人工确认：明确漏触发的判定方式，例如超过预定时间一定时长仍未生成即视为漏发。补发可由维护人手动执行，补发后需人工确认任务归属和截止时间是否仍合理；对时效已过的工作，应改为记录说明而非补建任务。
- 规则变更时的历史任务处理：规则调整只影响变更生效后的新周期，已生成的任务保持原样，除非业务负责人明确要求批量调整。变更记录中写明变更内容、生效时间和存量任务处理方式。
角色分工与各环节交付物
规则从提出到退役涉及四类角色。分工不清时，规则容易在配置完成后无人维护，出现漏发也找不到责任人。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 规则提出人（业务负责人） | 识别重复工作、说明业务节拍和完成标准、确认阈值取值 | 规则需求说明，含触发依据分类和参数依据 |
| 规则审核与配置执行人 | 审核字段完整性、配置规则、设置去重与跳过条件 | 已配置的规则及配置记录 |
| 日常维护与异常处理人 | 处理漏发补发、维护跳过日历和轮值表、响应无人认领告警 | 异常处理记录和跳过日历更新 |
| 复盘与调整责任人 | 按周期回顾触发准确率、任务完成情况，决定调整或停用 | 复盘结论和规则变更记录 |
小团队中一人可兼任多个角色，但提出与审核不宜由同一人完成，以保证字段被独立检查。规则数量增多后，建议指定一名规则管理员统一维护规则清单和变更记录。规则清单和变更记录可以放在团队文档库中统一管理，ONES Wiki 支持通过模板库一键创建制式化文档，适合承载规则登记表和变更日志这类需要长期维护的文档。
当规则需要落到任务生成、负责人分派和状态流转时，ONES Project 的自动化规则提供了流程自动化的配置与管理能力，管理者可自定义规则并通过统一平台查看运行情况，运行日志可帮助排查触发异常；其预置模板和自动分配负责人、父子工作项状态联动等场景，可作为配置时的参考。具体配置方式以实际产品为准。
示例：一份周度巡检任务的触发规则
以下示例为演示情景，用于说明字段如何填写，团队可按自身业务替换参数。
工作背景：某运维小组需要对办公网络设备做每周巡检，检查项固定，巡检结果需在周五前汇总给部门负责人。
| 字段 | 填写内容 |
|---|---|
| 触发依据 | 日历型。巡检按周固定发生，与上游交付无关 |
| 触发条件与周期 | 每周一上午九点生成，截止时间为当周周五十七点；跳过日历包含法定假日，命中时顺延至下一个工作日 |
| 生成对象 | 标准任务，标题为“网络设备周巡检-第X周”，描述附检查项清单和完成标准，归属运维项目 |
| 负责人 | 轮值表指派，轮值表由运维组长每月维护；任务生成后状态为待处理，负责人需在当天确认接收 |
| 交接设置 | 任务完成后自动通知部门负责人验收，验收不通过则退回负责人补充 |
| 重复与补发 | 去重键为“巡检规则＋周标识”，同周重复触发时跳过；超过周一十二点未生成视为漏发，由维护人手动补发并确认截止时间 |
| 生效范围与失效 | 适用于运维项目，自批准之日起生效；连续四周无异常且业务调整时可申请停用，停用后不再生成新任务，存量任务照常完成 |
运行后的观察点：连续观察四周，记录每周任务是否在周一上午准时生成、轮值负责人是否当天认领、周五前完成率、是否存在同周重复任务、跳过日顺延是否符合预期。任一观察点出现偏差，先修正参数再扩大适用范围。
上线前的完成检查
规则正式启用前，逐项核对以下检查项，全部通过再固化并纳入规则清单。
- 触发条件可复现：按规则参数手工推演未来四个周期，生成时间和数量与预期一致；事件型和状态型规则能用测试事件验证触发结果。
- 周期参数有依据：周期、时间点、阈值均注明取值来源，提前量和滞后量的计算基准日期明确。
- 责任人与交接明确：每条规则都有负责人指派方式，角色和轮值表有维护人，交接和验收环节已设置。
- 异常处理有约定：去重键、跳过日历、漏发判定与补发流程、规则变更后的存量任务处理均已写入规则。
- 试运行有记录：完成至少两周试运行，记录生成次数、重复次数、漏发次数、认领时长和完成情况，偏差已修正。
- 登记与变更完整：规则已录入规则清单，包含生效范围、失效条件和批准人；变更记录可追溯到具体时间和调整内容。
检查通过后，规则进入常规运行，由复盘责任人按固定周期回顾触发准确率和任务完成质量，把需要调整的参数和停用决定记入变更记录，使规则随业务节奏变化持续保持可用。
常见问题
周期任务触发规则和项目模板有什么区别，应该先做哪个？
两者解决不同问题。项目模板定义一次性项目的结构和阶段，触发规则定义重复工作何时生成、生成什么、交给谁。如果团队的项目结构尚未稳定，先梳理项目模板，再让触发规则引用模板；如果重复性工作已经明确，可以先制定触发规则，模板结构后续再补。规则中只引用模板，不在规则内定义模板结构，避免两处维护同一套内容。
事件型规则的上游事件延期或取消时，已经生成的任务怎么处理？
事件型规则应在配置时关联触发事件，任务生成后保留来源记录。上游事件延期时，由维护人评估已生成任务的截止时间是否仍合理，必要时调整截止时间并在任务中注明原因；上游事件取消时，对应任务应关闭并记录取消依据，而不是直接删除，以便复盘时追溯。若同类取消频繁出现，说明该工作更适合改为状态型或日历型规则，应重新分类。
规则试运行期间发现触发次数明显偏多，应该先调参数还是先改分类？
先判断偏多的原因。如果任务在业务上确实需要发生，只是生成次数超过预期，属于参数问题，应检查周期是否过短、阈值是否过低、状态型规则是否缺少最小触发间隔。如果任务在业务上本不该在该时机出现，例如上游未交付就生成了下游任务，属于分类问题，应把日历型改为事件型或状态型。分类错误时调参数只能缓解表象，建议先修正分类再重新试运行。
小团队人手有限，规则维护角色可以合并吗？
可以合并，但提出与审核不宜由同一人完成，以保证字段被独立检查。日常维护和复盘可以由同一人兼任，前提是跳过日历、轮值表和变更记录都有固定存放位置，交接时能直接查阅。规则数量增多后，建议指定一名规则管理员统一维护规则清单，把配置记录和异常处理记录放在团队文档库中，减少因人员变动造成的信息丢失。
规则上线后业务节奏变化，历史已生成的任务要不要跟着改？
规则调整只影响变更生效后的新周期，已生成的任务保持原样，除非业务负责人明确要求批量调整。变更记录中写明变更内容、生效时间和存量任务处理方式。如果节奏变化较大，例如从每周巡检改为每两周，建议先停用旧规则、按新参数重新试运行，确认生成时间和数量符合预期后再启用，避免新旧规则并行造成重复任务。
