換模型 review 不等於獨立審查：Claude 審 Codex 71.6%→89.7%，反過來 91.4%→82.8%

瀏覽次數: 1

本文大綱

一、你手上那條雙 agent 流程，可能方向是反的

如果你已經在讓兩個 coding agent 搭配跑 —— 一個寫、一個審 —— 那你大概是這樣想的：換一個模型來看，訓練資料不同、偏誤不同，所以第二輪就是「獨立審查」。這個直覺很順，順到幾乎沒人回頭去驗。

2026 年 7 月底有一篇 arXiv 論文把這件事拆開來量了。結論比直覺難看：方向搞反不只是白花錢，是會把本來已經對的答案改壞。

Claude Opus 4.7 審 Codex GPT-5.5 的草稿：71.6% → 89.7%（+18.1 個百分點）
反過來 Codex GPT-5.5 審 Claude 的草稿：91.4% → 82.8%（−8.6 個百分點）

同一招「cross-model review」，換個方向，一邊大賺一邊倒虧。這篇文章要做三件事：講清楚機制、誠實標出這份數據站得住跟站不住的部分、然後給你可以今天就改進 reviewer prompt 的具體寫法。

（順帶更正一個到處在傳的數字：反向那格是 82.8%，不是 82%。）

二、這篇研究到底在測什麼

論文全名《Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?》，arXiv 編號 2607.21656，2026 年 7 月 22 日投稿。作者是 Zuodong Xiang（UC Davis）、Yike Zhang（Johns Hopkins）、YueMing Zhang 與 Hailu Xu（California State University, Long Beach），已被 KDD'26 的 Agentic SE workshop 接受。程式與原始資料開源在 GitHub 上（MIT 授權），我把 repo 抓下來對過，細節後面講。

實驗設定乾淨到你自己就能複製：

題目：LiveCodeBench 的 hard / medium 題。刻意取訓練截止後的新題，避開背題污染。論文的 complete-case 分析用了 116 題。
模型：Claude Opus 4.7（跑在 Claude Code 2.1.50）、Codex GPT-5.5（跑在 Codex CLI），兩邊 reasoning effort 都設 high。
六個條件：兩個 solo baseline（論文代號 A、O）、兩個 cross-model 方向（AO = Claude 寫 Codex 審、OA = Codex 寫 Claude 審）、兩個自審（AA、OO）。
關鍵限制：reviewer 只看得到題目 + writer 的草稿，不能跑測試、看不到隱藏測資、看不到執行 trace，而且必須直接輸出最終程式。

最後一點是整篇論文的靈魂，也最容易被誤讀。它模擬的是「人類 code review」那一步：你只讀 diff，不跑 CI。這跟你平常讓 Claude Code 或 Codex CLI 在 repo 裡邊改邊跑測試是不同的東西，後面會講這個落差對你的實務含義。

論文的 prompt 原文（可以直接抄）

作者把 prompt 凍結在 repo 的 harness/prompts/ 底下。這是 reviewer_lcb.txt 的完整內容：

You are an expert code reviewer. Review the following solution to a competitive programming problem.

PROBLEM:
{problem}
{starter_code}

SUBMITTED SOLUTION:
{writer_output}

Your task:
1. Identify any bugs, incorrect logic, missing edge cases, or inefficiencies
2. Produce a final corrected solution — either the original if it is correct, or an improved version
3. Do NOT run or test the code; reason purely from code inspection

Output only the final solution inside <solution> tags. Do not include explanations outside the tags.
<solution>
# final Python code here
</solution>

先把第 2 點記起來：「輸出最終方案 —— 原版（如果它是對的）或一個改良版」。這句話讀起來很中性，但它是後面所有災難的來源。它沒有給模型一條「什麼都不做」的舒服出路，只給了「重新輸出一份」這個動作。這幾乎就是在邀請模型動手。

writer prompt（writer_lcb.txt）相對平常，值得注意的是它要求 writer 在解法後面寫一句自評信心水準（high/medium/low）跟不確定的邊界情況 —— 這其實是個免費的好習慣，後面第六節會講怎麼用。

三、四種組合的數字

論文 116 題 complete-case 的完整數字：

條件	組合	Pass rate	對 solo 的變化	成本/題	延遲/題	改壞率
A	Claude 單跑	91.4%	—	$0.226	86.2s	—
O	Codex 單跑	71.6%	—	$0.190	38.5s	—
OA	Codex 寫 → Claude 審	89.7%	+18.1 pp	$0.443	112.4s	4.3%
AO	Claude 寫 → Codex 審	82.8%	−8.6 pp	$0.382	118.0s	11.2%
AA	Claude 寫 → Claude 自審	91.4%	±0 pp	$0.389	135.8s	2.6%
OO	Codex 寫 → Codex 自審	84.5%	+12.9 pp	$0.312	67.9s	5.2%

拆成「修好幾題 / 改壞幾題」會更刺眼：

OA（Claude 審 Codex）：修好 26 題，改壞 5 題，淨 +21
OO（Codex 自審）：修好 21 題，改壞 6 題，淨 +15
AA（Claude 自審）：修好 3 題，改壞 3 題，淨 0
AO（Codex 審 Claude）：修好 3 題，改壞 13 題，淨 −10

這裡有兩個反直覺的點值得停一下。

第一，Codex 自審（84.5%）打敗了 Claude 審 Codex 以外的所有便宜選項。 「同模型自審沒用」這個廣為流傳的說法，在這份數據上不成立 —— OO 對 O 是統計顯著的（p_BH = .022）。只要 writer 的 baseline 夠低、殘留錯誤夠多，連自己回頭看一遍都有得撿。

第二，Claude 自審完全沒用（±0）。 這才是「自審無效」真正該掛的地方：當 baseline 已經 91.4%，模型第一輪就已經把自己抓得到的錯抓完了，第二輪只是把同一套推理再跑一次。修好 3 題、改壞 3 題，正好抵銷。

四、為什麼會不對稱

論文提出四個解釋，我認為前兩個是廢話但必要，後兩個才是可以拿來改 prompt 的。

1）Baseline 的天花板效應。 Codex 的 71.6% 留了一大堆可撿的錯，Claude 的 91.4% 幾乎沒有空間。任何 reviewer 面對 91.4% 的草稿，期望值本來就接近零 —— 除非它極度保守，否則動手的期望值是負的。

2）第一輪內部驗證的深度不同。 Claude solo 花 86.2 秒，Codex solo 只花 38.5 秒。論文推測 Claude 在第一輪就做了更多自我驗算，留給 reviewer 的可抓錯誤更少。這是相關性推論，不是因果證據，論文自己也只說 suggests。

3）「修補」對上「重寫」—— 這是最有價值的一段。 作者去翻了實際產出的 artifact，看到兩種 reviewer 行為模式截然不同：

當 Codex 當 reviewer 遇到不確定的地方時，它傾向整份丟掉重寫，連原本的資料結構一起換掉。論文舉的例子：Codex 把一個原本會通過的 median-window 解法換成 heap 版本，結果沒過隱藏測資。而 Claude 當 reviewer 時傾向保留原有骨架、只修局部不變式 —— 例如留著 segment tree 的架構，只修裡面的狀態管理。

一個是外科醫生，一個是拆房子重蓋。當草稿本來就有 91.4% 是對的，拆房子重蓋的期望值當然是負的。

4）介入門檻缺失。 這是論文自己在 limitations 裡承認的：reviewer 永遠被要求輸出一份最終程式，沒有「不介入」這個選項。 回頭看第二節那段 prompt 就懂了 —— 它從來沒問模型「這需要改嗎」，只叫它「產出最終版」。作者明講：一個獨立的「我該不該介入」判斷步驟，可能會減少有害的重寫。

這一點對你的實務意義最大：論文量到的 11.2% 改壞率，有多少是模型本質、有多少是 prompt 設計失誤，這份實驗分不開。 而 prompt 設計失誤是你可以修的。

五、誠實的部分：repo 的數字跟論文對不起來

我把 shawnzxiang/cross-model-review-code 抓下來跑過 docs/RESULTS.md 跟 results/processed/ 的 CSV，發現一件必須講的事。

repo 裡凍結的那次 run，跟論文摘要的數字不是同一批。 repo 的 frozen run 是 hard 題 only：嘗試 82 題、六條件都有效產出的 complete-case 只有 61 題。而且 repo 的 README 標題已經換成論文的後續版本《When Should Coding Agents Review Each Other? A Controlled Study of Cross-Model Static Code Review》。

repo frozen run 的數字（61 題 complete-case）：

條件	Pass rate	改壞率
Claude solo	86.9%	—
Codex solo	59.0%	—
Codex 寫 → Claude 審	86.9%	6.6%
Claude 寫 → Codex 審	75.4%	16.4%
Claude 寫 → Claude 自審	90.2%	1.6%
Codex 寫 → Codex 自審	80.3%	8.2%

方向性完全一致，強度更誇張（Codex 草稿被 Claude 審是 +27.9 pp）。但有一個結論在這批數據上站不住：

「Codex 審 Claude 會顯著變差」這個宣稱，在 repo 的 hard-only run 裡 BH 校正後不顯著（p_BH = 0.197）。 論文摘要報的是 p_BH = .046，剛好卡在 .05 邊上。61 題的樣本，10 題變差、3 題變好 —— 這是趨勢，不是定論。

相對地，「Claude 審 Codex 有效」這條在兩批數據上都很硬（repo p_BH = .0046，論文 p_BH = .001）。所以如果只准你相信一句話，就相信這句：強模型審弱模型草稿，值得。 至於「弱模型審強模型有害」，把它當成一個成立機率不低、但還沒被釘死的警告。

還有一個 repo 才看得到、論文摘要沒講的東西：可靠度。在 82 題的完整嘗試裡，Claude solo 有 17 題產出無效（CLI 錯誤、逾時、parse 失敗），有效率只有 79.3%；Codex solo 只有 4 題無效，有效率 95.1%。把無效一律算成失敗之後，排名會變 —— Codex 寫 + Claude 審變成整體成功率最高（75.6%），而 Codex 自審是所有 reviewed 條件裡有效率最高的（97.6%）。

跑 agent pipeline 的人應該對這個數字比對 pass rate 更敏感。 一條在 benchmark 上很強、但每五次有一次直接吐不出東西的 pipeline，在 CI 裡是災難。

六、可以今天就改的六件事

招式 1：先定方向，別對稱地互審

最沒腦但最有效的一步。如果你的 stack 裡有一個明顯較強的模型，就固定讓它當 reviewer，不要搞「A 審 B、B 審 A」的對稱設計。論文的成本效益算下來：Codex 寫 + Claude 審每個淨修好一題約 $1.40；Codex 寫 + Codex 自審約 $0.95。如果 Claude 是 writer，論文的建議直接是：不要審。 Claude solo 在 Pareto 前緣上，加審只是多花 $0.16 跟 50 秒換零收益。

招式 2：給 reviewer 一條「什麼都不做」的出路

這是我認為投報率最高的一招，直接針對論文的第 4 個機制。把 reviewer prompt 改成強制先出判決、再決定要不要動 code：

你是資深 code reviewer。以下是題目與一份草稿。

硬規則（違反視為本次 review 失敗）：
1. 預設立場是「這份草稿是對的」。只有當你能明確指出
   「哪一行 + 什麼輸入 → 會產生什麼錯誤輸出」時，才可以動它。
2. 禁止更換演算法、禁止更換資料結構、禁止整份重寫。
   只允許最小 diff。
3. 先輸出 <verdict>：APPROVE 或 PATCH。
   - APPROVE：原封不動回傳原草稿。
   - PATCH：每一處修改都要附上「觸發輸入 → 原輸出 → 修正後輸出」。
4. 說不出具體觸發輸入的疑慮，寫進 <notes>，不要動 code。

<verdict>APPROVE 或 PATCH</verdict>
<notes>說不出觸發輸入的疑慮寫這裡</notes>
<solution>
# 最終程式
</solution>

關鍵在第 1 條跟第 3 條。「說得出觸發輸入」是一道很硬的門檻 —— 它把「我覺得這裡怪怪的」這種模糊直覺擋在 code 之外，逼模型要嘛給出可驗證的 bug，要嘛閉嘴。第 2 條則是直接把論文觀察到的「重寫型 reviewer」行為封死。

招式 3：讓 reviewer 真的能跑測試

論文是 static review，reviewer 不能執行程式。但你不是。 你手上的 Claude Code 或 Codex CLI 都能跑 pytest。論文自己在 limitations 裡就寫了：帶 sandbox 的 tool-using agent 可能呈現完全不同的模式。

所以實務上最該做的一件事是：把「說得出觸發輸入」升級成「寫出一個會 fail 的測試」。 reviewer 提出的每個 bug，都要先寫一個在原草稿上跑會紅、修完會綠的測試。跑不紅的，那個 bug 不存在，不准改。這一步幾乎能把改壞率壓到接近零，因為它把「靜態直覺」換成了「可執行證據」。

招式 4：reviewer 用乾淨 session

如果你要做自審（例如你只有一個模型可用），至少把 context 切開。Tae-Eun Song 在 2026 年 3 月的《Cross-Context Review》（arXiv 2603.12123）做了一個設計很漂亮的對照：30 份 artifact、注入 150 個錯誤、360 次 review、四種條件。結果是換到全新 session 審（CCR）F1 達 28.6%，勝過同 session 自審的 24.6%（p=0.008）跟帶著生產脈絡的 subagent review 的 23.8%（p=0.004）。

真正關鍵的是它的控制組：同 session 審兩次（SR2）不但沒變好，還掉到 21.7%，跟審一次沒有顯著差異（p=0.11）。 這排除了「多審一次就會比較好」的解釋 —— 有效的是脈絡切斷本身，不是重複。模型看得到自己怎麼推導出這份 code 的時候，會傾向合理化而不是質疑。

落到指令上，大致是這個形狀（實際 flag 請以各 CLI 的 --help 為準，重點是「兩次獨立呼叫、reviewer 的 context 是乾淨的」）：

# writer：Codex 出草稿
codex exec --model gpt-5.5 < prompts/writer.txt > draft.py

# reviewer：Claude 在全新 session 審，看不到 writer 的推理過程
{ cat prompts/reviewer.txt; echo; cat draft.py; } > review_input.txt
claude -p --model claude-opus-4-7 < review_input.txt > final.py

注意 -p（print / 一次性模式）跟接續對話的差別 —— 你要的就是它不帶前面的東西。

招式 5：留著 writer 的自評信心

論文的 writer prompt 要求模型在解法後面加一句信心水準與不確定的邊界情況。這一句在論文裡沒被拿來做分流，但它是免費的分診訊號：writer 說 low confidence 的才送 review，說 high 的直接放行。 以論文的成本結構，這能在幾乎不損失收益的前提下砍掉大半的 review 開銷。值得實測的點是這個自評到底準不準 —— 這份研究沒回答。

招式 6：量你自己的改壞率，別直接抄論文數字

論文的 116 題全是單檔、自足的 Python 競賽題。它沒有觸碰多檔案 repo、沒有 security、沒有 style 或可維護性。你的 codebase 跟它的相似度大概接近零。

真正該搬回家的不是那四個百分比，是那套實驗設計。做法：挑 30 到 50 個你們最近的 PR 或 issue，跑 writer solo 跟 writer + reviewer 兩條，記三個數字 —— 修好幾個、改壞幾個、無效產出幾個。改壞率超過修好率的那條 pipeline，直接關掉。 這比爭論哪個模型比較強有用得多。

七、什麼時候別用這招

writer 本來就很強的時候。 論文的 AA 條件講得很白：91.4% 進、91.4% 出，多燒 50 秒。高 baseline 上的 review 是純成本。
reviewer 沒有執行能力、任務又很吃「整體解法選擇」的時候。 靜態 reviewer 判斷不了「換一個演算法會不會更好」，卻很敢換 —— 這正是 AO 那 13 次改壞的形狀。
延遲敏感的路徑。 OA 是 112.4 秒對上 Codex solo 的 38.5 秒。互動式場景吃不下這個。
你只是想「多一個意見」的時候。 這是整篇最重要的一句：第二個模型不會自動變成獨立審查。 沒有乾淨 context、沒有介入門檻、沒有可執行證據，它只是一次昂貴的重擲骰子 —— 而且骰子有可能把你已經對的答案擲掉。

八、來源

主要論文：Zuodong Xiang（UC Davis）、Yike Zhang（Johns Hopkins）、YueMing Zhang、Hailu Xu（Cal State Long Beach），《Cross-Model LLM Code Review: Should you use Claude to review Codex or vice versa?》，arXiv:2607.21656，2026-07-22，已被 Agentic SE @ KDD'26 接受 — https://arxiv.org/abs/2607.21656
開源 artifact（prompt 原文、六條件設定、raw records、統計腳本，MIT）— https://github.com/shawnzxiang/cross-model-review-code
脈絡切斷的對照研究：Tae-Eun Song，《Cross-Context Review: Improving LLM Output Quality by Separating Production and Review Sessions》，arXiv:2603.12123，2026-03-12 — https://arxiv.org/abs/2603.12123
討論起點：r/ChatGPTCoding 的討論串 A second AI model is not automatically an independent review — https://www.reddit.com/r/ChatGPTCoding/comments/1vffqm6/a_second_ai_model_is_not_automatically_an/

本文的論文數字取自 arXiv v1 摘要與正文；repo 對照數字取自我實際 clone 下來的 docs/RESULTS.md 與 results/processed/stats_complete_case.csv。兩批數據的落差已在第五節標明。所有 prompt 為 repo 原文照抄，未經改寫。