AI Coding Agent 改完程式之後，你最容易問：
「幫我檢查有沒有 Bug。」
這句不是錯。
但範圍太大。
Reviewer 最後可能列出：
命名問題。
格式問題。
幾個一般建議。
真正危險的地方反而沒有被你特別追問。
今天只學一個方法。
AI 改完 Code、準備開 Pull Request 以前：
固定把 Review 分成三欄。
影響範圍。
規則衝突。
未解風險。
第一欄：影響範圍
先不要問：
「這幾行 Code 寫得漂亮嗎？」
先問：
「我改這裡，還有誰會一起受到影響？」
這就是 Blast Radius。
例如 Coding Agent 修改：
登入 API 的 Response Format。
目前這個 Repository 的 Test：
全部通過。
但另一個 Repository 裡的：
Mobile App。
Admin Dashboard。
Billing Service。
可能還在依賴原本格式。
如果 Reviewer 只看這次 Diff：
不一定容易發現。
Qodo 的 Codebase Context 可以利用 Repository、PR History、Specification、Live Git State 與跨 Repository 關係協助分析這種影響。
所以第一欄固定問：
這次修改可能影響哪些其他 File、Service、Interface 或 Repository？
第二欄：規則衝突
接下來才問：
「這次修改有沒有違反我們原本的規則？」
例如團隊可能早就規定：
Production Database 不得直接修改。
特定 API 必須向下相容。
敏感資料不得寫進 Log。
付款流程不能自動 Retry。
某些 Directory 不得增加新的 Dependency。
程式本身可能：
可以跑。
Test 也通過。
但仍然違反公司真正的 Engineering Rule。
Qodo Agentic Toolbox 的 Get Rules 與 Rule Enforcement，就是把這類組織、Repository 或工作範圍規則帶進 Agent Workflow。
所以第二欄固定問：
這次修改是否和目前適用的 Engineering Rules、Specification 或既有設計決策衝突？
第三欄：未解風險
第三欄最重要。
不要要求 AI：
「找到問題就全部自己修掉。」
有些問題確實可以直接修。
例如：
漏掉明顯的 Error Handling。
少一個安全的 Validation。
漏掉一個對應 Test。
但有些問題不是「修 Bug」。
而是在做：
決策。
例如：
要不要破壞舊 API 相容性？
這次能不能改變退款邏輯？
要不要允許 Retry 造成不同 Production Behavior？
資料保存方式要不要改？
這些事情如果 Agent 自己選一個看起來合理的答案：
技術上可能完成。
商業上卻可能完全錯。
所以第三欄固定問：
有哪些問題無法安全自動解決，需要人類決定？
三欄合起來，就變成一個很簡單的 Review Prompt
例如：
「先 Review 目前 Local Changes，不要開 PR。結果分成三組：第一，這次修改可能影響哪些其他 File、Service、Interface 或 Repository；第二，有沒有違反目前適用的 Engineering Rules 或 Specification；第三，有哪些問題會影響 Production Behavior、資料、權限或架構，需要人類決定。能安全修正的明確問題可以提出修法；有決策性的問題先停，不要替我決定。」
你不一定每次都要完全照字面輸入。
真正要記住的是：
影響範圍 → 規則衝突 → 未解風險。
為什麼不是先叫 AI 修？
因為 Review 和 Fix 是兩個不同階段。
假設 Reviewer 發現：
付款 Retry 沒有 Idempotency Key。
這可能是相對明確的技術風險。
Agent 可以提出修法。
但如果 Reviewer 發現：
目前 Requirement 根本沒有寫：
失敗付款究竟可以自動重試幾次。
這就不是單純漏一行 Code。
而是：
需求還沒決定。
這時最好停下來問人。
Qodo 官方自己的 Agentic Toolbox 範例，也採類似界線：
安全能處理的問題讓 Agent 處理。
可能改變 Production Behavior 的決策留下給 Developer Review。
「影響範圍」要排第一，不是最後
很多人 Review Code 的順序是：
先找語法。
再找 Bug。
最後才想到：
其他功能會不會壞。
對 Agent 寫的 Code，這個順序可以反過來。
因為 Coding Agent 一次可能在幾分鐘裡：
改十個檔案。
建立新 Interface。
調整 Config。
再補一套 Test。
每個 File 單獨看：
都很合理。
真正的問題可能在：
File 和 File 之間。
Service 和 Service 之間。
甚至：
Repository 和 Repository 之間。
所以先問 Blast Radius：
通常比先挑 Coding Style 更有價值。
「測試通過」也不能跳過這三欄
假設 Agent 回報：
All tests passed.
很好。
但這只能證明：
目前真的有跑到的 Test 沒有失敗。
它不能自動證明：
另一個 Repository 沒受影響。
沒有漏掉公司規則。
Requirement 本身沒有問題。
沒有缺少重要 Test。
Production Environment 和 Local Environment 完全相同。
所以正確順序比較像：
Agent 修改。
跑相關 Test。
做三欄 Review。
處理可以安全處理的 Finding。
把未解風險交人。
再開 PR。
不是：
Test 綠燈 → 直接 Deploy。
Qodo 為什麼特別適合放在 PR 前？
因為 Agentic Toolbox Reviewer 可以檢查：
Committed Change。
Uncommitted Change。
甚至新的 Untracked File。
也就是程式還在你目前 Working Tree 裡：
就可以先 Review。
這和等到 PR 開出去後才發現問題不太一樣。
現在的目標變成：
問題還在作者腦中有 Context 的時候就先找出來。
能在 Local 階段解決：
就不用變成：
Reviewer Comment。
第二個 Commit。
再 Review 一次。
但 Pre-PR Review 不等於正式 PR Review 可以取消
這是另一個很容易誤解的地方。
Qodo 自己也明確區分：
Local／Pre-PR Review。
以及真正的 Pull Request Review。
前者的目的：
讓作者在開 PR 以前先把明顯問題整理掉。
後者還有：
團隊共同討論。
Approval。
Merge Control。
最終 Push 後版本驗證。
所以 Pre-PR Review 是：
提前增加一層。
不是：
拿掉後面那一層。
今天實際只做這一件事
下次 Claude Code、Codex、Kiro 或其他 Coding Agent 改完功能：
不要馬上說：
「開 PR。」
先多做一次 Review。
而且不要只問：
「有沒有 Bug？」
固定要求輸出：
1. 影響範圍
哪些 File、Service、Interface、Dependency、Repository 可能一起被影響？
2. 規則衝突
有沒有違反目前的 Team Rule、Specification、安全規則或既有設計？
3. 未解風險
有哪些問題不能靠 AI 自己安全決定，需要人來選？
然後再做下一步。
前兩欄裡：
明確、低風險、可驗證的問題。
可以讓 Agent 修。
第三欄：
只要牽涉：
Production Behavior。
權限。
資料。
商業規則。
架構取捨。
先留給人。
真正重要的不是多找一個 AI 說「LGTM」
如果 Coding Agent 說：
「完成了。」
Reviewer Agent 又說：
「Looks good。」
兩個 AI 都同意：
不代表得到兩份真相。
真正有價值的是第二個 Agent：
問了和第一個 Agent不同的問題。
第一個 Agent 的任務是：
把功能做出來。
第二個 Reviewer 的任務應該是：
找出：
它影響了誰。
違反了什麼。
還有什麼不能自己決定。
角色不同：
第二層 Review 才真的有意義。
所以今天的一分鐘技巧只有一句：
AI 改完 Code，開 PR 前不要只問「有沒有 Bug」；先分成「影響範圍、規則衝突、未解風險」三欄。
當第三欄還有答案：
先不要叫 AI 自己猜。
那就是人該回來的地方。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/08/24：Slack Code 驗收條件怎麼寫？先用「現在／要變成／不能動」三格再叫 AI 改程式
AI 快問快答｜2026/08/24：Slack Code 看完 Plan、Code Diff、Preview，就可以直接部署 Production 嗎？
AI 快問快答｜2026/09/07：QWEN.md 已寫「Production 不可直接修改」，就代表 Qwen Code 一定不會越界嗎？
