一份乾淨的 diff，仍可能是一份來路不明的變更。
檔案改得很少、測試全綠、命名也合理，但 reviewer 到 PR 出現時才第一次知道這個任務。他不知道原始需求是什麼、agent 被允許碰哪些範圍，也不知道執行途中是否改過計畫。最後只能一邊看 patch，一邊倒推前因後果。
人寫程式時，這個問題已經很常見。換成 agent 之後，只是發生得更快，而且一次能產生更多看似完整的變更。
Slack Code 最近公開一種協作方式：每個開發任務有獨立的 Code Channel，團隊成員能在裡面看到 plan、diff、preview 與完整紀錄，建立 PR 前還要經過人工確認。
這個安排把共同檢查提前到 PR 之前。團隊可以在任務還沒變成一包程式碼時，先確認 agent 打算做什麼，不必等結果送到眼前才開始補上下文。
同一個頻道看得到全部內容，仍不會自動變安全。若團隊沒有定義哪些決定需要人接手，再完整的紀錄也只是一條更長的動態牆。
很多流程把 review 當成「檢查 diff」。但 agent 任務至少有三個不同的 review object，混在一起會讓責任變得模糊。
這一層要回答：為什麼執行、誰是 human owner、agent 能動哪裡，以及怎樣才算完成。
例如「修正 checkout 表單的電話欄位驗證」仍然太寬。比較可執行的約定會寫清楚：可修改表單元件與相關測試；不得改付款 API、production config 或套件版本；既有正常輸入不能退化；若根因落在後端契約，就停止並回報。
這些資訊若不存在，agent 只能自行補齊空白。PR reviewer 看到的，則是 agent 猜完之後的答案。
計畫不是不能改，但跨出原本邊界時，不能悄悄改。
Agent 可能做到一半才發現前端修補不夠，必須升級 validation library，或連 API schema 一起調整。這時候該停下來確認，因為風險、影響面與 reviewer 都變了。若 agent 先全部做完，再在 PR 描述裡補一句「順便升級 dependency」，人工核准只剩形式。
團隊也不需要逐步盯著 agent。只有當檔案範圍、工具權限、外部副作用或關鍵技術決策跨出原約定時，才觸發 boundary-change gate。
最後才是大家熟悉的 diff，但光有 diff 還不夠。交付內容至少要包含實際執行過的檢查、preview、失敗項目與尚未排除的風險。
Reviewer 接到的應該是一份可以做決定的 change packet，而不是請他重新考古整段 agent session。前者讓人判斷是否能合併；後者只是把理解成本移到最後一棒。
我會把流程切成三個明確的停靠點。
before-run 由 human owner 確認任務意圖、允許範圍、驗收方式與停止條件。這個 gate 不必很重，重點是有人願意對任務邊界具名。
during-run-on-boundary-change 只在計畫越界時啟動。原訂只改表單與測試，卻發現必須碰 API contract，就先提出原因與替代方案，等人決定要擴大範圍、拆成另一張任務，還是直接停止。
before-pr 要求 agent 交付變更、驗證證據與未解風險，再由指定的人確認是否建立 PR。注意，這個人只是接受 handoff，正式的 code owner review 仍可照原流程進行。
三個 gate 分別保護授權、變更與交接。它們比「agent 跑完後請仔細 review」具體得多，也沒有把每一步都變成人工審批。
不必先導入大型治理平台。團隊可以從一份跟著 task 走的 agent-change 紀錄開始。下面是自訂的 pseudo-YAML，不是 Slack Code 的官方 schema：
ryanvale
agent_change:
intent: 修正 checkout 電話欄位驗證
owner: frontend-oncall
allowed_scope:
- src/checkout/form/**
- tests/checkout/**
stop_conditions:
- 需要修改 API contract
- 需要升級 dependency
- 需要變更 production config
acceptance_checks:
- 無效電話格式會顯示既有錯誤訊息
- 合法輸入仍可完成 checkout
- 相關測試通過並附上 preview
approved_boundary_changes: []
evidence:
commands: []
preview: null
failed_checks: []
unresolved_risks: []
handoff_approver: null
開始執行前，owner 填好上半部。Agent 執行時只更新可觀察的 plan、動作、核准事件與證據；開 PR 前，再補齊下半部。
這裡不需要保存 chain-of-thought。團隊要的是能被驗證的行為，不是模型腦內旁白。執行了哪些指令、改過哪些邊界、哪個檢查失敗，這些才會影響合併決策。
假設 agent 在隔離 branch 修正表單驗證。原始 contract 允許它修改 form 與 tests，所以補上驗證邏輯、測試案例，再產生 browser preview，都能直接進行。
做到一半，它發現前端收到的電話欄位格式和 API 文件不一致。此時有兩條路：在現有格式下完成最小修補，或改 API contract。第二條路已跨出 scope，agent 應該停在 boundary-change gate，而不是自行修改後端再一次送進 PR。
如果 owner 決定另開後端任務，這次變更就保留原邊界。到了 before-pr，change packet 會明確寫出：修了哪些情境、跑過哪些檢查、preview 在哪裡，以及 API 格式不一致仍是未解風險。
Reviewer 不必從 diff 猜故事。他拿到的是一段已經有人確認過邊界、保留過決策、也知道還欠什麼的變更。
Diff review 適合判斷 patch 本身：改動是否集中、抽象是否合理、測試是否真的覆蓋風險。Audit log 適合事故後重建：誰在何時用什麼權限執行了哪些動作。
本文談的是兩者中間那段常被忽略的流程：任務如何取得授權，執行中如何處理越界，最後又由誰接下合併責任。
多代理同時操作 shared repo 時，這段流程更重要。平行 agent 會增加程式碼衝突、資源爭用與重複決策的機會。多記幾份 log 解不了 ownership 問題；每個 task 仍要有一位 human owner，workspace 與 branch 也要有清楚歸屬。
Coding agent 讓產出 diff 的成本大幅下降，理解變更的成本卻沒有跟著消失。解法不該是逼 reviewer 更快消化 agent PR。把 review 往前移後，diff 出現以前，團隊就已知道這個任務為什麼能做、走到哪裡必須停，以及最後由誰負責把它交進既有開發流程。
iThome鐵人賽
看影片追技術