研究指企業採用 AI 編碼智能體後，PR 合併時間增加 49%；作者建議先審閲初稿
After Agents Arrived, PRs Took 49% Longer to Merge. Stop Opening Them From a First Draft
一份涵蓋 718 家公司的哈佛工作論文指出，企業採用 AI 編碼智能體後，PR 從提交到合併平均增加 3.45 天，相對基準 7.03 天上升 49%。要求修改的 PR 比例由 13% 增至 25%，已解決 Jira issue 則沒有統計上顯著增長；這是一項尚未經同行評審的觀察性研究。作者另建議先自行檢查改動並把修正交回智能體，待認可後才送 PR 審查；研究並未記錄 PR 是否由智能體初稿產生。
文章把 PR 退回與審查隊列負荷連結，並給出由作者先與智能體完成修訂、再交同事審查的具體流程。
- 書籍： Event-Driven Architecture Pocket Guide
- 我另有著作： Thinking in Go（2-book series）— Complete Guide to Go Programming + Hexagonal Architecture in Go
- 我的項目： Hermes IDE | GitHub — 專為使用 Claude Code 和其他 AI 編程工具交付軟件的開發人員而設的 IDE
- 關於我： xgabriel.com | GitHub
Agent 只花了十一分鐘便完成。你看了一眼摘要，測試全部通過，於是開啟了拉取請求。然後它擱置了一星期，收到「要求修改」的結果，隊友又花了一個下午撰寫意見，而 Agent 本來只需再改一輪便能修正這些問題。
這種等待並非憑空猜測。一份涵蓋 718 家公司的哈佛工作論文指出，企業採用 AI 編程 Agent 後，從提交拉取請求到合併所需的時間增加了 49%。被正式要求修改而退回的 PR 比例接近倍增。程式碼行數增加了 30%。以已解決的 Jira 議題衡量，完成的工作量則沒有顯著的統計增幅。
我的看法是：Agent 的初稿不等於拉取請求。請自行審閲，將修改意見交回編寫程式碼的 Agent，只有在你願意為內容負責時才開啟 PR。隊友的審閲時間是整個流程中最稀缺的資源。不要再把它浪費在初稿上。
論文實際衡量了甚麼
Fiona Chen 和 James Stratton 使用了Jellyfish的工程分析數據：來自 GitHub、Jira 和 Google Calendar 的約 3 億項工作事件，涵蓋 2021 年 1 月至 2026 年 3 月（論文，第 1–3 頁）。他們比較較早採用 AI 工具的公司，與較遲採用或完全沒有採用的公司，採用分期差異中的差異設計。採用情況按公司而非個別開發人員計算。
至於 AI Agent（而非自動補全式助手），論文報告如下（第 3 頁）：
- 程式碼行數增加 30%，提交次數增加 20%，拉取請求增加 23%
- 已解決的 Jira 議題和 Epic 數量雖略有增加，但在統計上並不顯著；研究排除了產出增幅超過基線 12% 的可能性
審閲數據見第 22–23 頁。從提交 PR 到合併的天數增加了 3.45 天，基線為 7.03 天，即增加 49%。標準誤為 1.60 天，因此實際影響可能小得多，也可能大得多。至少有一名審閲者正式要求修改的 PR 比例增加了 0.12，基線為 0.13。每個 PR 收到的審閲意見增加了 0.58 條，基線為 1.66 條，即增加 35%。AI 助手對這三項指標均沒有顯著影響。使用 Agent 的員工中，有任何程式碼審閲工作的比例增加了 14%；使用助手的員工則增加了 10%（第 24 頁）。
PR 並沒有變大。每個 PR 的新增程式碼行數沒有顯著變化，基線約為 1,168 行（第 23 頁）。因此，額外的審閲輪次並非因 PR 規模擴大所致。
閲讀時請留意。這是一份求職市場論文，現行版本日期為 2026 年 8 月 4 日，尚未經同行評審。研究屬觀察性研究。Jellyfish 審閲稿件，只為確認當中沒有披露專有資訊，並非審核其科學內容（第 1 頁）。論文亦沒有記錄任何一個 PR 是否來自 Agent 的初稿。這部分是我的論點，並非論文的研究結果。
被退回的 PR 就是一次重試
把程式碼審查看成一條隊列。作者提交 PR，審查者處理 PR，而審查者人數增長緩慢。論文發現，企業增加了參與審查的人手，但程式碼編寫速度提升得更快。
再看看要求修改的比例。每個被退回的 PR 都會再走一輪：作者修正後，PR 重新進入隊列，審查者再讀一次。這就是重試，而重試會增加已是瓶頸的階段的負荷。被退回的 PR 比例由大約八分之一升至四分之一，代表同一批已經應接不暇的審查者要多讀很多次。
容量固定的審查隊列，每個被退回的 PR 都會再次排隊。
作者提出兩個可能令審查工作增加的原因（第 23 頁）：程式碼質素可能下降，也可能是審查標準有所改變。一位受訪的初級工程師描述了一個團隊：「只有一位資深工程師獲準批准改動」，而他「每星期只能審查我的程式碼一次」；停機事故後的新規則「要求 AI 生成的程式碼必須經資深工程師批准，令審查瓶頸更加嚴重。」
單靠增聘審查者，無法及時解決問題。你可以減少送進隊列的草稿。
初稿由你和 agent 負責
人類隊友編寫程式碼時，初稿已先經過一位讀者，也就是輸入程式碼的人。他們輸入每一行時都經過思考。agent 的初稿跳過了這一步。它來得又快又有自信，而第一個仔細閲讀它的人往往就是審查者。
因此，修訂迴圈轉移了。以往在作者腦中完成的修正，現在變成 PR 評論，在兩個人之間進行，速度受隊列限制。要求修改，代表要在別人的一天裏多走一趟。
把這個迴圈移回成本較低的地方。編寫程式碼的 agent 就在旁邊，而且已載入相關上下文。你把修正交給它，只需一個回合。同一項修正若留作 PR 評論，就要耗費審查者一次閲讀、你重新切換回來、新一次推送，以及第二次審查。
我會採用這條規則：先由你閲讀每項改動，然後才請其他人查看。任何你會在別人的 PR 中指出的問題，都先交給 agent 修改。
在 PR 前完成修訂迴圈
你不需要新工具。讓 agent 在自己的分支上工作，然後：
# what the agent changed since the branch split off
git diff --stat main...HEAD
# read it in the order it was written
git log --reverse -p main..HEAD
# run your own checks, not the agent's summary
npm test
# push it, but don't ask anyone to review yet
gh pr create --draft --fill
把 npm test 換成你自己的測試指令。main...HEAD 中的三個點只顯示你的分支自 main 分出以來所作的改動。在 GitHub 上，草稿 PR「不能合併，而且不會自動要求程式碼擁有者進行審查」，這正是你和 agent 仍有分歧時想要的狀態。--draft 和 --fill 的用法記載於 gh 手冊。
發現問題時，像撰寫審查評論那樣説明，並在同一個工作階段中發給 agent：
在 src/orders.ts 中，refund() 不再檢查訂單是否已付款。請加回這項檢查，並為未付款的訂單新增測試。
指出檔案、説明問題，並説明完成後應有的結果。然後閲讀新的差異，再次執行檢查，並重複這個流程，直到你自己也認為可以批准為止。只有到那時才執行 gh pr ready，將 PR 標記為可供審查。由你親自撰寫説明。如果你無法用兩句話説明這項改動，審查者也無法做到。
Hermes IDE 如何處理
我負責開發 Hermes IDE，因此閲讀本節時請將這點納入考量。
Hermes 會儲存每個 Agent 回合，因此你可以比較差異或還原單一回合，並可復原操作。Review Desk（⌘G；Windows 和 Linux 上為 Ctrl+Shift+G）會按回合或檔案顯示任務變更，並標示風險；你在其中留下的行內註解，會傳回撰寫該行的 Agent。這就是上一節介紹的 PR 前流程，無須手動把檔名和行號複製到終端機。
Review Desk（⌘G）的「按回合」檢視畫面，顯示 orders-api 中一項 Claude Code 任務的兩個回合（T1：3 個檔案 +69 −1，T2：1 個檔案 +1 −0）、第 1 回合對 src/db.ts 的差異（新增 refunded 狀態）、變更檔案，以及根據各回合內容草擬的提交訊息。
確認各回合內容無誤後，按一下 提交，即可在一步內提交變更、建立拉取請求，或在本機合併至任務開始時所在的分支；這些操作都可以復原。你可以自行檢查，決定任務何時完成。Hermes 免費，原始碼依 BSL 1.1 授權提供，並可在 macOS、Windows 和 Linux 上執行。最新版本是 2.3.4，於 October 15, 2026 發佈。它與 Nous Research、Anthropic、OpenAI 或任何 Agent 供應商均無隸屬關係。
我在別再審閲程式碼 Agent 的最終差異一文中，談過逐回合檢視本身的做法。略過這種檢視，代價就會落在你的審閲者身上。
這種做法幫不上忙的情況
自行審查不能取代另一位審閲者。你和 Agent 對任務有相同的盲點，因為提示詞是你寫的。沒有參與這次對話的審閲者，仍能發現你看不到的問題。
這也會佔用你的時間。如果你每天要交付十幾個小型 Agent PR，逐一全面審查確實需要不少工夫。我認為無論如何都會有人仔細閲讀那些程式碼，分別只在於會佔用誰的下午。
AI 審查機械人也無法替你清空隊列。截至 2026 年 3 月，近 80% 的公司曾在程式碼審查中使用 AI 工具，但 AI 撰寫的審查評論只佔 23.3%，而只有 10.8% 的 PR 收到任何 AI 評論（第 25 頁）。大部分檢視工作仍由人手完成；作者指出，公司採用 AI 審查工具後，瓶頸依然存在（第 4–5 頁）。
你的團隊目前如何處理 Agent PR：直接送交審查，還是先由作者檢查一遍？歡迎在留言區告訴我。
如果這篇文章對你有用
審查隊列出現積壓，原因與其他隊列無異：生產者加快速度，消費者卻沒有，每次重試都會重新排隊。Event-Driven Architecture Pocket Guide 是我撰寫的一本簡明指南，介紹以隊列和訊息為核心的系統，涵蓋 saga、CQRS、outbox，以及那些沒有人會提醒你的陷阱。如果你想採用 PR 前流程，又不想手動複製貼上，下載 Hermes IDE；如果覺得有用，也可以在 GitHub 上為它加星。
來源：DEV Community · dev.to