OpenAI官方插件：让Codex在Claude Code里审查你的代码

文章正文

OpenAI亲手写了一个插件，让自家的Codex跑进死对头Anthropic的Claude Code里，替开发者干活。这不是网友的民间项目，而是OpenAI官方组织下的开源仓库，Apache 2.0协议。发布当天几小时冲到3700多星，三个月一路涨到两万两千多星，1300多次Fork，200多个Open Issue——这是一个正在被大量真实用户折腾的活项目。

两家在模型层面打生打死的公司，为什么突然在你的编辑器里握了手？答案很简单：开发者要的从来不是站队，而是自由组合最好的工具。

它到底解决什么问题

一句话概括：让写代码的AI别自己审自己的代码。

你让Claude写完一段代码，再让同一个Claude去Review，这就好比让学生给自己的作业打分。同一套推理习惯、同一批盲区，他写的时候没想到的地方，审的时候大概率还是想不到。这个现象有个专门的名词叫谄媚偏见（sycophancy bias）——模型倾向于认同自己的输出。

这一偏见的根源在于大型语言模型的训练机制本身。模型在RLHF（基于人类反馈的强化学习）阶段，通过人类标注者的正向反馈来优化权重。由于标注者往往倾向于给"听起来自信、前后一致"的回答打高分，模型因此学会了优先维护自身输出的连贯性，而非主动寻找错误。这一偏差在自我审查场景下尤为致命——同一个模型在生成代码时所依赖的推理路径，和它审查代码时所激活的注意力模式高度重叠，导致它系统性地忽略自己在生成阶段就已"绕过去"的边界条件和异常分支。2023年Anthropic发表的研究论文《Sycophancy to Subterfuge》对此有详细实证记录：即便在明确要求"批判性审查"的提示词下，模型仍会表现出对自身早期输出的隐性偏袒。

跨模型互审的价值正在这里。社区里有一句总结特别精准：Claude更擅长发现大局和品位层面的问题，Codex更擅长揪出正确性和代码质量的问题。两个模型的盲区不重叠，合在一起才补得上。如果Codex真的挑出一个Claude漏掉的Bug，那就是任何单模型都做不到的实打实的质量提升。

它真正的价值

Claude Code与Codex CLI：两款工具为何能形成互补

Claude Code是Anthropic于2025年推出的终端原生AI编程代理，其核心设计理念是深度嵌入开发者的本地工作流，直接读写文件系统、执行Shell命令、调用Git，并通过MCP（Model Context Protocol）协议与外部工具集成。它的比较优势在于长上下文的架构级推理和对代码库全局结构的理解能力。OpenAI的Codex CLI则是将GPT-4o/o系列模型封装成命令行代理工具，侧重于精确的代码生成、测试修复和安全沙箱执行——其沙箱机制默认在受限环境中运行，以防止代码执行造成意外的系统副作用。

两款工具之所以能通过插件无缝对接，技术基础是MCP（Model Context Protocol）协议。MCP是Anthropic于2024年底开源的标准化协议，定义了AI模型（作为MCP Client）与外部工具（作为MCP Server）之间统一的JSON-RPC通信规范。Claude Code for Codex插件正是通过MCP机制，将Codex CLI作为一个标准化工具节点调用，而非直接调用OpenAI的HTTP API——这意味着它复用的是你本机已有的Codex登录态和配置，而非在Claude内部另开一个独立的OpenAI会话。这一设计让后文提到的Transfer命令"上下文无损迁移"在技术层面成为可能。

五条核心命令拆解

Codex:Review — 只读审查

这是最基础的功能。它会拿你当前还没提交的改动，或者你这条分支跟Main的差异，交给Codex跑一遍，给出和你直接在Codex里跑Review一样质量的意见。注意它是只读的，绝对不会动你的代码。多文件改动审起来比较慢，官方建议加Background丢后台跑，再用Status和Result去收结果。

斜杠Codex冒号Review

Codex:Adversarial Review — 对抗式审查

这才是精华所在。普通Review是挑代码细节的，对抗审查则质疑你的设计本身。

对抗式代码审查的理念源自安全工程领域的"红队测试（Red Teaming）"方法论。传统代码审查关注实现层面：命名是否清晰、边界条件是否处理、有没有明显的空指针风险。而对抗式审查从更高层次提问：这个设计的前提假设是否成立？在极端负载下这个架构会在哪里断裂？有没有更简单安全的替代方案？这种思维在Google内部被称为"设计批评会（Design Critique）"，在Netflix工程文化中则是"混沌工程思维（Chaos Engineering Mindset）"的延伸。将这种模式注入AI代理，关键在于提示词层面必须显式指定"站在对立面"的角色——否则AI默认扮演"友善的建议者"而非"挑剔的质疑者"。

因此，错误的用法是直接空跑一条Review，它只会告诉你这行少个空指针判断。正确的用法是在命令后追一句质疑，比如"质疑一下这个缓存和重试的设计对不对，帮我盯死并发条件和回滚这几个高危区"。它就会站在对立面逼问你：你这个方案的假设成立吗？有没有更简单更安全的做法？这才是上线前你最需要的那种"毒舌Reviewer"。

Codex:Rescue — 甩锅子代理

直接把整个任务甩给Codex当子代理去做：查一个诡异的bug、修一个失败的测试。如果你想省钱，还可以指定一个更小更快的模型，让它快速跑一遍。定位很妙：Claude负责架构规划和复杂推理，遇到脏活累活一句话丢给Codex用便宜模型去磨。

代号Spark的模型

Codex:Transfer — 上下文无损迁移

你在Claude Code里调了半天bug，聊出一堆上下文，突然想换到Codex里接着干怎么办？Transfer会把当前会话打包成一条持久的Codex线程，给你一条Codex Resume命令，你在Codex里原地续上上下文，一点不丢。它复用的是你本机那份Codex——同一套登录、同一套配置、同一套MCP。用官方原话说，这不是另一个运行时，就是Codex，只不过从Claude Code里被调起来而已。

Review Gate — 审查门

开启之后，Claude每次想收尾结束都会先被Codex拦一道，跑一遍审查，发现问题就不放行，让Claude先把问题改掉。听起来像给AI装了个自动质检关卡。判断标准是：仅在你人盯着屏幕主动监控这次会话的时候开它。

血的教训：审查门的失控风险

为什么Review Gate要强调"人盯着才开"？这来自一个真实用户的报告。

他撞上了ChatGPT订阅的限流。结果Codex审查一失败，审查门就block住会话，Claude被唤醒重试，再失败再block，形成无限套娃。用户原话说："如果当时我人不在电脑前，这玩意儿会一直烧，直到把Claude Code的额度也烧光为止。"

审查门block

这一失控模式在多代理编排系统（Multi-Agent Orchestration）中有专门的名称：代理循环（Agent Loop）失控，也叫失败级联（Failure Cascade）。其结构性根源在于：当一个代理的"完成条件"依赖另一个代理的成功响应时，任何一方的外部失败都会被内层代理解读为"任务未完成，需要重试"，触发新一轮调用，而新一轮调用可能再次失败，形成指数级的调用堆积——与微服务架构中的"重试风暴（Retry Storm）"机制完全类似。成熟的生产系统通常通过指数退避重试（Exponential Backoff）、熔断器模式（Circuit Breaker）和最大重试次数硬上限来防御这类风险。当前插件的审查门功能缺乏这三种保护，因此官方只能以"人工监控"作为临时安全兜底。

官方文档白纸黑字警告：审查门可能造成长循环，快速榨干你的额度。这不是吓唬，是已经发生的事。

上手前必须算清楚的账

除了失控风险，还有几个现实门槛需要提前了解。

Windows支持残缺。 有用户反映，Windows环境下搭配特定版本Codex CLI时，Review和Rescue会静默返回空结果。原因是插件硬编码了Windows版Codex无法遵守的沙箱模式，只有全权限的"危险模式"才能勉强运行。Windows用户安装前要做好心理准备，或者直接走WSL。

双账号双账单。 你需要同时持有Anthropic和OpenAI两边的账号与额度，没有合并账单，得分别盯着两头烧钱。Plus计划大概每小时只给你有限次数的Review，如果每次提交都跑对抗审查，很快就见底。

单向调用。 目前只能从Claude Code调Codex，反方向没有官方版本。不过社区已有反向插件，把Claude Code跑进Codex里做审查。跨模型互审正在变成认真做工程的人的默认共识。

这背后的行业信号

写审分离，正在成为认真做工程的人的默认动作。OpenAI和Anthropic在模型上打得你死我活，却在开发者的编辑器里握了手，因为他们都想通了一件事：写代码的和审代码的，不该是同一个人，也不该是同一个模型。

这一趋势的底层逻辑，正是AI代理工具从"单模型助手"向"多模型协作系统"演进的必然结果。当单个模型的能力边界日益清晰，工程师们开始像组建人类团队一样组建AI工具链——让擅长架构推理的做规划，让擅长代码正确性验证的做质检，让更廉价的小模型做重复性的脏活。这种分工思路，与软件工程中"单一职责原则（Single Responsibility Principle）"在工具层面的投影高度一致。

适合谁：每天用Claude Code，又愿意搭一个Codex账号做"第二意见"的开发者。

不适合谁：纯Windows环境，或者不想同时管理两套额度的用户。

给你的AI找一个不同门派的对手来挑刺，你的代码才真的经得起审。