PR Review 最痛苦的不是「看 code」，而是「不知道該先看哪裡」。Claude Code 的 /plan 幫你解決這個問題。
先講結論
三步驟：
/plan— 讓 Claude 產出「審查計畫」，把 PR 按風險分層- 逐段 Review — 按計畫從高風險開始看
/copy— 一鍵產出可以直接貼進 GitHub PR 的 Review 內容
整個流程大概 15-20 分鐘搞定一個中型 PR。重點不是更快，而是更系統化——不會漏看重要的東西。
Step 1：/plan 拆解審查範圍
先在專案目錄開 Claude Code，然後：
請針對這個 PR 做 code review。先用 /plan 產出審查計畫：
- 分三層：高風險 / 中風險 / 低風險
- 每層列出要看的檔案與檢查點
- 補一份 review checklist
Claude 會回你一份按風險分層的審查計畫。高風險通常是付款邏輯、權限控制、資料庫操作；低風險是 CSS 修改、文件更新。
為什麼要先 /plan？ 因為如果你直接把整個 diff 丟給 AI 看，它會給你一大段空泛的回覆。先拆解範圍，每段的分析品質會好很多。
你也可以先跑 git diff main...HEAD --stat 拿到變更摘要，讓 /plan 更精準。
Step 2：按計畫逐段 Review
按 /plan 的順序，從高風險開始：
請先檢查高風險區段：
- src/payment/checkout.ts
- src/order/discount.ts
請指出：
1) 邏輯錯誤
2) 邊界條件
3) 測試覆蓋
一次只看 1-2 個檔案。 一次丟太多，模型的 context 會過載，產出品質會下降。你有沒有遇過 AI review 到後面開始講一些莫名其妙的東西？八成就是 context 太長了。
如果需要補上下文（比如比較新舊邏輯）：
這段是舊的邏輯：
<貼舊版程式碼>
請比較差異並指出可能的回歸風險。
Step 3：/copy 產出 PR Review 內容
Review 完了，用 /copy 整理成可貼的格式：
請用 /copy 產出可貼到 PR 的 review 回覆：
- Summary（2-4 句）
- Risks（條列）
- Suggestions（具體修改方向，最多 3 個）
- Checklist
格式用 GitHub Markdown。
出來的東西直接複製貼進 PR comment，省去自己排版的時間。Review 最花時間的不是找問題，是打字。
模板參考
## Review Summary
- （2-4 句摘要）
## Risks
- [ ] 風險 1：...
- [ ] 風險 2：...
## Suggestions
- 建議 1：...
- 建議 2：...
## Checklist
- [ ] 功能正確
- [ ] 邊界條件
- [ ] 效能
- [ ] 安全性
- [ ] 測試涵蓋進階：Multi-Agent 分工 Review
如果 PR 很大、涵蓋多個面向，可以用多個 Agent 分工：
- Agent A：高風險邏輯（付款、訂單、權限）
- Agent B：效能（查詢、快取、N+1）
- Agent C：安全與測試
最後讓主 Agent 收斂成一份統一的 Review。
多代理不是為了「更快」——事實上可能更慢。它是為了更穩定，不會因為單一模型的盲區而漏掉重要問題。
常踩的坑
- 一次 review 太多檔案 → AI 產出變空泛。解法：拆段，按 /plan 逐檔看
- 沒給背景 → 結論不精準。解法：貼 PR 描述、舊邏輯、相關 issue
- output 太長 → 沒人想看。解法：要求「只保留關鍵風險 + 3 個具體建議」
好的 Review 不是找到所有 bug，而是找到最重要的那幾個。/plan 幫你先知道「重要」在哪。