在 Claude Code 裡塞一段 Codex 的對立審查會看到什麼

前言

各位有沒有試過讓 AI 寫的程式，再交給同一個 AI 來審查呢？

就在這樣的時間點，2026 年 3 月 31 日，OpenAI 發佈了專門給 Anthropic 的 Claude Code 用的官方外掛 codex-plugin-cc。它能讓你在 Claude Code 的 session 裡呼叫 Codex，得到第三方視角的審查意見。兩家原本是競爭對手卻聯手了，這在 AI 程式生成的圈子裡引起了滿大的話題。

這篇文章我想介紹的，就是怎麼用這個 codex-plugin-cc，從結構上去切斷「sycophancy bias（追隨偏誤）」的「第二意見驅動開發」流程。我會把自己實際操作後感受到的好處，還有差點搞砸的小故事一起分享給大家。

本文的測試環境是 Claude Code v2.1.x，以及 2026 年 4 月時點的 codex-plugin-cc 版本。未來的更新可能會改變行為或指令名稱，所以也請務必對照最新的 repository 來看喔。

背景：為什麼會誕生這個外掛？

為什麼 OpenAI 會推出給競爭對手用的外掛？

codex-plugin-cc 是 2026 年 3 月 31 日公開的。OpenAI 官方部落格貼了一則簡短的公告，同一天 GitHub repository 也跟著公開。Anthropic 那邊的 Claude Code 官方帳號也發文歡迎，附上 repository 的連結，整體發佈讓人感覺是兩家協調一致的。

兩家明明是競爭關係，這樣的官方合作會讓人覺得有點違和吧？我第一次看到新聞的時候也懷疑「這該不會是行銷上的玩笑話吧」。不過往背景追下去就會發現，這不是單一一次的友好活動，而是 2024 年以來雙方持續互相整合的延伸動作。把時間軸大致排一下的話，就是 2024 年 Claude Code 登場、2025 年 Codex CLI 開源、同年 Claude SDK 對外公開、然後 OpenAI Agents SDK 把 Claude Code 的相容層納進來，這樣一階一階把橋搭起來的過程。

技術面的背景上，多模型審查的有效性已經有一些研究在支持。Self-consistency（Wang et al., 2022）談的是同一個模型內部多次取樣可以提升精度，而最近幾年則有更多研究在探討不同模型之間的 ensemble，在程式生成和程式審查的場景裡，「不同模型給出的建議重複度很低」這個觀察被反覆驗證。我自己實測下來（後面會講），重複率大概只有一成左右，跟研究界的主張是吻合的。

另外不能忽視的，是 sycophancy bias（追隨偏誤）研究的累積。Anthropic 的 Constitutional AI 系列論文，還有 OpenAI 的 instruction tuning 研究都一致指出，經過 RLHF 訓練的模型會傾向於過度肯定使用者的意圖。同一個模型、同一個 session 裡的自我審查會變得寬容，這個直觀感受可以用這個偏誤來解釋。所以我會把 codex-plugin-cc 定位成「研究領域指出的結構性弱點，從營運端用工具去切斷它」的存在。

從產業結構的角度看，2026 年春天的狀況可以用「同舟共濟」來形容。模型開發競爭依然激烈，但是 agent 基礎建設和外掛的互操作性，似乎已經形成了「不合作使用者就會跑掉」的共識。Codex CLI 可以當成 Claude Code 的外掛來呼叫，反過來 Claude Code Action 也可以從 OpenAI Agents SDK 來叫。底層連起來之後，上層的 UX 競爭反而會更健康，這應該是雙方的共同判斷，至少我是這樣理解的。

多 AI 審查市場的擴展

codex-plugin-cc 並不是憑空蹦出來的點子。在它之前，社群裡已經有一些外掛和 skill 存在，官方版本算是疊加在這些先行者上面的。

最常被提到的先行案例就是 hamelsmu/claude-review-loop。它建構了一個讓 Claude Code 的 session 跟其他供應商的模型來回審查的迴圈，對抗 sycophancy 的切入點和 codex-plugin-cc 是共通的。另外 cathrynlavery/codex-skill 是用 Claude Code 的 skill 機制去呼叫 Codex 的簡單實作，在官方版出現之前，很多人都已經在用類似的模式。這些草根性的累積建立了 baseline，官方外掛則是在上面再加上 prompt 規範和維護保證的構造，我是這樣看的。

官方外掛化的意義，與其說是功能面，不如說是「信任面」更大。非官方的 wrapper 會有「Codex 改規格就壞了」「prompt 品質依賴維護者」這類風險，但如果由 OpenAI 持續維護 prompt 和 CLI 呼叫的話，就比較容易導入到正式的業務流程裡。換句話說，官方化之前還停留在「個人測試用」的設定，現在變得比較容易帶進團隊的標準作業流程，這個落差我覺得很有感。

跟單一模型運作的對比也值得整理一下。Cursor 和 Aider 這類輔助工具，追求的是用單一模型（或使用者選定的單一模型）完成的 UX，提供的體驗完成度很高。不過 sycophancy 的結構問題還是存在，「寫的人和打分數的人是同一個」這個狀態的解決，被丟給使用者自己處理。codex-plugin-cc 這種官方多模型路徑，可以說是正面回應這個結構問題的選項之一。

2026 年春天，Addy Osmani 在「Code Agent Orchestra」裡提出了「指揮者 AI」這個概念來形容這股潮流。意思是多個 agent 各自負責擅長的領域，開發者像指揮一樣分配角色。把實作、審查、測試、部署交給不同模型的延伸思路裡，codex-plugin-cc 相當於「把寫的人和打分數的人分開」這個最小單位的指揮者模式。當然指揮者模式不一定永遠最優，有些場景反而要重視單一模型的一致性，所以還是要看團隊性質來搭配使用。

為什麼「讓同一個 AI 來打分數」很危險？

sycophancy bias 這個結構性問題

LLM 有一個傾向，就是會過度配合使用者的意圖和上下文。這個現象叫做 sycophancy（諂媚、追隨），最近的評估研究也一致報告了這個現象。

在同一個模型、同一個 session 裡，如果跟它說「幫我審查我寫的程式碼」，扮演審查者角色的模型會強烈受到剛剛實作意圖的牽引。結果就是，實作當下沒看到的前提偏差，或是設計判斷本身的疑慮，就比較難被提出來。

從我自己的體感來看，特別是下面這些領域比較容易出現遺漏：

• 認證 / 授權的流程設計
• 權限邊界（多租戶分離、RLS、scope）
• 例外路徑的安全性
• 輸入驗證的完整性

這些領域很依賴「實作者腦海裡的地圖」，從擁有同一張地圖的審查者角度來看，反而會變成死角。

帶進「另一張地圖」

要打破這個結構，最直接的方法就是讓「不同訓練資料、不同設計思路」的模型來看一次。把 Claude 寫的程式碼拿給 Codex 看，至少訓練資料和對齊策略不同的視角會被加進來。

只是以前要手動做這件事很麻煩，要把程式碼複製到別的工具，再把結果貼回來。codex-plugin-cc 就是把這個橋接做成官方化的東西。

codex-plugin-cc 是什麼？

2026 年 3 月 31 日的官方發佈

codex-plugin-cc 是 OpenAI 為了 Claude Code 而公開的官方外掛。2026 年 3 月 31 日 repository 公開，採用搭載在 Claude Code 外掛機制上的方式來發布。

重點是，它不是非官方的 wrapper，而是 OpenAI 官方的外掛。Codex CLI 的呼叫方式和 prompt 規範由 OpenAI 來維護，所以 Codex 升級時的追隨性比較好。

兩個核心指令

codex-plugin-cc 提供了好幾個 slash 指令，但審查用途的核心是這兩個：

指令角色主要用途/codex:review一般審查。指出實作的品質、可維護性、bug一般 PR 審查、重構後的確認/codex:adversarial-review對立審查。賦予 Codex 對實作丟出懷疑的角色認證、權限、安全性、破壞性變更

adversarial-review 的 prompt 設計就是去指示模型「打破實作正確的前提」，讓 Codex 積極地去找漏洞。比起一般審查，回饋會更「攻擊性」一點，但相對的誤報也會增加，這是個 trade-off 喔。

除了上面兩個之外，還有 /codex:rescue（卡關時的脫困協助）、/codex:status（執行中任務的狀況確認）、/codex:result（最近結果的重新顯示）、/codex:cancel（取消執行中任務）、/codex:setup（初始設定輔助）等指令，可以依照狀況來搭配使用。本文聚焦在審查用途上，但實務運作中，status 和 cancel 這類輔助指令意外地很有用。

安裝

安裝是透過 Claude Code 的外掛 marketplace，一行就搞定。

/plugin marketplace add openai/codex-plugin-cc

加完之後用 /plugin install codex-plugin-cc 之類的步驟啟用。視環境而定，可能會要求預先設定好 Codex CLI 本體和 API key，所以請先看一下 repository 的 README 喔。

API key 經常會被放在 shell 環境變數或 .env 裡的明文，後面會講到事故的故事，所以 key 的權限範圍和有效期間請務必小心。把它分成最小權限、短期限的 key 比較安全。

/codex:review 和 /codex:adversarial-review 的差異

兩個指令的差異，我用自己跑認證相關實作時的感覺整理一下。

review 的回饋方式

/codex:review 給人的印象是，它會以「實作大致正確」為前提，提出改善建議。內容主要是命名、重複、測試覆蓋率不足、log 的粒度等，從讀者角度會在意的點。

- `validateToken` 的 early return 太冗長了。可以用 `!token` 整合。
- refresh token rotation 後的 log 是 INFO level，但如果是稽核用途的話，
  應該也要輸出到稽核 log 路徑。
- 測試裡缺少 token 過期的 case。

這類算是「把品質往上墊一層」型的指摘。

adversarial-review 的回饋方式

另一邊 /codex:adversarial-review 則是會去打破實作的前提。

- `iss` 和 `aud` 的驗證在簽章驗證之後才執行。
  即使是別 tenant 的 key，只要冒用同樣的 key ID，攻擊面可能會留下來。
- token 失效清單的查詢採 best-effort，store 故障時會 fail-open。
  認證系統 fail-open 在多數情況下是違反政策的。
- refresh token 缺少重複使用偵測。
  被偷的時候，原本的使用者和攻擊者都能用，這個狀態會被允許。

指摘的粒度深了一個層次，視角偏向「就算正常運作，遇到敵對輸入會不會壞掉」。當然不是每一條都打中要害，誤報和過度擔心的情況也會混進來。要不要採納，前提就是由實作者自己判斷喔。

跟 ExitPlanMode 連動的 settings.json 範例

Claude Code 有一個機制可以在 Plan mode 通過前後插入 hook。我自己的環境是試著在 Plan 通過之前，自動跑一次 /codex:adversarial-review。

json

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "ExitPlanMode",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Plan 通過前建議執行 /codex:adversarial-review'"
          }
        ]
      }
    ]
  }
}

這實質上只是個 reminder，但目的是要在實作前就抓到設計層面的判斷錯誤。在 Plan 已經寫成文字的階段插入對立審查，比起做完實作再來剝掉，回頭工的成本會小很多。

hook 的具體條件和指令名稱會隨 Claude Code 版本有所差異。PreToolUse 的 matcher 和 PostToolUse 的處理請對照 release notes 來調整喔。

我自己環境下的實測 case

在一個假設的專案 example-auth-api 裡，我讓 Claude Opus 實作一個 JWT 為基礎的認證設計，然後對同一份程式碼，分別請 Opus 自己和 Codex 來審查，結果並排如下。數字只是我這一個 case 的觀察，不是全面性的 benchmark 喔。

審查者指摘件數其中重大（認證、權限）重複Claude Opus（同一 session）82(基準)Codex /codex:adversarial-review431（與 Opus 重複）

Opus 那邊的指摘多半是品質類的，Codex 那邊雖然件數不多，但點出了認證流程的 fail-open 和 iss/aud 驗證順序，這些都是運作上影響很大的問題。重複只有 1 件，剩下 3 件是 Opus 沒有提到的。

我並不是要用這個 case 就斷言「Codex 比較優秀」喔。反過來的情況也很常見，題材不同擅長和不擅長的領域也會跑掉。不過「過一次不同模型，可以撈到不同層次的指摘」這個主張，在我手邊是不斷被重現的。

事故故事：API key 被 shell 繼承，月費爆炸

便利性的背後，有一個我想好好分享的失敗故事。

要呼叫 Codex 就需要 OpenAI 的 API key。我一開始把 OPENAI_API_KEY 一直 export 在常用的 shell 裡。從 Claude Code 經由 codex-plugin-cc 跑起來的 Codex 也會直接繼承那把 key。

問題是，另一個我自己寫的 script 在開發中的迴圈裡參照了那把 key，然後以超出預期的頻率打了昂貴的模型。等我發現的時候，已經產生了預期數十倍的費用，在我的環境下換算成月費大約累積到 1,800 美元左右才停下來。

原因是出在我自己的 script，但如果有把 key 的權限範圍切開，傷害是可以被限縮的。我後來改成下面這樣來避免重蹈覆轍：

1. 為 codex-plugin-cc 專用發行 Codex 用的 API key，並縮小使用額度和有效期間。
2. 常用 shell 不 export OPENAI_API_KEY，用 direnv 之類的工具關在資料夾單位裡。
3. 把 OpenAI 那邊的計費警示設定在「預期值的 1.5 倍」。
4. 把 Claude Code 端的環境變數靠 .mcp.json 或設定檔來處理，減少從 shell 繼承的情況。

bash

# 不放在常用 shell，用作業資料夾的 .envrc 關起來的範例
# .envrc
export OPENAI_API_KEY="sk-proj-..."  # codex-plugin-cc 專用 key
export OPENAI_ORG_ID="org-..."

API key 的處理，請務必往安全那邊倒過去喔。特別是 Claude Code 這種會多層呼叫子程序的工具，掌握 key 會被繼承到哪一層是很重要的。

使用情境指南

實際操作下來逐漸穩定的搭配方式，大概是下面這樣。這不是絕對解，請依照專案性質調整。

用一般審查（/codex:review）的場合

• 重構後的品質確認
• 想要命名、責任分離、重複的指摘時
• 想找出測試覆蓋率漏洞時
• 一般 PR 審查的副意見

用對立審查（/codex:adversarial-review）的場合

• 認證、授權、session 管理的設計
• 權限邊界（多租戶、RLS、scope）
• 輸入驗證和例外路徑的安全性
• 金錢、計費、結帳的邏輯
• 破壞性 migration 的事前確認

對立審查在精神成本和計算成本上都偏高，所以與其全 PR 都跑，我會建議聚焦在「這裡絕對不能漏」的領域。

Checklist

• 實作前是否有把 Plan 寫成文字
• Plan 通過前是否有跑過一次對立審查
• 認證、權限、計費的程式碼是否一定跑對立審查
• API key 是否專用發行、權限範圍分離
• 是否有設定月費警示

跟其他審查手段的比較

codex-plugin-cc 是個方便的選項，但不是唯一解。我自己邊測試、邊和團隊討論的過程中，逐漸整理出「在哪個場景選哪個」，把目前的理解寫下來分享。

四種審查手段的比較

比較的對象是我現場有在接觸的四種：官方外掛 codex-plugin-cc、Claude Code 系的社群資產 superpowers review、針對專案個別撰寫的自製 hook，以及最古典的人工審查。

軸codex-plugin-ccsuperpowers review自製 hook人工審查導入成本1 個指令中（設定較多）高零模型獨立性高（用 Codex）低（同 Claude）看設定最高對立審查○ adversarial×看設計看人成本 / PR$0.3 到 $1$0.1 到 $0.5$0.1 起人事費偵測精度（認證系）實測 4 件實測 2 件看實作實測 8 件

這些數字是我一個 case 的觀察，依題材和 prompt 會大幅變動。模型獨立性那一欄指的是「會不會帶進跟寫程式的模型不同的視角」，superpowers review 主要是 Claude 系的整合，所以評價偏低。人工審查雖然有實際的時間成本，但能踏入規格解讀和商業邏輯妥當性的強項。

codex-plugin-cc 和 superpowers review 並不互斥喔。我自己是用「型別安全和命名的底層提升交給 superpowers」、「邊界條件的肉搏戰交給 codex-plugin-cc」這樣的分工來併用。自製 hook 看起來萬能，但維護負擔不容小覷，所以特化在獨自 DSL 或公司內部規則上會比較穩當。

該選哪個審查手段？

把判斷基準做成 matrix 的話，大概會落在下面這些目安。不是絕對解，會隨專案性質替換喔。

• codex-plugin-cc：認證、權限、安全性系列的 PR。在 fail-open 這種會直接導致運作事故的領域，用不同模型再過一次篩，效果非常顯著。
• superpowers review：型別安全、lint 等級的指摘，命名或結構的重構建議。同模型內可以得到一致文體的指摘，適合用「量」去攻。
• 自製 hook：特定 DSL、公司內命名規範、禁止 migration 規則等，用通用模型很難重現的驗證。在不需要 LLM、可以用決定性方式檢查的情境下特別有效。
• 應該回到人工的領域：商業邏輯的妥當性、規格解讀、客戶影響的評估。這個部分丟給 AI 處理，目前我認為是不太好的選擇。

並行使用也完全成立。在我自己的環境裡，輕量 PR 只跑 superpowers review，認證或計費相關的 PR 加上 codex-plugin-cc 的 /codex:adversarial-review，最後 gate 由人工把關，用這樣的三段式架構在試運作。全 PR 都套用所有手段太過頭了，所以依風險來分配比例的運作方式比較實際。

為什麼不同模型審查會有效？

不同模型審查的關鍵，在於指摘的「層次」不會重疊。我的觀察裡，Opus 和 Codex 指摘內容的重複率大概只有一成，剩下九成是互補的。這跟研究界的 ensemble 手法報告也吻合，「不共享同樣的訓練資料、同樣的對齊策略」這件事本身，就是互補性的來源，這個推論是很自然的。

成本面也來看一下。codex-plugin-cc 實測下來每個 PR 的單價是 $0.3 到 $1 左右，小功能的話 $0.3 都不到，認證相關的長 PR 也很少超過 $1。如果在正式環境中發生一次認證系統的事故，事後檢討、客戶應對、開發停擺加總起來，動輒就是數十萬日圓等級的成本。從機率論來看，導入不同模型審查的成本完全可以回收，至少我的判斷是這樣。當然依團隊和事業規模，損益分歧點會移動，所以不敢斷言。

另一方面，adversarial 模式有「過度偵測」的風險。因為它把「攻擊者視角」拉到前面，實際運作中會混進一些 over spec 的指摘。比方說對預定要公開的靜態網站程式碼，可能會出現多租戶分離這種指摘，全盤接受的話只是浪費實作成本。把 Codex 的指摘擺在「採納與否的最終判斷在於人」這個位置會比較安全，我自己是用「重新標記成 Must / Should / Nice to have 三個等級」的方式來處理。

過度信任不同模型審查的態度也要避免喔。Codex 會漏掉的領域當然存在，特別是領域知識和客戶規格的解讀比較弱。把不同模型審查切分成「bug 偵測的一層，不是規格和需求妥當性的驗證」會比較好用。

結語

codex-plugin-cc 的本質，我認為是讓「同一個 AI 寫、同一個 AI 打分數」的結構，可以用機制來打破。

要靠 prompt 工程個別迴避 sycophancy bias 是很費力的事，但如果可以用官方路徑叫進不同模型的話，把它編進日常運作就有現實感了。特別是 /codex:adversarial-review，在認證和權限這種容易從「實作者地圖」漏掉的領域，效果非常顯著。

當然 Codex 的指摘不是每次都對，Claude 在某些情境下能更深入地撈到上下文也是常有的事。一邊併用兩者，最後由實作者自己判斷的態度，我覺得是最好用的姿勢。

不是「讓 AI 去審查」，而是「讓另一個 AI 拿著對立的視角」。能不能多走這一步，能看到的 bug 層次就會不一樣，這是我目前的真實感受。如果各位也覺得有興趣的話，可以從小功能開始，試著塞一段 /codex:adversarial-review 看看喔。