Codex 忙了半小时：该继续等，还是接管任务？

适合已经把任务交给 Codex，却看不懂它的进度、担心白等或反复返工的人。你只需要能看到任务记录，以及项目文件、命令结果或交付物中的一种；不需要额外插件，也不需要先换模型。

先问：最近一次操作，新增了什么证据，推进了哪项验收？ 没有改文件不一定是空转，分析出一个错误假设也有价值；输出很多文字也不等于任务接近完成。

下载空白进展记录表（Markdown） · 下载本站填写示例（Markdown）

下载文件可用文本编辑器打开。浏览器若改为展示正文，可另存为文件；只需把空白表里的占位符换成自己的任务。模板不运行命令、不连接账号、不上传数据。

先分清四种状态

你实际看到的证据	当前更合理的判断	下一步
找到了相关文件、排除了一个假设，或目标检查结果发生变化	有效推进，即使暂时没有代码改动	继续到约定的检查点
正在执行具体命令，有任务标识或可查看的日志	等待执行结果	看这条命令的状态，不重复启动同一任务
权限、缺失资料、环境或外部服务有明确报错	有阻塞，不能靠“继续努力”消除	只补齐必要条件；未获准的操作保持停止
重复读同一批文件、重跑相同失败命令，没有新输入、新假设或新结果	值得介入检查，尚不能直接断言模型坏了	要求证据摘要，缩小下一步，约定退出条件

这里没有“超过五分钟就停止”的通用阈值。首次安装依赖、全量构建和研究任务耗时不同；应先约定检查点，例如“完成定位后”“首次目标测试返回后”。不知道命令是否仍在执行时，状态写“待核实”，不要填“失败”或“已完成”。

一张短表，别再只问“好了吗”

先确定一个可核验的目标，例如“原始请求恢复正确响应，同时保留现有接口”。每到检查点填写以下内容：

目标与验收项：
当前状态：推进 / 等待 / 阻塞 / 需纠偏 / 已验收 / 待核实
最近一次新证据：[时间、文件/命令/产物、实际结果]
它推进了哪项验收，或排除了哪个假设：
还缺什么证据：
下一步：[一个动作、预期能得到什么证据]
停止或改路条件：

证据应能回到命令输出、diff、测试结果、页面或原始材料。Codex 自己写的“检查通过”只能当摘要，仍需核对对应结果；测试数量和文件数量也不能替代验收。

一个真实记录：请求失败，不等于应该重部署

2026-10-05 晚间，本站需要确认当天内容已发布且页面可访问。第一种请求方式失败了。如果沿着“网站坏了”的假设不断改代码或重部署，就可能把排查带偏。

下表按当天公开复盘重新整理，时间为 Asia/Shanghai。这是已有真实过程的复盘，不是事前使用本模板的对照实验，也没有证据证明当时 Codex 陷入循环。

检查点	新证据	能得出的结论与下一步
20:00–20:02	同一提交的质量 CI、Workers 构建均成功	构建已完成；还需确认用户能看到页面
20:01	Python 请求出现 403 或 TLS EOF	该请求路径失败，根因未知；换一种独立方式验证，不立即改代码
随后的浏览器核验	首页入口能打开新案例，正文与检查命令可见	至少浏览器访问路径可用，不能断言全站宕机
20:02–20:03	curl 请求案例与 Sitemap 返回 200，正文标记和 URL 正确	页面交付获得更多证据；原 Python 异常仍保留为未解决项
20:05	其余两篇文章返回 200，标题匹配	本轮目标页面核验完成；不外推为全天可用率

有价值的变化是从“有错误”走向“知道错误能证明什么”。下一步应填补证据缺口，而不是换个说法再运行一遍同样的命令。

三段可直接改用的提示词

以下是本站整理的方法模板，不是官方命令，也不保证所有故障都能靠提示词恢复。按你的实际权限和任务范围修改。

1. 状态不明：先要一份证据摘要

请先给我一份简短进展摘要，不扩展任务范围：
1. 对照原始验收项，哪些有证据完成，哪些仍未完成？
2. 最近一次新增的证据是什么？给出文件、命令结果或产物位置。
3. 当前是在执行、等待、被阻塞，还是你还无法确认？
4. 如果重复了先前操作，说明新输入或新假设是什么。
5. 下一步只列一个最能缩小不确定性的动作，以及退出条件。
没有实际结果的内容请标“未验证”，不要补写测试通过。

2. 确认绕圈：缩小动作，不扩大权限

请停止扩展方案，只处理这一项：[尚未通过的验收项]。
保留已有改动和原始失败证据，不删除测试、不改无关模块。
先说明刚才的重复尝试为何没有推进，以及这次要改变的唯一条件。
执行一个最小验证；如果仍是同一失败且没有新证据，先报告阻塞，
不要自动重复，也不要扩大权限、重装环境或重新部署。
如果需要取消正在运行的操作，先确认其状态和安全停止方式。

3. 已有交付物：把“继续优化”换成验收

先不增加功能，按原约定验收现在的产物。
逐项列出：验收条件、实际检查、结果、未验证范围。
区分代码已改、本地通过、远端检查通过和线上可见。
只修复验收中发现的必要问题；全部满足后交付，不再扩展范围。

依据 2026-10-06 核对的 OpenAI Prompting，Steer 用于给当前运行补充指导，Queue 留到下一轮。想纠正当前方向时，先看消息实际采用哪一种行为；不要把“已经排队”理解为“当前任务已收到纠偏”。界面与快捷键以所用客户端为准。发送一段话也不等于正在执行的命令已被取消。

怎样验收这套方法

在自己的一个任务里，只选一个检查点试用空白表：

1. 不看 Codex 的结论，打开它给出的证据，确认确实存在且属于这次任务。
2. 检查下一步是否能关闭一项验收或排除一个假设，而非泛泛“继续分析”。
3. 若仍未完成，记录具体阻塞与保留现场的位置；“未知”也是合法结果。
4. 已满足约定时结束任务，不以“再多做一点”替代交付。

你能拿走的是一次可审查的任务状态，而不是“空转自动检测器”。本站没有测量它能节省多少额度或时间，也没有测试它在所有客户端的消息传递行为。

常见误判

• 看不到文件改动，就催它重写。 先看是否在定位、运行测试或等待结果，研究任务也可能只产生结论。
• 每隔几十秒索要报告。 频繁打断会增加沟通，按自然检查点观察更合适。
• 网络失败就开放全部权限。 先看实际错误与所需条件；更大权限不能证明根因已解决。
• 换模型后好了，就认为原模型普遍降智。 输入、上下文、环境和任务状态都可能变化，单次体验不能确定原因。
• 不知道前一次是否执行，就再次提交或部署。 先核验外部状态，避免重复动作。

来源与验证范围

• OpenAI Prompting：任务边界、验证与 Steer/Queue；本站核对 2026-10-06。
• OpenAI Long-running work：以结果、约束、验证定义完成；本站核对 2026-10-06。本文的方法表是本站整理，并非官方进度判定算法。
• The Progress Trap 社区原帖：2026-10-01 发布，本站于 10-06 重读。作者报告一个长项目持续产生工作但完整里程碑未验收；仅作为问题线索，未审计其全部材料，也不据此确认平台缺陷。
• 本站填写示例依据上述 10-05 公开记录，展示成功路径与未解决异常。没有伪造模型循环、恢复对照或用户收益数据。

任务已经结束但结果仍不能用时，继续看完成后的四层验证；方向本身不清晰时，先看如何缩小任务边界。