先分清：它擅长什么，不擅长什么
定时任务的本质是“把一段写好的提示词按时间或事件重复执行”。它适合边界清楚、结果可自己判断对错的活：生成简报、检查状态、整理清单、跑固定验证。它不适合需要你现场拍板的事，也不适合结果没人看就没人能发现错误的事。
| 适合交给定时任务 | 不建议交给定时任务 |
|---|---|
| 每天汇总某个目录最近 24 小时的改动 | 需要实时响应的交互式问答 |
| 每周整理新增 issue，按模块分类 | 需要当场确认方案的架构改造 |
| 定时跑测试，失败时给出定位思路 | 涉及生产环境写操作、发布与回滚 |
| 盯着 PR 状态，有新评审意见就汇总 | 无人复核就自动合并的代码变更 |
入口在哪：三个界面，两种形态
定时任务统一在 Scheduled 里查看和管理：桌面应用侧边栏有 Scheduled 视图，网页端也在 Scheduled 里看运行记录。命令行和 IDE 插件不提供这套管理界面——它们更适合先把提示词、技能或脚本调通，再去界面里排期。
| 入口 | 能做什么 | 限制 |
|---|---|---|
| 桌面应用 | 管理定时任务；可用本地项目，跑在项目目录或独立 worktree | 任务运行时电脑要开着、应用要运行 |
| 网页端 | 从 Chat 或 Work 创建任务；可用已上传的文件、连接的工具与技能 | 不能用电脑上的本地文件夹 |
| 命令行与 IDE 插件 | 调试提示词、技能、脚本；不提供 Scheduled 管理界面 | 需要到桌面应用或网页端排期 |
| 事件触发（网页/移动端） | Gmail、Slack、GitHub 事件发生时触发任务 | 桌面应用、CLI、IDE 不支持；不能与时间表混用 |
形态上有两种，选错会让上下文白丢：独立任务每次运行都开一个新会话，从保存的提示词重新开始；聊天内任务回到同一个会话，沿用里面的上下文。想让每次结果都独立成条、便于对比，用独立任务；想接着之前的讨论继续推进，用聊天内任务。
每次结果应该能单独看 -> 独立任务（新会话，结果进 Scheduled）
需要接着上次的上下文 -> 聊天内任务（回到同一个 chat）频率怎么写：从分钟到 RRULE
排期有三种粒度。聊天内任务支持按分钟计的间隔，适合盯一个长任务直到它完成；日常和每周的固定时点，用界面的自定义排期控件就够了；需要“每月 1 号早上 9 点”这类复杂规则时，再编辑底层的 RFC 5545 重复规则（RRULE）。
RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0- 排期前先手动跑一次提示词，确认输出是你想要的样子
- 频率不要一上手就设成每小时：先按天跑几天，看结果稳不稳再加密
- 结果太宽泛通常是提示词问题，不是频率问题——先改提示词再改节奏
- 每次运行都会消耗账号用量，密度越高消耗越快，具体以官方页面为准
跑在哪：本地项目还是 worktree
桌面应用里的项目级定时任务有两种落点。跑在本地项目目录，意味着它直接改你正在编辑的那份工作区；跑在独立 worktree，改动被隔离在另一份检出里，不会和手头的未完成工作打起来。两者都在后台执行。非 Git 项目没有 worktree 这一步，直接在项目目录里跑。
| 运行方式 | 适合的情况 | 要小心的地方 |
|---|---|---|
| 本地项目目录 | 任务只读、或本来就该改当前工作区 | 可能改到你正在编辑的文件 |
| 独立 worktree | 任务会写代码、想与手头工作隔离 | 长期高频运行会堆出很多 worktree，需要定期归档运行记录 |
worktree 里只继承提交进 Git 的文件，依赖和本地配置通常要额外准备。如果定时任务一跑就报找不到依赖，先在本地环境里补好安装步骤，再让它定时执行。
- 01
先确定结果交到哪
独立任务的运行结果会出现在 Scheduled 里，未读标记提示你去看；聊天内任务则回到原会话里。先把“我要在哪里看到结果”想清楚，再决定形态。
- 02
把提示词写死、写窄
无人值守时没人和它对话。提示词要写清：每次做什么、什么算“有事要报”、什么情况下停下来等人。
- 03
先跑前几次，再调范围
头几次运行后回看输出：是不是太啰嗦、是不是漏了关键模块。按需调整提示词、工具或频率。
权限：无人值守时把沙箱收紧
定时任务用你当前的默认沙箱设置运行，而且是在没有你确认的情况下运行。所以配定时任务之前，先想清它到底需要读什么、写什么、要不要联网。原则是从最窄的权限开始，跑不通再逐项放开。
| 沙箱档位 | 运行时能做什么 | 定时任务的后果 |
|---|---|---|
| read-only | 只能读文件；改文件、联网、操作应用都会被拦 | 要求写入或联网的步骤会直接失败 |
| workspace-write | 可在工作区内读写并跑常规命令；工作区外、联网仍受限 | 大多数“读代码 + 出报告”的任务够用 |
| full access | 没有文件与网络边界 | 后台任务风险最高，只在明确需要时使用 |
组织策略允许时，定时任务使用不再询问的审批策略；如果管理员禁止了这种策略，任务会退回你当前权限模式对应的审批行为，于是可能卡在一个没人回答的确认上。这也是“任务一直不动”的常见原因之一。
四个可以直接抄的用法
下面四段都是提示词本身，复制到任务里再按自己的目录、分支、模块名改一下即可。共同点是：范围窄、产出明确、有“什么不该做”的约束。
看最近 24 小时的提交（远程主干分支）。
为 <目录> 生成一份变更简报：按工作流分组，不要逐条列提交。
每组写一段大白话说明改了什么、影响谁。
带上相关 PR 链接，不要贴提交哈希。
如果没有值得汇报的改动，直接说“今天无显著变更”。整理仓库里过去 7 天新开的 issue。
按模块分组，每组给出一句话摘要和优先级建议。
标出信息不全、缺少复现步骤的条目，列成待补充清单。
只做分类和汇总，不要关闭、不要修改任何 issue。在工作区里跑一遍测试命令 <测试命令>。
如果全部通过，只回一行结果。
如果有失败：定位到具体用例，给出最小修复方案并实现，
只改与失败相关的文件，不要顺手重构。
改动完成后把 diff 摘要列出来，等人确认后再开 PR。检查依赖清单里是否有已知安全公告影响当前版本。
列出受影响的依赖、当前版本、建议升级到的版本与破坏性变更提示。
不要自动升级依赖，只输出清单和判断依据。
没有发现就直接说明检查范围与结论。如果团队里同一套流程要反复用，把它写成一个技能，再在提示词里用 $技能名 显式指定，比每次复制长提示词更好维护；技能本身也能创建或更新定时任务。
跑失败了怎么查
先看运行记录里的结果和错误，再判断属于哪一类：权限被拦、模型不可用、上下文没加载、还是任务本身写得太宽。三类问题的现象差别很明显。
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 运行记录显示命令被拒绝 | 沙箱是 read-only，或需要联网而网络未放开 | 改用 workspace-write，或用命令规则放行特定命令 |
| 任务一直停在等待状态 | 在等一个没人回答的审批 | 检查审批策略与组织策略；改为无需审批的运行方式 |
| 每次都在同一步失败 | 模型已下线，或提示词依赖的文件不在运行环境里 | 换成在售模型；确认任务能访问到需要的文件 |
| 什么都不做就结束 | 提示词太模糊，或判定条件没写清 | 补上“什么算有事要报”“没有就明确说无变化” |
| worktree 越堆越多 | 高频任务每次都新建检出 | 归档不再需要的运行记录，避免随意固定（pin）运行 |
- 01
先在本地把同一段提示词跑通
用同一份项目、同样的权限模式手动执行一次。手动能过而定时失败，问题通常在环境或权限，不在提示词。
- 02
再看是不是权限问题
只读模式下要求写文件必然失败。把任务需要的动作列出来，逐条对照当前沙箱档位。
- 03
最后看运行记录与会话日志
运行结果在 Scheduled 里；会话记录默认在 Codex 主目录的 sessions 目录下（默认 ~/.codex/sessions），分享前先确认里面没有敏感信息。
常见问题
定时任务和 GitHub Action 该用哪个？
看触发条件和执行位置。定时任务擅长“让 AI 读代码、写总结、起草改动”，跑在你自己的电脑或云端会话里；GitHub Action 擅长确定性的构建、测试与发布流水线。常见组合是让 Action 跑测试，让定时任务读测试结果并给出定位思路。
电脑关机了任务还会跑吗？
桌面应用里的项目级定时任务需要电脑开着、应用运行，并且项目在磁盘上仍然可用。想让任务脱离本机运行，用网页端创建的任务；它用上传的上下文和连接的工具，但碰不到你电脑上的文件夹。
定时任务会额外收费吗？
每次运行都是一次真实的模型调用，会消耗你账号的用量或 credits，和手动发起同样的对话没有本质区别。具体计费方式与额度以官方页面为准；提高频率等于提高消耗。
能不能用事件触发代替定时？
可以，但两者不能混在同一个任务里。事件触发支持 Gmail、Slack、GitHub 等来源，只在网页端和移动端可用；它解决的是“有事发生时立刻响应”，定时解决的是“到点检查一遍”。
官方文档与参考
本文依据上述官方文档整理；价格、额度与功能会随官方更新变化，第三方中转站的行为以其自身说明为准。