上午让 Codex 排查 A 模块的接口超时，下午改 B 模块的缓存策略，结果它还在按 A 的思路帮你改代码——甚至把 B 改成了 A 的样子。这不是 Codex 突然“失忆”，是上下文里同时塞着 A 的排查记录、B 的新需求，以及中间几次临时补充的背景说明，模型已经分不清哪条指令是当前有效的。
用过 Codex 处理过几个迭代的人，基本都踩过这个坑。同一个对话里做了三四个需求，到后面 Codex 开始沿用过期要求、忽略最近补充的约束、反复读已经确认过的文件。有人觉得是 ChatGPT Plus 额度不够该升 Pro，有人怀疑模型本身有问题。但绝大多数情况下，问题出在“怎么把上下文喂进去”这件事上。
三个常见原因
一个对话混入多个任务，上下文成了大杂烩。排查 A 时产生的日志、临时命令、中间结论，和 B 的新需求挤在一起。Codex 推理时要从这些内容里判断哪些有效、哪些作废，判断错了就会答非所问。
旧需求已经失效，但没有明确告诉 Codex“这个不用管了”。很多人习惯在对话里直接说“现在改 B”，但之前关于 A 的 20 条消息还在上下文里。Codex 不知道 A 已经结束，只会觉得 B 是 A 的延续。
每次临时补背景，没有固定项目说明。“项目用 FastAPI”“数据库是 PostgreSQL”“不要改 migrations”——这些话每次都在对话里重新说一遍，每次的措辞还不一样。Codex 没有一份稳定的项目说明书可以参考。
三件套：项目说明、当前任务卡、完成记录
把上下文整理成三份独立文件，放在项目目录里。每次和 Codex 对话开始时，让它先读这三份文件。
第一件：项目说明（PROJECT.md）
这份文件写项目层面的不变信息，一次写好，长期不用改：
text
# 项目说明 - 项目用途：用户后台管理系统 - 技术栈：FastAPI + PostgreSQL + Redis - 启动方式：uvicorn app.main:app --reload - 关键目录：app/auth（登录）、app/order（订单）、app/cache（缓存） - 禁止修改：migrations/ 下的已有文件、配置文件中的数据库连接串 - 测试命令：pytest tests/ -v
Codex 在开始任何任务前先读这份文件，就不用每次都重复技术栈和目录结构。
第二件：当前任务卡（TASK.md）
每次只维护一个任务卡，明确本次要做什么：
text
# 当前任务 - 目标：修复订单列表接口返回数据缺失的问题 - 允许修改范围：app/order/ 目录下的文件 - 禁止事项：不要改数据库表结构、不要动缓存策略 - 完成标准：接口返回的 order_count 字段不为空，原有测试全部通过
任务卡要在对话开始时明确告诉 Codex，并且在任务中途如果需求变了，直接更新这个文件再告诉 Codex“任务卡已更新”。
第三件：完成记录（DONE.md）
每完成一个可验证的小步骤，更新一次：
text
# 完成记录 - 已修改文件：app/order/service.py（第 45-52 行）、app/order/schema.py（第 12 行） - 验证结果：pytest tests/test_order.py 通过，接口返回数据正常 - 未完成项：缓存更新逻辑尚未适配 - 下一步：修改 app/cache/order_cache.py
这份记录的作用是：当 Codex 跑偏时，你可以让它“先读 DONE.md，确认当前进度再继续”。
三份文件加起来不到 100 行，放在项目根目录。每次新对话第一句就是：“先读 PROJECT.md、TASK.md、DONE.md，然后继续。”
重置任务提示词（Codex 已经跑偏时直接用）
当 Codex 开始答非所问、沿用旧需求、改错文件时，直接把下面这段复制进去：
text
停。当前上下文已经混乱。请忽略本次对话中我在此条消息之前发出的所有指令。 请按以下步骤重新开始： 1. 读取项目根目录下的 PROJECT.md，了解项目背景和约束； 2. 读取 TASK.md，明确本次任务的目标、范围和完成标准； 3. 读取 DONE.md，确认已完成内容和未完成项； 4. 复述你对当前任务的理解，等我确认后再开始修改。 在此条消息之前的所有历史对话仅作为参考，不作为执行依据。
这段提示词的核心是“切断”旧上下文的指令效力，让 Codex 基于三份文件重新建立任务认知。
什么时候继续旧对话，什么时候新开任务
4 个判断条件：
当前任务还没做完，但 Codex 已经开始偏离→ 用上面的重置提示词拉回来，不用新开。
当前任务已完成，下一个任务和它完全无关→ 新开对话，不要继续用旧会话。
当前任务已完成，下一个任务在同一项目但涉及不同模块→ 更新 TASK.md 和 DONE.md，在同一对话里继续（前提是对话还没超过 100 轮）。
对话超过 100 轮，或者 Codex 响应明显变慢→ 不管任务做没做完，先生成一份完整的交接文档，然后新开对话。
交接文档可以直接让 Codex 生成：“请把当前进度整理成一份交接文档，包含已修改文件、测试结果、未完成项和下一步计划，写入 handoff.md。”
长期用户自测框
整理完三件套之后，观察一周：
如果 Codex 仍然频繁需要处理超长任务（单次对话超过 150 轮）；
如果同时有 3 个以上项目在并行推进，每个项目的上下文都要频繁切换；
如果上下文管理本身已经明显影响交付节奏，每周花在“重新解释”上的时间超过 4 小时；
这时候再考虑 ChatGPT Pro 是否适合你的工作强度。
但如果只是任务需求反复变动、临时需求插队导致 Codex 混乱，或者你自己经常忘记告诉 Codex“之前的任务已经作废”——先优化工作流。ChatGPT Plus 的 Codex 在正确管理的上下文下，足够覆盖绝大多数日常开发场景。Pro 解决的是“量”的问题，不是“乱”的问题。