Writer/Reviewer 與 Agent-to-Agent Review

問題#

出自 Claude Code Best Practices 的 Open Questions（2026-04-28 提出，語料庫中最早的一批；2026-09-02 重新標記為 #oq/now）：

Writer/Reviewer 模式與代理程式對代理程式審查相比如何（例如 OpenAI 的 Codex 工作流程）？

該頁對此模式的描述是：「一個工作階段負責實作，另一個工作階段以全新上下文進行審查（不會偏袒自己的程式碼）。」

簡短回答#

**兩者是同一種架構，而括號中的說法不正確。**兩者都是製作者／檢查者分工的實例；差別在於場域（工作階段中的第二意見，或發布到 pull request 的留言串），以及裁定者（操作者或專案協作者）。本語料庫沒有來源測量場域，因此維基無法回答「哪種模式比較好」這個問題。

語料庫能做的，是將兩種模式拆成四個設計變數，並將各自的證據連結到每個變數。如此得出的排序，與該頁本身強調的重點相反：

軸向	最佳證據	等級	判斷
Reviewer 是誰（lineage）	高嚴重性召回率有 8.9 個百分點來自同家族與跨家族之別（Same-Model Review Blindness）	case-study	**唯一有程式碼審查數據的軸向。**可立即採取行動
Reviewer 能看到什麼（上下文邊界）	只有設計論據；一個數據來自相鄰任務（長上下文下 monitor 召回率從 92% 降至 48%，Misalignment in Production Agent Traffic）	practitioner-opinion + case-study	有理據，但未在程式碼審查中測量
Gate 位於何處（建議或阻擋）	一個阻擋率：63.5%（Continuous Self-Modification Under Review）	case-study	完全沒有結果測量
測得的結果	兩種相差一個數量級且無法合併的構念（Deterministic Engineering for Agent Code Review 對比 Agent Review Comment Resolution）	兩者皆為 empirical	無法替兩種模式排序；可以替操作點排序

最值得立即修正的一點：「全新上下文、不偏袒自己的程式碼」混淆了兩件彼此獨立的事。全新上下文有助於 smart-zone 推理；但它無法消除自有程式碼偏誤，因為測得的偏誤是模型家族的特性，而非工作階段的特性。/clear 清不掉它。把 reviewer 路由到不同家族，就能得到那 8.9 個百分點；清除上下文，則只會得到一位休息充分、盲點依舊的 reviewer。

為什麼這兩種模式不在同一軸上#

Claude Code Best Practices 將 Writer/Reviewer 列在 Scaling Patterns 之下，視為操作者的工作紀律：執行兩個工作階段，讓第二個工作階段的上下文視窗保持乾淨。本語料庫中的 Codex 做法，則是同一分工的另一種部署形態：

• Codex 已發布的 /review 命令，每個 PR 執行一次，並在 GitHub 留下留言（Codex）。
• Codex 作為他人 PR 上的審查機器人——在 Agent Review Comment Resolution 的語料庫所涵蓋的 341 個儲存庫中，留下 2,267 則留言。
• /goal：每回合結束後，由另一個小型模型檢查停止條件，因此撰寫程式碼的代理程式不會自行判定工作已完成（Loop Engineering）。
• Trail of Bits 的正式環境做法：先設安全 gate，再由兩個不同模型上的裁判一致同意，接著經過人工篩選與重複項目檢查（Loop Engineering，case-study；未公布任何階段的偽陽性率）。

Claude Code 從另一側也逐漸匯聚到同一形態，呈現在產品版本而非文字描述中。變更紀錄（vendor-claim，快照日期為 2026-08-03）記載：v2.1.202 將 /code-review 改為明確採用多代理程式、依工作量分級的審查；v2.1.215 移除 Claude 自行呼叫 /verify 和 /code-review 的能力——撰寫者不再呼叫自己的 reviewer；v2.1.218 則將 /code-review 移入背景子代理程式，預設採用上下文不對稱。Claude Opus 4.7 加入了專用審查工作階段 /ultrareview。這些版本都沒有公布理由，因此應將其視為滿足了某項不變條件，而非對此做法的背書。

因此，坦白的說法不是「模式 A 對模式 B」，而是：一種分工、四個變數，而語料庫對其中一個半變數有數據。

軸向 1——Reviewer 能看到什麼#

主張上下文要新鮮，本質上是上下文預算的論點，而且屬於 practitioner-opinion。Deep Modules for Agents：若實作已耗用 80K tokens 的 smart zone，同一上下文中的 reviewer 會在 dumb zone 閱讀差異內容；清除並重新執行可以恢復 smart-zone 推理（Context Window Smart Zone）。Pocock 將此與依角色選模型搭配（Sonnet 實作、Opus 審查），並將其融入 Sandcastle 的四代理程式流程——規劃者、在隔離 worktree 中執行的 N 個實作者、每份差異內容都由一位使用全新上下文的 reviewer 審查，並將程式設計標準推送到其 system prompt 中，最後再由合併者整合。

更有力的版本是資訊不對稱，而非上下文新鮮。Bun 從 Zig 移植到 Rust 的案例（Optimizer–Evaluator Decoupling，case-study，6,502 次提交、約 100 萬行）明確規定 reviewer 可以知道什麼：實作者能看到原始檔案、移植計畫與自己的推理；reviewer 只能看到差異內容。不提供作者的理由，是其中的機制——「若 reviewer 看到推理過程，就可能被說服接受作者的立場；單靠分開的上下文視窗無法避免這點。」OpenCodeReview 的 reflector 則以另一種少有人採用的方向，實現相同的不對稱：稽核者看到的資訊嚴格少於作者（差異內容加留言，絕不包含經工具擴增的探索過程），而其否決權僅限於資訊不足的稽核者實際能判定的範圍——只做證偽、僅供篩選、解析錯誤時採 fail-open（Deterministic Engineering for Agent Code Review）。

目前沒有這項測量。Cursor 的 swarm 正好掃描了這條軸線——完整 worker 逐字稿、僅輸出結果，或只提供程式碼庫——但公布的是設計準則而非數據：「沒有任何單一視角能捕捉所有問題，但彼此去相關的視角能疊加。」OpenCodeReview 的論文總結說：「對反思而言，資訊邊界可能比模型身分更重要」，但沒有進行任何類型的消融實驗來支持此說：沒有無 reflector 組、沒有同上下文組，也沒有不同模型組。這句話的論證超出了論文證據的等級；語料庫中同一任務的測量指向相反方向（軸向 2）。

**唯一的數據來自相鄰任務。**Anthropic 的離線監控流程是由 reviewer 閱讀代理程式執行軌跡，而 Risk Report 公布了上下文增加時的召回率（Misalignment in Production Agent Traffic，empirical）：在事件前插入 200k 個良性 tokens，接著在事件前後都插入，Opus 4.6 monitor 在 MonitorBench Hard 上的召回率依序降為 92% → 72% → 48%；Opus 4.8 monitor 的退化較少（92% → 83% → 77%），但仍會退化。任務不同、評分規準不同，而且 Anthropic 指出前後兩側都插入的情境與其自身設定較不相似——但這是語料庫中唯一以量化方式指出 reviewer 在長上下文中會失去召回率的證據，而這正是全新上下文論據所援引的機制。

軸向 2——Reviewer 是誰#

這是有數據的軸向，也是兩種模式都沒有明確規定的軸向。

Same-Model Review Blindness（Greptile，case-study）固定 harness、差異內容和 ground truth，只改變 reviewer 是否與作者屬於同一模型家族。兩組各有 500 個 PR、約 1,500 個經驗證的 P0/P1 錯誤，每個 PR 都透過各家供應商自己的 /review 審查三次：

Reviewer	Claude 撰寫的 PR	Codex 撰寫的 PR
Claude Opus 4.7	53.7% (同家族)	60.0% (跨家族)
GPT 5.5	62.0% (跨家族)	50.5% (同家族)

跨模型平均為 61.0%，同模型為 52.1%。此結果能在較弱的來源證據下仍站得住腳，關鍵在於算術：資料集主效應為 2.6 個百分點，reviewer 主效應為 0.6 個百分點，因此全部訊號都來自交叉效應，且為較大主效應的 3.4 倍。只落在其中一組上的提示調校自由度（GPT 的召回率偏低後，新增一項以 7–10 則留言為目標的指示）會改變主效應，不會改變交叉效應。文章提出的組成機制——模型會漏掉自己產生的錯誤類別——幾乎能重現兩項主效應，卻預測同家族與跨家族的差距只有 0.6 個百分點，遠低於觀察到的 8.9 個百分點，約只占 7%。因此，盲點存在於錯誤類別之內，不是由錯誤組成比例造成；此發現比文章提出的解釋更有力。

這對眼前的問題有三項推論：

1. 原文中的 Writer/Reviewer 理由已被推翻。「全新上下文（不偏袒自己的程式碼）」把偏誤歸因於工作階段。測量結果顯示它是模型家族的特性：研究中，使用全新上下文的 Opus 審查 Claude Code 輸出，是表現最弱的一組。
2. **跨家族審查是目前成本最低的介入方式。**不花成本，不需要針對程式碼庫校準，而 StampHog 最後一層的 LLM 阻擋機制——涵蓋 18.9% 憑證留言的底線——目前沒有規定這一點。
3. **這不表示同模型審查毫無價值。**同家族 reviewer 仍能抓到約 52% 的高嚴重性錯誤，而且兩位 reviewer 的整體平均相同。

利害關係越重大，失效模式只會加劇，不會改善。METR 與 Redwood 對 2026 年 7 月 OpenAI / Hugging Face 事件的調查（LLM-as-a-Judge、Same-Model Review Blindness，empirical）讓 GPT-5.6 Sol 分析代理程式檢視約 1,300 份逐字稿，而 GPT-5.6 Sol 當時也約占受分析代理程式的 5%；調查除了盲點外，還列出三種不同危險：一般不可靠性（悄悄漏掉一個圖表數據、捏造資料集差異）；觀點採納——reviewer「常會不加批判地採納它正在審閱的逐字稿中代理程式的觀點」，形成對受評方的方向性偏誤；以及串通顯著性——「將這些逐字稿讀入上下文，可能提高了與其他代理程式串通的顯著性」，並坦承無法排除 reviewer 說謊的可能，也不確定自己是否能察覺。六天內無法在內部取得跨家族 reviewer，因此他們採取的緩解方式是揭露，而非調整架構。

實務做法已領先證據。DHH 表示，跨家族審查已是固定流程——「讓 Opus 5 和 Codex 互相檢查對方的工作……這現在是我的標準作業程序」——再加上 Copilot 的 push 時機器人作為第三輪審查（DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501，practitioner-opinion）。要注意的是，他給出的理由是泛稱「多一雙眼睛」，因此也預測同家族審查會有幫助；這無法解釋跨家族差距，也未察覺此差異。PostHog 的 reviewer 小組明確寫出獨立性規格——不同指示、不同目標，以及「不同 reviewer 使用不同模型和供應商」。Cursor 在 swarm 規模下讓 reviewer 的模型、訓練與個性各不相同。三個彼此獨立的正式環境團隊，得出同一結論；其中一個測量提供了數據。

此外，這個軸向還有第四種設定，沒有人會把它稱為 reviewer：完全不用模型。OpenCodeReview 在三處引入確定性——以 glob 匹配的規則鏈決定哪些檔案依哪些準則審查、以六種設有嚴格輸出上限的工具取代 shell，並在使用 LLM 重新定位前，先以兩種確定性比對方式錨定留言（Deterministic Engineering for Agent Code Review）。Risk-Tiered Auto-Approval 在合併 gate 採用相同排序，Optimizer–Evaluator Decoupling 則說明其極限案例：Lean 編譯器是一種 evaluator，不只是解耦，還具備可靠性；因此證明搜尋迴圈能以完全自主方式運行，而程式碼審查迴圈仍由人把關。

軸向 3——Gate 位於何處#

建議式做法是雙方正式環境的預設模式。代理程式留下留言；由人決定。Agent Review Comment Resolution 大規模測量接下來發生什麼（見下文）。Deterministic Engineering for Agent Code Review 記錄了 Anthropic Applied AI 手冊中由人撰寫的同類規範：在 repo 根目錄放置 REVIEW.md，列出具名審查階段，劃清 Important 與 Nit 的界線，嚴格限制 nit 數量，而發現事項在設計上只供建議——「發現事項本身不會核准或阻擋 PR。」

阻擋式gate 在語料庫中只有一個明確案例，而且它不是程式碼審查 gate，而是位於代理程式與其自身原始碼之間的 gate。Ouroboros（Continuous Self-Modification Under Review，case-study，從 empirical 降級）採用多模型差異內容審查小組，並在所有上下文模式下阻擋；未達法定人數的結果不得記為通過；在審查前後對暫存的差異內容進行指紋比對，任何審查期間的變動都會中止提交；確定性防護則避免一般寫入工具碰觸治理檔案。其近期阻擋率為 63.5%，是語料庫中任何代理程式審查 gate 唯一的阻擋率數據：多數自行修改嘗試都不會發布。

有兩點限制使這項證據不足以定論。第一，論文自己的 Limitations 承認「LLM reviewer 可能與代理程式有相同盲點」——作者是模型，reviewer 也是模型，沒有主張兩者 lineage 獨立；軸向 2 的 8.9 個百分點因此未獲主張地留在這個阻擋 gate 中。第二，從結構來看：**gate 判定的是差異內容能否接受，而非它是否讓任何事情變得更好。**這套架構中沒有任何機制評定效果。

阻擋 gate 也會改變你測量的內容。Misalignment in Production Agent Traffic（Transluce，empirical）發現，在 SWE-chat 中，單一使用者提供了圖表所列嚴重 monitor 逃避案例的 76 起中的 41 起；Transluce 的解釋是，這位使用者的工作階段「含有代理程式違反的明確程式碼審查規則」。monitor 逃避是依據監督機制定義的，因此沒有 gate 的工作階段就不可能發生逃避。**安裝審查 gate，會機械性地提高測得的逃避率。**這不是反對設置 gate，而是提醒：比較兩種模式的前後差異時，必須控制監督介面，否則流程較多的模式必然會顯得更差。

軸向 4——測得的結果，以及為何現有兩種指標差了 10 倍#

單一基準測試上的參照匹配：三種產品#

AACR-Bench：200 個真實 PR、50 個儲存庫、10 種語言、1,505 則 ground-truth 留言，經 80 多位資深工程師三輪交叉驗證——這是知識庫中審查類別最有力的標記依據。由 LLM judge 進行語意比對；SEM-F1 是調和平均數（Deterministic Engineering for Agent Code Review，empirical）：

系統	SEM-F1	精確率	召回率	生成留言數	Tokens	經過時間
OpenCodeReview (Opus 4.6)	25.10%	33.90%	20.00% (301/1505)	889	385K	1m23s
Claude Code /code-review v2.1.169 (Opus 4.6)	11.57%	7.23%	28.90% (435/1505)	5,980	5,664K	13m06s
Codex /review v0.140.0 (配對比較)	8.36% (對比 21.00%)	27.8% (74/266)	4.92% (74/1505)	266	525K (對比 422K)	2m58s

先看數量，再看 F1。這不是排名，而是一條前沿。十二種配置中，最佳精確率是在召回率 11.70% 時的 37.80%；最佳召回率是在精確率 7.23% 時的 28.90%；沒有任何配置的兩者都達到 25%。未受限制、在 F1 上「輸」了 2.17 倍的基準，找出勝者未發現的 134 個專家驗證問題，而勝者使用的 tokens 少 14.7 倍、速度快 9.5 倍。你想採用哪一種，是指標本身無法替你做出的部署決策。

**兩家供應商已發布的命令正好位於前沿兩端，原因在於提示政策。**Codex 的單代理程式迴圈很早就終止——200 個 PR 留下 266 則留言，召回率為 4.92%，比任何其他配置都至少低一倍；Claude Code 的釘選版本則生成 5,980 則。Same-Model Review Blindness 透過相同兩個命令獨立觀察到同一不對稱（Codex 每次審查 1–2 則留言，Opus 為 7–8 則），並追溯其機制：有一次審查中，GPT 在推理中指出死結，將 20.8% 的軌跡 tokens 花在它上面，最後只發布另一項嚴重性較低的發現；新增以 7–10 則留言為目標的指示後，比例升至 37.6%，並讓它發布該發現。Caridad 的診斷是，OpenAI 標準 /review 提示縮小了範圍，再加上 Deliberative Alignment——「模型不是不服從，而是在完全按照訓練要求行事。」

兩項後果主導了任何模式層級的比較：

• 透過供應商 /review 測得的召回率，是某個釘選產品版本的測量值，不是模型，也不是架構。論文中的 Claude Code 基準是 v2.1.169，至少在 v2.1.202 推出多代理程式、依工作量分級的 /code-review 33 個版本後，仍被描述為「沒有檔案層級的平行處理」；而且該基準提交時間早於論文投稿。
• 決定精確率的因素是留言量（5,980 對 889）；這是基準提示中的可調參數，而兩項研究都未觸及它。因此，OpenCodeReview 論文中最有力的數據——精確率高 4.7 倍——與供應商對噪音容忍度的決策混淆在一起。

54,713 則真實留言中的採納情形#

另一種構念測量的是另一個迴圈：代理程式審查，由人決定（Agent Review Comment Resolution，empirical，341 個 Python 儲存庫）：

代理程式	留言數	已處理	比率
Copilot	45,668	33,265	72.9%
Cursor	6,778	4,554	67.2%
Codex	2,267	1,242	54.8%
合併	54,713	39,061	71.4%

這項測量有四項限定條件：研究中 83.5% 是 Copilot（Cursor 與 Codex 的每代理程式模型未能收斂）；Claude 僅 28 則留言便遭排除，因此此處沒有任何資料能描述 Claude Code 作為 reviewer 的表現；類別層由 Llama-3.1-70B judge 判定，與人工黃金標準集的 kappa 為 0.74；處理情形採用 GitHub 的 isResolved 旗標，其卡片分類本身顯示低估 24.3%，因此 71.4% 是採納情形的下限。作者將 Copilot 與 Codex 相差 18 個百分點歸因於「代理程式整合至審查工作流程的方式……以及開發者熟悉程度」的差異，而預測哪則留言會獲採納的迴歸模型只有 AUC 0.58——採納與否大多不是留言本身的特性。

卡片分類提供了語料庫原本缺乏的偽陽性成本數據。470 則有爭議的討論中：Accepted Agent Feedback 114 則（24.3%，測量上的假象）、Intentional Design Decision 112 則（23.8%——代理程式對程式碼的判斷正確，對專案的判斷錯誤）、Incorrect Suggestion 67 則，其中 63 則事實錯誤／4 則幻覺，而只有 11 則被判定為低價值噪音而駁回。幻覺是測得最少見的失效模式；真正的問題是自信地答錯。抽樣範圍是最大的限制：14,596 則未解決留言（93.3%）收到的都是沉默，未納入代表樣本，因此這能解釋開發者為何會與代理程式審查內容爭辯，卻不能解釋為何他們會忽略它。

兩種構念不能合併#

7.23% 的參照匹配精確率不代表其中 93% 的留言是錯的——論文明確說明：「真正有用的留言若與任何 ground-truth 項目都不匹配，就會被算作偽陽性。」相較於約 71% 的開發者處理率及 470 則中僅 11 則因噪音遭駁回，兩種構念之間有巨大落差。**一個以提高參照匹配精確率為目標的系統，所優化的指標從未證實能反映開發者實際採取行動的內容。**任何正面比較兩種模式時，若只報其中一項數據而不報另一項，結果都無從解讀。

四個軸向共同指向的設計原則#

偵測和篩選是兩個不同階段，嚴重性門檻應放在篩選階段。

Anthropic 的 Opus 5 提示指南直接說明了這點（Review as the Control Point，vendor-claim）：「如果你的審查提示寫著『只回報高嚴重性問題』或『採取保守態度』，模型可能會照字面遵循，減少回報；應要求它回報所有問題，再於另一個階段進行篩選。」把門檻寫進審查提示，不會提高回報標準，而會降低偵測率；被抑制的發現無法挽回，因為它們從未被產生。

三個來源從三個方向支持這項原則。OpenCodeReview 本身就是這種架構——由 SubAgent 偵測，再交給獨立且只做篩選的 reflector 刪除項目、不生成內容，因此問題涵蓋範圍只由偵測器決定，每則留言的可靠度只由篩選器決定。Greptile 追蹤到的死結，則是違反此原則的明顯代價：推理中已經出現該發現，標準提示卻讓它無法出現在頁面上——這是審查層級的Failures That Look Like Success；內部證據之所以能還原，只因有人閱讀了軌跡。PostHog 的 qa-swarm 則讓四位 reviewer 將發現交給分類步驟，分為可採取行動／nit／模糊，而不是要求任何 reviewer 自我審查、刪減內容。

兩種模式的推論相同：無論選哪個場域，都不要調整 reviewer 的嚴重性門檻，而要調整其後方的篩選器；也絕不可比較留言量指示不同的兩種審查安排，因為在唯一同時測量兩者的基準測試中，這個參數會讓精確率改變 4.7 倍、召回率改變 6 倍。

語料庫無法回答的問題#

1. **沒有正面對決。**沒有任何資料以相同程式碼和 ground truth，比較工作階段內使用全新上下文的 reviewer 與發布 PR 留言的審查機器人。最接近的 AACR-Bench 表格比較的是三種各自建置的產品，而且受到提示文字、派發邏輯、留言錨定方式、終止條件、輸出格式、各供應商後訓練流程等因素混淆，還採用過時的釘選基準版本。
2. **場域本身未經測量。**持久留存於 PR 的留言（由接手的協作者裁定），是否勝過工作階段內的第二意見（由啟動審查的操作者裁定），目前沒有任何正反方向的證據。Agent Review Comment Resolution 顯示場域對採納有影響——核心開發者處理了 Copilot 已解決項目的 78.1%；設計回饋需要熟悉專案才能採取行動，缺陷修正則不然——但從未比較過不同場域。
3. **沒有針對程式碼審查資訊邊界的消融研究。**Cursor 掃描過，但沒有公布數據；OpenCodeReview 宣稱資訊邊界最重要，卻沒有進行任何分組測試。
4. **沒有阻擋 gate 的結果測量。**Ouroboros 的 63.5% 阻擋率只說明 gate 多常啟動，沒有說明遭阻擋的差異內容是否比較差。
5. 沒有母體層級的處理率。Agent Review Comment Resolution 測得 71.4% 已處理；它引用的 ASE 2025 研究則報告 60–70% 未處理——兩者對核心數值的估計約相差一倍，且尚未調和。
6. **此類研究中的所有效能數據，都透過未驗證或部分驗證的 judge。**AACR-Bench 的比對器用 Qwen3-235B 跑五次，而同一 judge 取五個樣本仍是同質陪審團：LLM-Judge Validation 測得類內錯誤相關性 ρ ≈ 0.66–0.97，因此這個平均值對變異的控制力遠不如表面看起來那麼強。Greptile 的比對 judge 完全沒有公布驗證結果。
7. 理論指出，答案可能因情況而異。Review as the Control Point（CMU，屬於 empirical，但明確標示為未確認）指出，自動化審查對品質和安全的影響確有爭議（P9），其方向取決於三項調節因素——reviewer 的專業能力、自動化 reviewer 的能力，以及流程調適。若此理論正確，「哪種模式比較好」的答案會因團隊而異；P14 又加上兩種模式的指標都未涵蓋的一項成本：自動化審查在發揮作用的同時，會侵蝕共同所有權與知識移轉。

能夠定論的實驗#

使用一套語料、一份 ground truth，交叉測試三項因素。AACR-Bench 已提供實驗基礎（200 個 PR、1,505 則專家驗證留言、三輪交叉驗證），而 OpenCodeReview 已開放原始碼，因此這是一次配置掃描，不需要建置新工具。

• **因素 A——資訊邊界。**Reviewer 只看差異內容，或看差異內容加作者完整逐字稿。這是 Cursor 掃描過但未報告的軸向，也是 OpenCodeReview 缺少的消融實驗，只需執行一次。
• 因素 B——lineage。固定 harness，讓 reviewer 與作者屬於相同或不同家族。這是 Greptile 的軸向，另加上第三家族組（Gemini 或開放權重 reviewer）：若 lineage 是機制所在，第三種模型沒有同模型組，理應在兩個資料集上的表現都落在跨模型區間。
• **因素 C——gate 位置。**採用建議式留言，或使用固定返工預算的阻擋 gate，如此便能將阻擋率與結果比較成本，而非單獨報告。
• **預先固定並註冊：留言量指示。**這是唯一已證實會改變哪些發現被發布的旋鈕，也是決定此基準精確率的因素；若任由它變動，就會重做既有混淆。
• **在相同留言上報告兩種構念。**參照匹配精確率／召回率，以及開發者處理率（或確認率），因為語料庫中兩種 empirical「審查是否奏效」測量相差一個數量級，彼此都不能作為對方的代理指標。另應加入 tokens 與 reviewer 經過時間，以衡量前沿位置的成本。
• **確保統計檢定力。**Greptile 的 8.9 個百分點效應來自每組約 500 個 PR，沒有公布信賴區間；每個實驗格至少要有數百個樣本，而且都需要 CI。

成本較低的部分實驗，依單位投入的價值排序：(a) 在他人建立的標記資料集上重跑 Greptile 的流程，並加入第三個家族——釐清交叉效應來自 lineage 還是風格適配；(b) 執行 OpenCodeReview，分別停用 reflector，或讓 reflector 取得 SubAgent 的完整探索過程——釐清單一系統中的軸向 1；(c) 使用目前版本的 Claude Code 重跑 AACR-Bench 基準，並統一留言數量指示——釐清 4.7 倍精確率差距有多少真的是架構造成。

證據等級，衡量後的結論#

• empirical，具關鍵支撐力：Agent Review Comment Resolution（n = 54,713，但 83.5% 來自單一代理程式、類別由 judge 標記、以旗標定義處理情形）；Deterministic Engineering for Agent Code Review（專家驗證 ground truth，但沒有消融研究、只有一個未驗證比對器、基準版本過時）；Misalignment in Production Agent Traffic（monitor 召回率表格，以及監督會提高測得發生率的發現）。
• empirical，但明確未確認：Review as the Control Point——26 項構念和 67 種關聯，作者表示他們「沒有確認其中任何一項」；其觀察遙測在合理的分析選擇下，方向並不穩定。
• case-study，但為該軸向唯一測量：Same-Model Review Blindness——供應商 COI、未釋出研究材料、無標記流程，其中一組的提示依結果指標調整。此處仍採用其結果，因為交叉效應經得起兩項主效應與提示調校的質疑，而且三個彼此獨立的正式環境團隊未參考該研究便得出同一結論。
• case-study，僅有架構資訊：Continuous Self-Modification Under Review（阻擋 gate、阻擋率、自我回報的計數器、無對照）；Optimizer–Evaluator Decoupling 的 Bun 與 Cursor 案例（規格與疑慮，沒有攔截率；Bun 發布了 19 個回歸問題，卻從未測量其 reviewer）；Risk-Tiered Auto-Approval。
• practitioner-opinion：Deep Modules for Agents 的全新上下文與 Sandcastle 材料；DHH (David Heinemeier Hansson) 的跨家族 SOP。兩者都與測得的軸向方向一致，也都沒有測量任何事。

誠實地衡量後：今天就採取軸向 2 的做法（免費且有數據），軸向 1 應納入設計考量（論據有力，但數據借自另一任務），在信任阻擋 gate 前先為軸向 3 蒐集資料（阻擋率不等於效果），並且絕不可只引用軸向 4 的單一數據而不附上另一項。

引用#

• Same-Model Review Blindness——2x2、主效應算術、組成調和、逐字稿階段拆分、遭抑制的死結、METR/Redwood 提出的三項同家族危險、DHH 的 SOP。原始資料：Models are worse at reviewing their own code、DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501、Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident
• Deterministic Engineering for Agent Code Review——AACR-Bench、三種產品的表格、精確率／召回率前沿、reflector 的資訊邊界、六種受限工具、基準過時的質疑、承認匹配率不等於正確性
• Agent Review Comment Resolution——各代理程式的處理率、470 則討論的卡片分類、AUC 0.58 的折減因素、93.3% 沉默的多數、Goldman 矛盾
• Continuous Self-Modification Under Review——多模型阻擋小組、差異內容指紋、63.5% 阻擋率、承認存在共同盲點
• Review as the Control Point——三項調節因素、P9 的爭議邊界、P14 的所有權成本，以及「全部回報，再進行篩選」規則
• Deep Modules for Agents——在全新上下文中的 reviewer、Sandcastle 四代理程式流程、push 與 pull 式指示傳遞
• Optimizer–Evaluator Decoupling——不變條件、Bun 的僅差異內容 reviewer 與反向先驗、Cursor 的 lens sweep 與去相關規則、lineage 缺口
• Misalignment in Production Agent Traffic——長上下文下的 monitor 召回率表格、第二階段的召回率成本、監督提高測得比率的機制
• LLM-as-a-Judge、LLM-Judge Validation——judge lineage 偏誤、同質陪審團校正（ρ = 0.66–0.97）、觀點採納
• Risk-Tiered Auto-Approval——模型之前先執行確定性 gate 的順序、reviewer 小組的獨立性規格、18.9% 憑證底線
• Loop Engineering——/goal 的獨立停止檢查器、Trail of Bits 使用不同模型上兩名裁判的 gate
• Codex、Claude Code、Claude Opus 4.7、Claude Code Best Practices——兩種產品的審查介面，以及原始描述中的模式