想像你是一間餐廳的老闆

你開了一間小餐廳，廚房有 10 個廚師。某天，有人送了你 1,000 個機器人廚師，說「免費的，讓它們幫忙出菜吧」。

聽起來是天大的好事對吧？但三天後你發現：機器人確實會炒飯，但它們不看訂單、不管客人過敏、有的還會把生肉直接端出去。更慘的是，你那 10 個人類廚師現在花 80% 的時間在「檢查機器人有沒有搞砸」，而不是自己做菜。

這不是比喻。這是 2026 年 GitHub 上正在發生的事。

Drexel University 和 Missouri S&T 的研究團隊從 GitHub 上撈出了 33,596 筆由五大 coding agent 提交的 PR —— 全部來自 100 星以上的真實 repo，有 CI/CD、有 reviewer、有 contribution policy。不是 benchmark，不是 SWE-bench，是你我每天在用的那種 GitHub repo。

然後他們問了一個簡單的問題：這些 PR，到底有多少活下來了？

Clawd Clawd 吐槽時間：

這篇論文已被 MSR 2026（Mining Software Repositories）接收 —— 軟體工程研究的頂級會議，peer review 過的正經學術研究 (◕‿◕) 不是某個 startup 的業配 blog，也不是「我用了三天覺得很讚」的推文。33k 筆 PR 加上 600 筆手動標註的失敗案例，這規模就像你期末考交了一份用全校學生成績做的統計分析，教授想當你都難。

成績單出來了：有人考 90 分，有人不及格

先看全班平均：71.48% 的 agent PR 成功 merge。

聽起來還行？就像你跟媽媽說「我考了 71 分」，她可能會說「還可以啦」。但等她看到隔壁小孩考了 83，而你最好的朋友只考了 43，事情就沒那麼單純了。

各 agent 的成績單：

  • OpenAI Codex — 21,799 PRs → 82.6%（班上第一名，而且交了最多作業）
  • GitHub Copilot — 4,970 PRs → 43.0%（不及格，連擲硬幣都不如）
  • Devin — 4,827 PRs → 53.8%（勉強及格）
  • Cursor — 1,541 PRs → 65.2%（中上）
  • Claude Code — 459 PRs → 59.0%（交的作業最少，成績中規中矩）
Clawd Clawd 想補充：

Codex 這成績有點離譜 —— 作業交最多，分數還最高？這就像班上那個每天打電動但考試永遠第一名的傢伙，你想恨他但數據就是數據 ┐(￣ヘ￣)┌

但 Claude Code 只有 459 筆 PR 是怎回事？我的猜測：Claude Code 的用戶比較像那種在家把作業寫完、檢查三遍才交的學生，不像 Codex 是直接在 GitHub 上開 PR。所以這個樣本量可能低估了 Claude Code 的真實實力。

至於 Copilot⋯⋯43%。每交 10 份作業只有 4 份及格。你花錢請了一個家教，結果他幫你寫的作業有六成被老師退回來，這筆帳怎麼算都不划算。

簡單的活搶著做，難的活一塌糊塗

研究團隊把 PR 分成 11 種任務類型，結果非常符合直覺 —— 但殘酷：

做文件、改 CI config、調 build 設定？merge rate 高達 74-84%。這些就像餐廳裡的「擺盤」和「洗碗」—— 不需要理解客人想吃什麼，照 SOP 做就行。

但一碰到 bug fix（64%）和 performance 優化（55%）？直接掉到六成以下。因為修 bug 就像醫生看診 —— 你不能光看症狀就開藥，你得先搞清楚病因。而 AI agent 目前最弱的就是這個：它會開藥，但不太會診斷。

Clawd Clawd murmur：

這邊有個很生活化的比喻：你叫 AI agent 幫你整理房間，它可以把衣服疊好、書排整齊（docs、CI config）。但你叫它「找出為什麼洗衣機會漏水」（bug fix）或「重新規劃動線讓房間感覺更大」（performance），它就傻了 (╯°□°)⁠╯

不是它不努力，是它缺少那個「住在這間房子三年所以知道哪根管子有問題」的 context。Pattern matching 能解決的事它很行，需要 deep understanding 的事它還差得遠。

為什麼 PR 會被拒？一齣三幕悲劇

好，現在我們知道整體成績了。但成績不及格的那 29%，到底是怎麼死的？

研究團隊翻了被拒 PR 的屍體，發現死法不只一種 —— 而且它們會連環爆，一個比一個慘。

第一幕叫「好心辦壞事」。Agent 拿到一個任務，比如修一個小 bug，結果它不只修了 bug，還順手重構了三個檔案、改了 import 順序、更新了一個它覺得過時的 dependency。就像你請水電工來修漏水的水龍頭，結果他幫你把整間廁所砸了重裝 —— 改太多東西。Reviewer 一看到幾百行的 diff，腦袋裡只有一個字：Close。

但故事沒完。因為改了太多東西，CI 開始爆了。一個 check fail 還好，兩個也勉強，但有些 PR 直接 fail 了十幾個 check —— 每多一個失敗的 CI check，merge 機率就降 15%。這就像期末考 15 題錯了 12 題，你字再漂亮教授也不會看的 (￣▽￣)⁠／

然後第三幕登場了，也是最讓人心累的一幕。Agent 不會放棄。它會不斷修改、不斷 push、不斷 re-request review。Reviewer 回饋一次，agent 改了但又弄壞別的東西。再回饋一次，又是新的問題。來來回回五六輪之後，reviewer 的耐心值已經歸零了 —— 這時候最理性的反應不是「再給它一次機會」，而是直接放棄。

你有沒有試過教一個人路怎麼走，說了五遍他還是走錯？你的反應不會是「好我更有耐心地說第六遍」—— 你的反應是「算了我自己走比較快」。

Clawd Clawd 插嘴：

Honeycomb 的 Technical Fellow Liz Fong-Jones 在 LeadDev 的報導裡講了一句我覺得會被寫進教科書的話：agent PR “risk becoming a DDoS attack on your development pipeline.” (⌐■_■)

DDoS 你的開發流程。不是提升生產力，是癱瘓你的 pipeline。Boris Cherny 一個月處理 250 個 PR，一般人一個月才 12 個。你的 reviewer 不是被 AI 賦能了，是被 AI 淹沒了。

論文最狠的發現：不是 code 寫太爛，是根本沒人看

好，前面講的都是「為什麼 PR 品質不好」。但論文真正讓我倒抽一口氣的發現是另一件事。

研究團隊手動分析了 600 筆被拒的 PR，幫它們分了四個層級的「死因」。結果最常見的死因不在第三層（code 寫得爛）也不在第四層（agent 特有問題）——

而是在第一層：Reviewer Abandonment。

白話文：PR 開了，然後⋯⋯沒人看。就像你認真寫了一封情書塞進對方抽屜，結果對方連看都沒看就丟垃圾桶。

為什麼？因為當一個 repo 每天收到幾十個 agent PR，maintainer 光看 title 就知道是 AI 生成的 —— description 一看就是模板、改的檔案莫名其妙、CI 還是紅的。這時候最理性的做法就是：忽略。

第二常見的死因是重複 PR（agent 不知道別人已經修了）和自作主張加功能（沒人要你加的 feature 啊大哥）。真正因為「code 品質太差」被拒的，反而排在後面。

Clawd Clawd 溫馨提示：

這個發現讓我想到一個更深的問題：我們一直在優化 agent 的「寫 code 能力」，但真正的瓶頸根本不在 code (￣▽￣)⁠／

就像你拼命練廚藝、考了米其林三星，結果餐廳開在深山裡沒人來吃。Agent 的 code 品質是「廚藝」，但 PR 能不能被 merge 取決於「有沒有人願意走進來坐下」。

如果你的團隊沒有 agent PR 的 review 策略，那 agent 寫的 code 只有兩個下場：不經 review 直接 merge（恭喜，你在製造 Cognitive Debt），或者根本沒人看（恭喜，你在燒 compute 費用取暖）。

當 1,000 個 Agent 同時衝進你家廚房

記得開頭那間餐廳嗎？現在把場景放大十倍。

LeadDev 2 月 10 日的報導直接把鏡頭從「單一 PR 品質」拉到了「整個廚房會不會爆炸」的層面。BuildBuddy 的 Son Luong Ngoc 丟出了一個讓人頭皮發麻的數字：「現在 AI lab 的目標是讓 10 個工程師指揮 1,000 個 coding agent。」

1,000 個 agent 同時對你的 CI 發 PR。你家那台 GitHub Actions runner 本來就跑得喘吁吁了，現在要它同時處理一千份考卷？這就像你那間餐廳的瓦斯爐只有 10 口，突然來了 1,000 個廚師搶著開火 —— 不是產能提升，是廚房要炸了。

Fong-Jones 說 Google 15 年前就用 Blaze（現在的 Bazel）解決了精確 rebuild 的問題 —— 只重新 build 受影響的路徑，不用整個 monorepo 從頭跑。但這就像說「Google 15 年前就有自動駕駛了」—— 對，但你家沒有 Google 的路，也沒有 Google 的車。你那台裝在辦公室角落的 CI server，跟 Google 的基礎設施之間的距離，大概就是腳踏車跟 F1 賽車的距離。

而且這不是「未來可能發生的事」。你公司只是還沒踩到而已。

延伸閱讀

Clawd Clawd 真心話：

Fong-Jones 還提到一個我們很熟悉的東西：她說 AGENTS.md 要「灑在 monorepo 的每個角落」，不然 agent 會迷路 —— 不是找不到要改的檔案，就是把整個 codebase 塞進 context window 然後爆掉 ヽ(°〇°)ﾉ

欸等等，這不就是我們 CP-9 翻過的 Vercel AGENTS.md 那篇講的事嗎？好的 AGENTS.md 才是 agent 成功的關鍵，不是模型本身。看看，學術研究和產業實踐殊途同歸。

所以這場 Agent PR 革命，到底是福是禍？

回到我們開頭那間餐廳。

1,000 個機器人廚師不是不能用。但你需要的不是更多機器人 —— 你需要的是一套「機器人管理系統」：哪些菜讓機器人做、哪些菜一定要人類做、怎麼在機器人端菜之前先 QC、廚房的動線要怎麼重新設計才不會被機器人塞爆。

翻譯成工程語言就是：Agent PR 不是 drop-in replacement，它是一整套 workflow 的重新設計。從哪些任務放給 agent、PR size 怎麼控制、CI 基礎設施能不能撐住、到 reviewer 有沒有一套 triage 策略 —— 每一環都不能缺。

論文的數據很清楚：71% 的整體 merge rate 說明 agent PR 確實有用。但那 29% 的失敗裡藏著的模式 —— 改太多、CI 爆、沒人看 —— 每一個都是可以被 process 解決的問題，而不是等模型變更強就會消失的問題。

這大概是這篇研究最重要的 takeaway：瓶頸不在 AI，在人。 在你怎麼設計人跟 AI 的協作流程。

就像那 1,000 個機器人廚師 —— 問題從來不是「機器人會不會炒飯」，而是「你的廚房準備好了嗎」(๑•̀ㅂ•́)و✧

原始來源