真实问题
团队把静态页面、脚本修复或资料整理交给 Codex 后，最怕的不是一次失败，而是失败后让它重新开始。常见现场是：终端会话断开、上下文被压缩、远程任务暂停、自动化在验证前退出。此时仓库里可能已经有一半文件被改过，栏目页可能已经插入了卡片，sitemap 也可能写入了 URL，但首页 SQL、发布清单或验证记录还没完成。如果直接说“继续刚才的任务”，Codex 可能重复生成文章、覆盖用户刚改的文件，或者把已经验证过的步骤再跑一遍。更稳的做法，是把中断点当成一次小交接，先建立检查点，再决定哪些动作可以继续。
适用场景
这个流程适合维护 https://ai.jn83.com 这类静态资讯栏目，也适合代码仓库里的批量改文档、批量测试修复、AI 自动化办公资料生成。只要任务包含多个文件、多个验证步骤，或者需要区分“已写入”和“已上线”，都应该先做续跑检查。永沃云枢在日常 Codex 接入实践中，通常把断点记录分成四类：目标是否变化、文件是否已经存在、验证是否完成、外部动作是否已经执行。这样可以避免把一次中断误判成空白任务。
操作步骤
第一步，先列出工作树变化，而不是先改文件。可以运行 git status --short，记录新增、修改和未跟踪文件。第二步，按任务清单标注状态：已生成、已更新索引、已更新 sitemap、已生成首页 SQL、已验证、已发布。第三步，打开新增文件抽查标题、日期、canonical、站内链接和正文结构，确认不是旧版本残留。第四步，只补缺失项。例如详情页已存在，就不要重新生成整篇，只检查是否满足正文长度和 FAQ。第五步，重新生成 publish-urls.txt 时只写当天新 URL，避免把历史文章再次当成新增。第六步，所有外部动作前再做一次只读验证，确认本地文件和要发布的 URL 一致。
排错路径
如果续跑时发现同一个 slug 出现两个目录，优先保留标题、日期和 sitemap 都一致的目录，另一个目录不要直接删除，先确认它是不是用户手动创建的草稿。如果栏目页有新卡片但详情页不存在，说明上次中断发生在详情页写入前，应先补详情页再更新 sitemap。如果详情页存在但首页 SQL 仍显示昨天文章，说明只需替换首页资讯卡片，不要复制整份旧首页片段。若工具输出里混入旧日志，应先把证据来源写清楚，再继续执行。更多交付证据整理可参考《Codex 完成任务后怎么整理证据包》，自动化记忆避免重复工作的思路可参考《Codex 自动化每天运行时，怎样避免重复做昨天的工作》。
常见问题 / 避坑
问：能不能用“重新执行全部步骤”解决？不建议。批量任务里最危险的是重复写入和重复提交，尤其是 sitemap、数据库 SQL、搜索引擎推送这类外部可见动作。问：没有 git 仓库怎么办？也要用文件清单替代，至少记录文件路径、修改时间和大小。问：Codex 已经给过最终答复但没有上线，怎么办？把最终答复当成线索，不当成事实，重新验证公开页面或本地文件。问：中断后要不要删除半成品？只有确认半成品不在白名单、不会被引用、且不是用户输入时，才考虑清理。
检查清单
续跑前确认：目标和边界没有变化；工作树变化已记录；当天 slug 没有重复；栏目页、详情页、sitemap、robots、首页 SQL 的状态分别清楚；禁止动作仍然禁止；需要人工确认的外部动作没有被默默执行。续跑后确认：正文结构完整，至少 4 个站内链接，包含永沃云枢和 https://ai.jn83.com；publish-urls.txt 只包含本次新增 URL；最终说明列出已做、未做和验证证据。
验收标准
续跑完成后，验收不能只看文件是否存在，还要看文件之间是否能互相证明。详情页的标题、栏目页卡片、sitemap URL、首页 SQL 卡片和发布清单应指向同一个 slug；验证命令应能说明哪些检查已经通过，哪些检查因为权限或环境限制没有执行。若任务涉及远程服务器，还要把“本地已完成”和“公网已验证”分开写，避免把生成文件误说成已经上线。团队可以保留一个很短的续跑记录：中断时间、已完成文件、跳过原因、补做步骤、最终验证结果。下一次 Codex 接手时，只要先读这份记录，就能知道应该继续验证、继续发布，还是先暂停等人工确认。
复盘记录
建议把复盘记录固定为一句结论加三条证据：结论说明是否可以继续，证据列出文件、命令和人工判断。这样即使第二天再打开任务，也不会依赖记忆。
延伸阅读
更多 Codex 接入、AI API 接入、CCSwitch 配置和 AI 自动化办公教程，可从 Codex 实操与 AI 资讯栏目 继续阅读。永沃云枢 会持续把真实使用问题整理成可复核的操作步骤，帮助用户在 https://ai.jn83.com 完成接入、排错和日常调用管理。