Sprint 收尾那幾天，PR 排隊排到五、六個，每個都要在開會前看完。PR #123 改了六個檔案、380 行，20 分鐘後要開會，只能快速掃過去。那段限制檢查的邏輯看起來沒問題，留了 LGTM。上線兩週後才發現，外部 API 回呼還沒結束前，判斷式就先放行了——那個 race condition 藏在第三個檔案，掃過去的時候沒注意到。
環境備好了（上一篇提過），PR 也能實際跑起來，但「跑一次」抓不到所有問題，尤其是這種要對照好幾個檔案才看得出來的邏輯漏洞，也不是每次都有時間逐行讀完 380 行 diff。這篇要處理的是，怎麼在 PR review 這個環節，讓 AI 先幫忙掃一輪，抓出可能有問題的地方，人再針對這幾條做最後判斷。
為什麼在本機跑，不只是看網頁上的建議
GitHub 網頁上如果掛了 Copilot 之類的 review 建議，看到的只有 diff 那幾行文字，沒有整個 repo 的上下文。像 Claude Code 這種在本機跑的工具不一樣：它能讀到完整的原始碼，可以順著函式呼叫往下追、看關聯的測試怎麼寫，不是只憑 diff 那幾行猜前後文。PR #123 那個 race condition，光看 diff 看不出來外部 API 是非同步呼叫，得追進 client.ts 才看得到——這正是在本機、有完整 repo context 的工具才做得到的事。
macOS 安裝 Claude Code
npm install -g @anthropic-ai/claude-code
裝好之後在任何一個 repo 目錄下打 claude 就能啟動，第一次執行會走瀏覽器登入。
其實一句話就夠
不用先手動 gh pr checkout、再 git worktree add。實務上大部分時候是這樣：cd 進手上這個 repo（不用先切到 PR 那個分支），打開 claude，直接貼 PR 網址請它看：
幫我 review 這個 PR：https://github.com/org/repo/pull/123，
注意有沒有 race condition，findings 要附檔名跟行號。
Claude Code 自己會用 gh pr diff、gh pr view 這類指令抓資料，需要看到完整上下文時，也會自己判斷要不要 checkout 分支來讀原始碼，不需要你先把前面那幾行指令打好等它。真正要自己手動 gh pr checkout 加 worktree 的時機，是你自己要實際跑這個 PR 的情況——下面會提到。
用 /code-review 讓流程固定下來
一句話夠用，但每次想到什麼就講什麼，遺漏的機會也比較大。Claude Code 內建的 /code-review 指令把這件事變成可以重複執行的流程，可以直接帶 PR 編號或網址當目標，一樣不用先手動 checkout：
/code-review high 123
effort 分好幾級，low／medium 找得少、但幾乎都是真的問題；high 到 max 覆蓋範圍更廣，連不太確定的線索也會列出來，花的時間也更長。日常 PR 用 high 大致夠用，牽涉到金流、權限這類影響大的改動，才值得拉到 max。
跑完會列出幾條 findings，每條附檔名、行號，例如：
[correctness] service.ts:142
限制檢查在 client.ts 的 confirm 回呼完成前就先放行，
這個外部 API 是非同步呼叫，這裡有 race condition。
[simplification] service.ts:88
轉換邏輯跟 repository.ts:34 重複，可以抽成共用函式。
這份清單不是結論，是待驗證的線索。第一條對照程式碼確認是真的問題，第二條看過之後覺得目前重複的量還不大，先不動。留言只留給驗證過、真的要處理的那幾條，不是把 AI 列的東西整包貼上去。驗證過確定要處理的，可以讓它直接貼成 PR 的 inline comment：
/code-review high --comment
覺得改法明確、想先看套用後的樣子，可以讓它套到工作目錄，但不會自動幫你 commit：
/code-review high --fix
套用之後還是要自己看一次 diff，確認改法沒有動到不該動的地方，再決定要不要 commit。
需要實際跑程式時，才用 worktree
讀 diff、追函式呼叫，AI 靠 gh 抓資料就夠了，不用真的把 PR checkout 到你的工作目錄。但如果懷疑的地方牽涉到執行期行為——像 PR #123 那個 race condition，想親自送一筆超過上限的請求進去看看是不是真的被擋下來——這時候才需要 上一篇 講的 gh pr checkout 加 git worktree add，把 PR 拉成一個真的能跑起來的環境，自己動手測。
/code-review ultra：排隊排很長的時候
PR 多到來不及一個一個看的時候，/code-review ultra 可以直接對一個 GitHub PR 下，背後是雲端跑的多個 agent 一起看：
/code-review ultra 123
這個指令要使用者自己觸發、而且會計費，AI 助理不會自己幫你發動；跑之前它會先跳出確認畫面。排隊排到五、六個 PR 的那種時候，比較適合用來先篩過一輪，抓出真正需要人工細看的那幾個。
請 AI review PR 時，指令要講清楚驗證的分寸
跟前兩篇同樣的道理：AI 遇到不確定的地方，容易傾向給一個「看起來合理」的說法，但「看起來合理」跟「真的是問題」是兩回事，尤其 code review 這種需要判斷業務邏輯對不對的事，最後一步該留給人：
請審查 PR #123 的改動。
規則：
1. 每一條 finding 都要附檔名、行號，並說明具體會在什麼輸入或情境下
出錯，不要只給「建議這樣寫比較好」這種沒有具體失敗情境的意見。
2. 不確定是不是真的問題的，明確標成「不確定」，不要包裝成肯定的
結論。
3. 列完 findings 之後停下來，等我逐條確認，不要自動用 --comment
貼到 PR 上。
4. 如果用 --fix 套用修正，只改 finding 提到的那幾行，不要順手重構
看不順眼的其他程式碼。
重點在「附具體失敗情境」跟「列完先停」這兩點。前者逼 AI 給出可以驗證的線索，而不是空泛的建議；後者確保留言留給人核可過的內容，不是 AI 掃過一遍就自動公開貼上去。
AI 抓範圍，人做判斷
一句話貼 PR 網址，或是用 /code-review 固定流程，做的都是同一件事：讓 AI 先在 380 行 diff 裡圈出值得花時間細看的地方。真的要驗證執行期行為，再拉回上一篇的 worktree 流程自己跑一次。兩件事合起來，PR #123 那種藏在第三個檔案裡的 race condition，不會等到留了 LGTM、上線兩週後才被發現。
AI 找到的永遠是待驗證的線索，不是可以直接採信的結論——這條界線清楚，review 的品質才不會因為省了讀 diff 的時間而打折扣。