Codex 中的预测—规划—评审—验证分阶段工作流

一句话结论

把 Sol 的长程编码任务拆成预测、规划、实现、对抗评审和验收五段，可把“模型自称完成”与“按计划交付”分开检查。

适用场景

• 适合的任务：多文件编码、代理编排、测试驱动实现和容易出现无限修复循环的长期任务。

• 不适合的任务：一次性问答或没有可验证产物的创意任务。

• 适用的模型版本：GPT‑5.6 Sol；也可迁移到其他代码代理。

• 适用的客户端、Agent 或 API：Codex、OpenCode 等能保存计划、运行测试和复查代码的 Agent。

• 推荐的推理档位和参数：评论没有给出固定档位；先用能完成任务的最低档位，循环任务单独记录成本。

可直接使用的内容

以下是根据评论中公开的阶段名称重建的可复用骨架，不是作者公开的完整系统提示：

prediction_stage:
  写下预期行为、关键风险、最小验收信号。
planning_stage:
  将目标拆成可检查的步骤；明确范围、不可改变的接口和停止条件。
implementation_stage:
  只实现当前计划，边改边运行针对性测试。
review_stage:
  对实现和测试做对抗性检查，重点找奖励投机、过度工程和测试放水。
verifier_stage:
  将实际产物逐项对照计划与验收信号；通过则交付，失败则只回到缺失阶段。
loop_policy:
  若验证失败，给出具体缺口和下一步；达到停止条件后禁止继续扩张范围。

测试/工作流步骤

1. 在任务开始前保存 prediction 和 plan，避免后续目标漂移。

2. 实现阶段只提交与当前计划相关的代码和测试。

3. 评审阶段检查测试是否真的覆盖需求，是否为了“通过”而弱化断言。

4. 验证阶段运行独立命令或黑盒检查，并逐项记录通过/失败。

5. 循环时只修复失败项；如果模型反复改动同一处，暂停并让人确认范围。

原始证据与数据

• 评论公开提到的顺序是 prediction_stage、planning_stage、review_stage 和 verifier_stage，并建议在代码和测试落地后检查 reward hacking。

• 评论者明确说这是自己测试中的 hack，不是受控基准或官方 Codex 配置。

• 同一帖子主文对 Sol Ultra/Max 的体验存在强烈争议；评论区有用户报告高效，也有用户报告过度工程和耗尽额度。

适用边界

• 这是一条社区工作流建议，不代表 Sol 的默认行为或 OpenAI 官方最佳实践。

• 阶段名称和示例需要映射到实际 Agent 的 hook、文件或命令；来源没有给出可复制的完整配置文件。

• 验证阶段不能替代人工审查高风险变更，尤其是数据库、权限和生产部署操作。

来源摘录或观察（仅做合规短引）

评论建议在实现和测试完成后，用 review_stage 检查 “signs reward hacking in tests”。