摘要：Codex处理大型项目和长任务时，经常会出现上下文越来越长、回答开始偏离、重复读取文件或换会话后丢失进度的问题。本文整理控制上下文、保存任务状态和跨会话交接的5个实用方法。

使用Codex修改一个小函数时，通常感觉不到上下文有什么影响。

但任务一旦变成多文件修改、持续排错或完整功能开发，就可能出现这些情况：

• 前面已经确认的规则，后面又被忽略；
• Codex重复读取已经分析过的文件；
• 修改方向逐渐偏离最初需求；
• 对话越长，响应和执行速度越慢；
• 新建会话后，不知道上一轮做到了哪里；
• 额度还没有完全用完，任务却越来越难继续。

这类问题的核心，往往不是Codex突然变笨了，而是当前线程中需要保留的信息越来越多。

Codex的线程内容必须放进模型可用的上下文窗口中。对于较长任务，系统可能自动进行上下文压缩，把相关内容总结后继续工作，但反复压缩后，一些细节仍有可能不如最初完整。

因此，长任务不能只依赖聊天记录保存进度。

一、不要把整个项目一次性塞进上下文

很多人使用Codex时，第一句话就是：

读取整个项目，帮我找出所有问题并完成优化。

这条指令范围太大。

Codex可能需要同时处理：

• 项目目录；
• 源代码文件；
• 配置文件；
• 依赖信息；
• 测试结果；
• Git差异；
• 运行日志；
• 已完成和未完成的任务。

文件越多，当前线程需要保留的信息就越多。

即使Codex能够完成第一轮分析，后续真正修改代码时，也可能已经积累了大量不再需要的内容。

更稳妥的方式

先明确本次任务只涉及哪个模块：

只分析用户登录模块，重点读取auth、middleware和相关测试文件，暂时不要检查其他业务目录。

完成登录模块后，再新建一个任务处理权限或用户资料。

上下文管理的重点不是让Codex看到越多越好，而是让它在正确时间看到真正相关的内容。

二、复杂任务先规划，不要立即修改

任务越复杂，越应该先让Codex生成计划。

OpenAI官方建议，遇到复杂、模糊或不容易描述清楚的任务时，先使用规划方式，让Codex收集必要信息、确认步骤，再进入具体实现。部分Codex界面支持通过/plan进入规划模式。

例如，不要直接输入：

帮我重构订单模块并修复所有问题。

可以先输入：

请先分析订单模块，列出当前结构、主要问题、涉及文件和建议修改顺序。暂时不要修改代码。

确认计划没有偏离后，再继续：

先执行第一步，只拆分订单校验逻辑，不修改数据库和接口返回结构。

这样做有两个好处：

第一，错误方向能够在写代码前被发现。

第二，每个阶段需要保留的上下文更少。

三、任务进行到一半时，生成交接文档

长任务不能只依赖对话记录。

当你发现当前线程已经很长、额度接近限制，或者准备换一个会话继续时，应该先让Codex生成一份交接文档。

可以使用下面这段指令：

请把当前任务进度整理到docs/codex-handoff.md中，包括： 1. 本次任务的目标； 2. 已经完成的内容； 3. 已修改的文件； 4. 每个文件修改了什么； 5. 已运行的测试及结果； 6. 当前仍存在的问题； 7. 下一步应该从哪里继续； 8. 哪些内容禁止再次修改。

OpenAI在长时间迭代任务的官方示例中，也建议把进度记录在日志中，而不是完全依赖上下文；这份日志可以成为下一次会话的交接点。

交接文档相当于给下一个会话准备了一份项目简报。

即使聊天记录丢失，也能通过文件恢复任务状态。

四、新会话不要从“继续”两个字开始

很多人新建Codex会话后，只输入：

继续刚才的任务。

新会话通常没有上一条线程的完整信息，仅靠“继续”很难准确恢复状态。

更有效的做法是让新会话先读取交接文档和代码差异：

请先读取： - docs/codex-handoff.md - AGENTS.md - 当前Git Diff 根据这三部分内容，总结： 1. 已经完成了什么； 2. 当前代码处于什么状态； 3. 下一步准备做什么。 暂时不要修改代码。

确认Codex理解正确后，再让它继续执行。

还可以要求它先检查：

• 交接文档是否与当前代码一致；
• 是否存在未提交修改；
• 测试结果是否仍然有效；
• 上一轮有没有留下临时代码。

不要默认上一轮生成的总结一定完全正确，新的会话仍然需要先验证。

五、长期规则放进AGENTS.md，不要每次重复

有些信息不是某一次任务的临时进度，而是整个项目都需要遵守的长期规则，例如：

• 项目使用pnpm；
• 不允许修改数据库结构；
• 不允许新增第三方依赖；
• 必须运行哪些测试；
• 哪些目录不能修改；
• 接口返回结构不能改变。

这些内容不应该每次都重新复制到对话里。

可以把它们写进仓库中的AGENTS.md。Codex会在开始工作前读取相关的AGENTS.md文件，把其中内容作为项目级指导。

例如：

# AGENTS.md ## 项目规则 - 使用pnpm，不要使用npm或yarn。 - 不允许修改数据库表结构。 - 未经确认不要新增生产依赖。 - 不要修改任务范围之外的文件。 - 修改业务逻辑后必须运行相关测试。 - 完成后列出修改文件和测试结果。

这样，新会话只需要读取任务交接文档，就不必重复介绍全部项目规则。

可以把两类文件分开理解：

• AGENTS.md：长期不变的项目规则；
• codex-handoff.md：当前任务的临时进度。

六、什么时候应该主动新建会话

不是线程越长越好。

出现下面几种情况时，可以考虑主动结束当前线程：

• Codex开始重复相同分析；
• 已经连续修改多次仍未解决；
• 当前任务阶段已经完成；
• 对话中包含大量失效日志；
• 需求方向已经发生明显变化；
• 当前上下文混入多个无关任务；
• Codex开始忘记前面确定的限制。

结束线程前，先完成三件事：

1. 保存当前代码；
2. 生成交接文档；
3. 记录测试结果。

然后再建立一个干净的新会话。

新线程减少的是无关历史，不是删除项目本身的重要信息。

七、不要把完整日志永久留在线程里

排查报错时，完整日志很重要。

但问题解决后，大量旧日志就可能变成无效上下文。

比较好的做法是：

• 第一次排查时提供完整日志；
• 找到根因后总结关键错误；
• 把最终结论写进交接文档；
• 新会话不再重复粘贴已经失效的日志。

例如，可以让Codex总结：

本次报错的根因是什么？哪些日志是真正关键的？请把结论写进交接文档，不要保留无关输出。

这样既保存了排查结果，也避免后续任务反复处理旧信息。

八、一个适合长任务的Codex工作流程

第一步：定义单一目标

说明本次只完成什么，不完成什么。

第二步：先让Codex生成计划

确认涉及文件、修改顺序和潜在风险。

第三步：分阶段修改

一次只完成一个可以测试的小阶段。

第四步：每个阶段运行验证

记录测试命令、执行结果和未解决问题。

第五步：生成交接文档

保存已完成内容、文件变化和下一步计划。

第六步：必要时建立新会话

让新线程读取AGENTS.md、交接文档和Git Diff后继续。

这个流程比在一个线程中不断输入“继续修改”更稳定，也更容易发现任务什么时候开始偏离。

九、可直接使用的交接提示词

当前任务准备暂停，请生成一份完整交接记录。 需要包含： 1. 原始需求； 2. 已完成步骤； 3. 已修改文件及主要变化； 4. 当前Git状态； 5. 已运行的测试及结果； 6. 尚未解决的问题； 7. 下一阶段的执行顺序； 8. 不能修改的内容； 9. 新会话开始时需要优先读取的文件。 请将内容保存到docs/codex-handoff.md。 不要继续修改业务代码。

新会话中可以输入：

请读取AGENTS.md、docs/codex-handoff.md和当前Git Diff。 先验证交接记录是否与代码一致， 然后列出下一步执行计划。 在我确认前不要修改文件。

总结

Codex上下文满了以后，真正需要解决的不是怎样把更多内容继续塞进同一个线程，而是怎样把任务状态保存下来。

最实用的5个方法是：

• 缩小每次任务的文件范围；
• 复杂任务先规划再修改；
• 阶段结束时生成交接文档；
• 新会话先读取交接记录和Git Diff；
• 把长期项目规则写入AGENTS.md。
• 关于Codex的订阅和使用方法可以点开我主页私信详谈！

上下文可以压缩，对话也可以重新开始，但任务目标、修改记录和验证结果不能只存在聊天窗口中。

当项目规则和任务进度都被写进文件后，即使切换会话，Codex也能更快恢复状态，减少重复分析和越改越乱的问题。