Codex定时任务怎么设置？ChatGPT Plus用Worktree自动巡检项目

Codex定时任务适合处理已经跑通、步骤固定、需要周期性重复的开发工作，例如每天检查失败测试、每周汇总依赖变化、定期整理Issue。

不建议把尚未验证的复杂流程直接设为定时任务。正确顺序是：

先手动运行并调整结果，再设置执行时间，最后用Worktree隔离后台修改。

Codex的Scheduled Tasks可以设置项目、任务说明、运行周期和执行环境。Git项目既可以在本地目录运行，也可以使用独立后台Worktree，避免定时任务影响正在编辑的代码。

一、哪些任务适合定时执行？

适合自动运行的任务通常有三个特点：

• 输入来源相对固定；

• 输出结果容易检查；

• 即使失败，也不会造成严重影响。

比较实用的场景包括：

• 每天扫描失败测试；

• 每周汇总最近提交；

• 定期检查依赖变化；

• 整理待处理Bug和Issue；

• 生成发布说明初稿；

• 汇总CI失败原因；

• 输出项目健康报告。

官方建议先在普通Codex对话中手动运行一次，确认提示词、模型、工具和输出格式都符合预期，再启动周期执行。

不适合直接定时执行的任务包括：

• 自动修改生产环境；

• 自动执行数据库迁移；

• 自动升级核心依赖；

• 自动删除大量文件；

• 无人检查就直接合并代码。

定时任务适合减少重复劳动，不适合绕过工程审批。

二、Codex定时任务怎么创建？

在ChatGPT桌面端，可以从Scheduled页面创建任务，也可以直接在ChatGPT或Codex对话中描述：

• 要处理哪个项目；

• 每次运行做什么；

• 多久运行一次；

• 结果返回当前对话，还是创建独立运行记录。

例如可以输入：

每个工作日检查当前项目最近24小时的失败测试。

只分析失败原因，不修改业务代码。

输出失败用例、相关文件、可能原因和建议动作。

如果没有新增失败，只回复"没有发现新的失败测试"。

这种任务比"每天检查一下项目"更可靠，因为它明确了：

• 检查范围；

• 是否允许修改；

• 输出格式；

• 没有结果时怎样处理。

独立定时任务的每次运行会生成单独记录，并集中显示在Scheduled页面，方便查看未读结果、暂停任务和检查历史执行。

三、本地模式和Worktree怎么选？

Git项目的定时任务可以选择：

本地模式

Codex直接在当前项目目录中运行。

适合：

• 只读分析；

• 汇总日志；

• 生成报告；

• 不修改代码的检查任务。

风险是：如果定时任务拥有写入权限，它可能修改你正在编辑的文件。

Worktree模式

Codex为定时任务使用独立Git工作目录。

适合：

• 可能生成代码修改；

• 需要运行多轮测试；

• 后台持续处理问题；

• 不希望影响本地工作区。

Worktree拥有独立文件副本和工作状态，但与原仓库共享Git提交信息。这样定时任务可以在后台工作，而不会直接干扰本地未完成的代码。

简单判断：

只读巡检可以用本地模式；

可能产生修改，优先使用Worktree。

四、Worktree为什么会缺少依赖？

Worktree创建的是新的工作目录。

Git已经跟踪的代码文件会正常存在，但以下内容可能缺失：

• node_modules；

• Python虚拟环境；

• .env配置；

• 本地缓存；

• 未提交文件；

• 被.gitignore忽略的资源。

因此，定时任务可能出现：

代码读取正常，但测试无法运行。

可以在Local Environment中配置Setup Script，让Codex创建Worktree后自动执行初始化命令，例如：

npm install
npm run build

Local Environment还可以配置常用操作，例如运行测试、启动开发服务和执行构建。相关配置可以保存在项目根目录的.codex文件夹中，方便团队共享。

不要为了让任务运行，直接把全部密钥和敏感配置复制到每个Worktree。只提供当前任务真正需要的环境信息。

五、权限应该怎么设置？

定时任务是无人值守运行的，因此权限需要比普通交互任务更谨慎。

官方说明中，Scheduled Tasks会使用默认沙箱设置。只读模式无法执行写入、网络访问和部分应用操作；项目内写入模式可以修改工作区，但项目外文件和网络仍会受到限制。完全访问模式风险最高，因为后台任务可能修改文件、执行命令和访问网络。

推荐设置：

• 项目巡检：只读权限；

• 自动补测试：项目内写入；

• 查询GitHub或外部系统：只开放必要插件或网络；

• 数据库、生产环境：不交给无人值守任务直接操作。

最稳妥的原则是：

权限只覆盖当前任务，不要为了减少报错而开放整台电脑。

六、怎样判断定时任务是否可靠？

创建后不要马上放任它长期运行。

先检查前几次结果：

• 是否重复报告同一问题；

• 是否把旧错误当成新增错误；

• 是否读取了正确项目；

• 是否运行了预期测试；

• 是否产生无关修改；

• 输出是否方便人工审查；

• 执行频率是否过高。

如果任务每次都需要你重新解释，说明流程还不稳定。

这时应该先把工作方法整理成Skill，再由Scheduled Task负责运行周期。官方推荐的原则是：

Skill定义怎么做，定时任务定义什么时候做。

七、推荐的项目巡检模板

可以先从一个只读任务开始：

每天检查当前项目最近24小时的失败测试、异常提交和新增高风险Issue。

不修改代码，不创建Issue，不重新运行CI。

将重复问题合并。

按严重程度排序，并为每个问题提供证据、相关文件和建议动作。

如果无法访问某项信息，明确说明。

如果没有新问题，只输出"本次巡检未发现新增问题"。

官方Bug Triage示例同样建议先手动执行一次，在同一对话中调整报告质量，再把稳定流程设为定时任务；输出时应区分观察证据和推测，避免自动修改外部系统。

结语

Codex定时任务最适合处理已经稳定的重复工作。

正确流程不是：

写一句提示词，然后让AI长期自动运行。

而是：

手动验证流程

→ 明确输入和输出

→ 限制权限

→ 选择本地或Worktree

→ 检查前几次结果

→ 再逐步扩大自动化范围

只读巡检从简单任务开始，可能修改代码时使用Worktree隔离，高风险操作继续保留人工审批。

这样才能让Codex节省重复检查时间，而不是在后台制造新的工程问题。