Agent Review Comment Resolution

資料來源#

• AI-to-AI Code Reviews of GitHub Pull Requests
• developer responses agent review comments
• What Types of Code Review Comments Do Developers Most Frequently Resolve?

摘要#

Cynthia、Widyasari、Roy、Zhang 與 Lo（University of Saskatchewan / Singapore Management University / Monash，arXiv 2607.21997，2026 年 7 月）進行首項大規模研究，探討 AI 代理程式留下審查留言之後會發生什麼事。他們從 341 個 Python GitHub 儲存庫中蒐集 54,713 則代理程式生成的審查留言，並提出三個問題：有多少留言獲得解決、由誰解決，以及留言的哪些特徵能預測它是否會獲得解決。

請仔細看清方向——這與知識庫中其他每一篇審查文章都相反。 Review as the Control Point、Security Debt of Agent-Generated Code 和 Efficiency Debt of AI-Generated Code 衡量的都是人類審查代理程式撰寫的程式碼，其有效性問題是「審查者能否發現缺陷」。本文衡量的是代理程式審查拉取請求，有效性問題則是「人類是否會依照代理程式的發現採取行動」。兩種迴圈共用一些詞彙，其他幾乎完全不同。留言獲得解決不代表缺陷確實存在；它只代表某位專案協作者同意程度足以關閉討論串。還要注意，論文從未確認受審查程式碼的作者是誰——這些是在活躍 Python 儲存庫中受到審查機器人留言的 PR，既有人類撰寫，也有代理程式撰寫，沒有區分。

證據註記。 empirical，完整閱讀後確認，但每個數字都須連同四項限制一起理解。(1) 「五個代理程式」是蒐集範圍，不是分析範圍。 蒐集到來自 Copilot、Cursor、Codex、Devin 和 Claude 的 342 個儲存庫、54,791 則留言；但 Devin（50 則）和 Claude（28 則）因資料太稀少，不納入推論，最後留下 341 個儲存庫、三個代理程式的 54,713 則留言。本文沒有對 Claude 或 Devin 作為審查者的特性提出任何描述。(2) 這主要是 Copilot 研究。 Copilot 占 54,713 則中的 45,668 則（83.5%；論文有一處寫成 86%）；作者表示合併迴歸「大致反映 Copilot 的互動模式」，而 Cursor 和 Codex 的個別模型因資料稀疏與分離問題未能收斂。(3) 分析有一層使用 LLM 評審。 15 類留言分類、七種解釋類型，以及相關性／清晰度／簡潔度分數，都由 Llama-3.1-70B 產生。研究者以 100 則留言的人類黃金標準集，將它與 GPT-4o 和 Qwen3-8B 比較後選用（分類的 kappa 為 0.74，人類互評基準為 0.86；多標籤解釋類型的 Jaccard 為 0.90，僅保留信心度 >= 0.9 的標籤）。這是相當程度的一致性，不是真值。(4) 解決與否的構念是 GitHub 的 isResolved 討論串旗標——作者在效度威脅一節明確如此說明，而卡片分類也證明這個指標會雙向出錯（見下文）。

RQ1：大約十則留言中有七則獲得解決#

（表 III，已對照 PDF 核實。）

Agent	留言數	已解決	解決率
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%

引用前先修正摘要中的算術說法。 摘要寫著「Copilot 占已解決留言的多數（72.9%）」，把兩種不同數值混在一起。72.9% 是 Copilot 的解決率；Copilot 占全部已解決留言的比例則是 33,265/39,061 = 85.2%，這說的是它在此語料中的市占，而不是品質。兩個數字都是真的，但彼此不同。

Copilot 和 Codex 之間 18 個百分點的差距是論文的主要發現，而論文自己的解釋是，差距不是留言本身的特性。迴歸控制留言特徵後，代理程式層級的差距仍然存在，因此作者將之歸因於「代理程式整合至審查工作流程的方式，以及代理程式整合程度與開發者熟悉度的差異」——也就是呼叫方式與使用習慣，而非審查品質。應將這個排序視為受到嚴重混雜因素影響的採納度量（未控制儲存庫組成、任務組合，或各代理程式的觸發方式）。

各代理程式留言的主題差異，比它們獲得採納的頻率差異更大。 Copilot 已解決留言分布於多個類別——解決方案方法 21.8%、文件 19.8%、功能缺陷 18.1%、視覺呈現 11.3%；Cursor 和 Codex 則幾乎只聚焦於功能缺陷（已解決留言分別有 88.0% 和 88.6%；Codex 第二常見的類別是資源問題，占 2.9%）。研究把通用型審查者與缺陷偵測器放在同一軸線上比較，而缺陷偵測器的解決率反而較低。

RQ2：核心開發者負責解決，周邊開發者較常處理缺陷#

只計入解決者同時也是 PR 作者的案例（表 IV），核心開發者——以每個儲存庫為單位，而非全域計算，按已撰寫加已審查的已關閉 PR 數取前 20%——占 Copilot 解決案例的 78.1%、Cursor 的 54.6%、Codex 的 58.4%；母體中有 1,538 位核心開發者與 2,554 位周邊開發者。

依類別來看（圖 4），核心開發者占各類別的 70.5% 至 79.8%——所有類別的大多數都由核心開發者解決。差異在於周邊開發者最常出現在哪些類別：**功能缺陷（周邊開發者占 29.5%，n=8,481）**和視覺呈現（28.1%，n=3,167）最高；解決方案方法（20.2%，n=6,262）、程式碼組織（20.3%）和命名（20.9%）最低。設計與可演進性意見需要熟悉專案才能採取行動；修正缺陷則不需要。

這是 Returns to Expertise in Agentic Coding 在審查接收端的對應觀察：運用代理程式設計意見的能力，仰賴同一種專案特定知識，而這些知識也讓你能夠推翻代理程式的建議。

未解決背後的十種模式——以及解析過程隱藏的模式#

15,652 則未解決留言中，只有 1,056 則（6.7%）收到任何回覆，其中 655 則由 PR 作者回覆。作者從核心開發者回覆的 431 則和周邊開發者回覆的 224 則留言中，分層抽樣 470 則討論（核心 284 則、周邊 186 則），再以開放式卡片分類歸入 10 個類別和 13 個子類別，評分者間 kappa 為 0.85。

（下表 V 依 PDF 還原；此表的 docling 解析結果已損壞——見 Sources。每一列都能核對：子列加總等於父類別、核心加周邊等於總數、各代理程式分項加總等於總數，466 則可分類加 4 則無法分類等於 470。）

模式	討論數（Copilot/Cursor/Codex）	核心	周邊
Accepted Agent Feedback	114 (66/31/17)	54	60
— Accepted Suggestion	78	35	43
— Addressed Afterwards	36	19	17
Intentional Design Decision	112 (55/48/9)	81	31
— Context-Specific Implementation	64	44	20
— Expected Behaviour	37	26	11
— Developers' Preference	11	11	0
Incorrect Suggestion	67 (36/19/12)	32	35
— Factually Wrong or False Positive	63	29	34
— Agent Hallucination	4	3	1
Challenging Agent Feedback	39 (22/12/5)	25	14
— Disagreement with Suggestions	27	14	13
— Questioning Agent's Claim	12	11	1
Needs Further Discussion	36 (19/10/7)	20	16
Delegation of Work	31 (22/6/3)	24	7
— Agent Task Delegation	23	18	5
— Delegating to Developer	8	6	2
Suggestions Deferred	25 (12/9/4)	16	9
— Future Improvement	21	15	6
— Deferred to Future PR	4	1	3
Acceptable Trade-Offs	19 (9/10/0)	13	6
Missed Existing Fix	12 (9/2/1)	9	3
Dismissed as Low-Value	11 (7/4/0)	8	3

這份分類表有四點比分類法本身更重要：

1. 四分之一的「未解決」是衡量上的假象。 Accepted Agent Feedback——開發者已套用變更，卻從未將討論串標記為已解決——是最大的類別，占 470 則中的 114 則（24.3%），也是唯一偏向周邊開發者的類別（60 比 54）。GitHub 的 isResolved 旗標取決於使用者是否養成整理習慣，而較不融入專案的貢獻者較少這麼做。因此，71.4% 的解決率是採納率的下限，而非其估計值。（一項有用的交叉檢查：RQ3 重新建立標籤——排除僅由 AI 處理的解決案例，並納入「已在提交中修正……」、「完成」、「已更新」等明確確認——結果為 53,086 則中有 37,512 則 = 70.7% 有用。兩種不同方式建立的分母，得到幾乎相同的數字，顯示整體而言確認狀態修正幅度不大，儘管它在這組有討論的樣本中占了很大比重。）

2. 最常見的真實拒絕理由是脈絡，而非錯誤。 Intentional Design Decision 占 470 則中的 112 則（23.8%），而且明顯偏向核心開發者（81/112，72%）：程式碼是刻意如此設計，代理程式卻看不出原因。主要子類別是 Context-Specific Implementation（64 則）——「不，這個想法是把 add logs 用於 docker stream」——其次是 Expected Behaviour（37 則）。代理程式對程式碼本身並沒有判斷錯；它誤判的是專案。

3. 幻覺幾乎沒有；自信地判錯卻很常見。 Incorrect Suggestion 共 67 則，但內部分布是63 則事實錯誤／誤報，對比 4 則幻覺——僅占抽樣討論的 0.9%。「AI 審查失敗是因為它捏造內容」這種常見說法，在這個規模的測量中反而是最少見的失敗模式。真正的問題是代理程式讀了真實程式碼，卻從中得出錯誤結論。要注意，這個子類別正是受損解析結果隱藏的部分：docling 把 4/3/1 這一列併入相鄰列，讓幻覺看起來像一個 39 則討論的類別。正因為這一列，才必須還原表格，而不能直接引用解析結果。

4. 拒絕錯誤的代理程式意見不需要資深程度。 Incorrect Suggestion 是唯一明顯偏向周邊開發者的主要類別（35 比 32）；作者的解讀恰當：看出建議錯誤「可能不需要深入的專案知識」，而知道某種實作是刻意如此則需要。

依代理程式區分，兩種主要模式與 RQ1 的結果清楚對應：Intentional Design Decision 在 Cursor 的討論中比例偏高（32%，Copilot 21.4%、Codex 15.5%）——儘管它聚焦功能問題，仍有脈絡理解落差；Incorrect Suggestion 在 Codex 的比例偏高（20.7%，Copilot 14.0%、Cursor 12.6%），與 Codex 最低的解決率一致。

抽樣框架是分類結果的硬性限制，但論文沒有明說。 470 則討論取自 1,056 則有收到回覆的未解決留言。其餘 14,596 則未解決留言（93.3%）都沒有收到回應，因此沒有納入上述任何百分比。這項分類說明開發者為什麼會與代理程式審查留言爭論；它沒有說明他們為什麼忽略留言——而忽略才是多出一個數量級的主要行為，也是審查疲勞或雜訊假說會預測的行為。

RQ3：可採取行動的建議最有幫助，但模型仍幾乎無法預測#

以六項留言特徵進行邏輯迴歸；若人類已解決留言，或明確確認已修正，就算作有用（37,512 則有用、15,574 則未採納，n = 53,086）：

預測因子	OR（全部）	功能性	可演進性
Inline code suggestion	1.617	1.672	1.459
log 留言長度	0.926	0.855	—
has explanation	0.593	— (n.s.)	0.578
explanation: Rule	1.144	—	1.102
explanation: Benefit	1.087	1.066	—
explanation: Example	1.080	—	—
相關性／簡潔度／清晰度	1.046 / 1.059 / 1.022	1.044 / — / —	1.051 / 1.077 / 1.033

單變量分析中，含有 GitHub suggestion 區塊的留言解決率為 75.5%，沒有區塊的為 64.6%（Chi-squared p < 0.05，Cramer's V = 0.12——效果偏小），而且兩種問題類別都呈現這個差距。未採納留言較長（平均 807 個字元、中位數 405），有用留言則較短（平均 617 個字元、中位數 356）；差異顯著，但效果量可忽略。長度的負面影響只出現在功能性類別（未採納平均 1,240，有用平均 966），在可演進性類別中則消失。寫作品質分數在兩組間的差距最多只有一個中位數點（簡潔度 7 比 6），各項效果量都可忽略。

論文在效度威脅一節提出的折減因素：AUC = 0.58。 上述每個勝算比在 53,086 筆資料上都達統計顯著，但整體模型在排序哪些留言會被採取行動時，只比擲硬幣稍好。作者自己的結論是：「未觀察因素，例如審查者權限或專案脈絡，可能影響結果」——這與卡片分類得到的是同一個發現，只是以統計方式得出：決定是否採納的因素，大多不是留言本身的特性。 若根據這張表調整審查代理程式的文字表達，就是在最佳化那一小部分殘差。

一項不宜照單全收的內部矛盾。 has explanation 的 OR 為 0.593——解釋理由反而有害——論文卻把它列為主要發現之一（「簡潔、以行動為導向的留言更容易被採納」）。但論文自己的表 VII 已推翻這種單變量解讀：沒有解釋的組別解決率為 83.7%，且其中 89% 屬於表層類別（文件 234 則、視覺呈現 178 則、命名 75 則）；作者正確指出「觀察到的效果是由類別特徵造成，而非缺少解釋」。這項但書沒有延伸至迴歸分析；迴歸只控制功能性／可演進性的區分，沒有控制 15 種類別。站得住腳的解讀應是仍然成立的類型結果：基於規則、效益和範例的解釋與採納呈正相關；基於情境和問題的解釋則沒有。發現關乎解釋的風格；是否提供解釋則可能只是組成效應。

解釋豐富度為兩種解釋類型時，有用性最高（71.7%），超過兩種後便下降（三種為 69.3%，四種以上為 65.0%）——與長度的負面影響形狀相同；論文的解讀是，過多細節會降低可採取行動的程度。

對照調和：本文與它引用的研究#

引言引用 Goldman 等人（ASE 2025），支持「LLM 生成的留言約有 60-70% 未獲解決」這項主張。本文測得 71.4% 獲得解決——兩篇相隔一年的 empirical 研究，在核心數值上出現約兩倍差距，卻沒有進行調和。知識庫既沒有 Goldman 的母體，也沒有他的解決構念。 （2026-09-22 已取代——已取得 Goldman 的研究並釐清問題：兩篇論文測量的根本不是同一事件。）

Goldman、Lin、Pasuksmit、Thongtanunam、Tantithamthavorn 等人（The University of Melbourne + Atlassian + Monash，arXiv 2510.05450，ASE 2025）從 Atlassian 內部 1,007 個儲存庫中，取出兩個月期間（2025 年 6 至 7 月）發布於 3,746 個拉取請求中的 4,000 則 LLM 生成審查留言。留言由 Atlassian 自家的 **RovoDev Agent（透過 Claude 3.5 Sonnet）**發布，並由 GPT-4.1 評審分類至五類。他們對「已解決」的定義原文如下：

"We consider a given code review comment to be resolved if a subsequent commit modified the exact line where the comment was placed."

（圖 5，依頁面影像還原。設計和無問題比例在內文中完全沒有出現，整體比例在論文中也完全沒有出現；五個分母加總恰好為 4,000，這就是調和兩者的依據。）

類別	已解決／留言數	比例
程式碼可讀性	586 / 1,354	43.3%
程式碼錯誤	399 / 952	41.9%
可維護性	483 / 1,333	36.2%
程式碼設計	101 / 353	28.6%
沒有問題	2 / 8	25.0%
全部留言	1,571 / 4,000	39.3%

因此可比的數字是 Goldman 39.3%，本文 71.4%——共同尺度上的 32 個百分點差距，正是需要解釋的部分。Goldman 所稱「許多 LLM 生成的留言沒有由開發者解決（60%-70%）」，是對其圖表精確給出的 60.7% 所做的寬鬆概括。

差距主要由構念造成；產品效應有上限；母體效應方向相反#

母體效應方向相反，因此不可能是差距來源。 本文的 RQ2 指出核心開發者負責解決留言——Copilot 的案例中占 78.1%，而且在全部 15 個類別中都是多數——周邊貢獻者較少採取行動，也較少標記留言。Goldman 的母體涵蓋 1,007 個內部儲存庫，工作者全是領薪員工，並遵循強制審查流程：全是核心開發者，沒有本文中拉低數字的臨時貢獻者。若母體造成差距，產業數字理應更高；但它低了 32 個百分點。母體差異或許會縮小差距，卻無法造成目前觀察到的方向。

產品效應確實存在，但上限約為差距的三分之一。 本文最強的單一預測因子是 GitHub 內嵌 suggestion 區塊——有區塊的解決率為 75.5%，沒有的為 64.6%，OR 1.617——但 Cramér's V = 0.12，效果偏小。Copilot、Cursor 和 Codex 都會透過 GitHub 原生審查介面發布留言，並可一鍵套用；論文沒有任何地方描述 RovoDev 發布可套用的差異內容，只提到以行為錨定的留言。這個發布管道最多可能帶來約 11 個百分點差距，而且只能視為上限，因為本文計入的留言也並非全都帶有建議區塊。

構念差異是事件性質的不同，足以解釋剩餘差距。 Goldman 要求後續提交在某一特定行加入程式碼差異；本文只要求任何人因任何理由切換討論串旗標。兩者計算的是不同事件，且錯誤方向相反：

• Goldman 會將下列情況計為未解決：開發者同意並修正問題，但修改位置不在錨定行（例如在呼叫端修正、抽取函式或重新整理結構）；錨定行被直接刪除；或 PR 合併時沒有後續提交。研究也未設定追蹤期限：資料涵蓋 2025 年 6 至 7 月，因此資料擷取時間愈早，觀察期間末段留言遭右設限的情況就愈嚴重。以上每一種機制都會單向低估認同。
• 本文會把沒有任何程式碼變更、僅以否決關閉的討論串計為已解決；另一方面，從未標記的採納又會被漏掉——作者自己的卡片分類發現，有討論但標為未解決的案例中，24.3% 屬於 Accepted Agent Feedback。

構念舉足輕重的最明確證據，就在 Goldman 自己的類別排序之中。 可讀性（43.3%）> 錯誤（41.9%）> 可維護性（36.2%）> 設計（28.6%），恰好也是修正內容對特定行的依賴程度排序。論文從行為角度解讀設計類別較低的比例，認為設計問題「涉及更複雜的架構考量，需要更深入的理解和更廣泛的變更，因此較難解決」——卻沒有注意到，更廣泛的變更正是精確行數代理指標會漏掉的情況。論文的主要類別結果與測量工具混雜在一起；只有把兩篇論文並列，這點才顯而易見。

這項歸因的合理界限。 這是對兩種已發表構念的解讀，不是在兩個母體中以同一構念重新測量。沒有人把 Goldman 的精確行規則套用到 GitHub 討論串，也沒有人把 GitHub 旗標套用到 Atlassian 語料；任何一種比較都能更妥善拆解差距。目前可以確定的說法比知識庫原有的結論更強：兩個數字都不是採納率，而是夾住採納率範圍的上下界。 39.3% 是要求錨定位置出現差異內容的下限；71.4% 是將「不修正」也算入的處置計數。把其中任何一個稱為代理程式審查留言的「解決率」都是類別錯誤，取兩者平均則更糟。

同一來源對 LLM 審查者選擇留言內容的觀察#

Goldman 的 RQ1 與解決率是另一種測量，也有各自的限制：它比較同一個 RovoDev 代理程式與人類審查者在兩個語料中的表現，而結果不一致，因此任何一種模式都不能單獨推廣。

類別	Atlassian 內部——LLM / 人類	OSS（CuRev）——LLM / 人類
程式碼錯誤	18.2% (128/702) / 6.5% (30/465)	20.1% (253/1,256) / 18.1% (181/1,000)
可維護性	26.8% (188/702) / 19.1% (89/465)	37.9% (476/1,256) / 23.6% (236/1,000)
程式碼可讀性	33.2% (233/702) / 46.0% (214/465)	23.7% (298/1,256) / 24.5% (245/1,000)
程式碼設計	21.2% (149/702) / 19.4% (90/465)	15.7% (197/1,256) / 23.6% (236/1,000)
沒有問題	0.6% (4/702) / 9.0% (42/465)	2.5% (32/1,256) / 10.2% (102/1,000)

（圖 3 和圖 4，按影像讀取；內文只提供這二十個數值中的六個。每一欄總和都等於其分母。）

在 Atlassian 自家程式碼上，LLM 審查者提出錯誤留言的比例是人類的 2.8 倍（18.2% 比 6.5%），提出可維護性留言的比例則是 1.4 倍；人類近半數留言都聚焦可讀性。這是論文提出互補性的依據——但範圍限制很重要：只適用於 Atlassian 內部。 OSS 中，錯誤類別的優勢縮小至 20.1% 對 18.1%，設計類別的關係也顛倒，人類提出的設計留言更多（23.6% 對 15.7%）。即使在互補性成立的 Atlassian 語料中，設計類別也接近打平（21.2% 對 19.4%）；互補性主要來自錯誤和可讀性，而非設計。

兩個語料中都成立的發現是負面的，而且指向代理程式：相較於自身其他類別，LLM 審查者提出的錯誤留言偏少——在 OSS 中比可維護性低 17.8 個百分點，在 Atlassian 中比可讀性低 15.0 個百分點。這才是論文實際主張，而不是說它提出的錯誤留言比人類少。與本文 RQ1 並列來看，Cursor 和 Codex 有 88% 的已解決留言聚焦功能缺陷，解決率卻仍低於通用型 Copilot；如今語料中有兩項產業規模的測量，兩者在同一軸線上的類別組合相差一個數量級，採納率排序也不相同。類別組合看起來是產品決策，而且無法以一致方向預測採納率。

論文未提及的一項但書，削弱兩個 RQ 之間的連結。 RQ2 樣本的組成與 RQ1 不同：設計在 RQ1 的 702 則 Atlassian 留言中占 21.2%，在 RQ2 樣本中卻只占 4,000 則中的 353 則，即 8.8%；無問題留言也從 0.6% 降至 0.2%。研究窗口不同，抽樣方式也不同。因此，解決率所依據的留言組合，不等於互補性主張所描述的組合；不應將兩項結果相乘，算出「LLM 審查者的預期值」。

本文對審查有效性的問題能回答什麼、不能回答什麼#

知識庫在 Review as the Control Point 和 Security Debt of Agent-Generated Code 中持續追問：審查涵蓋率是否能提高缺陷攔截率？代理程式 PR 的審查涵蓋率正接近人類基準，但外洩憑證的實測有效性只有 18.9%。本文沒有回答這個問題，而兩者看似相似，正是陷阱。 它測量的是另一個迴圈——代理程式擔任審查者，人類負責決定——因此 71.4% 是審查層輸出的採納率，不是代理程式程式碼缺陷的攔截率。

本文補上自動化審查層表現不佳之雙面原因中的另一半，而兩半的失敗方式不同：

• 未偵測到（Security Debt of Agent-Generated Code）：針對硬編碼憑證這類氣味，已有七種商業偵測器專門設計來偵測；機器人與人類合計只對 18.9% 真正有效的憑證留下留言。這一層大多根本沒有觸發。
• 不相關（本文）：這一層一旦觸發，約十則留言中有七則會關閉；其餘留言最常見的原因，是代理程式誤解專案脈絡（23.8%），或對真實程式碼做出自信但錯誤的判斷（13.4%）。470 則有討論的案例中，只有 11 則被當作低價值雜訊駁回。

兩種失敗都不是人類疏忽。這項發現最應該改變知識庫中「開發者只是照單全收」的先驗判斷：在未解決且有討論的留言語料中，開發者仔細閱讀，足以發現代理程式的錯誤；而且這種情況更常出現在周邊貢獻者身上，他們對專案脈絡的掌握最少。

與 Efficiency Debt of AI-Generated Code 的連結最為鮮明。Tran 等人將 AI 撰寫失敗診斷為「通用型 LLM 缺乏對內部企業單一儲存庫結構的高度特定脈絡」，並建議在提示時注入儲存庫脈絡。本文測量的 AI 審查主要失敗，同樣是缺少脈絡，只是換了頂帽子——代理程式把團隊刻意決定的設計標記為缺陷。同一種脈絡落差，兩種症狀，同一項解方。

延伸閱讀#

• Closed-Loop AI Review — 這 54,713 則留言所屬的母體，以及永遠不會到達人類面前的迴圈另一半。 Selvanayagam 與 Ghaleb 統計公共 GitHub 審查端，共有 8,560,237 筆歸屬明確的審查留言項目和 4,141,107 筆審查項目，涵蓋至少有一項 AI 歸屬審查的 248,641 個代理程式撰寫 PR。這些資料有兩點與本文相互補充。規模顯示，本文衡量的採納情況來自一個規模龐大、每年成長兩個數量級的審查層，而非小眾現象。組成則使構念更複雜：其中 208,145 個 PR 由撰寫該 PR 的產品審查；在這種情況下，「解決」可能是自動化產品工作流程，而不是開發者的決定，且兩個資料集都無法區分。兩項研究都沒有衡量正確性。
• Same-Model Review Blindness — 自動化審查有效性的另一半，兩個數字不可合併。 本文衡量代理程式審查者輸出的採納率（71.4% 的留言獲得解決，並公布標註評審者的 kappa）；Greptile 衡量對照錯誤黃金標準的召回率（指出 52–62% 的高嚴重度錯誤，但沒有評審者驗證，標籤集由廠商建立，case-study）。留下的留言不等於被抓到的錯誤；抓到的錯誤也不等於留下的留言——兩者合起來首次讓人能端到端估算這個審查層：在不同語料、不同代理程式、相差兩個證據層級的資料中，大約只指出一半的嚴重錯誤，而指出的留言約有七成會被採取行動。兩者的失敗機制互補，而非相互競爭：此處不採納的主要原因是審查者缺少專案脈絡；另一處召回率不足的主要原因是審查者與作者共享相同的模型先驗。
• Review as the Control Point — 鏡像方向，也是對該理論第二個調節因子首次進行有相當規模的測量。 文中的自動化審查者能力調節因子，現在有了採納數字（依代理程式為 54.8-72.9%），也指出能力受限之處：是專案脈絡，而非正確性或文字表達。研究無法確認 P8（吞吐量）或 P9（品質／安全性），因為它兩者都沒有測量；但研究確實證明，控制留言特徵後，代理程式層級的合併差距仍然存在，這是調節因子效應，而非訊息品質效應。
• Security Debt of Agent-Generated Code — 自動化審查層的兩種失敗模式，從相反端點衡量：該文發現審查層沒有觸發（真正有效的憑證僅有 18.9% 收到留言）；本文發現審查層觸發時，約 71% 的輸出會被採取行動，剩下的問題是脈絡錯誤，而非人類疏忽。合起來看，審查層的弱點應從注意力問題重新定位為偵測與相關性問題。
• Risk-Tiered Auto-Approval — 對留言設計的獨立佐證。 StampHog 的核准是一個沒有逐行留言的 GitHub 簡單核准；拒絕則以 1-2 句話說明風險等級與後續步驟。本文測量出這種形式為何恰當：內嵌建議是解決率最強的預測因子（OR 1.62），而長度的負面影響集中於功能性意見（OR 0.855）。研究也支持將模型降為否決者而非留言者：否決者沒有解決率可失去。
• Efficiency Debt of AI-Generated Code — 撰寫端同樣缺少專案脈絡。Tran 等人將 AI 的指令式偏誤歸因於「通用型 LLM 缺乏對內部企業單一儲存庫結構的高度特定脈絡」，並建議注入脈絡；本文也發現同一落差，讓代理程式審查者在 23.8% 有討論的案例中，把刻意採用的設計標記為缺陷。這也是證據類別上的制衡：該研究有人工對照組，本文則沒有，因此「代理程式審查者是否劣於人類審查者」仍未測量。
• Acceleration Whiplash — Faros AI 記錄代理程式式審查的比例從 0% 上升至 25% 的 PR，速度快於代理程式式撰寫；本文則測量這一層的輸出是否獲採納。結果是有採納（約 71%），對加速反噬的論述稍有制衡；但合併數字中 Copilot 占 83.5%，而且兩項研究都未把審查留言採納與任何下游品質結果連結起來。
• AI as Primary Author — 監督層自動化速度快於撰寫層，是本文能夠出現的前提；本文則首次提供母體層級的數字，呈現監督層的輸出是否有人採取行動。
• Verification as the New Bottleneck — 對「全自動審查應推進到什麼程度」的採納資料：已部署的自動化審查者，其輸出約有十分之七會被採取行動；影響最大的因素是可套用的差異內容，而非更好的文字表達；AUC 0.58 則顯示決定因素大多在留言之外。
• LLM-as-a-Judge — 對 15 類程式碼審查分類器發表的校準結果：開放權重 Llama-3.1-70B 與人類黃金標準集的 kappa 為 0.74，優於 GPT-4o 的 0.70，也大幅勝過 Qwen3-8B 的 0.38；人類互評上限為 0.86。多標籤解釋分類在只保留信心度 >= 0.9 的結果後，Jaccard 達 0.90。這是依據測量一致性而非品牌選出評審者，並公布了測量結果；自 2026-09-22 起，現在又多了一組配對比較：Goldman 以 GPT-4.1 執行同一項任務，在同一項合理性檢查中對人類互評基準 0.80/0.86 得到 kappa 0.42，卻以「足夠」為由，將它用於 4,000 則留言。兩個程式碼審查留言評審者的機會校正一致性相差約 1.8 倍，卻都被報告為可接受。
• Returns to Expertise in Agentic Coding — 審查的接收端：採取設計與可演進性意見需要核心開發者（解決方案方法留言的 79.8% 由核心開發者解決）；周邊貢獻者最常出現在功能缺陷修正中（29.5%）。能讓你採用代理程式設計建議的專案知識，也能讓你推翻它。
• Optimizer–Evaluator Decoupling — 在母體規模下部署的分離案例：審查代理程式從未撰寫程式碼，其留言沒有合併權限，必須說服人類。已測得的失敗正是此種分離的代價——評估者缺乏作者的專案脈絡，23.8% 有討論的拒絕案例正是如此。
• Post-Acceptance Edit Behavior — 兩種衡量人類如何處置機器輸出的行為工具，粒度不同，卻得出同一診斷。本文約 71% 的代理程式審查留言獲得解決，最常見的真實拒絕原因是代理程式看不到的專案脈絡（23.8%）；另一篇則發現最可能遭刪除的 AI 補全內容，是那些「細微地不符合開發者意圖或程式設計脈絡」的內容。同一種脈絡不足，兩種產物。也應指出兩者共通的方法限制：兩者都只衡量採納，從不衡量正確性——留言獲得解決不等於錯誤被抓到，補全內容被保留也不代表程式碼品質良好。
• Deterministic Engineering for Agent Code Review — 採納率和召回率之外，又多了一種構念；它最容易落入本文已警告的黃金標準配對陷阱。 OpenCodeReview 以 AACR-Bench 的專家驗證參考集衡量精確率（12 種設定介於 7.23%–37.80%）——與本文 71.4% 的解決率、Same-Model Review Blindness 的 52–62% 召回率又是不同數值，三者不可合併。OpenCodeReview 自己的 §6 也承認了本文構念警告的反向版本：真正有用的留言若對不上任何黃金標準項目，就會在該研究被計為誤報，正如本文「470 則有討論的案例中只有 11 則被當作低價值」的鏡像。兩者在機制上的一致性最強——OpenCodeReview 的反思器與留言最常漏掉的原因，是差異內容以外的專案脈絡；本文也發現，這是 23.8% 有討論未解決案例背後的原因。OpenCodeReview 的有限 file_read_diff 和逐檔 SubAgents 正是為了補回這種脈絡而設計，但依據目前證據，仍未完全做到。
• Open Source Under Agent Contributions — 同一個反向迴圈，只是發生在儲存庫入口，而非 PR 內部：DHH 讓代理程式分類每個新 PR，並只回覆是否合併的決定。
• Writer/Reviewer vs Agent-to-Agent Review — 本文補上同一工作階段內 Writer/Reviewer 與 PR 留言式代理程式審查四軸比較中的採納部分；卡片分類是語料中唯一提供誤報代價資料的研究（63 則事實錯誤、4 則幻覺、470 則中 11 則被當作雜訊駁回）。比較這兩種模式時必須注意的限制：71.4% 解決率與 7.23–37.80% 參考匹配精確率相差一個數量級，兩者不能互相替代，因此只報告其中一種指標的直接比較沒有可解讀性。

開放問題#

• 470 則討論分類只抽樣了收到回覆的未解決留言——占未解決母體的 6.7%。沉默的 93.3% 是什麼原因？審查疲勞、留言量、分類處理，還是同一種脈絡錯誤，只是根本不值得爭辯？分類結果（470 則中只有 11 則被當作低價值）若套用到雜訊主導的沉默多數，看起來會很不一樣；直接抽樣沉默留言即可區分這兩種假說。**What Types of Code Review Comments Do Developers Most Frequently Resolve? 提供的脈絡（2026-09-22），但不是答案：**該研究的 4,000 則留言樣本沒有要求留言收到回覆，因此其 60.7% 未解決率涵蓋整個未解決母體，也包含沉默多數。這證明沉默多數是產業現象，而非 GitHub 禮節造成的假象。但研究對原因的唯一說法，是討論部分提出、未經測量的推測（「留言缺乏清晰度、相關性和簡潔性」）；沒有卡片分類、沒有回覆分析，也沒有沉默集合的抽樣。問題仍未解決。
• 解決代表採納，不代表正確。已解決的代理程式留言是否對應到一項原本會隨產品上線的缺陷？與沒有代理程式審查者的基準相比，代理程式審查者是否改變任何下游結果（逃逸缺陷、事故、還原率）？語料中沒有研究在審查迴圈的任何一端測量此事；這也是缺少的結果衡量，使 Risk-Tiered Auto-Approval 的吞吐量數字無法與安全性連結。狀況未變，而且自 2026-09-22 起證據加倍：What Types of Code Review Comments Do Developers Most Frequently Resolve? 以產業規模測量同一個迴圈，但使用的構念離正確性更遠，而非更近——後續提交只要修改精確位置的程式碼行就算解決，不管留言是否造成這項修改，因此熱門行上的無關變動也會算成認同；該研究同樣未測量下游結果。兩項產業規模研究，兩種不相容的構念，兩者都沒有正確性的黃金標準。

已解決問題#

• 兩項相隔一年的 empirical 研究，在核心數值上相差約兩倍：Goldman 等人（ASE 2025）報告 LLM 生成的審查留言有 60-70% 未解決，本文報告 71.4% 已解決。差距來自母體（產業與開源 GitHub）、產品（內部管線與附帶一鍵建議區塊的商用代理程式），還是構念（Goldman 計算的事件，與本文自己的卡片分類顯示低估約 24% 的 GitHub 討論串旗標）？2026-09-22 由 What Types of Code Review Comments Do Developers Most Frequently Resolve? 回答：差距來自構念。 換算成相同尺度後，Goldman 是 39.3%（1,571/4,000，依圖 5 還原，因為論文沒有公布整體比例），本文是 71.4%：相差 32 個百分點，而非兩倍。差距方向排除了母體因素——Goldman 的 1,007 個內部儲存庫皆由相當於核心開發者的領薪員工組成，而本文 RQ2 顯示核心開發者解決率較高，因此全核心開發者母體預測的數字應該更高，但 Goldman 的數字較低。產品效應上限約為 32 個百分點中的 11 個百分點——本文測得內嵌建議留言為 75.5%，無建議為 64.6%，Cramér's V = 0.12；RovoDev 沒有發布可套用的差異內容。剩下的是構念，而且兩者測量的事件性質不同：「後續提交修改留言所在的精確行」是一種錨定行的程式碼差異事件，會漏掉所有行外修正、所有遭刪除的錨定行，以及追蹤期限未明而被右設限的留言；GitHub 的 isResolved 是處置旗標，會把否決算入，卻漏掉未標記的採納。Goldman 自己的資料也證實了這點：他的類別排序（可讀性 43.3% > 錯誤 41.9% > 可維護性 36.2% > 設計 28.6%）恰好是修正對特定行的依賴程度排序；他解釋設計類別較低時又說設計需要「更廣泛的變更」——精確行數代理指標正是無法捕捉這種情況。**後續仍須保留但書：**這是對兩種構念的解讀，並非在兩個母體中以同一構念重新測量，因此產品與構念各自占多少差距，只是論證結果而非估計值。穩健的結論是兩個數字為採納率劃出範圍，而非估計採納率，任何一個都不能被當成「唯一正確」的解決率。完整論證見上文對照調和：本文與它引用的研究。

資料來源#

• developer responses agent review comments — Shamse Tasnim Cynthia、Ratnadira Widyasari、Banani Roy、Ting Zhang 與 David Lo（University of Saskatchewan / Singapore Management University / Monash，arXiv 2607.21997，2026-07-24），empirical。§III（資料蒐集、依審查者登入模式識別代理程式、排除 Devin/Claude、核心／周邊定義、LLM 標註器選擇與 kappa/Jaccard 驗證、有用性構念）；§IV + 表 III + 圖 3（解決率和各代理程式類別分布）；§V + 表 IV + 表 V + 圖 4（核心／周邊區分與十種討論模式分類）；§VI + 表 VI-VIII（依程式碼建議、長度、品質分數與解釋類型分析有用性；邏輯迴歸）；§IX（效度威脅——AUC 0.58 的坦承和解決率代理指標的讓步）。 解析警告：原始資料由 docling 解析，verify: warn 並帶有 table-collapse，而且這項旗標確實正確。 表 V（討論分類）同時受到兩種損壞——Agent Hallucinated 標籤與下一列標籤黏在一起，變成 Agent Hallucinated Challenging Agent Feedback；它的三個數值則黏進前一列的儲存格（| Factually Wrong or False Positive | 63 4 | 29 3 | 34 1 |）；此外，Suggestions Deferred 的括號內容也移到了 Future Improvement 列。若照解析結果閱讀，Agent Hallucination 子類別會消失，39 則討論的「父類別」也成了假象。本文引用的表格是透過執行 pdftotext -f 7 -layout 還原，並獨立核對：子列加總等於父類別、核心加周邊等於各列總數、各代理程式三項數值加總等於各列總數，466 則可分類加 4 則無法分類等於所述 470；而且 §V 內文所有代理程式百分比（Cursor 32%、Copilot 21.4%、Codex 15.5%，以及 Incorrect Suggestion 的三組數值）都可從還原表格重新計算。其他七張表也以相同方式交叉核對：表 III、IV、VI 和 VII 忠實呈現原文，且算術自洽；表 I 的外觀遭黏合（docling 顯示 12 列，另有一個孤立的 software 儲存格，而 PDF 和內文所述一致，實際是 15 個類別——描述仍保留，因此沒有數字受影響）；表 VIII 的兩列分段標題（Functionability issue、Evolvability issue）被散落至全部四欄，資料列則正確。 **論文內有四處前後不一致，並非解析造成，已對照 PDF 確認：**摘要中的「多數已解決留言（72.9%）」混淆解決率與占比；§III 說分析「限制在 2023 年 12 月以前建立的 PR」，但儲存庫篩選條件要求 PR 建立於 2024 年 12 月之後，所有引用範例 PR 也來自 2024-2025；RQ3 答案框把程式碼建議 OR 寫成 1.609，而表 VIII 是 1.617、內文是 1.62，另列出不成範圍的「OR range: 0.77-0.134」；表 VI 的可演進性無建議儲存格寫成 67%，但 6807/9873 是 69.0%。這些都不影響本文引用的內容。圖 3、4、5、6、7 含有內文未完整列出的各類別分布；本文引用的圖 3 與圖 4 數值，取自 pdftotext -layout 的座標軸標籤，而非目視圖表估算。
• What Types of Code Review Comments Do Developers Most Frequently Resolve? — Saul Goldman、Hong Yi Lin、Patanamon Thongtanunam（The University of Melbourne）；Jirat Pasuksmit、Kla Tantithamthavorn（另任職 Monash）、Zhe Wang、Ray Zhang、Ali Behnaz、Fan Jiang、Michael Siers、Ryan Jiang、Mike Buller（Atlassian, Australia）；Minwoo Jeong、Ming Wu（Atlassian, USA）。arXiv 2510.05450 v1，2025-10-06，6 頁，ASE 2025。empirical——證據等級有依據：1,007 個正式上線儲存庫、3,746 個真實 PR 中的 4,000 則真實 LLM 生成留言，解決情況依實際後續提交計算。§III-B/C（五類分類法與 GPT-4.1 評審者）；§IV RQ1 + 圖 3-4（Atlassian 內部與 OSS/CuRev 的人類與 LLM 留言類型分布）；§IV RQ2 + 圖 5（解決率和解決構念原文）；§VI（效度威脅——RovoDev 專有架構揭露，以及 13 個 OSS／1,007 個內部儲存庫的範圍說明）。 利益衝突已揭露，而且影響研究解讀。 15 位作者中有 12 位是 Atlassian 員工，受研究的 LLM 審查者是 Atlassian 自家的 RovoDev Agent；論文也明確聲明，研究結果「不應被解讀為對 Atlassian 所提供產品品質的評估」。這是產品供應商自行測量自家產品；較能支撐其可信度的是主要發現並不討喜（自家代理程式有 60.7% 留言未獲解決）。RovoDev 的架構和提示被宣告為機密，因此無法重現介入方法。分類層使用 GPT-4.1 評審者；它對兩位標註者黃金標準集的 Cohen's kappa 為 0.42（中度），而同一檢查中兩位人類評審彼此的一致性為 0.80 和 0.86——大約只有標註者互評一致性的一半，卻只用「足夠」一句話作為理由接受。底層分類法本身完全沒有評分者間一致性數據：六位 Atlassian 工程師在單次會議中協力分類 336 則留言，論文明確表示「無法計算 kappa」。 解析註記：docling 解析文字正確（6 頁、信心度 excellent、canary-recall 6/6、一個表格），但圖說連結錯誤，而且錯得不易察覺。 原始 Markdown 把 image_000001 和 image_000002 都放在「Fig. 3」圖說之下，把 image_000003 放在「Fig. 4」之下，而「Fig. 5」圖說下面完全沒有圖片。閱讀四張圖片後確認，正確對應為：image_000001 = 圖 3（Atlassian RQ1）、image_000002 = 圖 4（OSS RQ1）、image_000003 = 圖 5（RQ2 解決率）。若相信 Markdown，讀者會把解決圖表誤認為圖 4，並以為圖 5 遺失。各欄分別加總至所述分母（702、465、1,256、1,000、4,000），證實此對應；內文兩項差值也完全吻合圖表：「OSS 低於可維護性 17.8%」是圖 4 的 37.9 − 20.1；「Atlassian 內部專案低於程式碼可讀性 15%」是圖 3 的 33.2 − 18.2。圖 5 是最關鍵的還原結果：它提供內文略過的設計比例（101/353）和無問題列（2/8）；其五列加總為 4,000，可算出論文全篇未提到的整體解決率 1,571/4,000 = 39.3%，而本文的調和分析正是以此數字為核心。表 I（分類法）解析忠實，只含定義，本文未從中引用任何數字。 另有一處論文內部錯誤，已對照兩張圖確認，不是解析造成。 OSS 結果段落寫著「LLM 審查者產生的無問題留言少於人類審查者，只有 0.6% 屬於無問題，相較於人類的 9.0%。」這些是圖 3 的 Atlassian 數值（4/702 = 0.6%；42/465 = 9.0%）。圖 4 的 OSS 實際數值是 2.5%（32/1,256）和 10.2%（102/1,000）——主張方向仍成立，但所引用的數值屬於另一個語料。本文表格採用圖表數值。
• AI-to-AI Code Reviews of GitHub Pull Requests — Selvanayagam 與 Ghaleb（ÉTS Montréal / Trent），arXiv 2608.21311，2026-08-21，15 頁，ESEM 2026 Emerging Results track，empirical。本文只引用其規模與組成：§3.2 的歸屬審查串流（12 個審查者端代理程式，共 4,141,107 筆審查項目、8,560,237 筆審查留言項目）；§4.1 的 248,641 個至少有一項 AI 歸屬審查的代理程式撰寫 PR；以及 §4.3 + 表 2 的同產品多數情況。該研究測量留言數量和自我標示的類別標題，從未測量採納或正確性，因此既沒有重現，也沒有駁斥 71.4% 或 39.3%。表格已在編譯時對照 pdftotext -layout 核對。完整分析見 Closed-Loop AI Review