Appearance
Codex 定时任务与持续目标实战
自动化不是把一个模糊提示设成每天运行。正确顺序是：手动跑通、固定输入输出、加入验证和失败策略，最后才设定持续目标或计划任务。
Goal 与 Scheduled task 的区别
- Goal：同一个任务围绕一个明确完成条件持续推进，适合需要数小时或多轮的项目。
- Scheduled task：按时间创建独立运行，适合日报、检查、监控和周期性整理。
如果每次运行都应该从新状态开始，使用定时任务；如果要延续当前调查、上下文和决策，使用 Goal。
用 Goal 驱动长任务
先在 App 中使用 /plan 调查并确认方案，再设置：
text
/goal
完成订单导出功能：实现后端导出、前端下载、权限与上限处理、测试、文档和最终构建。保持现有列表 API 不变，不提交或推送。只有所有验收项都有验证证据才算完成。好的完成条件包含：
- 明确交付物；
- 不可改变的边界；
- 验证命令和用户路径；
- 外部动作限制；
- 哪些情况必须停下来询问。
运行中可以补充信息或纠偏，但不要不断改变核心目标。新需求应拆为后续任务。
适合 Goal 的任务
- 多阶段重构；
- 大型文档站补全；
- 跨模块功能并带测试和审查；
- 持续排查难复现故障；
- 大批量但可验证的迁移。
不适合：完成标准本身未决、需要频繁业务审批、不可逆生产操作，以及没有可观察验证的探索。
创建 Scheduled task 前先手动跑三次
候选流程至少手动运行几次，确认：
- 输入来源稳定；
- 输出格式可审查；
- 没有依赖临时聊天上下文；
- 失败会明确报告；
- 不会修改正在使用的工作树；
- 权限和成本可接受。
将稳定方法固化成 Skill，定时任务只负责“何时、在哪个项目、用哪个输入运行”。
创建一个只读周报任务
在桌面应用 Scheduled 页面创建，选择项目、执行环境和时间。示例提示：
text
生成本周项目变化摘要。
范围：从上周一 00:00 到现在的已提交记录和当前 CI 状态。
输出：
1. 已交付功能；
2. 重要修复；
3. 仍失败的检查；
4. 下周需要人工决策的问题；
5. 引用对应提交或工作流链接。
只读，不修改仓库，不创建 issue，不发送消息。找不到证据时写“未确认”。Git 仓库的定时任务优先使用专用 background worktree，避免与 Local 修改冲突。
一个安全的自动 Bug 扫描任务
第一阶段只报告：
text
检查最近 24 小时合入的代码，寻找一个能被测试或明确复现的真实回归。
只输出：触发条件、证据、影响、最小修复建议和验证命令。
不要修改代码、创建分支、提交或评论 PR。报告质量稳定后，再增加“在独立 worktree 中生成候选修复，但不要推送”。最后才考虑自动创建草稿 PR。不要一步跨到自动合并。
测试定时任务
创建后先手动触发一次，检查：
- 实际项目和分支；
- worktree 是否正确；
- 时区和计划时间；
- Skills、Plugins、MCP 是否加载；
- 网络和认证是否可用；
- 输出发到哪里；
- 失败是否产生可见通知；
- 是否留下未清理 worktree。
修改提示后重新测试，不要等下一次正式运行才发现问题。
权限与外部动作
定时任务无人实时盯着，权限应比交互任务更窄：
- 默认只读；
- 写入仅限独立 worktree；
- 网络按域名或工具限制；
- 不使用个人高权限账号；
- 不自动发送邮件、消息或生产变更；
- 生成草稿而不是直接发布；
- 日志和输出不包含秘密。
监控自动化是否仍然有效
定期检查：
- 最近成功率与失败原因；
- 产物是否仍被人使用；
- 输入 API、插件或仓库结构是否变化；
- Skill 和任务提示是否漂移；
- Token、外部 API 和存储成本；
- 不再需要的连接和计划是否已删除。
“一直成功”也可能只是任务已经没有有效输入。
常见失败
依赖上一轮聊天
把必要上下文放项目文件、Skill 或任务提示中，定时任务每次按独立运行设计。
在 Local 目录产生冲突
改用专用 worktree，或将任务改为只读报告。
自动化把警告当修复
先要求可复现证据和候选 diff，再由后续门槛决定是否修改。
输出越来越长
固定格式、数量上限、时间范围和优先级，只报告有证据的变化。
完成门槛
- [ ] 流程已手动稳定运行。
- [ ] Goal 或定时任务有明确完成/输出定义。
- [ ] 执行环境和 worktree 不干扰本地工作。
- [ ] 权限、网络和外部写操作受限。
- [ ] 手动触发测试成功，并能看到失败通知。
- [ ] 有停用和清理机制。
下一步
需要在脚本或 CI 中运行时，继续学习 codex exec 与 GitHub Actions。