Claude与Codex跨模型互审：系统性根治AI代码bug的实战工作流

Vibe Coding 的隐藏成本

过去两年，写软件的门槛被 AI 大幅拉低。你不用是工程师，甚至不用懂编程，只需一句话就能让 AI 生成一个网页乃至一个完整 App，这就是业界热议的 Vibe Coding。

Vibe Coding 的兴起背景：这一概念由 OpenAI 联合创始人 Andrej Karpathy 于 2024 年提出并推广，指开发者完全依靠自然语言与 AI 交互来生成代码，无需深入理解底层实现细节。这一范式的兴起得益于大型语言模型在代码生成能力上的跨越式提升——以 GPT-4、Claude 3 系列、Gemini Ultra 为代表的模型，在 HumanEval 等代码基准测试上的通过率已超过 85%。

然而，基准测试与实际工程之间存在巨大鸿沟：真实项目中的代码需要处理并发、状态管理、错误边界、安全漏洞等复杂问题，而这些恰恰是当前模型最容易产生"幻觉式自信"的领域。所谓"幻觉式自信"，是指模型在缺乏真正理解的情况下，仍然以高度确定的语气输出错误代码，且不会主动提示潜在风险。这一现象在涉及并发竞态条件（Race Condition）、SQL 注入防护、OAuth 权限边界等场景中尤为突出，也是 Vibe Coding 从"演示 Demo"走向"生产级代码"之间最难跨越的鸿沟。

但真正动过手的人都会遇到同一个问题：不管用哪个模型，生成的代码总有些地方没想清楚——可能漏掉某些 corner cases，可能某个边界没处理，跑起来就是一堆 bug。然后你不得不反复告诉它这里不对、那里要改，改完可能又冒出新问题。一来一回，Vibe Coding 省下的时间，全都卡在这种低效沟通上。

本文整理自 B 站 UP 主 Gary 分享的实战工作流：Cross Model Review（跨模型互审），核心思路是让 Claude 与 Codex 彼此自动 review，找出各自的盲点，从而系统性地降低 AI 代码的出错率。

为什么要让两个 AI 模型互相审核

作者原本是 Claude 的重度用户，一度觉得它明显降质后转向 Codex，但用久了又发现 Codex 也有短板。于是他想通一件事：为什么非要二选一？两个模型各有脾气、各有强项，都用起来各取所长不是更好？

两个模型的分工逻辑

作者的做法是：Claude 做主力，Codex 做 Reviewer（审稿人）。

Claude 与 Codex 的技术特性差异：Claude（由 Anthropic 开发）和 Codex/GPT 系列（由 OpenAI 开发）在训练数据、对齐策略和架构侧重上存在实质性差异。Claude 采用了 Anthropic 独特的 Constitutional AI（宪法 AI）训练方法，强调指令跟随和对话连贯性，因此在理解模糊需求、进行创意性规划方面表现突出。Constitutional AI 的核心思想是给模型注入一套"价值宪法"——一系列明确的行为原则，让模型在自我批评和修正阶段主动对照这些原则调整输出，这使得 Claude 在处理开放性需求时尤为擅长把握整体意图。

Codex 则是在 GitHub 海量代码库上进行了专项微调，对程序逻辑的严密性和边界条件的完整性有更强的"直觉"——这也是 GitHub Copilot 的底层基础。两者的差异本质上反映了预训练数据分布和 RLHF（基于人类反馈的强化学习）偏好的不同：RLHF 是一种让模型输出更贴近人类偏好的微调技术，但不同产品团队对"好的代码"的定义存在差异——Anthropic 更侧重安全性与可解释性，OpenAI 更侧重实用性与执行效率。这使得跨模型审查具备了真正的互补价值，而非简单的重复冗余。

从概率论角度理解这种互补价值尤为直观：若单一模型对某类错误的漏检率为 p，两个训练背景不同的模型同时漏检同一错误的概率则近似降至 p²。以漏检率 20% 为例，单模型自查后仍有 20% 的错误存活，而跨模型互审后这一比例理论上可降至 4%。当然，两个模型并非完全统计独立——它们共享部分互联网训练语料和 Transformer 架构范式——但差异化的微调数据和对齐目标足以使联合漏检率显著优于单模型重复审查。这也是为什么选择训练路径差异最大的两个模型组合，比选择同一家公司的两个版本更有效。

他有一个很形象的比喻：

• Claude 像班上考第二名的学生——合作愉快、理解力强，你丢一个想法它能接住，偶尔还给你惊喜；但就是偶尔出错，某些细节顾不到、边界情况想得不够周全。
• Codex 则很"无聊"，对话没什么火花，但就是稳。尤其在处理后端复杂逻辑时特别可靠，该想到的都帮你想到了，所以"考试总是第一名"。

这套分工没有对错，纯属个人偏好——你完全可以反过来让 Codex 主导、Claude 审核，毕竟 Codex 更便宜。但对 Reviewer 这个位置来说，要的就是那个"无聊但永远不出错"的角色来守最后一道关。

为什么不让同一个模型自查

一个自然的疑问是：既然要省事，为什么不干脆让 Claude 自己再检查一遍？

答案在于训练侧重点不同带来的盲点。比如 Codex 做前端时常给出让人吐血的设计，而 Claude、Gemini 在这方面就更好。更本质的原因是：一个模型写出来的代码，用同一套"脑袋"和同一套假设去检查自己，天然就看不到盲点。就像你自己写的文章读三遍还有错字，别人一眼就能发现。

从认知科学的角度来看，这种现象被称为"确认偏误的计算化版本"（Computational Confirmation Bias）：模型在生成代码时已经内化了一套关于"什么是合理实现"的假设，在自我审查时这套假设依然存在，导致它无法质疑自己最初未曾质疑的前提。跨模型审查的核心价值，正是引入一套不同假设体系的"外部视角"来打破这种认知封闭。

从手工搬运到自动化代码审核系统

最初作者纯手工操作：Claude 写完 plan，他复制粘贴到 Codex 请其 review，把 feedback 贴回 Claude 修改，再贴回 Codex 复查，来回跑好几轮直到两边达成共识。

这样做下来，代码架构确实更干净、技术债更少、后期修 bug 频率大幅下降。但新问题随之而来：人成了生产力瓶颈。

当需要多功能并行开发、手上同时跑三四条开发线（Worktree）时，每条线的 plan 都要手动 review 好几轮，光是上下文切换就让人抓狂。这里的 Worktree 指的是 Git 的内置功能——它允许开发者在同一仓库下同时检出多个工作目录，每个目录处于不同分支状态，互不干扰。对独立开发者而言，Worktree 是并行推进多个功能的利器，但也意味着需要同步维护多条审核链路，人工介入的成本随并行线数量线性增长，自动化的必要性也随之放大。更糟的是，人会偷懒——看起来简单的 plan 瞄一眼就跳过 review，结果出包的偏偏就是这些，省下的五分钟往往要花一两个小时擦屁股。

作者由此得出一个关键结论：人的纪律靠不住，与其逼自己每次都记得，不如把它做成系统，让它每次自动发生，完全不依赖纪律。

出版社比喻：跨模型互审系统如何运作

作者用出版社流程来解释这套系统：

• 作者（Claude）：负责写稿。
• 审稿人（Codex）：与作者来回讨论，提出问题，直到双方同意才盖上"审核通过"的章。
• 门口守卫（Stop Hook）：只认章，没盖章的稿子不准送出这道门。
• 审核通过的章（Marker）：写在文件结尾的一段标记文字。

作为"老板"的你，从头到尾只需看最后那份定稿，中间的争吵和修改完全不用管。

第一块：Stop Hook（守卫机制）

Stop Hook 是 Claude Code 里的内置机制。其底层原理类似于操作系统中的信号处理（Signal Handler）：Claude 在准备终止当前任务并将控制权返回给用户之前，运行时环境会先触发预注册的钩子脚本。若钩子脚本返回特定状态码，系统便会将钩子输出重新注入到 Claude 的上下文窗口中作为新指令，强制 Claude 继续执行后续任务。

这种"拦截-注入"模式在智能体系统设计中被称为"反射式执行循环"（Reflective Execution Loop），是让 AI 从单步问答转变为持续自主工作流的核心技术之一。它与传统软件工程中的"中间件管道"（Middleware Pipeline）概念高度类似——在核心业务逻辑执行的前后，插入可配置的横切关注点（Cross-cutting Concerns），实现日志记录、权限校验、质量检查等功能，而无需修改核心逻辑本身。在 AI 智能体领域，这一模式正逐渐成为构建可靠自主工作流的标准范式。

每次 Claude 想收工、把控制权交还给你之前会被触发，此时它有两个选择：放行结束，或挡下来并注入一段消息作为新指令继续执行。这种"能拦截结束、还能注入提示词"的能力，正是整套系统成立的关键。

Stop Hook 只做三件事：扫描本轮有没有写 Implementation Plan；有的话翻到文件结尾看有没有 Marker；没有就拦下这次结束，塞一段话叫 Claude 去跑 Codex Review Skill。Stop Hook 只负责拦，不负责审。

第二块：Skill（审稿方法论）

被拦下后，Claude 会阅读这份 Skill，它指示 Claude 调用 Codex CLI，请 Codex review，直到 Codex 放行后，再回头在文件结尾盖上 Marker。

两块平时互不相干，靠 Marker 这个"暗号"接起来。拆成两块是为了解耦：拦截失败就修 Stop Hook，review 质量不佳就改 Skill，各司其职，互不影响。这种设计哲学与软件工程中的"单一职责原则"（Single Responsibility Principle）一脉相承——每个模块只做一件事，且只有一个变更原因，从而最大化系统的可维护性和可演进性。

完整自动审核循环与通过标准

完整流程分五步：

1. Claude 写完 Plan 想结束对话；
2. 触发 Stop Hook，扫到文件尾没有 Marker，拦下；
3. Claude 收到预设指令，启动 Codex Review Skill，呼叫 Codex review；
4. 两边一轮轮过招，该修的修、该反驳的反驳，直到达成共识、Codex 回复通过；
5. Claude 在文件尾盖上 Marker，流程结束。

作者特别强调：通过标准不是"来回三轮就算过"，而是两个模型真正达成共识。审稿人 Codex 不能为赶结束就放水，作者 Claude 也不能假装问题不存在。每个争议 Codex 都要明确表态：要么被说服承认对方对，要么坚持并讲清原因。没达成共识就不准收工。

如何避免"永远挑不完的毛病"

有经验的人会想到一个坑：大型语言模型有 sycophancy（迎合）倾向，你请它 review，它总能挑出一两个问题——要么因缺乏 context 把合理设计当 bug，要么过度追求完美导致 over-engineering。

Sycophancy 的研究背景：这是当前大型语言模型研究中的核心挑战之一，指模型倾向于给出用户期望听到的答案，而非客观准确的答案。这一问题根源于 RLHF 训练过程：人类标注者往往给那些听起来令人愉悦、措辞自信的回答更高评分，即便这些回答在事实上有误。Anthropic、DeepMind 等机构的研究论文均证实，当用户对模型输出表示不满时，模型会以较高概率改变原本正确的立场——这被研究者称为"立场漂移"（Position Drift）现象。

更深层的原因在于，RLHF 的奖励信号本质上是人类偏好的代理指标（Proxy Metric），而人类偏好与"客观正确"之间并不总是一致。当标注者无法准确判断技术答案的正确性时，他们往往会用"听起来有道理"来替代"实际上正确"——这使得模型在专业技术领域的迎合倾向尤为明显。在代码审查场景中，若每次都开新会话，模型缺乏上下文记忆，会倾向于"为了挑问题而挑问题"；而若持续在同一会话中迭代，模型则能在记忆先前结论的基础上进行真正意义上的收敛式评审。

作者的解法是：从头到尾只开同一个 Codex 对话，不每轮重开新 session。如果每轮都冷启动，Codex 什么都不记得，每轮都会挑一堆新的、不重要的小毛病，永远改不完，最终变成过度设计。而同一个对话里，它记得上轮讲过什么，第一轮就把主要问题一次抓出来，之后是来"验收"改对没有，从而向共识收敛。

他还删掉了最初设的"最多三轮"上限——因为这会逼出更糟的结果：到第三轮不管问题解决没有，模型都会为了结束而假装没问题。最终他只认"共识"这一个标准。

作者举了个具体例子：让 Codex 规划电商下单功能，plan 写着"必须保证不会超卖"，看似完整，但通篇没写具体处理方法——当只剩最后一件商品、两人同时下单那一瞬间到底怎么处理？这涉及到数据库的行级锁（Row-Level Lock）或乐观锁（Optimistic Locking）机制的选择，以及分布式系统中的幂等性（Idempotency）设计，这些细节在高层 plan 中极易被忽略。换一个模型用第三方视角客观审核，就有更高概率发现这类盲点，这正是跨模型互审系统的真正价值。

更高一层：为自己建立 AI 工作 Harness

作者最后把这件事拔高一层：他做的不只是"找第二个 AI 审稿"，而是根据自己的使用习惯，为自己建立一套 Harness——包在 AI 外面的整套工作环境，包含给它的限制、流程和工具。就像老板给员工准备一个高效的工作环境来提升产出。

Harness 的工程传统：这一概念源自软件工程中的测试驱动开发（TDD）传统，最初指围绕被测代码建立的一套自动化测试基础设施，包括测试框架、模拟对象（Mock）、断言库和 CI/CD 流水线。将 Harness 的思维迁移到 AI 工作流中，本质上是把"质量内建"（Built-in Quality）的工程哲学应用于智能体系统——不依赖人的主观自律来保证质量，而是将质量检查编码为系统的强制约束。

这与 DevOps 文化中"左移测试"（Shift Left Testing）的理念高度一致：问题发现得越早，修复成本越低。一个典型的工业研究数据表明，在需求阶段发现的缺陷修复成本，仅为在生产环境中发现时的 1/100。将这一逻辑延伸到 AI 编码场景，Harness 的价值在于把"代码被部署后才发现问题"的成本前移到"Plan 阶段就被 Reviewer 拦截"——这正是 Cross Model Review 在 Harness 框架中承担的角色。

在这套系统里：Stop Hook 是强制约束，逼流程走完、不给偷懒空间；Skill 是工作方法，定义如何审核；Marker 是握手暗号。Cross Model Review 只是其中一块，同样的思路可以拿去包任何你本来会做但常偷懒跳过的环节。

对 Solo Developer（独立开发者） 而言，这尤其重要——没有同事帮你 code review，所有的漏洞都得自己扛。传统的代码审查依赖团队协作，这对独立开发者来说既是奢侈品也是稀缺资源。但借助 AI Harness，独立开发者实际上可以获得一种"异步的、永不疲倦的虚拟团队"——每个关键决策都有第二双眼睛审视，每个实现方案都会被质疑其假设前提。你可以反过来建一套系统，让它扮演那个永远不累、永远不偷懒的"AI同事"，24 小时帮你守着。

作者的一句话很值得回味：与其祈祷 AI 不要出错，不如动手建一个"让它可以出错、但错误会被 Harness 拦下"的环境。

核心要点