凌晨两点，我正准备用 Codex 把老项目里那个“屎山”登录模块重构掉。刚开始还挺顺利，我甩给它整个项目的上下文，要求“读取登录相关代码、优化鉴权逻辑、修改拦截器、补充单元测试并修复所有潜在报错”。

头十分钟，它确实在吭哧吭哧地翻文件。但就在修改到第三个文件、准备运行测试时，窗口突然卡住，随后输出中断。重新唤起后，它茫然地问我：“请问您的项目结构是怎样的？登录逻辑在哪里？”

那种血压飙升的感觉，想必你也很熟悉。很多人把这类中断归咎于会员额度不够，但经过反复踩坑，我发现长任务中断的根本原因，99% 不是算力不足，而是任务设计与上下文管理失控。

一、Codex为什么处理长任务时更容易中断

Codex 本质是一个无状态的对话模型。它不像一个持续在后台运行的项目经理，而像一个记忆力极强但短期记忆容错率低的高级工程师。当发生以下情况时，它的“思维链条”极易断裂：

1. 任务目标过于宏大：当你抛出“重构整个项目”这种指令时，Codex 无法在一个“思考周期”内完成全局最优解的计算，它会试图生成一个覆盖全量的计划，导致计算资源（上下文窗口）被计划本身占满。

2. 单次修改文件过多：试图一次性输出 5 个以上文件的完整代码，输出的 token 量巨大，极大概率触发输出层的截断保护机制。

3. 上下文对话过长：在你反复调试报错的过程中，之前的错误堆栈、修复尝试、新的报错信息不断累积，导致最开始的“系统指令”被挤出窗口。

4. 测试与修复循环混乱：每次运行测试都会产生大量日志。如果把这些日志全部丢回给 Codex，它会花费大量算力去“消化”这些噪音，而不是去“修复”逻辑。

5. 缺乏显式的进度锚点：由于是无状态对话，一旦中断，Codex 无法知道自己在“5步计划”中走到了哪一步，只能重新开始推理。

二、不要让Codex一次处理整个项目

要解决中断问题，首先要改变交互范式：把 Codex 当成一个“结对编程的实习生”，而不是“外包的开发团队”。

错误示范：

“帮我检查整个项目，把所有问题都修复。”

正确拆解示范（分阶段推进）：

第一阶段（分析）：“先分析登录模块，只读取src/login下的文件，不要修改代码。输出文件关系图、潜在的代码异味列表。”
第二阶段（计划）：“基于上一步的问题，生成一个修复计划，按优先级排序。”
第三阶段（执行+验证）：“执行第一项计划，修改LoginService.ts。修改完成后，立即生成对应的测试用例并运行。测试通过后，向我汇报，等待下一步指令。”

核心原则：

• 先读后写：让 Codex 先建立“心智模型”。

• 原子化提交：一次只处理一个具体的逻辑点（如“修复 Token 刷新逻辑”），而不是“优化鉴权模块”。

• 测试即锚点：每修改一步，就用测试结果作为该阶段完成的“里程碑”。

三、给Codex建立项目任务说明书

为了对抗 Codex 的“无状态”，我们需要在对话中建立一个持久化的“项目任务说明”。每次新开对话或感觉 Codex 记忆模糊时，直接将该模板复制到对话框中。

推荐复制的 Markdown 模板：

markdown

# 项目任务说明（上下文锚点） ## 1. 当前核心目标 修复登录状态在页面刷新后失效的问题，并优化 Token 刷新机制。 ## 2. 允许修改的文件边界 - src/auth/ - src/store/modules/user.ts - src/utils/request.ts - **严禁修改**：src/payments/（支付模块）、src/orders/（订单模块） ## 3. 技术约束 - 使用 Vue3 + Pinia。 - Token 存储在 Cookie 中，过期时间 30 分钟。 - 刷新 Token 接口为 /auth/refresh。 ## 4. 验收标准 - 刷新页面后，Pinia 状态能从 Cookie 恢复。 - Token 过期时，自动刷新，不报 401 错误。 - 现有 Jest 测试用例通过率 100%。 ## 5. 当前进度（状态记录） - **[已完成]**：修复了 Cookie 解析失败的问题。 - **[进行中]**：正在处理并发请求导致 Token 重复刷新的锁机制。 - **[待解决]**：登出时清除所有定时器。

四、善用“交接记录”与状态锚点

当你发现对话过长，或者准备切换设备/网络时，不要直接关闭窗口。在中断前，强制要求 Codex 生成一份“交接记录”。

提示词示例：

“由于上下文过长，请生成一份当前状态交接记录。内容包括：1. 已修改的文件列表及改动摘要；2. 当前未通过的测试用例名称；3. 下一个待执行的具体操作命令。请用纯文本格式输出，以便我新开对话时直接复制。”

这份记录可以让你在新会话中，秒级恢复 Codex 的记忆，彻底摆脱“重新解释项目背景”的噩梦。

五、结语

客观来说，ChatGPT Plus 或 Pro 的额度确实会影响调用的频率，但对于单次任务中断，额度从来都不是第一要素。

通过拆分任务粒度、限制上下文长度、建立文件边界、强制状态记录这四板斧，你会发现 Codex 的执行稳定度大幅提升。下次任务中断时，不妨先看看上下文窗口里是否塞满了无关的日志，而不是急着去升级套餐。

Codex长任务排查清单：

1. 是否一次性要求修改了 3 个以上核心文件？

2. 上下文是否包含超过 5000 字的报错堆栈？

3. 对话轮次是否超过 15 轮未重置？

4. 是否明确指定了“只读”和“可写”的文件路径？

如果以上中了任意一条，优化你的提示词，比换账号更管用。