假設一個小團隊每週請 agent 更新操作文件，順手補一組相關測試。週一早上 PR 已經開好，reviewer 點進去，卻找不到這次改動要通過哪些檢查；測試沒跑完，也沒人知道是失敗、跳過，還是根本沒設定。PR 看起來完成了，接手的人反而得從 diff 猜需求。
這是設計情境，不是哪家工具的實測事故。問題在於：agent 能提出修改，不代表團隊已經有辦法接受那份修改。
GitHub Agentic Workflows 把 issue 整理、CI 故障分析、文件及測試工作帶進 GitHub Actions，官方也描述了預設唯讀、沙箱等保護設計。Cursor 的 Agent SDK 提供事件觸發、eval 與 replay 等建置材料；Entire 則把 agent 的執行軌跡與變更結果放進 review 脈絡。這些方向各有用途，但「有執行紀錄」和「這個 PR 可以合併」仍是兩件事。工具的能力與防護，要按實際設定驗證，不能拿產品介紹當成團隊的驗收結果。
IT Pro 引述的 Atlassian 開發者體驗調查也指出類似落差：受訪者覺得 AI 讓寫程式變快，開發流程的摩擦卻未必跟著減少。這是受訪者回報的現象，不是台灣團隊的實測，更不能單憑它推論因果。對手上真的有一堆 PR 等著看的團隊來說，倒是個好提醒：少算一點產碼時間，多看一眼等待與退回的時間。
我會先挑一件範圍固定的工作，例如同步 docs/ 的操作步驟並更新 tests/docs/ 的對應測試。給 agent 能提出變更所需的最小權限，不給合併、改保護規則或部署正式環境的權限。允許路徑也不能只寫在提示詞裡；CI 必須檢查實際 diff，發現修改碰到其他目錄就擋住。怎麼設定這道關卡，取決於團隊使用的 repository 和 CI。
PR 裡附一張簡短交接單，讓 reviewer 不用重看整段對話。下面是我建議團隊自訂的欄位，不是 GitHub、Cursor 或 Entire 的共同格式：
ryanvale
task_id: docs-sync-weekly
trigger: weekly-docs-sync
allowed_paths: ["docs/**", "tests/docs/**"]
expected_acceptance: "文件步驟與對應測試一致，路徑檢查與指定 CI 通過"
pr: "<實際 PR 網址>"
commit: "<實際 commit SHA>"
checks: "<已跑的檢查、結果，以及未跑的原因>"
residual_risk: "<尚待人工核對的內容>"
reviewer: "<指定審查人>"
這份交接單不是通行證。checks 要能對回該 commit 的 CI 結果，allowed_paths 要跟實際變更比對；光靠 agent 自己填「已通過」沒有意義。如果任務改了範圍、測試沒跑、CI 失敗，就把 PR 留在待處理狀態，交給人決定要縮小任務還是修復環境。不要讓同一個 agent 為了讓紅燈變綠，順手改掉檢查規則。
我會用一個正常案例和幾個故意失敗的案例驗這條流程：文件與測試都在允許路徑內，證據齊全時交給 reviewer；改到權限設定檔時擋下來；CI 紅燈時不進入可合併狀態。還有一種更容易漏掉：自動 eval 顯示通過，reviewer 卻發現文件步驟跟產品目前的操作不符。這時該退回 PR，而不是讓分數蓋過需求判斷。以上是建議的驗收情境，不是已執行的測試報告。
接著記錄任務進站到 PR 被接受花了多久，其中多少時間在等 review、多少次退回重工、CI 與人工審查各花多少成本。寫碼速度若變快，交付時間卻沒縮短，下一個該改的可能是交接與驗收規則，不是再多開幾個 agent。
候選 PR 可以讓自動化先跑起來；能被人看懂、拒絕並安全接手的候選 PR，才有機會成為交付。
iThome鐵人賽
看影片追技術