Codex 定时任务失败时，先找到停止的步骤，再修改对应环节。没有触发、无法启动、账号未登录、结果未保存，看起来都可能只是一个“失败”提示，处理方法却不同。本文提供按执行顺序排查的方法，适用于周期性资料整理、报表和网站内容任务。
资料核验：2026年9月6日。产品行为依据官方定时任务文档；登录部分以 WordPress REST API 文档为例。下面的排查表和记录模板为编辑建议，不包含真实账号、密钥或私有运行日志。
第一步：确认任务有没有真正开始
官方文档区分独立定时任务和返回既有对话的定时任务；需要本地文件的工作，运行时应保持电脑开启、桌面应用运行、项目目录可用。来源：官方定时任务说明（核验于2026-09-06）。
先查看最近一次执行时间和第一条实际工作记录。如果完全没有工作输出，就检查启用状态、下次运行时间、执行目标和项目位置。如果已经开始联网或读取资料，则继续定位最后一个成功步骤，避免反复修改无关的定时设置。
| 看到的现象 | 先检查 | 修复后的验证 |
|---|---|---|
| 到点没有输出 | 启用状态、时间与本地运行条件 | 出现一次可识别的执行记录 |
| 启动立即失败 | 目标任务、目录和必要文件是否可用 | 能读取预定的输入资料 |
| 页面能打开却不能编辑 | 当前登录身份与对应权限 | 确认预期账号能进入编辑入口 |
| 提示完成但结果找不到 | 保存响应、目标位置与最终状态 | 独立重新读取实际产物 |
第二步：把时区写到可核对的位置
如果你的业务按北京时间执行，而电脑使用其他时区，不要只在提示词写“早上八点”。还应检查调度界面给出的下次运行时刻，换算后确认日期和小时都正确。每次调整计划后，把“下一次实际触发时间”作为验证结果保存。
跨地区协作可以同时记录业务时区与 UTC 时间。例如北京时间08:00对应 UTC 00:00。这个换算关系可以用来复查配置，但不代表所有调度产品采用相同的时区解析方式。
第三步：区分网页登录和接口认证
WordPress 官方文档说明，浏览器中的 Cookie 认证与供远程程序使用的应用密码是不同认证方式；Cookie 请求还涉及相应的 nonce。应用密码可用于 HTTPS 下的接口认证，不能把“接口验证成功”当成“后台网页已登录”的证明。参见WordPress REST API 认证文档（核验于2026-09-06）。
一个合理的预检应回答两件事：当前程序能否按授权读取和保存数据；当前浏览器能否以预期身份打开需要检查的界面。如果业务要求人工可见的界面复核，就把它作为独立步骤。遇到登录失效，应恢复已有账号访问，不要把凭证写进文章、共享文件或运行摘要。
第四步：给每个产物留下状态记录
建议每个业务日期保存一份记录，包含分类或任务项、产物ID、保存状态、最终链接、最后成功步骤、失败原因。日志只记录恢复工作所需的信息，不保存密码或认证头。
以“每天处理四项资料”为例，第二项失败时，应保留第一项的成功记录。重试先读取目标系统，核对第一项是否已经完成，再继续剩余三项。仅凭本地记录判断也不够，因为程序可能在服务端保存成功之后、写本地记录之前中断。
第五步：用小范围验证结束排查
- 读取一份真实但范围有限的输入，确认访问路径正确。
- 生成一个可检查的结果，按任务授权保存到明确位置。
- 重新打开或读取结果，检查内容、归属和实际状态。
- 确认本次结果记录已保存，再恢复正常周期。
通知也应与主任务分别记录。网站保存成功、邮件摘要失败，是两个结果；应保留网站产物并单独处理通知问题。重试通知前检查是否已发送，避免把一次暂时无响应变成重复邮件。
常见问题
是否应该先换模型？
如果错误发生在目录、登录或启动阶段，先修复这些依赖。模型更换无法证明这些问题已解决。
任务会自动补齐所有漏跑日期吗？
应在业务规则中明确补跑范围。内容发布等任务尤其需要先去重，并重新核查历史材料是否仍然适用。
修复配置后能立即认定恢复了吗？
配置保存只证明修改已生效。至少还要核对下次执行时间，并完成一次有实际结果的验证。
参考资料
- OpenAI：定时任务与运行条件，核验于2026-09-06。
- WordPress：REST API 认证，核验于2026-09-06。
- 更多工作方法见效率指南。
