让 Codex 学会自我纠错：迭代修复循环的工程实践

Sat, 23 May 2026 09:00:00 +0800

一次提交就能写好代码？别做梦了

写代码的人都知道一个朴素的道理：第一次写出来的代码几乎不可能完美。你需要运行它，看看哪里报错，修一修，再跑一遍，再修一修。这个过程循环往复，直到代码真正可用。

那 AI 编程 Agent 呢？大多数人对 Codex 的使用方式是：扔一个任务进去，拿一个结果出来，看看行不行，不行就换个说法再试一次。这种「一次性投喂」的模式，本质上是把人类的迭代思维压缩成了一次性操作。

OpenAI 开发者关系团队的 Shreekant Agrawal 最近在官方 Cookbook 上发布了一篇教程，展示了另一种思路：让 Codex 自己建立一个「审查、修复、验证」的闭环，通过结构化的反馈驱动多轮迭代，直到问题真正被解决。

这不是一个玩具 Demo。它用三个故意写坏的 Jupyter Notebook 作为测试素材，展示了从一轮修复到三轮修复的完整收敛过程。

整个工作流分为三个阶段，每个阶段有明确的职责边界：

审查（Review）：读取当前产物，返回结构化的问题清单。这个阶段不修改任何文件，只负责发现问题。问题类型包括过时的 API 调用、缺失的环境配置说明、运行时风险等。

修复（Repair）：拿到审查结果和上一轮的验证反馈后，对产物做最小化修改。注意「最小化」三个字，Agent 被要求不要大刀阔斧重写，而是针对具体问题做精准修补。

验证（Validate）：执行修复后的产物，检查是否真正可用。对于 Notebook 来说，就是跑一遍所有代码单元格。验证失败的具体错误会成为下一轮修复的输入。

这三个阶段形成一个循环：审查发现问题，修复尝试解决，验证确认结果。如果验证不通过，失败原因直接进入下一轮的修复指令。

很多人用 Codex 的方式是自然语言对话，输出也是自由文本。但这个工作流的精髓在于，每个阶段的输入和输出都是严格的 JSON Schema。

审查阶段返回的是一个 findings 数组，每个 finding 包含 artifact（哪个文件）、issue_type（问题类型）、severity（严重程度）、description（描述）和 suggested_fix_direction（建议修复方向）。

修复阶段返回的是一个 fix 对象，包含 changes_made（做了什么改动）、unresolved_items（没解决的问题）和 updated_artifact_path（修复后的文件路径）。

验证阶段返回的是一个 validation 对象，包含 overall_passed（是否通过）、cases（每个验证用例的结果）和 remaining_delta（剩余问题）。

这种设计的好处是显而易见的：每个阶段的输出可以直接作为下一个阶段的输入，不需要人工解读。调试时你可以打开 record.json 文件，一眼看到每轮迭代发生了什么。

教程准备了三个故意写坏的 Notebook，难度逐级递增：

简单案例（Qdrant 向量搜索）：API 调用过时了，需要从旧版 qdrant.search 迁移到 qdrant.query_points。这类问题通常一轮修复就能搞定。