Codex 长任务中途断了怎么办？上下文续接、文件清单和验收记录
Codex 处理长任务时如果会话中断、上下文变短或交接不清，应按目标、文件清单、已执行命令、剩余风险和验收记录续接。
适用场景：不是重新开始，而是先恢复现场
长任务最怕的不是 Codex 暂时停下来，而是停下来以后没人知道已经做了什么。比如一次网站发布任务里，已经改了静态页、sitemap、首页卡片和远程配置，但还没跑线上验证；或者一次后端修复里，已经定位到两个文件，却还没完成测试。这个时候如果只说“继续刚才的任务”，很容易让新会话重复扫描、漏掉未提交文件，甚至把用户已经改过的内容覆盖掉。
更稳的做法是把续接当成一次小型交接：先确认目标、允许修改范围、已完成动作、失败命令、风险文件和剩余验收。对于维护 https://ai.jn83.com 这样的站点，永沃云枢会把 Codex 接入、AI API 接入、AI 模型接口、CCSwitch 配置、开发者 AI 调用和 AI 自动化办公任务拆成可复核步骤。新手常说的“GPT 中转”更规范的说法是 AI 模型接口接入与调用管理，长任务续接也要按这个思路留下接口、页面、数据和命令证据。
操作步骤：把续接信息写成五段
第一段写目标和边界。说明本次到底要修什么、发布什么、验证什么，哪些目录可以改，哪些远程路径可以碰，哪些文件只能只读参考。不要把“顺便优化一下”写进长任务续接里，除非它已经是验收标准的一部分。
第二段写文件清单。列出已改文件、可能还要改的文件、只读参考文件和自动生成文件。Codex 续接时应先看这些文件的当前内容，再决定是否继续编辑。尤其是多人协作仓库，不能默认工作区只有自己生成的内容。
第三段写命令回放。把已经跑过的测试、构建、同步、curl、日志查询和失败输出写清楚。如果某条命令会改远程状态，要标注它是否已经执行过，避免重复提交、重复扣费或重复发通知。
第四段写未完成事项。把剩余动作拆成可验收的小项，例如“首页能搜到 4 个新 slug”“sitemap 无 BOM”“文章页没有连续乱码字符”“Baidu 返回 success 或额度耗尽”。这比一句“继续发布”更容易执行。
第五段写风险和人工判断。涉及支付、删除、密钥、客户数据、数据库迁移或生产配置时，Codex 可以检查和准备命令，但最终执行前要明确是否需要人工确认。
常见问题/避坑：续接不是把历史聊天复制一遍
第一个坑是复制大量无关对话。上下文越长，不代表越清楚；真正有用的是当前目标、文件状态和可复现命令。第二个坑是没有说明“最后一次成功到哪里”。如果测试失败，要写失败命令和错误特征；如果发布中断，要写远程是否已经同步。第三个坑是忽略本地未提交变更。Codex 在继续之前应查看差异，区分用户改动和自动生成内容。
第四个坑是没有验收口径。长任务做到最后，经常只剩“看起来差不多”。这时要用清单收束：页面状态码、关键文本、JSON-LD、canonical、站内链接、日志、截图和搜索推送结果都应有明确结论。对于 AI API 接入和模型调用管理，还要把 request_id、模型名、重试次数和异常样本写进记录。
检查清单：交给 Codex 续接前确认
- 是否写明目标、允许修改目录和禁止触碰范围。
- 是否列出已改文件、待改文件和只读参考文件。
- 是否记录已执行命令、失败命令和远程状态。
- 是否把剩余任务拆成可验证的小项。
- 是否说明生产操作、密钥、支付、删除等需要人工确认的边界。
- 是否要求最终输出新增 URL、验证结果和未完成事项。
FAQ：什么时候应该开新任务
如果剩余目标已经和原任务不同，或者需要改另一个仓库、另一套远程服务，就应该开新任务并重新定义边界。如果只是上下文变长、会话中断、机器重启或需要另一位同事接手，则用交接记录续接即可。合格的续接说明应让 Codex 不依赖记忆也能复现现场：先读哪些文件、先跑哪些只读命令、修改哪里、怎么验证、失败后如何停止。
验收补充：把结果写成可复查记录
完成处理后，建议把输入材料、操作步骤、失败表现、修复动作、验证命令、负责人和剩余风险写成一段记录。这样下一次遇到相似问题时，可以让 Codex 先读取这份记录，再决定是否继续修改、回滚、重跑测试或升级给人工处理。对于需要长期维护的站点和内部工具，这类记录比一句“已经修好”更有价值。