Codex 处理长任务时，最容易出现的问题不是模型不会写代码，而是上下文越堆越多。需求、报错、文件片段、测试输出和临时讨论混在一起，后面再提问时，模型可能抓不住重点。compact context 和会话摘要的作用，是把重要信息留下，把噪声压下去，让任务继续往前走。
长任务开始前，就应该把边界说清楚。比如只修一个接口，还是顺便整理测试；只改前端展示，还是允许调整后端返回；只生成文档，还是也要检查事实。边界清楚，后面压缩上下文时才知道什么该保留，什么可以丢掉。
会话摘要不等于把所有聊天记录缩短。好的摘要应该包含目标、当前结论、已读文件、已修改文件、未解决问题、验证命令和下一步动作。它像一张任务地图，让后续对话不用重新翻前面的每一句话。
文件引用要具体。只说“看一下配置文件”不够，最好写清路径、函数名、配置项和相关行附近的行为。Codex 读过很多文件后，如果引用太泛，下一轮很可能重新搜索一遍。具体路径能减少重复劳动，也能减少误改。
当上下文里出现大量日志时，要先筛选。保留错误码、时间点、堆栈顶部、请求路径、相关配置和复现步骤，删掉重复噪声。很多日志看起来很长，真正影响判断的只有几行。把噪声塞满上下文，只会拖慢后续判断。
compact context 更适合在阶段切换时使用。比如调查结束准备修改，修改结束准备测试，测试失败准备二次排查。每次切换都把前一阶段压成结论和证据，后面就不会被早期猜测干扰。
如果大家想体验一线 AI 编程模型 codex 和 claude，用它们帮你完成长任务拆解、上下文管理和工作提效，可以参考以下教程文档进行接入配置，接入配置好后即可使用。文档教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg
会话摘要里要区分事实和猜测。事实是“某个测试失败”“某个接口返回 401”“某个文件存在这个配置”；猜测是“可能是权限问题”“也许是缓存导致”。把两者混在一起，后面模型容易把猜测当成确定结论。
长任务还要记录被排除的方向。排查问题时，很多时间花在证明某些原因不存在。比如已经确认 API Key 没错、网络可达、模型名可用，就应该写进摘要。这样下一轮不会又回到同一条路。
文件引用也可以分层。核心文件必须保留完整路径，辅助文件只记录作用，临时文件可以不进摘要。所有文件都同等重要时，摘要反而失去重点。真正影响改动的路径，要放在最显眼的位置。
如果任务跨越多天，建议每天结束前让 Codex 生成一份交接摘要。第二天恢复时，先让它基于摘要复述进度，再读取当前文件确认是否变化。这样既能保留上下文，也不会被过期信息带偏。
上下文管理和 git 也要配合。摘要里写清当前分支、关键 commit、未提交改动和测试状态。只靠聊天记录看进度，很难判断本地代码到底处在什么阶段。git 状态是长任务的现实锚点。
不要把所有知识都塞进一次会话。长期稳定的项目规则应该放进 AGENTS.md、README、配置文件或团队文档；临时任务状态才放进会话摘要。长期规则和临时进度混在一起，会让后续维护很累。
当 Codex 输出开始变得重复、答非所问或老是引用早期讨论，就该整理上下文了。不要继续追加更长的提示。先让它提炼当前任务，再删除无关方向，必要时开新会话并带上摘要。
成熟的做法是把长任务拆成几个可验证阶段：理解需求，定位文件，提出方案，执行修改，运行测试，整理结果。每个阶段结束都留一份短摘要。这样 compact context 不只是节省长度，而是在帮你保持工程节奏。
上下文压缩还要保留失败记录。某个方案已经试过但不行，就应该写进摘要。否则后续会话可能再次走同样的路，浪费时间不说，还会让开发者以为工具一直在绕圈。
如果任务里有多个角色参与，比如产品、后端、前端和测试，摘要里最好写清每一方关心的点。Codex 后续生成方案时，就能同时照顾接口、页面和验收口径。
引用文件时可以加一句为什么重要。只写路径有时不够，说明它控制路由、鉴权、样式还是构建流程，后面模型才知道应该怎样使用这条线索。
当上下文已经非常乱时，最好的办法不是继续补充，而是暂停整理。让 Codex 输出当前事实清单，人工删掉不重要的部分，再用干净摘要开新阶段。
长期项目可以形成固定摘要模板。目标、范围、证据、改动、验证、风险、下一步，这七项足够覆盖大多数开发任务，也不会显得太重。
落地到 Codex 工作流时，建议保留一份简短检查表。检查表不用复杂，只要写清任务目录、分支、关键文件、验证命令和最后一次成功时间。以后重复处理类似任务时，这些信息会比临时记忆可靠。
如果任务涉及多个配置入口，要把优先级写出来。命令行参数、项目配置、用户配置和环境变量可能同时存在，谁覆盖谁必须清楚。很多看似模型不听话的问题，其实是配置来源没有理顺。
每次完成一轮修改，都要让 Codex 说明改了什么、为什么改、还没验证什么。这个习惯能把 AI 输出变成可审查的工程记录，而不是一段看完就丢的聊天内容。
遇到异常时，不要立刻扩大范围。先用最小任务验证能力是否正常，再逐步加回真实项目的复杂条件。最小复现能把工具问题、项目问题和环境问题分开。
如果准备把流程推广给团队，先在一个低风险项目里连续跑几天。记录成功率、失败原因、人工修正时间和测试结果。只有这些数据清楚，才知道流程是否值得推广。
Codex 的优势是能读上下文、改文件、跑命令和整理结果，但它仍然需要边界。边界越清楚，输出越稳定；验证越及时，返工越少。把工具放进工程流程，而不是把工程流程交给工具，才是长期好用的关键。
