Codex 上下文与会话历史怎么管理？长任务实践

Codex 的上下文指什么？

当前任务中被纳入处理范围的信息总和：对话内容、指定的文件、项目结构与工具读取到的输出，都属于上下文。

上下文不是越大越好。信息过多时，任务相关的约束会被淹没在无关内容里，模型更容易忽略既有约定、误改无关文件，排查成本随之上升。

控制上下文的核心手段有两个：明确任务边界，以及只提供与任务相关的文件和说明。给得准比给得多重要。

会话历史存在哪里？

取决于使用入口：本地命令行与编辑器任务通常留有本机记录，云端任务保存在账号体系内；两类的可见范围与保留策略不同。

• 本地记录随设备走，换机器不会自动带走。
• 云端任务与账号绑定，同账号可在其他设备访问。
• 企业或团队空间的记录归属以账号体系规则为准。
• 清理方式与保留周期以官方数据说明为准。

上下文太长会出现什么问题？

三个典型症状：遗忘早期约定、修改范围失控、回复质量随对话长度下降。发现这些信号时应及时新建任务。

• 此前的约束条件被忽略，重复犯错。
• 为完成任务而大范围改动无关文件。
• 回复开始出现与仓库事实不符的描述。
• 同一任务里混杂多个目标，难以验收。

长任务怎么分段管理？

按可验收的里程碑切段：每段一个目标、一组文件、一个验证方式；段与段之间用简短的交接说明衔接。

分段的另一个好处是成本可控：每段对话都短而聚焦，消耗更接近实际工作量；出现误改时也更容易判断是哪一段引入的，回退范围更小。

1. 1开工前把任务拆成若干个可以独立验收的片段。
2. 2每段开始时重新说明目标、范围与约束，不依赖上文的模糊记忆。
3. 3每段结束后运行验证命令并检查 diff，确认后再进入下一段。
4. 4需要延续时，用一页交接说明概括已完成事项与待办事项。

哪些内容不该进入上下文？

生产密钥、真实用户数据、内部机密文档与完整支付信息都不应进入任务上下文，无论本地还是云端。

养成用示例数据替代真实数据、用脱敏片段替代完整文件的习惯。上下文里的信息一旦进入历史留存，清理成本远高于提前排除。

• API key、数据库连接串与生产环境凭据。
• 包含个人隐私或客户信息的文件与截图。
• 未脱敏的日志、订单与支付数据。
• 与任务无关的内部文档与合同。
• 临时使用的调试密码与临时令牌，用完即应轮换。

换设备后怎么继续之前的任务？

云端任务依赖账号登录直接访问；本地任务需要把代码与必要的上下文说明一并带过去，历史本身不能直接迁移。

最稳妥的延续方式是代码优先：确保变更已提交到仓库分支，再用一段简短的交接说明描述当前进度与下一步目标。这样在任何设备上都能重建任务上下文，而不是依赖某个工具的历史记录。

交接说明建议包含四要素：目标与背景、已完成变更、验证方式、下一步计划，控制在半页以内，任何人都能据此接手。