AI 编码让实现速度越来越快。
很多人可能已经处于人类无法跟上所有实现审查的状态。
作为解决方案之一，本文介绍了自制的 Skill（技能）codex-review 的最新版本——它让 Codex 子 Agent 承担审查角色，反复修正和重新审查，直到重要问题全部消除。
实际上是六个月前创建的 Skill
实际上，这个 Skill 的基础是在大约六个月前创建的。我一直在逐步改进，并定期使用它。
https://x.com/makaneko_AI/status/2005475035075707092
之前的版本介绍的方法是由 Claude Code 负责实现，Codex 作为审查者被调用，反复进行修正和重新审查。当时，Claude Code 在实现任务上很强，而 Codex 只是“聪明”，所以采用了那种配置。
然而，AI 环境已经彻底改变。Codex 现在在实现上更强、也更聪明了（除了 Fable 5），很多人可能仅用 Codex 就能完成实现任务。
为了适应这样的环境，我对内容进行了更新，使得循环在 Codex 内部运行。
最新版本中改变的三点
基本流程与之前版本相同。
将实现主导者和审查主导者分开 ↓ 审查者以只读模式查看 ↓ 若有重要问题被提出，则判定不通过 ↓ 修正 ↓ 使用相同方法重新审查 ↓ 迭代直到通过
最新版本的关键点如下三点：
1. 针对 GPT-5.5 优化
2. 聚焦重要问题
3. 整体精度提升
下面依次说明。
1. 针对 GPT-5.5 优化
截至 2026/06/18，OpenAI 最新 GPT-5.5 系列被定位为适合 Agent 编程和实际工作的模型。它被描述为能够自主处理多步骤、模糊的任务。
查看官方 GPT-5.5 指南，会发现类似“与其塞入详细步骤，不如简洁地写出期望结果，效果更好”的建议。
因此，在最新版本中，我停止了列出详细的模板，而是强化了审查者必须遵守的规则。
https://x.com/makaneko_AI/status/2049848091860463995
2. 聚焦重要问题
Codex 有一个倾向，即凭借其智力，无论好坏都会挑剔细节。
所以，在最新版本中，我明确告诉审查者“只提取 P0/P1 级别（最高/高优先级）的问题，不处理小的风格问题”。
这样一来，不必要的重复小修正减少了，流程更顺畅了。
3. 整体精度提升
我在细节上全面提升了精度。
例如，堵住了审查中途停止却被标记为通过的漏洞。审查者未能启动，或返回的报告损坏无法读取的情况，不再被标记为通过。
即使较大的改动由多个审查者共享，只有所有审查者都返回通过且没有未审查或失败的审查时，整体才通过。这些改进降低了遗漏问题的风险。
推荐用法
这个 Skill 被设置为在规格设计或中大规模实现之后自动触发，但建议在用户期望的时机启动。
例如，在 Codex 始终首先读取的 AGENTS.md 文件中添加“当……时执行 Codex 审查”。或者，如果存在实现计划格式，则将其作为强制步骤纳入。
之前版本的解说文章也说明了这一点。
https://note.com/makaneko_ai/n/n3cefcec49e2d
Skill "codex-review" 全文
规模 | 标准 | 策略 |
|---|---|---|
小 | ≤3 个文件，≤100 行 | 一次 diff 运行 |
中 | 4-10 个文件，100-500 行 | 架构 → 一次 diff 运行 |
大 | >10 个文件，>500 行 | 架构 → diff（多次并行运行）→ 交叉检查 |
{
"ok": false,
"summary": "审查摘要",
"issues": [
{
"file": "src/auth.py",
"lines": "42-45",
"problem": "问题描述",
"recommendation": "修正方案",
"verification": "修正后的验证方法"
}
],
"notes_for_next_review": "备注"
}
``text
## 修正循环
如果 ok=false，则最多迭代 max_iters 次。默认值为 max_iters=5。
1. 分析 issues 并创建修正方案。
2. 实现者以最小 diff 进行修正（将规格变更作为未解决问题保留）。
3. 根据变更风险执行测试、lint 或替代验证。若不执行，则留下原因；若关键路径上未验证，则视为阻塞。
4. 以相同模式重新审查。
停止条件：
- ok=true：关卡通过
- 达到 max_iters：关卡失败
- 连续两次测试失败：关卡失败
- 审查者失败 / JSON 解析失败 / 输出格式缺失 / 存在未审查区域：关卡失败
如果因关卡失败而停止，则在最终报告中将剩余的阻塞、未审查和失败的验证标记为未解决。
## /review 回退
仅在 JSON 关卡失败时使用 /review。/review 是辅助发现工具，其输出不能直接用作 ok=true 的依据。
## 错误规则
- 如果审查者未能建立，则在最终报告中记录失败原因、尝试的审查者路径以及未审查的范围。
- 不得放宽审查者的只读限制。
- 如果输入过多或超时，可以通过缩小范围或拆分来重试。
## 最终报告示例
这是一个存在未审查区域的示例，并非完整的模板。
``text
Codex 审查结果
- 模式：JSON 关卡或 /review
- 审查范围：分支 diff
- 规模：大（12 个文件，620 行）
- 并行：3 个子 Agent
- 审查者路径：首先 spawn_agent
- 回退证据：无
- 迭代次数：2/5
- 审查关卡：ok=false
- 原因：unreviewed_scope 非空
- 完成证据：push/merge/release/任务完成等均已单独确认
修正历史
- auth.py：添加了授权检查
未审查
- utils/legacy.py：Codex 超时，需要重新审查
未解决
- main.py：内容、风险、建议操作
总结
codex-review Skill 的最新版本不仅仅是让之前版本在 Codex 内部运行。它去掉了不必要的步骤，以适应当前的 Codex 和 GPT-5.5，并明确了作为审查关卡必须遵守的规则。
一个能自动审查和修正的机制非常方便，请务必尝试引入。
如果你觉得这篇文章有帮助，欢迎关注和分享。我会继续分享如何不仅使用 AI，而是让 AI 自主工作。
相关文章
https://x.com/makaneko_AI/status/2058739339606233492
