当前位置：首页 > news >正文

Codex 聊着聊着开始答非所问怎么办？ChatGPT Plus / Pro 用户整理上下文的方法

news 2026/7/31 11:17:00

上午让 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 基于三份文件重新建立任务认知。