第 7 章：Codex 对照

草稿章节。跑通格式用的第一版，正式索引前会再打磨。

本章目标

你会在 OpenAI Codex 里重建 PR 审查助手，并用前几章那个同一个 diff 跑一遍。重点不是评出谁更好，而是把能迁移的东西（概念）和厂商特有的东西（配置写法）分开。这样将来换工具，你只花一天重学语法，不用把整套设计重写。读完你会有三样东西：一个跑在 Codex 自己配置上的 reviewer、一张并排对比表，还有一份换工具后没动过的设计清单。

为什么这章放在课程中段、放在 evals 和可观测性之前？因为被某家厂商绑死本身就是个问题。如果你的 reviewer 只能靠某家厂商那套精确的 prompt 语法才跑得起来，那你的判断就跟厂商的配置绑死了。在两套工具上把同一件事各做一遍，能逼你看清哪些是想法、哪些只是实现细节。

前置准备

• 完成第 4 到 6 章：在基于 Claude 的 agent 里有一个可用的 PR 审查助手，带明确范围、最小权限工具，以及（可选）第 6 章的编排。
• 拥有 OpenAI Codex 的访问权及其文档。Codex 提供 CLI（@openai/codex）、IDE 扩展、云/web 模式，还有若干集成方式。详见官方文档。
• 你之前审查过的同一个 PR 或 diff，这样对比才公平。在不同输入上对比说明不了任何问题。

动手做

1. 用与工具无关的方式重述审查意图

用大白话把审查任务写下来，别提任何厂商。这段陈述就是能迁移的核心：要是它提到某个具体的配置键或 prompt 块名字，那就说明还没写干净。把它砍到只剩目标、检查项、输入、输出格式。

意图（与厂商无关）：
  目标：审查一个 PR diff，报告资深工程师会卡住不放的缺陷。
  检查：安全（注入、越权、密钥），
        性能（N+1、热点路径上的阻塞 I/O），
        测试（未测分支、被删的断言）。
  输入：unified diff + 改动文件内容（只读）。
  输出：JSON 列表 {file, line, severity, finding, suggested_fix}。
  限制：对仓库只读；无网络；不写文件。

2. 把每个概念映射到 Codex 对应物

你基于 Claude 的设计里有哪些部件，就去 Codex 文档里逐个找对应的东西，记下哪些对得上、哪些对不上。两套工具相同的地方比不同的地方多：都有项目指令、一套权限/审批模型、一个沙箱、给外部工具用的 MCP，还有一个无界面的 headless 模式。区别只在名字和文件格式。

概念                     Claude Code              Codex
项目指令                 CLAUDE.md                AGENTS.md
打包好的能力             Skill（SKILL.md +        custom prompt / 「skill」式
                         脚本）                   可复用指令 + 脚本
配置面                   settings.json            config.toml（model、审批、
                                                  沙箱、mcp_servers、profiles）
权限模型                 allow/ask 工具规则       approval_policy + sandbox_mode
外部工具                 MCP servers              MCP servers
headless / CI 运行       SDK / -p 一次性          codex exec（非交互）
子任务                   subagents                subagents

注意：上面 Codex 的具体配置键只是示意，名字和取值请对照官方文档核实，它们会随版本变化。

3. 在 Codex 里原生实现 reviewer

用 Codex 自己的文件来表达意图，别把你的 Claude 配置硬翻过去。把长期指令放进仓库根目录的 AGENTS.md，在 config.toml 里设好模型和安全选项，再选一个不写盘的沙箱、配一条永不自动改文件的审批策略，让 reviewer 保持只读。这里有个坑：把你的 CLAUDE.md 逐字抄进 AGENTS.md。这两个文件用途一样，但各自周边的默认值不同，所以你迁的是意图，剩下的让 Codex 自己的约定去补。

# config.toml （示意；键名请在 Codex 官方文档里核实）
model = "<某个-Codex-支持的-模型>"
approval_policy = "on-request"   # 审查期间永不自动应用改动
sandbox_mode = "read-only"       # reviewer 读 diff，什么都不写

[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]

<!-- AGENTS.md （Codex 自动读取的项目指令） -->
# PR reviewer
被要求审查 diff 时，以资深 reviewer 身份行事。
只检查安全、性能和测试覆盖。
输出一个 {file, line, severity, finding, suggested_fix} 的 JSON 列表。
不要修改文件。不要访问网络。

4. headless 跑同一个 diff

用 Codex 的非交互模式，让这次运行能写进脚本、能复现，就像你在 CI 里跑那样。喂给它一模一样的 PR，把 JSON 输出存下来。调用用 headless、输出保持结构化，这正是下一章 evals 的前提：一份你存不成数据的审查，没法打分。

# 示意；确切子命令和参数请查官方文档
codex exec "按 AGENTS.md 里的规则审查 pr-1234.diff 里的 diff，\
  只输出那个 JSON 列表。" > codex-review.json

5. 比对两份审查

针对同一个 PR，把 Codex 的发现摆在你 Claude 的发现旁边。对比四点：覆盖（两边是否都命中了你意图里点名的每项检查？）、一致（标的是同样的行吗？）、语气、投入程度。分歧的地方才有意思：它们多半来自默认值不同（一套工具的沙箱让它读到了另一套读不到的文件），而不是某个模型更聪明。

                       Claude Code           Codex
标出 SQL 注入          是（第 12 行）        是（第 12 行）
标出 N+1               是                    是
标出缺失测试          是                    部分（点了文件，没点分支）
语气                  简短、命令式          更偏解释
分歧的根因            prompt 措辞，而非模型能力

习得「见过另一套生态」小满在 Codex 里把同一个 reviewer 又搭了一遍，发现指令、沙箱、审批、MCP、headless 这些原语两边都有，只是名字和文件格式不一样，于是它开始能分清哪些是想法、哪些只是某家厂商的具体写法。

如何验证

• 确认 Codex reviewer 覆盖了第 1 步意图陈述里点名的每一项检查。漏掉某项检查是迁移没做好，不是模型不行。
• 标出哪些概念能一对一对上（指令、MCP、headless 运行）、哪些需要返工（配置格式、审批语义）。对不上的那部分，正是厂商特有的东西。
• 确认能迁移的核心在两边都产出了可比的审查。要是两份审查差得离谱，问题几乎总出在你的 prompt 或沙箱默认值上，而不是模型上。先把它查出来，再去怪厂商。

习得「分歧不一定怪模型」你现在能在同一个 PR 上把两份审查并排看，确认那个跟厂商无关的意图核心两边都覆盖到了，也明白结果差很多时，原因多半在你的 prompt 措辞或沙箱默认值上，而不是哪个模型更聪明。

原理

两个 agent 都是用同一批原语搭起来的，因为这件工作（读代码、推理、在权限边界内输出发现）跟谁出运行时无关。项目指令、沙箱、审批闸、MCP 工具、headless 模式，这些不是 Claude 的功能，也不是 Codex 的功能，它们是 agent 的功能。一旦你把 reviewer 看成「意图 + 权限边界 + 工具面」，厂商的文件格式就只是一种写法而已。这就是为什么第 1 步的意图陈述一字没改就搬过去了，而配置文件却得重写：前者是想法，后者是具体写法。

小结

真正能长期留下的是概念：清晰的任务陈述、限定的指令、最小权限工具、只读沙箱、headless 调用。这些从 Claude Code 搬到 Codex，只要改个名就行。具体写法（CLAUDE.md 对 AGENTS.md、settings.json 对 config.toml、allow 规则对 approval_policy）每家厂商各不相同，反而是最容易重学的部分。围绕概念去构建，任何 agent 运行时都只是一个部署目标，不用重写。本章给第 2 部分收尾：你现在可以把同一套 reviewer 设计同时落到 Claude Code 和 Codex 上。第 3 部分让它变得可信，从 evals 开始。

常见坑

• 迁的是语法不是意图。 逐字照抄某个工具的配置会失败，因为它周边的默认值不同。先迁第 1 步的概念，再用原生方式表达。
• 想当然觉得功能和默认值都一样。 沙箱行为、审批语义、模型支持各有不同。逐项对照 Codex 文档核实，别凭记忆，本章里的配置键也都只当示意。
• 省掉同输入测试。 在不同 diff 上对比说明不了任何问题。用同一个 PR，分歧才有意义。
• 默认值对不上就怪模型。 多数跨厂商分歧来自 prompt 措辞或沙箱权限，而不是原始能力。先查这两样。

小满见到了 Codex，发现世上不止一种活法。轻松的一站，可你注意到：它开始有了「比较」，也有了「偏好」。异乡渡口，亮了。

0123456789101112131415

刚点亮 异乡渡口 · 地图已点亮 8 / 16

可你信得过它吗？你怎么知道它没在糊弄你？下一站：试炼场。

来源

1. OpenAI Codex 官方文档 · official
2. OpenAI Codex CLI（开源） · official