不要每天重复催 Codex：怎样把稳定工作流变成 Automation

很多任务并不难，只是会反复出现：

每天汇总失败的 CI；
每周整理 issue 和 PR；
定期检查文档死链；
到固定时间提醒更新项目复盘；
持续观察某个条件是否发生变化。

如果每次都需要重新打开对话、重新说明范围和格式，这部分重复劳动就应该考虑交给 Automation。

Skill 解决“怎么做”，Automation 解决“什么时候做”

Skill 是一份可复用的专项操作手册；Automation 则负责在未来某个时间或周期触发任务。

一个完整自动化通常至少包含三部分：

目标对象：对应哪个项目、仓库、线程或外部信息源；
触发时机：一次提醒、固定时间、周期运行或条件检查；
执行内容：到时具体检查什么、输出什么、是否需要写入。

只有当执行内容已经足够稳定时，自动触发才有意义。

最容易忽略的是“自包含”

自动化运行时，不应该依赖你记得几天前在对话里说过什么。

下面的写法过于模糊：

检查一下文档链接。

更可靠的写法是：

检查 docs/ 目录所有 Markdown 文件中的外部链接。

范围：
- 只检查以 http:// 或 https:// 开头的链接。
- 忽略相对路径和页面锚点。

输出：
- 按“文件 | 行号 | 链接 | 状态”列出失败项。
- 全部正常时输出“全部链接正常”。

验证：
- 请求超时设为 5 秒。
- 不修改任何文件。

第二个任务无论什么时候触发，都有相对稳定的行为。

从低风险任务开始

第一次配置时，优先选择：

只读；
范围明确；
输出可以人工检查；
即使失败也不会产生副作用。

例如：

每个工作日上午检查过去 24 小时的失败 CI。
按仓库、工作流、失败步骤和错误摘要整理。
没有新失败时不要发送通知。
不要重新运行工作流，不要修改代码。

这比“一旦 CI 失败就自动改代码并发布”安全得多。

自动化上线前的四步

1. 先手动跑通

如果任务在普通对话里都不稳定，不要直接定时运行。先确认输入、输出和验证方式。

2. 检查权限边界

自动化是否会联网、写文件、操作外部系统或发送消息？这些能力应该分别确认。

3. 观察第一次真实运行

第一次结果可以暴露很多问题：时间范围错误、重复信息、没有过滤条件、输出过长或权限不足。

4. 设定停止条件

一次性提醒不需要无限保留；阶段性项目也应该有结束日期。条件监控则要说明“条件未满足时是否保持安静”。

哪些任务不适合自动化

目标和范围仍然经常变化；
涉及不可逆删除；
自动部署或修改生产数据；
需要复杂人工判断；
凭据和权限尚未配置清楚；
结果没有可检查的验收标准。

自动化不会修复一套含糊流程，只会更快、更频繁地重复它的问题。

一份通用模板

任务目标：
[每次运行具体完成什么]

检查范围：
- [项目、目录、时间窗口或数据源]

判断规则：
- [什么情况需要输出或通知]
- [什么情况保持安静]

输出格式：
- [字段、排序和长度要求]

权限边界：
- [是否允许联网、写文件、调用外部系统]
- [禁止事项]

失败处理：
- [失败时记录什么]
- [是否重试，是否需要人工处理]

写在最后

Automation 的价值不是“让 Codex 一直忙”，而是把已经成熟的重复流程放到正确时间执行。

可靠的顺序应该是：

手动跑通
→ 写成自包含任务
→ 从只读场景开始
→ 观察第一次运行
→ 调整规则与权限
→ 再长期保留

自动化的上限，取决于流程本身有多清楚。