适合谁读：已经用 Codex 处理代码、报告或内容发布，想把重复工作交给定时任务，又担心重复执行、误改文件和“看似成功”的开发者。核心结论是：可靠自动化不是把一段提示词按时重放，而是明确输入、状态、权限、验收和失败出口。
本文更新：2026 年 7 月 24 日。本文依据当日可访问的 OpenAI 官方文档整理，不涉及套餐、价格或未经证实的功能。
定时触发不等于自动化完成
“每天上午检查一次项目”只定义了时间，没有定义检查对象、变化范围和完成标准。这样的任务第一次可能给出有用结果，第二次却重复报告旧问题，第三次又因网络失败留下半成品。真正可长期运行的任务，至少要回答五个问题：
- 每次从哪里读取输入；
- 怎样识别“自上次运行以来”的变化；
- 可以修改哪些文件或外部系统；
- 用什么证据判断成功；
- 失败时停止、保留还是回滚什么。
OpenAI 官方文档说明，定时任务可以在后台重复运行，并在 Scheduled 中查看状态与近期运行；桌面端的项目任务可在项目目录或隔离的 Git worktree 中工作。能力只是起点，是否可靠取决于任务契约是否完整。
第一步：选对“独立任务”还是“同一聊天”
如果每次运行都应从固定提示重新开始，例如每日新闻摘要、每周依赖检查，适合独立定时任务。它把每次结果作为单独运行呈现，边界清楚，也便于比较。
如果任务要持续追踪同一件事，例如等待部署完成、轮询一个 Pull Request、继续研究或排障，则更适合在现有聊天中调度。官方文档指出，这种方式会复用聊天上下文，适合需要连续状态的跟进；提示中仍要写清“本轮做什么、什么值得报告、何时停止或请求输入”，不能只依赖聊天历史猜测。
一个简单判断法是：把上次聊天记录全部拿走，本轮是否仍能正确执行？能，就优先独立任务；不能，就使用同一聊天，并把关键状态另存为可读记录。
第二步：把提示写成任务契约
一份可复用提示可以固定为六段：
目标：每个工作日检查指定模块的新错误，并只处理新出现的问题。
输入：项目日志、当前 Git 状态、上次运行记录。
范围：只修改该模块及其直接测试；保留已有未提交改动。
流程：先读状态，再复现，再做最小修复，最后运行相关测试。
验收：测试通过、Diff 无无关修改、结果包含证据与剩余风险。
失败：网络或权限不足时停止，不部署、不扩大权限、不重复提交。
“只处理新问题”必须有状态依据。可以保存最近处理的事件标识、最后成功时间、内容哈希或已发布对象名。状态文件只记录继续工作所需的最小信息，不保存令牌和敏感正文。每轮先读后写，并在确认成功后才推进游标；否则一次失败会让后续任务误以为工作已经完成。
第三步：选择本地目录还是 worktree
Git 项目中的定时任务可以直接在本地项目运行，也可以使用独立 worktree。直接运行适合只读检查或明确需要更新主工作区的流程，但它可能与正在编辑的文件相互影响。
会生成代码、批量改文件或准备提交的任务，更适合 worktree。隔离能降低覆盖未完成工作的风险，也让 Diff 更容易审查。但隔离不是免检通行证：任务仍应在开始时确认分支与仓库根目录，结束时报告修改文件和测试结果。频繁运行还会积累 worktree，因此要定期归档不再需要的运行，避免把每次结果永久保留。
非 Git 项目通常直接在项目目录运行，此时更应缩小写入范围，并优先采用“生成新文件—检查—替换”的可回滚方式。
第四步：权限按最小闭环配置
官方文档强调，定时任务无人值守，并使用默认沙箱设置。最安全的做法不是给满权限，而是从完成闭环所需的最窄访问开始：
- 只做分析时保持只读；
- 需要改项目文件时使用工作区写入；
- 只有确实需要查资料或调用 API 时才开放网络；
- 部署、删除、付费操作和生产写入设置额外门槛；
- 不把令牌写进提示、状态文件、稿件或日志。
“自动运行”也不意味着可以遇错就安装系统软件、修改全局配置或绕过安全策略。遇到权限阻塞，应报告缺少哪项能力和哪一步未验证，而不是偷偷扩大范围。
第五步：设置发布前的验证门
高风险工作应拆成准备与生效两个阶段。例如内容发布流程先创建草稿，回读标题、Markdown、渲染 HTML、链接和敏感信息，再调用发布接口；代码流程先修改和测试，再由明确条件决定是否提交或创建 PR。
每轮至少留下四类证据：
- 输入证据：本轮读取了哪些时间范围、对象或版本；
- 变化证据：发现了什么新内容，怎样排除旧内容；
- 验证证据：实际执行的测试、API 回读或页面检查；
- 结果状态：成功、无变化、需人工决定或失败。
尤其不要把“命令退出码为 0”当成业务成功。发布任务还要确认公开状态和页面内容；修复任务还要确认回归测试与最终 Diff；报告任务要确认来源日期和关键数字。
第六步：让失败可恢复，而不是反复重试
定时任务常见失败包括网络超时、令牌失效、来源不可达、工作区冲突和测试不稳定。可靠流程应为每类失败准备停止条件。
如果外部来源不足，就保留草稿而不发布；如果测试失败，就保留最小诊断信息而不提交；如果连续运行没有新变化，就返回“无变化”而不制造内容。对同一错误的重试要有上限，并避免产生重复文章、重复 Issue 或重复消息。恢复后应能依据状态继续，而不是从头猜测。
技能与定时任务如何配合
官方文档支持把定时任务与技能组合。适合复用的做法是：定时任务只定义“何时运行、作用于哪个项目、结果回到哪里”，技能负责稳定流程、检查清单和工具用法。这样流程发生变化时只更新一处，也方便在普通聊天里先手动测试。
上线前建议完整手动跑一遍提示，检查默认模型、工具、权限和输出是否符合预期；再观察最初几次定时结果，收紧模糊范围或调整频率。自动化不是写完即永久正确，它需要像代码一样被验证和维护。
最后建议
先挑一个低风险、结果容易验证的重复任务试运行，例如每周生成变更摘要或检查失效链接。为它补齐输入、状态、权限、验收和失败出口，再逐步增加外部写入。真正值得信任的 Codex 定时任务，不是每次都声称“已完成”，而是能准确区分成功、无变化、失败和需要你决定，并为每种状态留下可复查的证据。