上午让 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/ -vCodex 在开始任何任务前先读这份文件就不用每次都重复技术栈和目录结构。第二件当前任务卡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 解决的是“量”的问题不是“乱”的问题。