Merge 不是終點：四篇研究追蹤 agent PR 合併後的 30 天，發現我們一直在量錯東西

瀏覽次數: 19

本文大綱

這篇文章適合你，如果你是…

在團隊推 coding agent 的技術主管：你的周報裡有一欄「agent PR 合併率」，老闆看到 80% 很開心。這篇要告訴你那個數字到底量到了什麼，又漏掉了什麼。
每天讓 agent 開 PR 的工程師：你按 merge 的速度越來越快，因為它幾乎都對。這篇給你看合併之後 30 天發生的事，以及哪一種 PR 該多看一眼。
正在比較 Codex、Devin、Copilot、Cursor、Claude Code 的採購決策者：你需要的是分 vendor 的合併後數據，不是行銷頁上的 SWE-bench。

1. 前言：問題場景（約 600 字）

Hook 開場

我們自己的內容 repo 有一個排程，每天會讓 agent 產出內容、commit，然後直接 push 到 main。它跑了好幾個月，大部分時候都很順。順到某一天我發現，我對「它推上去之後發生什麼事」幾乎沒有任何數字。我知道它每天都有推，也知道 CI 是綠的。但哪些 commit 隔週被我手動改回來、哪些被下一次排程的 agent 自己蓋掉，我說不出來。

這不是我一個人的盲點，是整個業界衡量 agent 的方式有結構性的缺口。我們看 agent 好不好，看的幾乎都是「合併前」的訊號：benchmark 解決率、PR 合併率、review 通過率。但從系統角度看，merge 只是一次狀態轉移，程式碼真正開始被使用、被依賴、被修改，是在 merge 之後。一個只在入口量測的系統，等於只看了出貨數，沒看退貨率。

數據佐證

**** Stack Overflow 在 2026 年 10 月 6 日發布的年度開發者調查（超過 30,000 人填答）顯示：有在用 AI coding 工具的人裡，73% 每天用，31% 每天用超過 4 小時。但用 AI 來部署、維運、排查生產系統的只有 20%。

翻成白話：agent 寫的程式碼每天大量流進主幹，但主幹之後的那一段，幾乎沒有 agent 在看，也很少有人在量。

解決方案預告

2026 年 9 月到 10 月初，剛好有四篇實證研究不約而同地把鏡頭轉向「合併之後」。每一篇只看生命週期的一段：誰來修、效能宣稱有沒有兌現、revert 率依 vendor 差多少、agent 怎麼證明自己。把它們接起來，你會得到第一張 agent PR 完整生命週期的地圖，以及一個有點不舒服的結論。

文章承諾

四篇論文的一手數字（不是新聞轉述），附資料窗口與限制
「merge 量到的其實是信任，不是品質」的證據鏈
反向證據：哪些 agent 在哪些面向比人類好
一張可以明天就開始追的 post-merge 指標表，附一段計算修補率的腳本

讀者收穫

讀完這篇文章，你將能夠：

說清楚為什麼「agent PR 合併率」不能當 KPI 或採購依據
在自己的 repo 建立 30 天修補率與 revert 率的基準線
找出哪一類 agent PR 該在合併後加強監控
對效能類 PR 設一道「宣稱必須可重現」的門檻

TL;DR

Agent PR 合併後 30 天被「確認修補」的勝算是人類 PR 的 1.62 倍，一半發生在第一週
修它的 69.6% 還是同一個 agent，76.4% 的修補 PR 沒有任何人類 commit
30 個已合併的效能修補重跑後，9 個沒變快或變慢，14 個改了沒被測到的行為
合併與否最強的預測變數是 repo 對 agent 的既往信任（33% → 84%），不是程式碼內容
反過來，Codex 的 revert 率只有人類一半：要分 vendor 看，更要看合併之後

2. 核心概念：把 merge 當成一台測量儀器（約 700 字）

一個比喻：入學考 vs 畢業率

PR 合併率很像大學的錄取率。錄取率高，可能是學生優秀，也可能是學校門檻低、或是考官跟這個學生很熟。你要知道學生到底好不好，得看他入學之後的表現：有沒有被當、要不要補修、畢不畢得了業。

PR 的「入學之後」就是 post-merge。四篇研究分別量了三種「入學之後」的訊號：

訊號	意思	觀察窗口
驗證修補（verified fix）	之後另一個 PR 被確認是在修這個 PR 引入的問題	30 天
Revert	這個 PR 被整個撤回	90 天
宣稱重現（claim reproduction）	PR 說「快 3 倍」，重跑之後測到多少	即時重跑

這些研究從哪裡來：AIDev 資料集

四篇中有三篇建立在同一個資料集上：Queen's University 的 AIDev（Hao Li、Haoxiang Zhang、Ahmed E. Hassan）。它目前收錄 932,791 個由 agent 開出的 PR，橫跨 116,211 個 repo、72,189 位開發者，涵蓋 OpenAI Codex、Devin、GitHub Copilot、Cursor、Claude Code 五個 agent。因為 agent 開的 PR 在帳號或 commit 簽名上可辨識，研究者才有辦法大規模追蹤「agent 寫的那段 code 後來怎麼了」。

必須先講的時效限制

**** 這批資料的 agent PR 主要落在 2024 年 12 月到 2025 年 7 月（其中一篇延伸到 2025 年 10 月，另一篇到 2026 年 6 月）。也就是說，研究看到的是「上一代」的 Codex、Devin 和 Claude Code。

所以這篇文章不會告訴你「今天的 agent 就是這麼爛」。我要講的是另一件事：這些研究揭露的，主要是測量方法的問題。模型會變強，但如果你的團隊還是只看合併率，你就永遠不知道它變強了多少，或是在哪裡變弱了。

關鍵術語

術語	英文	說明
Agentic PR	Agentic pull request	由自主 coding agent 開出的 PR
候選修補	Candidate fix	30 天內同 repo、標為 fix、動到同檔案的合併 PR（啟發式找出）
驗證修補	Verified fix	候選修補中，經人工或 LLM judge 確認「直接修補原 PR 問題」者
自我合併	Self-merge	操作 agent 的人自己按下 merge
Post-merge churn	—	合併後新增程式碼被再修改的比例

視覺素材 #1：agent PR 生命週期時間軸（開 PR → review → merge → 7 天 → 30 天 → 90 天），每一段標上對應研究的關鍵數字

3. 深度拆解：四篇研究，四段生命週期（約 2,300 字）

3.1 合併之前：被拒的理由看不見，合併的理由不是品質

研究：Peralta 等人，Why Are Agentic Pull Requests Merged or Rejected?（arXiv 2605.22534）；Qi 等人，Merged, Not Measured（arXiv 2609.37985）

先看被拒的 PR。Peralta 團隊從 11,048 個已關閉的 agent PR 中，挑出 717 個人工逐一檢視拒絕原因。結果：

只有 35.7% 是明確的 agent 失敗
31.2% 是流程限制，例如同一個 issue 已經被別的 PR 解掉、不符貢獻規範
33.1% 根本看不到決策理由

Qi 團隊在效能類修補上看到更極端的數字：被拒的 agent PR 有 61% 沒有給任何理由；在 24 小時內直接被關的那一類，86% 沒有任何文字。

那合併的呢？這是整篇最關鍵的發現。Qi 團隊分析了 1,105 個已關閉的效能修補，發現合併率在 agent 之間差很大：Codex、Claude Code、Jules 都是 73%，Copilot 50%，Cursor 42%，Devin 30%。

但先別急著排名。他們同時發現：Codex、Cursor、Claude Code 的已合併修補中，有 81% 到 95% 是操作 agent 的人自己按 merge。Copilot、Devin、Jules 則是以 bot 帳號開 PR，需要別人核准。合併率的高低，很大一部分反映的是「誰有權按 merge」。

更進一步，他們用 logistic 迴歸找合併的預測變數：

預測變數	接受率變化
該 agent 在這個 repo 的過往紀錄	31–37% → 70%
這個 repo 對其他 agent PR 的既往合併率	33% → 84%
修補內容（唯一穩定的內容變數：刪除行佔比）	合併的刪了 26% 變更行，被拒的 15%

說白了：一個 agent PR 會不會被合併，最好的預測方式不是看它寫了什麼，而是看這個 repo 以前有多信任 agent。

**** 這在系統設計裡有個名字：自我強化的回饋迴圈。repo 越常合併 agent PR，下一個 agent PR 就越容易被合併，不管它本身品質如何。合併率在這個迴圈裡不是品質的測量，而是信任的累積。

視覺素材 #2：合併率 vs repo 既往信任度的階梯圖（33% → 84%）

3.2 合併之後 30 天：誰來收尾？

研究：Takerngsaksiri、Duong、Barnett（Deakin University），Who Finishes the Job?（arXiv 2609.26847，投稿 Empirical Software Engineering）

這篇追蹤了 891 個 repo（≥500 stars）裡 6,774 個已合併的 agent PR，以及同 repo 的 5,044 個人類 PR，問一個簡單的問題：合併後 30 天內，有沒有另一個 PR 回來修它？

方法上，研究者先用啟發式找「候選修補」（30 天內、標為 fix、動到同一個檔案），再用人工標註和 LLM judge 確認哪些是「直接修補原 PR 引入的問題」。人工標註一致率 90%（Cohen's κ 0.77），Claude Opus 當 judge 與人類 κ 0.78。

Before/After 對比（Tier 3）：同一批 repo、同一段時間，人類 vs agent

	人類 PR	Agent PR
30 天內候選修補	14.7%	20.9%
30 天內驗證修補	2.34%	3.68%
驗證修補勝算比	基準	1.62 倍（95% CI 1.10–2.39）

依 agent 拆開，驗證修補率從 Claude Code 的 3.2% 到 Codex 的 5.5%（Claude Code 樣本只有 63 個，要保留解讀）。兩組都有一個共同模式：30 天內的修補，一半發生在第一週。

先講清楚比例感：4.5% 的驗證修補率，代表 95% 以上的 agent PR 在 30 天內沒有被確認需要修。這不是「agent code 大多要重寫」，而是「比人類多一截」。

真正讓我停下來的是 RQ2 和 RQ3：

修補 agent PR 的人是誰？69.6% 是同一個 agent，人類只佔 27.4%。Copilot 的自修比例高達 95.0%。
修補 PR 本身的 commit 呢？平均 87.4% 是 agent 寫的，76.4% 的修補 PR 從頭到尾沒有一個人類 commit。
對照組：人類 PR 的修補，89.1% 由人類完成。

**** 這代表錯誤迴圈正在 agent 內部閉合。agent 寫了一個 bug，agent 發現它（或被 issue 指派），agent 修掉它，人類按 merge。整個過程中，人類看到的是兩個綠色的 PR，而不是「這個模組在一週內被同一個工具改了兩次」。這跟我們之前寫過的「理解負債」是同一個機制，只是這次有了量化證據。

最後是 RQ4：合併當下，有沒有訊號能預測之後要修？

合併時的訊號（增加 10 倍）	驗證修補勝算比	p
PR 的 commit 數	6.1 倍	<0.001
Review 項目數	2.4 倍	0.022
首次推送後的 churn	1.3 倍	<0.001
Review 花的時間	無顯著關係	0.18

commit 來回越多次的 PR，合併後越可能要再修。review 花多久則完全不影響。 這對 review 流程是很直接的啟示：拉扯很久終於過關的 agent PR，不代表它被審得更徹底，反而是要在合併後加強監控的那一批。

視覺素材 #3：「誰修 agent 的 PR」圓餅圖（同 agent 69.6% / 人類 27.4% / 別的 agent 3.0%），對照人類 PR 的修補分布

3.3 效能宣稱：說快 3 倍，重跑之後呢？

研究：Qi 等人，Merged, Not Measured（arXiv 2609.37985）；Peng、Calvo、Kalu、Davis（Purdue），How Do Coding Agents Optimize Software…（arXiv 2610.03969）

效能 PR 是最適合檢驗的類別，因為它的宣稱可以量。Qi 團隊做了一件少見的事：真的把 PR 拿去容器裡重跑。

已合併的 30 個效能修補，用 S/M/L 三種工作量、每個版本 12 次交錯執行、Mann-Whitney U 檢定與 Cliff's δ 效果量，門檻是中位數至少改善 5% 且統計顯著：

結果	數量
達到宣稱的效能改善	18
有改善但低於宣稱	3
沒有顯著改善，或變慢	9
在沒被測到的輸入上改變了行為	14

（後兩列可重疊，一個 PR 可以同時沒變快又改了行為。）

30 個裡有 9 個合併進去的「效能優化」沒有讓任何東西變快，而將近一半偷偷改了某些輸入的行為，只是剛好沒有測試覆蓋到。

他們也重跑了 23 個被拒的效能修補：6 個重現了宣稱、4 個部分重現、13 個重現失敗，測到的加速中位數只有 1.02 倍。有幾個例子很有畫面：

rsbuild 的一個路徑去重函式，宣稱快 2 到 7 倍，1,000 條路徑時實際只有原本的 0.40 倍速度
opteryx 把 LIMIT 移到 projection 上方，1,000 列的查詢慢了 80 倍
vibetunnel 的 debounce 在突發流量時減少 75% 更新，但在穩定串流時讓動畫卡住 4 秒

被拒的大多被拒得有道理，但已合併的也不見得兌現了。合併決策沒有在做測量的工作。

Peng 團隊從另一個角度補上「agent 怎麼證明自己」。他們配對了 1,130 個 agent 與 1,130 個人類的效能 PR，橫跨 2024 年 12 月到 2026 年 6 月：

	Agent	人類
合併率	54.4%	73.3%
合併所需時間（中位數）	4.99 小時	19.16 小時
有提供某種驗證	82.3%	80.6%
主要證據是靜態推理（「這樣寫應該比較快」）	51.4%	39.3%
主要證據是 benchmark	46.1%	57.2%
有驗證的 PR 中附量化數字	50.9%	52.4%

兩個重點。第一，兩邊都有一半「說有驗證」的 PR 沒有任何數字，這不只是 agent 的問題。第二，人類會分辨改動類型：純重構類改動附驗證 73.5%，動到資源的改動 82.8%。agent 不分：83.0% 對 81.7%。agent 的驗證段落比較像是一個格式，而不是一個判斷。

視覺素材 #4：30 個已合併效能修補重跑結果的 waffle chart（18 / 3 / 9，疊加 14 個行為改變標記）

3.4 合併後 90 天：不是所有 agent 都一樣

研究：Kraishan，Not All Agents Are Equal（arXiv 2609.17598）

前面幾篇如果讓你覺得「agent code 就是比較差」，這篇會把你拉回來。它分析了 2,807 個 repo 中 37,623 個 PR，按 vendor 拆開看 90 天內的 revert 率：

Agent	Revert 率	對人類勝算比
OpenAI Codex	6.1%	0.50
Claude Code	10.5%	0.90（不顯著）
Cursor	11.4%	1.00
人類	11.5%	基準
GitHub Copilot	12.5%	1.10（不顯著）
Devin	14.5%	1.31

最好和最差之間差了 2.6 倍。Codex 的 PR 被 revert 的比例只有人類的一半；pooled 起來，agent 程式碼含安全 smell 的比例也比人類低（勝算比 0.63），主要是 hardcoded credentials 和 eval 類寫法少很多。

也有讓人在意的訊號：Claude Code 的 PR 中位數 495 行（其他約 60 行），安全 smell 率 9.5%，等第一個人類 review 的中位數是 12.6 小時，其他 agent 是 1 到 4 小時。大 PR 難審，這在人類身上也成立。

作者的結論很直接：採購決策要分 vendor 看，pooled 的「AI 程式碼」平均數會把關鍵差異抹掉。

視覺素材 #5：五個 agent + 人類的 revert 率森林圖（勝算比 + 95% CI）

3.5 好消息：行為正在改變

**** Peng 團隊的時間序列給了一個正面訊號：agent 用 benchmark 證明效能的比例，從 2025 年第二季的 31.6% 升到 2026 年第二季的 60.1%，已經追上人類（57% 到 59%）。

**** 我的解讀是，agent 的「格式」學得很快，只要訓練資料和 harness 開始要求 benchmark，它就會附 benchmark。這也是為什麼我認為重點在團隊的測量制度：你要求什麼，它就會交什麼。你只看合併率，它就會優化合併率。

4. 決策框架：從合併率換成 post-merge 指標（約 750 字）

結論先講

把四篇接起來：

合併率反映的是「誰按 merge」和「repo 多信任 agent」
review 花多久跟合併後要不要修無關
合併後的修補，大多是同一個 agent 自己完成，人類看不到
已合併的效能修補有三成沒變快
vendor 之間差異大到 pooled 平均沒有意義

所以 merge 這台儀器量到的是信任。信任很重要，但它不是品質。

Post-merge 指標表

指標	怎麼量	健康警訊	依據
7 天修補率	合併後 7 天內，有 fix PR 動到同檔案	明顯高於人類 PR 基準	Who Finishes the Job（一半事件在第一週）
30 天驗證修補率（分作者類型）	fix PR 明確連回原 PR	agent / 人類比 > 1.5	同上
修補 PR 的人類 commit 佔比	修 agent PR 的 PR 中，人類 commit 比例	長期接近 0	同上 RQ3
90 天 revert 率（分 vendor）	revert commit 連回原 PR	單一 vendor 明顯高於其他	Not All Agents Are Equal
效能宣稱重現率	宣稱加速的 PR，CI 跑 base vs head	測量值 < 宣稱值 50%	Merged, Not Measured
自我合併比例	開 agent 的人自己 merge 的比例	高且無第二位 reviewer	同上

決策樹

這個 agent PR 要不要加強監控？
│
├─ commit 數 / review 項目數明顯偏高？
│    └─ 是 → 合併後 7 天標記觀察（commit ×10 = 修補勝算 ×6.1）
│
├─ PR 宣稱效能改善？
│    ├─ 有附 base vs head 數字且 CI 可重跑 → 正常流程
│    └─ 只有「應該比較快」的文字 → 不合併，要求 benchmark
│
├─ 這是在修另一個 agent PR？
│    ├─ 第一次修 → 正常流程
│    └─ 同一區域第二次以上 → 強制人類 review，不讓 agent 自修
│
└─ 開 PR 的人就是要按 merge 的人？
     └─ 是 → 至少一位非操作者 reviewer

場景案例

場景 A：10 人新創，全員用 Claude Code，PR 由開發者自己 merge

需求：速度優先，沒有專職 reviewer
推薦：只做兩件事，fix PR 必填 Fixes-PR: trailer，加上每月跑一次修補率腳本
理由：自我合併是常態時，合併率完全沒有資訊量；修補率是最便宜的品質訊號

場景 B：中型團隊，Copilot coding agent 以 bot 帳號開 PR

需求：bot PR 很多，review 疲勞
推薦：依 commit 數分流，高 commit 數 PR 合併後加 7 天觀察 tag；監控自修比例
理由：Copilot 自修比例 95%，迴圈最容易在 agent 內部閉合

場景 C：企業採購，評估兩家 agent vendor

需求：要一個可比較的品質指標
推薦：PoC 期間至少跑 90 天，分 vendor 記 revert 率與 30 天修補率，不採用 vendor 自報的合併率
理由：vendor 間 revert 勝算比從 0.50 到 1.31，差 2.6 倍

場景 D：效能敏感的基礎設施 repo

需求：agent 常送「優化」PR
推薦：CI 強制 base vs head benchmark，加 property-based 或 differential test 覆蓋邊界輸入
理由：30 個已合併效能修補中 14 個改了未測行為

視覺素材 #6：決策樹流程圖
視覺素材 #7：「合併率 vs post-merge 指標」對照卡

5. 實戰最佳實踐（約 500 字）

常見錯誤	正確做法
把 agent PR 合併率放進周報當 KPI	換成 30 天驗證修補率與 90 天 revert 率，分 vendor、分作者類型
用「AI 程式碼」的平均數做採購	每個 agent 分開記帳，PoC 至少 90 天
讓 agent 一直修自己的 PR	同一區域第二次修補強制人類 review
接受「我已驗證效能」的文字	要求數字，並在 CI 重跑 base vs head
拉扯很久的 PR 終於過了就放心	commit 數多的 PR 合併後反而要加強觀察
開 agent 的人自己 merge	至少一位非操作者 reviewer
只靠既有測試把關效能改動	加 property-based / differential test 覆蓋沒測過的輸入

**** 還有一個研究裡的小發現值得記住：刪除行佔比是唯一跨 agent、跨 repo 都穩定的合併訊號。被合併的修補刪掉的程式碼比例明顯更高（26% vs 15%）。如果你在寫 agent 的指令，「優先用刪除和簡化解決問題」不是風格偏好，是有數據撐的。

6. 實作：算出你自己 repo 的 30 天修補率（約 400 字）

前提：團隊約定 fix PR 在描述中寫 Fixes-PR: #123。沒有這個約定的話，可以先用論文的啟發式（30 天內、同檔案、標題含 fix）抓候選，再人工抽查。

# post_merge_fix_rate.py
# 依賴：Python 3.10+、GitHub CLI (gh) 已登入
# 用法：python post_merge_fix_rate.py owner/repo
import json, re, subprocess, sys
from datetime import datetime, timedelta

REPO = sys.argv[1]
AGENT_MARKERS = ("Co-Authored-By: Claude", "codex", "copilot", "devin", "cursor")

def gh(args):
    out = subprocess.run(["gh", *args], capture_output=True, text=True, check=True)
    return json.loads(out.stdout)

# 抓最近 500 個已合併 PR（含 body、作者、commit 訊息）
prs = gh(["pr", "list", "-R", REPO, "--state", "merged", "--limit", "500",
          "--json", "number,title,body,author,mergedAt,commits"])

def is_agent(pr):
    text = (pr["body"] or "") + " ".join(c["messageBody"] for c in pr["commits"])
    login = pr["author"]["login"].lower()
    return any(m.lower() in (text.lower() + login) for m in AGENT_MARKERS)

merged_at = {p["number"]: datetime.fromisoformat(p["mergedAt"].replace("Z", "+00:00")) for p in prs}

# 建立「被修補」對照：fix PR 的 body 裡寫 Fixes-PR: #N，且在 N 合併後 30 天內合併
fixed = set()
for p in prs:
    for n in map(int, re.findall(r"Fixes-PR:\s*#(\d+)", p["body"] or "")):
        if n in merged_at and merged_at[p["number"]] - merged_at[n] <= timedelta(days=30):
            fixed.add(n)

for label, group in (("agent", [p for p in prs if is_agent(p)]),
                     ("human", [p for p in prs if not is_agent(p)])):
    if group:
        rate = sum(p["number"] in fixed for p in group) / len(group)
        print(f"{label:6s} n={len(group):4d}  30-day fix rate={rate:.1%}")

注意：最近 30 天內合併的 PR 觀察窗口還不完整，正式計算時要排除；agent 辨識依賴你的 commit trailer 習慣，請依團隊實際情況調整 AGENT_MARKERS。

7. 工具與資源（約 250 字）

AIDev 資料集：arXiv 2602.09185，目前最大的 agent PR 公開資料集，可在 Hugging Face 取得
Who Finishes the Job 複現包：github.com/wannita901/pr-fix-authorship，含候選修補連結與 LLM judge 流程
GitHub CLI：cli.github.com，上面腳本的基礎
hyperfine：github.com/sharkdp/hyperfine，CLI 層級 base vs head 計時
benchstat：pkg.go.dev/golang.org/x/perf/cmd/benchstat，Go benchmark 的統計顯著性比較
pytest-benchmark / criterion.rs：Python 與 Rust 的 benchmark 工具，可接進 CI
Hypothesis：hypothesis.works，Python property-based testing，用來覆蓋「沒被測到的輸入」

8. 總結與展望（約 400 字）

一表看完

生命週期	研究	關鍵發現
合併前	Peralta 等 / Qi 等	被拒理由 33–61% 不可見；合併最強預測是 repo 信任（33% → 84%）
合併後 30 天	Takerngsaksiri 等	驗證修補勝算 1.62 倍；69.6% 由同一 agent 修；一半在第一週
效能宣稱	Qi 等 / Peng 等	30 個已合併中 9 個沒變快、14 個改了未測行為；一半驗證沒數字
合併後 90 天	Kraishan	revert 勝算比 0.50（Codex）到 1.31（Devin）；agent 安全 smell 較少

按讀者類型的建議

工程師：fix PR 寫上它在修哪個 PR；效能 PR 一律附數字
技術主管：把周報裡的合併率換成 30 天修補率；設自修上限
採購決策者：分 vendor、跑 90 天、自己量

未來趨勢

Agent 開始維護 agent 的程式碼：69.6% 的自修比例只會更高，「這段 code 的 owner 是誰」會變成真實的組織問題。論文作者也提出了一個沒人回答過的問題：當寫這段 code 的模型被下架，誰來接手？
驗證會從文字變成產物：benchmark 採用率已從 31.6% 升到 60.1%，下一步是 CI 自動重跑、宣稱值與測量值自動比對。
Post-merge 觀測會變成 agent 平台的標配：Stack Overflow 調查中只有 20% 把 AI 用在生產維運，這段空白是下一個工具戰場。

今天就可以開始的三步

在團隊的 PR 範本加一行 Fixes-PR: #
下週跑一次上面的腳本，拿到你的第一個基準線
在 CI 加一個規則：PR 標題或描述含「faster / 優化 / speed up」時，必須附 benchmark 輸出

金句

「Merge 量到的是信任，不是品質。」

「Review 花多久，跟合併後要不要修無關；commit 來回多少次，才有關。」

「當 agent 修的是 agent 寫的 bug，人類只會看到兩個綠色的 PR。」

延伸思考

你的團隊現在能說出「上個月合併的 agent PR，有幾個在 30 天內被修過」嗎？如果不能，是缺資料，還是缺約定？
在你的 repo 裡，按下 merge 的人，和開 agent 的人，通常是同一個人嗎？
如果明天 agent 的合併率從 80% 掉到 60%，你會覺得它變差了，還是 reviewer 變嚴了？你有辦法分辨嗎？

10. FAQ（約 450 字）

Q1：這些研究是不是證明 agent 寫的程式碼比人類差？
不是。驗證修補勝算是人類的 1.62 倍，但絕對值是 3.68% 對 2.34%；Codex 的 revert 率還只有人類的一半。研究證明的是「合併率無法告訴你品質」，以及 vendor 間差異很大。

Q2：資料是 2025 年的 agent，現在還適用嗎？
數字會變，測量問題不會。三篇的主要資料窗口是 2024 年 12 月到 2025 年中，Peng 等人的資料到 2026 年 6 月，並顯示 agent 的 benchmark 採用率一年內翻倍。請把它當成方法論的警訊，然後量你自己的 repo。

Q3：為什麼 Claude Code 的修補率最低但安全 smell 最高？
樣本小（修補研究只有 63 個 PR）、PR 大（中位數 495 行）。大 PR 會讓 smell 偵測數變多，也會讓 review 變慢。論文自己也提醒這兩者混在一起，不宜直接比較。

Q4：Codex 合併率高，是因為它比較好嗎？
部分是。但 Qi 等人發現 Codex、Cursor、Claude Code 的已合併修補有 81–95% 是操作者自己 merge，合併率在這種情況下大多反映流程，而不是品質。

Q5：「驗證修補」是怎麼判定的？靠 LLM 可靠嗎？
先用規則找候選，再由兩位作者標 50 對（κ 0.77），以 Claude Opus 為 judge（與人類 κ 0.78、precision 90%）。二元判斷可靠，三分類較不穩定，作者有列在限制中。

Q6：讓 agent 修自己的 bug 有什麼不好？
修得快是好事。風險在於人類失去對「這個模組最近一直出問題」的感知。設一個上限：同一區域第二次修補時拉人進來。

Q7：我們沒有 Fixes-PR 的約定，還能算嗎？
可以用論文的啟發式：30 天內、同檔案、標題或標籤是 fix 的合併 PR。會有雜訊（論文中候選 22.9% 只有約五分之一是真修補），所以要抽樣人工確認。

Q8：效能 PR 最低要附什麼？
base 和 head 在同一環境、多次執行的數字，最好有中位數與變異。論文的門檻是改善至少 5% 且統計顯著，宣稱值與測量值落差超過一半就算不成立。

Q9：要多久的觀察窗口？
7 天抓早期警訊（一半事件在第一週），30 天算修補率，90 天算 revert。

Q10：小團隊有必要做這些嗎？
最低限度做兩件事：fix PR 標註它在修誰，每月跑一次修補率。成本很低，但能讓你第一次看到合併後發生的事。

11. 參考資料

論文

Takerngsaksiri, W., Duong, N., Barnett, S. (2026). Who Finishes the Job? A Study of Follow-Up Fixes and Commit Authorship on AI Coding Agent Pull Requests. arXiv:2609.26847. https://arxiv.org/abs/2609.26847v2
Qi, Z., Li, H., Chen, J., Chen, H., Zhao, Y., Zhu, D., Cerny, T., Liu, B., He, S. (2026). Merged, Not Measured: An Empirical Study of Performance Issues Fixed by Coding Agents. arXiv:2609.37985. https://arxiv.org/abs/2609.37985
Peng, H., Calvo, R., Kalu, K. G., Davis, J. C. (2026). How Do Coding Agents Optimize Software and Report Performance Validation? arXiv:2610.03969. https://arxiv.org/abs/2610.03969
Kraishan, O. (2026). Not All Agents Are Equal: Code Quality and Post-Merge Maintenance Across Five Autonomous Coding Agents in the Wild. arXiv:2609.17598. https://arxiv.org/abs/2609.17598
Peralta, S. R. O., et al. (2026). Why Are Agentic Pull Requests Merged or Rejected? An Empirical Study. arXiv:2605.22534. https://arxiv.org/abs/2605.22534
Li, H., Zhang, H., Hassan, A. E. AIDev: Studying AI Coding Agents on GitHub. arXiv:2602.09185. https://arxiv.org/abs/2602.09185