一個 AI agent 送出 PR，測試有跑，描述也寫了，diff 看起來還算乾淨。
然後 reviewer 還是把它退掉。
這件事一點都不矛盾。真實工程流程不會在「能改出一版 code」就結束。PR 要被接受，還得回答更討厭的問題：這是不是值得修？是不是用對方法修？有沒有碰到不該碰的地方？reviewer 能不能在合理時間內相信這個修改？
很多團隊剛開始用 coding agent，會把 rejected PR 解讀成模型不夠聰明。這個判斷太快了。
有時候 agent 真的寫錯。這不用替它辯護。但更多時候，失敗在 agent 動手之前就開始了。Issue 太模糊、優先級不明、架構限制沒寫、驗證方式沒定義、非目標沒講清楚。Agent 很會把這些空白補成一個完整 diff。問題是，完整不等於可合併。
PR 被退，常常是在提醒人類：你還沒有先定義什麼值得修。
我們習慣把 code review 想成抓 bug。
但 reviewer 在看 PR 時，其實一直在評估風險。這個改動是不是符合需求？有沒有改壞旁邊的行為？測試是不是對得上風險？diff 大小是不是合理？作者有沒有理解系統原本的取捨？
人類作者至少還有一些社會脈絡。你知道他熟不熟這個模組，知道他會不會亂重構，知道他碰到不確定的地方會不會先問。這些東西不是絕對可靠，但 review 時多少會被納入判斷。
Agent PR 少了這層隱性信任。
它可能產出一個語法正確、測試通過、描述流暢的 PR，卻沒有讓 reviewer 看見它怎麼判斷。它為什麼選這個修法？它有沒有看過相關模組？它是不是把非目標也一起改了？它跑的測試夠不夠？哪些地方只是猜的？
如果這些答案不清楚，reviewer 退 PR 很正常。
這通常不是 reviewer 對 AI 有偏見。合併責任最後還是落在人身上。Agent 可以寫 code，不能替 reviewer 承擔 merge 後的事故。
Agent 最麻煩的能力之一，是它很會補洞。
人類看到模糊 issue，可能會停下來問：「這是要修 UI 還是 API？」、「這個行為是 bug 還是產品決策？」、「相容性要不要保？」Agent 則很容易直接找一條看似合理的路走下去。
這在 demo 裡很漂亮，在產品 repo 裡很危險。
因為模糊需求被 agent 接住後，不會以模糊的樣子回來。它會變成檔案修改、測試調整、註解、PR 描述。看起來像完成品。reviewer 反而要花更多時間拆開來看：這個方向是不是一開始就錯了？
所以派工前要先做一件很無聊的事：判斷這件事值不值得交給 agent。
適合的任務通常有幾個特徵：
不適合直接交出去的任務也很明顯：
這不是說 agent 永遠不能碰高風險任務。它可以先做分析、整理候選方案、找相關檔案、補測試骨架。但「讓它直接改完開 PR」是另一件事。
工具越強，越需要派工前的篩選。
不然你得到的不是效率，是更快產生 review debt 的能力。
很多 agent PR 被退，主線修法未必完全錯。真正卡住 review 的，反而是它順手做了太多事。
修一個錯誤訊息，順便整理 error helper。補一個測試，順便改 fixture 結構。修一個 UI 狀態，順便調整 component props。這些動作有時候合理，但如果任務一開始沒講，reviewer 就必須重新推理整個 diff。
派工時的限制條件，不是拿來把 agent 綁死。它比較像護欄，幫 reviewer 少重建一輪上下文。
一個比較像樣的 agent task，至少要寫清楚：
例如這樣：
修正
billing/usage在免費方案用量歸零時顯示錯誤的問題。允許修改 billing 模組與對應測試，不要調整方案判斷規則，不要碰付款流程。先新增一個失敗測試重現問題，再修改 production code。完成後跑pnpm test billing和pnpm lint。如果需要改到權限或付款邏輯，停止並回報原因。
這段不厲害，也不花俏。
但它讓 agent 少猜一點，也讓 reviewer 少猜一點。這就是價值。
很多團隊期待 agent 產出「高品質 PR」，卻只給它一句「幫我修一下」。這其實不公平。你沒有給工作單，只是給一個願望。願望被轉成 diff 之後，通常很難 review。
「請確認沒問題」不是驗證。
這句話對人類都不夠清楚，對 agent 更糟。Agent 可能跑了一個最容易通過的測試，可能只做靜態檢查，可能在環境壞掉時用一句「無法執行」帶過。PR 看起來還是很完整，但 reviewer 沒有真正拿到證據。
比較好的做法，是在 agent 開始前就定義驗證契約。
不要等 PR 開出來才問它跑了什麼。一開始就說：
這會改變 agent 的工作方式。
它的工作就不會停在「把 code 改到看起來合理」。它必須交出一組可以被 reviewer 檢查的證據。這組證據不一定保證 PR 正確，但至少讓人知道哪些地方被檢查過，哪些地方還在風險區。
我看 agent PR 時，最怕看到的是那種過度順滑的描述：
Implemented the fix and verified everything works.
這句話幾乎沒有資訊。
我寧可看到比較笨、但有用的版本：
Added a regression test for expired free-plan usage reset. Changed
usageSummarymapping only. Ranpnpm test billingandpnpm lint. Did not run e2e because local Stripe fixture is unavailable; no payment-flow files were modified.
這才像工程交付。
它不一定比較漂亮，但比較容易被相信。
很多人談 agent productivity，只看寫 code 省了多少時間。
這個算法少算了一半。
如果 agent 省下 30 分鐘實作，卻多花 reviewer 60 分鐘判斷它有沒有亂改，團隊沒有賺到效率。成本只是從寫 code 的人搬到 review 的人身上。
更麻煩的是，review cost 通常不會立刻被記錄。團隊只會看到「agent 開了很多 PR」，看不到 reviewer 每天被迫讀一堆缺乏脈絡的 diff。久了之後，大家不是更信任 agent，而是更懶得收它的 PR。
所以 agent PR 的標準不該只是「能不能跑」。
還要問：它有沒有降低 reviewer 的理解成本？
一個好的 agent PR 應該讓 reviewer 快速知道：
如果 PR 讓 reviewer 必須從零開始重建所有上下文，它就算 code 正確，也不是一個好的 agent 產出。
工程流程追求的從來不只是「有人把 code 寫出來」。
更實際的目標，是團隊能不能用可承擔的成本，把正確的修改合併進系統。
Agent 必須服務這件事，不是繞過這件事。
真的要把 coding agent 放進 issue/PR 流程，我會先要求每個 agent task 至少回答這幾題。
第一，這件事為什麼值得修？
不是每個看起來能修的東西都值得修。低優先級、低影響、方向不確定的 issue，很容易讓 agent 產出一個「技術上能改，但產品上不重要」的 PR。
第二，完成定義是什麼？
修 bug 要有重現與回歸測試。改 UI 要有前後行為。改 CLI 要有命令輸出。補文件要知道讀者要完成什麼任務。
第三，不能碰什麼？
禁止區域比允許區域更重要。權限、付款、資料刪除、schema migration、公開 API，這些地方不要靠 agent 自己判斷「順手調整」是否合理。
第四，最小可驗證路徑是什麼？
不要叫 agent 跑「所有可能測試」當成儀式。列出跟風險對得上的命令和證據。小任務小驗證，高風險任務高驗證。
第五，PR 要留下什麼決策紀錄？
Agent 不需要寫長篇心得，但它要說清楚主要取捨、未驗證假設、沒有採用的路線。這些東西會直接影響 review 速度。
這張檢查表沒有什麼魔法。
它只是把人類本來藏在腦袋裡的 review 條件提前寫出來。
而 agent 最需要的，剛好就是這些原本沒寫出來的東西。
我不相信未來的好團隊會把所有 issue 都丟給 agent。
那不是成熟，是懶。
比較成熟的團隊會知道哪些工作適合委派，哪些工作只適合請 agent 先分析，哪些工作必須人類先做設計。它們也會先定義退貨條件：什麼情況 PR 直接退、什麼情況要求補證據、什麼情況代表任務描述本身要重寫。
這聽起來很麻煩，但會讓 agent 更好用。
因為大家不再靠感覺判斷「這個 PR 怪怪的」。你可以直接指出：超出修改範圍、沒有跑指定驗證、沒有說明未驗證假設、把非目標一起改了、修的不是這個 issue 真正要解決的問題。
這樣一來，Agent PR 被退才會變成可改進的流程訊號，而不是一句「AI 還是不行」。
模型會繼續變強。這不用懷疑。
但模型變強不會自動解決派工問題。它只會更快把模糊需求變成看起來可以合併的東西。
真正拉開差距的，可能不是哪個團隊最會買工具。
差距會出現在更普通、也更刺耳的地方：在 agent 寫 code 之前，人類有沒有先把價值、限制、驗證和 review 成本講清楚。
否則 PR 被退，通常不是意外。
只是流程很誠實，把問題退回來而已。
ryanvale
iThome鐵人賽
看影片追技術