Codex长对话怎么压缩上下文？compact前保存约束、压缩后核对任务

一个项目聊了很多轮，测试日志、尝试方案和修改记录挤在一起，继续任务时容易遗漏关键要求。Codex CLI提供/compact来总结当前可见聊天、释放上下文空间。压缩能减少旧消息负担，但摘要需要核对。本文用一次进行中的小型代码修复，说明压缩前记录什么，以及压缩后怎样安全接着做。

第一步：分清recap、compact与clear

/recap用于获取回顾，不压缩上下文；/compact把前面的会话整理成简要摘要以释放空间；/clear开启新的聊天上下文。还想继续原任务时，不应因为消息太多就误用清空。压缩也不会把磁盘文件恢复到某个版本，更不能替代Git提交或备份。

先确认终端里的Codex已经完成当前操作并处于可输入状态。不要一边让它运行长命令，一边把压缩当作停止任务的方法。若当前版本提供菜单确认，阅读说明后再继续；CLI能力与普通网页聊天菜单不同，不在网页中输入同名命令就假定效果相同。

第二步：先生成任务回顾

/recap

阅读回顾时，重点找目标是否仍准确、用户修改过的要求是否保留、已完成的事项有没有混入计划。模型此前说“将检查测试”不代表测试已经通过；一句“问题已处理”也不能替代退出状态和实际结果。先把缺少的证据补充到当前会话，再考虑压缩。

请整理压缩前检查表：当前目标、明确约束、已经修改的文件、已执行验证及结果、尚未解决的问题、下一步。把已确认事实和推测分开。不得把计划当成完成，不运行新命令，也不修改文件。

第三步：补齐不能丢的约束与状态

以修复登录跳转为例，应保留目标页面、触发条件、允许修改范围与验收方式；如果用户要求不动支付模块，这条不能被“完成登录修复”概括掉。对于暂时失败的检查，记录原始失败原因和仍缺少的依赖，不只写一个“测试待做”。

当前任务：修复练习项目登录后回跳。
边界：只改登录相关文件，不修改支付配置。
已完成：填写真实文件与实际差异。
验证：填写已运行检查、结果与失败原因。
待处理：填写具体问题。
继续前：先核对当前文件与分支，再按待处理列表工作；不得自动部署或提交。

上面是填写模板，不是已经发生的测试记录。重要决定可由你另存到任务笔记，保存前检查是否包含令牌或私密日志；不要把一整段聊天无差别塞进项目长期指令。任务状态和长期通用规则的用途不同，维护一份短且准确的工作记录更有帮助。

第四步：执行compact并阅读摘要

/compact

官方说明该操作以简要摘要替换较早的可见会话内容，保留关键点以减少上下文占用。若界面提供确认提示，按当前提示完成，不假定所有版本的交互完全一样。它压缩的是会话表示，不会自动修复代码，也不保证每条历史细节原样保留。

对照刚才的检查表看摘要，尤其检查最后一次用户修正、禁止事项、尚未通过的验证和下一步。遇到缺失，应明确补回正确内容，而不是让模型“凭记忆继续”。原始日志很长时，可保留其位置和结论，再在需要时重新读取。

第五步：先只读核对，再继续执行

先只读核对压缩后的任务状态：复述目标、修改边界、已完成验证和待处理事项。检查当前分支及相关文件是否与摘要一致。发现冲突先列出，不按旧摘要覆盖新改动；核对完成后给出下一步建议，暂不执行写入。

磁盘可能被其他程序修改，摘要也可能保留了过时路径。继续前检查真实文件，就能避免把“压缩前存在”的状态当作现在仍成立。确认后再进入原来的工作流程，只运行与未解决问题相关的检查，不因压缩而重复所有已完成操作。

验收标准是任务目标、约束、证据与下一步都准确，且当前文件状态已经重新确认。若只需要简短回顾而上下文并不紧张，使用recap即可；若要换一个无关任务，则按需要新开会话。根据目的选择，才能让长对话管理服务于实际工作。

官方资料

资料核对日期：2026年11月6日。

• OpenAI：Developer commands