“每天运行一次”只是定时任务的表层外壳。真正决定其能否无人值守运行的，是当输入未到达时如何处理、重复运行是否会生成两套结果、凭证过期时如何停止，以及如何验证完成状态。在配置计划表之前，必须清晰定义这些问题。
首先判断工作流是否适合定时调度
当工作具有固定频率、明确的输入来源、可文档化的决策规则以及可核查的结果时，才适合进行定时调度。不要自动化那些每次都需要临时协调、目标不断变化或依赖口头提供关键信息的工作。
连续手动执行该流程数次并记录差异。如果每次步骤都不同，应先修复工作流，而不是用调度器来掩盖其不稳定性。
- 触发时间或事件明确定义
- 输入路径和格式稳定
- 异常可分类处理
- 结果有固定存放位置并指定负责人
将需求文档化为“任务合同”
任务合同至少应明确时区与触发条件、读取内容、允许的操作、禁止的操作、成功交付物、失败通知方式以及最大运行时长。
例如，“每天检查网站”过于模糊。可改为：每天 09:00（Asia/Shanghai），读取指定的站点地图，仅检查正文内容中的内部链接；输出带日期的 CSV 文件；记录所有 404 错误但绝不自动删除页面；即使无变更也需记录运行状态。
- 将任务绑定至特定时区
- 定义空输入的终止规则
- 限制外部写入范围
- 明确输出格式与保留周期
使用幂等性规则防止重复执行
网络超时可能触发重试。如果每次运行都创建新文章、重复发送消息或追加相同记录，一次失败就可能引发多重副作用。请使用“日期+任务名称”或业务主键作为唯一标识，并在写入前检查状态。
对于本身不具备幂等性的操作，先创建草稿或待审批记录，最后通过单一步骤完成提交。重试时，从上次确认的安全节点继续。
- 每次运行拥有唯一 ID
- 写入前检查任务是否已完成
- 最终发布仅执行一次
- 允许部分失败的步骤独立重跑
上线前执行三次故障演练
故意模拟空输入、外部 API 超时和凭证无效的情况。确认任务能在安全点停止，错误报告能指出最后成功的步骤，且恢复操作不会导致重复写入。
首次生产环境运行请使用只读或草稿模式。运行结束后，直接打开最终文件或页面，而非仅检查进程状态。同时单独测试通知渠道。
- 设置整体超时时间与重试上限
- 故障通知中需包含任务 ID 和时间
- 验证交付物本身，而非仅检查成功状态
- 保留手动停止选项
上线后维护检查清单
定期检查调度是否仍启用、凭证是否临近过期、输入结构是否变更、空结果是否预示问题，以及旧交付物是否按策略清理。工作流发生变更时，请返回测试模式。
SmaugBrain 支持定时执行，但任务合同、权限和验收标准仍需由业务负责人确定。建议从低风险任务开始，如查询公开信息或创建内部草稿。
- 记录开始时间、结束时间及结果数量
- 为故障和长时间无活动设置独立告警
- 每季度审查一次权限
- 保留回滚步骤
延伸阅读
如需继续了解相关流程，请阅读 无结果定时任务的排查顺序 和 工作流监控与恢复。
下一步
首先在 SmaugBrain 中创建一个只读定时任务。在开启写入权限之前，务必验证任务合同与故障演练结果。