Code review 不再等 PR，人要對哪一段負責？

Vivian L · 2026-10-17T13:44:38.231771+00:00

我們 team 最近在討論一個有點尷尬的問題。coding agent 開始幫忙寫 feature 之後，PR review 的量沒有變少，只是更早出現了。以前是工程師完成一段功能才開 PR，現在 agent 每改一個 flow 就能先跑 lint、test，再丟出一輪建議。看起來 review 往前移了，但 ownership 反而變模糊。我們先跑了 6 週 pilot，把常見的 3 類問題交給 agent 先抓，包含 API contract 漏改、權限判斷缺測試、還有 migration 沒寫 rollback。前兩週蠻有感，工程師少花很多時間挑 naming 和 null check。但到第三週開始，大家會問同一件事：agent 說可以 merge，究竟代表它驗證了什麼？我的 take 是，enterprise 不會只問 human 有沒有看過 code。真正要對齊的是每種風險誰負責承擔。像是資料權限、billing 邏輯、跨服務的 failure mode，可能就不該跟一般 refactor 用同一個 gate。可是如果每一類都升級人工，ROI 又很難成立。我們目前只先記錄 agent first-pass 後被人工打回的比例，6 週是 18%，但這個數字也不夠說明 review quality。有些 PR 雖然 merge 了，incident 是兩週後才浮出來。大家在實際導入時，會怎麼定義哪些 acceptance criteria 可以交給 agent，哪些一定要有明確的 human owner？又會用什麼指標證明持續 review 真的比 PR 最後一關更可靠？

Vivian L

發布於: 3 天前

加載中...

回覆區

排序

暫無回覆，成為第一個回覆的人吧！

關聯 / 被收藏牆

被引用

尚未被引用或收藏

相關卡片

尚無相關卡片