Codex 长任务上下文塞满后怎么续接？

长任务做到一半时，如果 Codex 开始忘记前提、重复读文件或改错范围，应先压缩上下文、固定决策记录和续接验收点。

• 站内相关：Codex 长任务怎么交接上下文
• 站内相关：Codex 任务拆分和验收清单
• 站内相关：Codex 和 ChatGPT 对话怎么分工
• 站内相关：Codex 接入专题
• Codex 实操与 AI 资讯
• CCSwitch 配置专题

真实问题：越做越长的任务为什么容易跑偏

一个维护静态站、排查接口或整理资料的任务，刚开始只有三句话，执行到第三轮以后就可能堆进目录结构、错误日志、用户补充、临时方案和半成品文件。此时 Codex 仍然能继续工作，但它看到的是一团不断增长的上下文：哪些约束是最新的，哪些只是旧方案，哪些文件已经生成，哪些检查还没有跑，如果没有明确记录，就会出现重复扫描、重复生成、把旧标题当成新标题、或者把已经否定的方案又拿出来执行。永沃云枢在 https://ai.jn83.com 处理类似长任务时，会先把“任务事实”和“过程噪声”分开。事实包括允许修改范围、已采用方案、已生成文件、未完成检查和上线边界；过程噪声包括中间报错、临时猜测、已经废弃的命令输出。长任务续接的重点不是把所有对话原样保存，而是保留下一步判断必须依赖的信息。

适用场景

这套方法适合 Codex 接入后的站点维护、批量 SEO 页面生成、跨模块代码修复、PR 评论处理、AI 自动化办公资料整理和多轮排错。尤其是任务需要等构建、等远程验证、等人工补充信息时，更应该准备续接摘要。它也适合把 ChatGPT 里讨论过的方案交给 Codex 执行：ChatGPT 可以负责解释和比较，Codex 应拿到更短、更硬的执行说明。新手有时会把这类需求叫成“让 AI 记住上下文”，更规范的做法是把 AI API 接入、AI 模型接口和 Codex 接入里的上下文管理拆成可审计的任务状态。

操作步骤：先写一份可续接任务卡

第一步，开头就写清楚任务卡，格式不要复杂，但必须包括目标、允许修改目录、禁止触碰目录、验收命令、输出清单和失败时停止条件。第二步，每完成一个可验证动作，就把状态改成“已完成”或“待验证”，不要只在聊天里说“继续”。第三步，遇到方案变更时，只保留最终采用的决定，并写明为什么放弃旧方案。第四步，超过一小时或上下文明显膨胀时，要求 Codex 生成一段 300 到 600 字的续接摘要，摘要里必须列出新增文件、修改文件、未跑检查、已知风险和下一步。第五步，下一轮开始时先让 Codex 复述它理解的边界，再继续写文件或执行命令。对开发者 AI 调用项目，还要记录模型名、base_url、CCSwitch 配置 profile 和关键环境变量名，但不要把密钥写进摘要。

排错路径：从重复动作里判断上下文已经失真

如果 Codex 开始反复读取同一批文件，却说不清为什么；如果它把昨天的四篇文章当成今天新增；如果它提出要修改禁止目录；如果它把已经通过的检查重新当作待办，基本可以判断上下文已经失真。处理方式不是立刻开新任务，而是先冻结写入，做一次只读复盘：列出现有改动、最新文件时间、publish-urls、sitemap 中的新增 URL 和当前失败项。确认事实后再让 Codex 生成新的续接摘要。对于 AI API 接入任务，可以加一条最小验证命令，例如只请求健康检查或只跑单元测试，不要在上下文混乱时直接触发部署、数据库写入或批量提交。

常见问题 / 避坑

问：把完整聊天记录复制给 Codex 是不是最稳？不一定，完整记录里有很多废弃判断，反而会增加误判。问：续接摘要要不要写得很长？不需要，关键是能指导下一步。问：可以让 Codex 自动维护摘要吗？可以，但每次摘要生成后要人工看一眼，尤其是权限边界和未完成事项。问：模型上下文越大是不是就不用摘要？不是，上下文大只能容纳更多文本，不能替你判断哪些文本仍然有效。问：站内 SEO 批量生成时最容易漏什么？最容易漏去重结论、首页同步、sitemap lastmod 和乱码检查。

检查清单

任务卡是否包含目标、边界、验收命令和停止条件；每次关键决策是否保留最终版本；废弃方案是否明确标记为不要执行；续接摘要是否列出新增文件和未完成检查；Codex 是否在继续前复述最新边界；站内链接是否回到 Codex 资讯、AI API、CCSwitch 和自动化办公专题；长任务结束后是否把可复用经验沉淀到团队 SOP，而不是留在零散聊天里。