一个项目在 Codex 里反复折腾了一个月，还是怎么都解不开。
我一开始以为，只要继续补上下文、继续改提示词、继续让 Codex 尝试，总会跑通。实际结果却是：对话越来越长，改动越来越多，真正卡住的问题依然没有被说清楚。
后来我换了一个入口。我在普通聊天里选择 5.6 Pro，用 @GitHub 让它读取项目，但先不允许它改代码。我们只讨论目标、第一阻塞点、根因、约束和验收证据。
就这个具体项目的体验看，聊天里的 5.6 Pro 达到了我使用 Codex 5.6 Sol max 时感受到的深度。它不是把答案写得更长，而是真的把那个在 Codex 里沉了一个月的问题想通了。
这只是我的项目实测，不是 OpenAI 官方模型映射，也不代表所有项目都会得到相同结果。
什么时候适合这样做
当项目出现下面这些情况时，可以先把执行停一下：
- Codex 已经反复修改，但同一个问题持续出现；
- 对话很长，却说不清真正的第一阻塞点；
- 你无法给出明确的验收标准，只能不断说“再优化一下”；
- 每一轮都产生新改动，但没有可观察的进展。
如果问题只是明确的小 Bug、单文件修改，或者根因已经清楚，就没必要多绕一层，直接让 Codex 执行和验证更合适。
三步救援工作流
第一步：先在普通聊天里把问题想透
选择聊天 5.6 Pro，用 @GitHub 读取仓库。先不改代码，只讨论目标、第一阻塞点、根因、关键约束和验收证据。
这一步的交付物不是一篇泛泛的分析，而是一份可以直接执行的交接。
第二步：把已经想清楚的上下文带回 Codex
在 Codex 里引用 @刚才的项目对话，要求它以已经确认的目标、约束和验收标准为准，重新读取当前仓库现场。
第三步：只解决并验收第一阻塞点
不要一次继续铺开整个项目。让 Codex 只处理第一阻塞点，运行匹配的验证，并分别报告实现状态、验证状态和残余风险。
两段可直接复制的 Prompt
在普通聊天里这样说：
@GitHub 读取这个仓库。先不要改代码。请和我一起把当前目标、第一阻塞点、根因、关键约束和验收证据聊清楚，最后输出一份给 Codex 的执行交接。
交给 Codex 时这样说：
@刚才的项目对话 以其中已确认的目标、约束和验收标准为准，读取当前仓库现场，只解决第一阻塞点；完成后运行相应验证，并分别报告实现状态、验证状态和残余风险。
做到什么程度才算完成
用下面四项验收，不用“代码已经写完”验收：
- 能用一句话说清当前目标；
- 只保留一个第一阻塞点；
- Codex 完成了对应修改并运行了匹配的验证；
- 实现状态、验证状态和残余风险被分别报告。
失败后怎么调整
如果普通聊天仍然给不出清晰根因，不要让它编造确定答案。让它列出证据、冲突点和需要补充的信息：缺日志就先取日志，缺复现就先做最小复现，缺业务选择就停下来由人决定。
如果 Codex 执行后仍然复现同一问题，也不要在同一方向无限加补丁。把新的运行证据带回深度讨论，重新判断根因。
省用量只是第二收益
按我这次账户里的观察，这个流程减少了 Codex 里的无效往返和配额消耗。但实际计费与配额仍以每个人自己的 Usage 页面为准。
我真正想分享的不是一个省 token 技巧，而是一次项目救援：普通聊天里的 5.6 Pro，先把 Codex 一个月没想通的沉疴想通，再由 Codex 把已经明确的结论落到真实项目里。
工具是否用对，最终不看聊了多少轮，而看项目有没有得到一个可验证的结果。