一張 issue 能不能交給 coding agent，看你寫不寫得出第一個 diff

做完和能被檢查是兩回事

Coding agent 的能力確實已經到了可以「做完」的程度。依 GitHub 文件的說明，它自家的 Copilot coding agent 會在雲端環境裡研究 repo、規劃改動、修改檔案、執行測試與 linter（自動檢查程式寫法的工具），自己建立 branch（獨立的修改分支）、寫 commit（每一次修改的紀錄）訊息、推上去，最後開出 pull request。另一個例子是新創公司 Cognition 開發的 Devin，一個標榜能獨立完成工程任務的 coding agent。Cognition 執行長 Scott Wu 今年 5 月接受 TechCrunch 訪問時提到，公司工程師提交的程式碼有 89% 是由 Devin 提交的，他形容 Devin 的程度介於初階和中階工程師之間。

從這些描述很容易推出一個結論：既然它能從 issue 一路做到 PR，就把整個功能交給它。這個推論漏掉一件事：做完和能被檢查是兩回事。

一個動了十四個檔案的 PR，就算每一行都正確，審查的人也得先把 agent 的思路重建一遍，才判斷得了。重建不出來，就只剩兩個選擇：照單全收，或整個退回。前者讓沒人真正看懂的程式碼進了 main，後者把 agent 的一小時和自己的半小時一起丟掉。

Scott Wu 在同一篇訪問裡說，要做什麼「應該永遠由人決定」。問題在於，如果這個決定只發生在最後看 PR 的時候，人能做的其實只有接受或拒絕，談不上決定。

寫不出第一個 diff 的任務，先不要交

所以，指派之前先在 issue 裡寫一行：「第一個 diff 只改＿＿，用＿＿證明它是對的。」

寫得出來的例子：「匯出功能新增 Excel 格式。第一個 diff 只在 exporter 模組加上 xlsx 輸出，用『十筆會員資料匯出後欄位與 CSV 版一致』的測試證明。」這樣的 issue 可以交出去，並要求 agent 做到這個 diff 就停下來，等人看過再繼續。

寫不出來的時候，通常卡在三種原因之一：

• 需求還沒定。 產品要的是 Excel 還是 Google Sheets 還沒決定，agent 只能自己猜。
• 沒有東西能證明對錯。 相關流程沒有測試，任何改動都只能靠人肉眼判斷。
• 改動天生跨很多地方。 權限、付款、登入、刪除、資料遷移，牽一處就動全身。

這三種情況下，agent 仍然有用，只是用途要換：讓它讀程式碼、列出會受影響的檔案、草擬測試、比較兩種做法的優缺點。這些產出不會進 main，錯了也只是浪費一點時間，卻能幫人更快把需求想清楚。等那一行寫得出來，再把實作交出去。

這條規則也有代價。拆得越小，PR 越多，審查的次數也越多。對已經有完整測試、改法高度重複的工作，例如大量升級相依套件，或依固定規則替一批函式改名，一次整批交出去反而更有效率；Scott Wu 說 agent 最適合接手的長尾維護工作，多半就是這一類。判斷依據仍然是同一個：說得出怎麼驗證。「全部測試通過、建置成功、行為沒變」能證明一次大量升級，那就適合整批交。

AI 整理卡

請 AI 幫你判斷這張 issue 能不能交給 coding agent 這段提示詞會先問清楚 issue 的狀況，再試著寫出第一個可審查的 diff；寫不出來時，改建議 agent 現在能先做的研究工作。

我想判斷一張 issue 能不能直接交給 coding agent（例如 Copilot coding agent 或 Devin）實作。
判斷標準來自這篇文章：https://boosterminiclass.com/posts/coding-agents-need-human-checkpoints/
能交出去的任務，必須寫得出「第一個可以單獨審查的 diff」：它只改哪些檔案或模組，以及用哪一個測試證明它是對的。

請先問我 3 個問題：
1. 這張 issue 的完成條件是什麼，有沒有還沒定案的產品決定；
2. 相關程式碼目前有沒有測試可以證明它的行為；
3. 這次改動會不會碰到權限、付款、登入、刪除或資料遷移。

根據我的回答，請輸出：
- 一行判斷：可以交出去／先拆小再交／只讓 agent 做研究；
- 如果可以交：用一句話寫出第一個 diff 的範圍和驗證用的測試，讓我直接貼進 issue；
- 如果還不行：說明卡在哪一個原因，以及 agent 現在可以先做的研究工作（例如列出受影響的檔案、草擬測試、比較兩種做法）。
不要替我假設不存在的測試或程式結構；資訊不夠就繼續問我。

AI 的建議只能幫你把問題問完整，要不要交出去，仍由負責這個 repo 的人決定。