混合 AI 代码审查:Claude Opus 4.8 与 Codex 的循环协作
Tech
AI
Claude Opus 4.8
Codex
GPT-5.5

混合 AI 代码审查:Claude Opus 4.8 与 Codex 的循环协作

两个前沿模型在循环中协作:Claude Opus 4.8 编写每个修复,Codex 通过我的 AI 桥接器进行审查,真实构建投票决定。39 个生产环境修复,无一由人工手写。

Uygar DuzgunUUygar Duzgun
Jun 20, 2026
更新於 2026年6月24日
7 min read

有一类工作是单个 AI 代理会悄然失败的:大型、多步骤的清理工作,其中一个错误的假设会在数十次编辑中累积放大。我的答案是混合 AI 代码审查 —— 两个不同的前沿模型在循环中协作,一个负责构建,一个负责审查 —— 上周,它在一个下午就将一个混乱的 SwiftUI 原型变成了零 App Store 阻碍的状态,而我一行代码都没写。

这两个模型分别是担任工程师角色的 Claude Opus 4.8 和担任审查员角色的 Codex (GPT-5.5),它们通过我的 AI 桥接器处理每一个任务,直到通过真实的构建。根据我的经验,这种混合 AI 代码审查设置始终优于任一模型单独工作,而这次运行是最清晰的证明。以下是它的确切工作方式。

从计划开始,而不是凭感觉

你不能直接给代理一个“让它达到生产就绪”的指令。那样只会得到自信满满的胡言乱语。

所以我从计划开始。我让 Claude 克隆仓库(一个名为 Kiddays 的简易记忆 iOS 应用),利用并行子代理阅读*整个*代码库,并生成一份生产就绪性审计:39 个具体项目 —— 9 个严重的 App Store 阻碍项,其余为高和中等级别。每个项目都包含文件、行号、工作量估算和拟议的修复方案。

这份审计成为了 `PRODUCTION_READINESS.md` —— 一个带有 `- [ ]` 复选框的 markdown 清单,按阻碍项优先排序。只有一个文件,作为单一事实来源。其中的每个任务都是小规模、具体且*可验证*的。最后一个词很重要:如果你不能勾选一个框并证明它,那它就不是任务,只是愿望。

混合 AI 代码审查循环,逐步解析

我在一个自定进度的循环中运行了整个流程(Claude Code 的 /loop 模式)。每次迭代处理一个任务,或一组紧密相关的任务,并始终遵循相同的节奏。

五步节奏

Claude Opus 4.8 读取真实文件并设计修复方案。 不是靠记忆 —— 它首先打开实际代码。
它将设计方案交给 [Codex](https://github.com/openai/codex) 以获取独立意见,通过我的 AI 同行审查桥接器 —— 即开源的 ai-collab-bridge 技能 —— 经由 CLI 交接:

bash codex exec --sandbox read-only -o /tmp/answer.txt <<'PROMPT' Pair-reviewing a fix for this SwiftUI app. Here are the files... Recommend the idiomatic iOS 17 approach, flag pitfalls, validate the diff. PROMPT

它们来回博弈。 Codex 提出惯用方法,指出会出错的地方,并验证(或反驳)计划。Claude 实施修复,根据反馈进行调整,并在不同意时进行反驳。
真实构建是裁判。 每个任务都以 `xcodebuild` 通过(green)结束,否则就不算完成。没有“应该能编译”这种说法。
勾选复选框,更新清单,进入下一个任务。

然后循环再次启动,一次又一次,持续数小时,无需人工值守。混合 AI 代码审查的全部意义在于,这个循环可以在没有我照看的情况下运行 —— 是构建结果,而不是我的注意力,在控制每一步。

为什么两个模型胜过一个

推薦閱讀

魔力不在于任何一个单独的模型 —— 两者都很出色,我之前也写过 Claude Opus 4.8 在我自己的代码库上胜过 Codex。魔力在于它们有不同的盲点,而且一个没有编写代码的审查员不会对差异投入自尊心。

让这套设置物有所值的捕获点

这次运行中的一些真实时刻:

Keychain 迁移。 将认证令牌从明文 `UserDefaults` 移出看起来微不足道。Codex 指出,简单的交换会静默破坏 SwiftUI 的反应性,并推动使用通过环境注入的 `@Observable` 存储。Claude 转而构建了该方案。没有损坏的登出 UI。
错误处理。 我有大约 20 处地方用 `try?` 吞掉了数据库错误。Claude 的第一反应是每个视图弹出警报。Codex 主张使用单个根错误展示器 —— 一个警报界面,所有保存操作都路由到那里。更简洁,这也是最终发布的版本。
StoreKit 2、SwiftData 架构版本控制以及磁盘文件保护检查。 这些都是 iOS 17 特有的雷区,第二意见避免了一个微妙的错误 —— 正是那种快速阅读能通过但在实际环境中会失败的问题。
推薦閱讀

这就是形式盖章与真正审查之间的区别。Codex 会反驳某些内容;Claude 会整合好的反驳并为其余部分辩护。在两个不共享大脑的模型之间的边界上,差异变得更好 —— 这正是 受控代理工作流 背后的全部理念:结构化的交接胜过一个模型自言自语。

诚实的部分:代理会挂起,所以要建立看门狗

有两次,Codex CLI 卡住了我 —— 不是在思考过程中,而是在关闭时,因为其后台 MCP 服务器未能干净地关闭。在进程死寂了几分钟后,我亲自追踪了第一次停滞,发现源于 MCP 引导过程。在无人值守的循环中,一次挂起就会停滞一切。

解决方案是一个强力的看门狗:每次咨询周围都有一个杀死计时器,并且完全禁用该调用的 MCP(`-c mcp_servers={}`),这样就没有东西可挂起。循环检测到停滞,杀死了僵尸进程,获取已经写入的答案,然后继续运行。“没有任何东西会卡住”在自主工作中不是一项锦上添花的功能 —— 它是整个游戏的关键。

结果

39 个项目全部完成。 所有 9 个 App Store 阻碍项已清除。
从头开始的干净构建(`xcodebuild clean build`,退出码 0)在结束时完成 —— 不仅仅是增量通过。
13 个新文件。 真实的 Keychain 存储、真实的 StoreKit 2 购买、真实的录音、真实的本地通知、GDPR-K 家长同意记录、架构版本控制、崩溃报告接口。
虚假变为真实,或诚实地移除。 虚假的“高级”开关变成了真实的订阅流程。虚假的 Google 按钮和虚假的家庭邀请(它们生成了 bogus 数据)被移除,法律文案被重写,不再承诺尚不存在的后端。

剩下的只是没有任何模型能为你完成的工作:在 App Store Connect 中创建应用内购买产品、搭建真实的后端、让律师签署隐私政策。每一项都在清单中标记了确切的需求。

方法与来源

这是对我自己的 Kiddays 代码库进行一次真实运行的第一手记录。审查员是 Codex CLI (GPT-5.5);模型到模型的交接使用了我的开源 ai-collab-bridge 技能。iOS 特定的决策对照了 Apple 自己的 StoreKit、SwiftData 和文件保护文档 —— 更重要的是,在我宣布完成之前,每一个更改都通过了从头开始的干净 `xcodebuild` 确认。我不是在报告模型声称的内容;我是在报告实际编译通过的内容。

结论:是一个团队,而不是助手

在我依赖混合 AI 代码审查的项目中,解锁的关键从来不是“找到那个能做一切的模型”。而是一个栈:

一个转化为可勾选清单计划
Claude Opus 4.8 构建每个任务,
Codex 以无利益关联的方式审查它,
桥接器 通过干净的 CLI 交接连接它们,
拥有最终投票权的构建
以及一个 /loop 来运行它直到清单为空。

一个模型编写代码是一个助手。两个模型针对一个可以说“不”的构建相互审查,开始看起来像一个团队 —— 而在这次运行中,那个团队在我旁观时交付了 39 个生产环境修复。