Appearance
Codex 定时任务与持续目标实战
嘿，朋友们！今天咱聊聊 Codex 的自动化和定时任务。这个话题我可踩过不少坑——第一次设定时任务的时候，我把一个随手写的提示词直接扔上去，结果第二天打开电脑，它帮我在 main 分支上搞了一堆乱七八糟的提交，差点没把我送走。所以我现在的原则很简单：先把活儿在普通对话里跑顺了，再考虑自动化。后面聊的所有技巧，基本上都是从那几次翻车经历里总结出来的。
Goal 和 Scheduled task，到底用哪个？
Codex 提供了两种自动运行的方式，选对场景能省好多事：
- Goal：同一个任务持续往前推进，直到干完为止。比如一个要折腾好几轮的大项目，Codex 会记住上下文、接着上次的进度继续搞。
- Scheduled task：按日历定时触发，每次都是独立的一次运行。适合日报、巡检、周期整理这类「到点就干活」的事情。
简单粗暴的判断方法：每次运行需要接着上次的结果继续，就用 Goal；每次都应该从零开始、不依赖历史聊天记录，那就用定时任务。
用 Goal 驱动长任务
我的习惯是，先在 App 里用 /plan 把方案盘清楚，确认没问题了再设 Goal。举个例子：
text
/goal
完成订单导出功能：实现后端导出、前端下载、权限与上限处理、测试、文档和最终构建。保持现有列表 API 不变，不提交或推送。只有所有验收项都有验证证据才算完成。一个好的完成条件，我建议把这几样写清楚：
- 到底要交付什么东西；
- 哪些边界绝对不能碰；
- 用什么命令验证、用户走哪条路径验证；
- 外部操作的限制（比如能不能提交、能不能发消息）；
- 什么情况下必须停下来问你。
运行过程中当然可以补充信息、纠正方向，但别三天两头改核心目标，不然 Codex 也懵。真有新需求，拆成下一个任务就好。
哪些活适合扔给 Goal
- 多阶段的重构，一两天搞不完的那种；
- 给大型文档站补全内容；
- 跨好几个模块的功能开发，还得带测试和 review；
- 死磕一个很难复现的 bug；
- 大批量但可以自动验证的迁移。
反过来，下面这些就别硬塞给 Goal 了：完成标准你自己都没想清楚、需要频繁等老板审批、涉及不可逆的生产操作、还有那种纯探索性质、没法验证结果的活儿。
Scheduled task：先手动跑三次再说
这是我血泪教训换来的铁律。设定时任务之前，至少手动把这个流程跑几遍，确认：
- 输入来源靠不靠谱；
- 输出格式能不能方便审查；
- 有没有偷偷依赖聊天上下文（这个特别容易忽略！）；
- 失败了会不会明确报出来；
- 会不会搞乱你正在用的工作树；
- 权限和 token 成本能不能接受。
流程稳定了，把它固化成 Skill，定时任务只负责「什么时候跑、在哪个项目跑、输入参数是什么」。这样职责清晰，出问题也好排查。
一个只读周报任务的例子
在桌面应用的 Scheduled 页面创建，选好项目、环境和时间。提示词可以这么写：
text
生成本周项目变化摘要。
范围：从上周一 00:00 到现在的已提交记录和当前 CI 状态。
输出：
1. 已交付功能；
2. 重要修复；
3. 仍失败的检查；
4. 下周需要人工决策的问题；
5. 引用对应提交或工作流链接。
只读，不修改仓库，不创建 issue，不发送消息。找不到证据时写"未确认"。另外提一句：Git 仓库的定时任务，尽量用专用的 background worktree，不然跟你的本地修改打架就麻烦了。这个我也是吃过亏的，改了一半的代码被定时任务覆盖，那滋味真不好受。
一个安全的自动 Bug 扫描任务
别一上来就想让 AI 帮你自动修 bug，循序渐进才安全。我建议分三步走：
第一阶段先只让它报告：
text
检查最近 24 小时合入的代码，寻找一个能被测试或明确复现的真实回归。
只输出：触发条件、证据、影响、最小修复建议和验证命令。
不要修改代码、创建分支、提交或评论 PR。报告质量稳定以后，再升级到第二步：「在独立 worktree 中生成候选修复，但不要推送」。最后才考虑自动创建草稿 PR。千万别一步跨到自动合并，那是在玩火。
测试定时任务，别等它自己跑
任务建好之后，立刻手动触发一次，逐项检查：
- 项目和分支对不对；
- worktree 是不是用对了；
- 时区和计划时间准不准；
- Skills、Plugins、MCP 都加载了吗；
- 网络和认证通不通；
- 输出发到哪去了；
- 失败了有没有通知你；
- 会不会留下没清理的 worktree。
改过提示词就重新测一次，别偷懒等下一次正式运行。这个懒我偷过，结果周一早会打开一看，周末三条定时任务全挂了，还没人知道。
权限和外部动作，宁可紧一点
定时任务没人实时盯着，出问题你可能是最后一个知道的。所以权限要比交互任务更保守：
- 默认只读；
- 要写东西也只能写在独立 worktree 里；
- 网络访问按域名或工具做限制；
- 别用你自己的高权限账号跑；
- 别让它自动发邮件、发消息、或者碰生产环境；
- 生成草稿就好，别直接发布；
- 日志和输出里绝对不能带密钥。
监控：自动化跑着跑着可能就废了
自动化不是设完就忘的事。隔段时间检查一下：
- 最近成功率怎么样、失败原因是啥；
- 产出的东西还有人看吗；
- 依赖的 API、插件、仓库结构有没有变化；
- Skill 和任务提示是不是已经过时了；
- Token、外部 API 和存储花了多少钱；
- 那些不再需要的定时任务和连接删了没。
有个反直觉的现象：「一直成功」有时候反而是最大的坑——可能它早就不产生有效结果了，只是没报错而已。我就遇到过，一个日报任务连续三周输出「本周无变更」，其实是因为 API 权限变了，它根本拉不到数据。
常见翻车现场
偷偷依赖上一轮的聊天记录
定时任务每次都是独立运行，没有上一次的上下文。把必要信息写进项目文件、Skill 或者任务提示里。
在 Local 目录打架
改用专用 worktree，或者把任务设成只读。
把警告当成 bug 去修
先要求可复现的证据和候选 diff，确认是真的问题再动手。
输出越来越长，没人看了
限定格式、数量上限、时间范围和优先级，只报告有证据支撑的变化。
完成门槛
- [ ] 流程已手动稳定运行。
- [ ] Goal 或定时任务有明确完成/输出定义。
- [ ] 执行环境和 worktree 不干扰本地工作。
- [ ] 权限、网络和外部写操作受限。
- [ ] 手动触发测试成功，并能看到失败通知。
- [ ] 有停用和清理机制。
下一步
需要在脚本或 CI 中运行时，继续学习 codex exec 与 GitHub Actions。