摘要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开始忘记前面确定的限制。结束线程前先完成三件事保存当前代码生成交接文档记录测试结果。然后再建立一个干净的新会话。新线程减少的是无关历史不是删除项目本身的重要信息。七、不要把完整日志永久留在线程里排查报错时完整日志很重要。但问题解决后大量旧日志就可能变成无效上下文。比较好的做法是第一次排查时提供完整日志找到根因后总结关键错误把最终结论写进交接文档新会话不再重复粘贴已经失效的日志。例如可以让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也能更快恢复状态减少重复分析和越改越乱的问题。