Claude Code /code-review 完整教學：從 /simplify 改名後，AI 用四個 Agent 幫你掃 PR

打開 PR review，1200 行變更，今天不用吃午飯了。

這是台灣工程師每週都會遇上的場景。然後你看著 diff 想：「能不能把這事丟給 AI？」——可以，但 Claude Code 之前的 /review 命令，不是太囉嗦（順手幫你改 code）就是太保守（只列 nit）。

直到五月中，Anthropic 把它整個換過。原本叫 /simplify 的命令改名為 /code-review、移除「順手修補」的行為、改成四個平行 agent 掃 diff、confidence ≥ 80 才出聲、加上 --comment 直接把 inline 評論發到 GitHub PR。

這個改動的好玩在於——不是新增功能，是刪除功能。Anthropic 把命令收窄到「只做一件事」：找 correctness bug。其他的事它不做。

這是這篇要拆給你看的：為什麼這樣設計、怎麼用、什麼時候別用。

三秒先講結果

把這個指令背起來：

# 在 PR 分支上，輸出到終端機
/code-review high

# 在 PR 分支上，把問題用 inline comment 發到 GitHub
/code-review high --comment

high 是 effort level，可以換成 medium 或 low。--comment 是把結果發到 PR。沒這兩個參數，預設行為是中等強度、輸出到 terminal。

跑完之後 AI 會：

啟動 4 個 review agent 平行掃 diff
每個發現的問題給一個 0-100 的 confidence 分數
只輸出 ≥ 80 分的問題
結果去重、按嚴重性排序
有 --comment 就 post 到 GitHub，沒有就印在 terminal

整個過程不修 code，只指出 bug 在哪。它變成一個只做評審的工具，不再順手改東西。

為什麼從 /simplify 改名

這是這次改動最容易被忽略、但最值得想的地方。

原本的 /simplify 行為是「找到 bug，順手清乾淨」。聽起來好像很貼心——AI 看出問題、AI 直接修——但實務上會發生兩件事：

第一，reviewer 看不到問題就被解掉了。你提了 PR，AI 在背景跑 /simplify，回來告訴你「好了喔」。你不知道它改了什麼、為什麼改、有沒有改錯。code review 的價值有一半在「看見問題」，這層被跳過了。

第二，修補本身可能引入新 bug。AI 改 bug 的時候很自信，但它的修補是不是真的對？沒人複查。原本的程式碼有 bug 是已知的，AI 修完的程式碼有沒有 bug 是未知的——多了一個變數。

/code-review 的設計選擇剛好相反：只找問題、不修問題。修補的決策權還給人。這個決定看起來像功能變弱了，實際上是把工具的角色講清楚——它是一個 reviewer，不是一個 fixer。

工具角色一清楚，搭配的工作流才能穩定。reviewer 不會偷偷改東西，所以 reviewer 可以跑得更積極（每個 PR 都跑、跑多次）；fixer 由你決定要不要做、做哪些——這層是不能被外包的判斷。

四個 Agent 平行掃描的意義

/code-review 觸發時，Claude Code 會在背景開 4 個 review agent，各自獨立看同一段 diff。

為什麼是 4 個？這跟 LLM 的「多次採樣」邏輯有關。同一個模型同一個 prompt，每次推理會給略不同的答案。如果你跑 4 次、4 次都說「這行有問題」，這個 bug 的可信度遠高於「跑 1 次說有問題」。

具體做法是這樣：

4 個 agent 分別跑完，各自列出他們發現的 issue
每個 issue 比對其他 agent 的結果，給一個 confidence score（多少個 agent 都看出來）
把 score < 80 的 issue 砍掉
剩下的 issue 去重（同一個問題不同說法只留一份）
按嚴重性排序輸出

這個設計把 LLM 的「隨機性」變成資產，而不是負債。單跑容易有假警報（false positive），四跑取交集就把雜訊濾掉一大半。

想自己調 confidence 門檻可以改 commands/code-review.md 裡的 80，範圍 0-100。設低了會收到一堆 nit，設高了可能漏 bug。預設 80 是個平衡點。

Effort Level 怎麼選

high / medium / low 不是「看多認真」的差別，是「掃多深」的差別。

**low**：快速看一輪，找明顯的 logic error 與 typo。適合 1-2 個檔案的小變更。
**medium**（預設）：深一點，會看 edge case 與 null check。適合 PR 範圍 200-500 行。
**high**：完整檢查，會跨檔案追 data flow、檢查 race condition、評估錯誤處理。適合 500 行以上、或者觸碰核心邏輯的 PR。

實務經驗：高度自信的小 PR 用 medium 就夠了。觸碰共用 module、改了 schema、跨服務的、production 路徑相關的——直接 high，多花的時間值得。

–comment 三種行為模式

--comment 旗標的行為要分三種情況講，因為跟你預期可能不同：

情況	沒有 `--comment`	有 `--comment`
沒發現問題	在 terminal 印「沒問題」	在 PR 留一個「review complete, no issues」摘要
發現問題	在 terminal 印 issue 清單	在 PR 各行 post inline comment + 摘要

第二格是這個指令最值錢的地方。Claude 會根據每個 issue 的位置，直接在那一行 GitHub PR 的程式碼旁邊留評論，跟人類 reviewer 的留言完全一樣。摘要會放在 PR 評論區，列出總共幾個 issue、按嚴重性分類。

注意一個細節：沒給 --comment 但發現問題，預設不會發到 GitHub。這是個保護性設計——你跑 /code-review 練習一下、看看 AI 抓得準不準，不會誤觸發 PR 上的雜訊。要真的發出去得明確加 flag。

三種典型工作流

本地預檢，發 PR 前先掃

git checkout -b feat/payment-flow
# ... 寫 code ...
git push
gh pr create --draft
/code-review medium

本地跑、輸出 terminal、看完 AI 的建議再決定發不發 PR。等於把自己的 PR 先當別人的 PR 來 review 一次，抓掉低級錯誤再給人看。

Reviewer 用來輔助

1 2	gh pr checkout 1234 /code-review high --comment

PR 收到要 review，先 checkout 下來、跑高強度評審、把 AI 認為有問題的點直接 post 到 PR 上。剩下要自己看的就是 AI 沒看出來的部分——business logic、設計合理性、命名好壞——這些 AI 不擅長判斷，但 logic bug / null check / race condition 它抓得快。

整合到 CI 自動跑

# .github/workflows/code-review.yml
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Claude Code Review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          claude -p "/code-review high --comment"

每次 PR 開或更新，AI 自動掃一次。人類 reviewer 進來看的時候，AI 已經把該抓的抓好了。注意要設預算上限，免得跑爆——/code-review high 在大 PR 上會吃不少 token。

什麼時候不要用

第一種：你要的是「重構建議」，不是「找 bug」。/code-review 不會跟你說「這段拆成兩個 function 比較好」，它只找 correctness 問題。要重構建議用其他指令或直接問 Claude。

第二種：PR 範圍極小（< 30 行）。四個 agent 平行跑一次 token 成本不小，30 行 diff 自己看比較快。

第三種：你正在學一個新框架。AI 可能誤判 framework-specific idiom 是 bug，會干擾你判斷。等熟悉了再跑。

第四種：security review。/code-review 找的是 correctness bug，不是 security vulnerability。安全議題用 /security-review，那是另一個指令、用另一套 prompt、跑另一組檢查。

跟舊的 /review 命令的差別

有些教學文還會教你跑 /review——那是另一個指令，行為類似但更簡化。差別整理：

指令	用途	confidence 過濾	改 code	適合場合
`/review`	通用 PR review	沒有	不改	快速看一眼
`/code-review`	找 correctness bug	confidence ≥ 80	不改	嚴肅 review
`/security-review`	找安全漏洞	安全規則匹配	不改	release 前掃
`/simplify`（已廢棄）	找 bug 順手修	—	會改	已不建議用

簡單記：要 AI 幫你決定發不發出去用 /code-review，要 AI 快速看一眼跟你聊聊用 /review。

一個常見踩坑

跑 /code-review high --comment 在大 PR 上，結果 GitHub PR 多了二十條 AI inline comment——人類 reviewer 進來嚇一跳。

解法是把 confidence 門檻拉高。改 ~/.claude/plugins/code-review/commands/code-review.md：

1 2	# 把這行的 80 改成 90 或 95 issues with confidence >= 80

confidence 90 大概只會留下 4-6 個最有把握的 issue，PR 看起來乾淨多了。代價是漏報率上升。

如果你還是擔心 AI 留太多 comment，先用 --comment 留 draft：

1
2
3

/code-review high
# 看完輸出後，如果覺得 OK 再
/code-review high --comment

兩段式：第一次本地看，第二次發到 PR。多花一次 token，但能控制最終 PR 上看到什麼。

為什麼這個指令值得放進日常流程

回到開頭那個 1200 行 PR 的場景。

人類 reviewer 看完 1200 行的時間是 1-2 小時，注意力會在後半段衰退——前 200 行抓得很細，後 1000 行只看 commit message 就 LGTM。這是人類 review 不可避免的偏差。

/code-review high --comment 把這 1-2 小時的工作切兩半。AI 的注意力不會衰退，1200 行對它跟 200 行對它的精細度差不多——前提是 token 預算夠跑高 effort。它先把「明顯的 correctness bug」抓完，人類 reviewer 進來的時候，剩下要看的是 AI 抓不到的層次：