/code-review 跟我自己請 Claude 幫忙看程式碼（不用這個指令，直接在對話裡貼程式碼問）,實際上有什麼不同？
最大的差異在於「執行方式」與「上下文使用」。直接在對話裡貼程式碼問,審查過程會佔用主對話的上下文空間,如果審查的檔案較多,容易讓對話變得冗長；/code-review 目前是以背景 subagent 執行,擁有自己獨立的上下文視窗,逐檔分析的過程不會佔用主對話的空間,只有最終結果會被送回來。
另一個差異是預設的審查範圍。直接在對話裡問,審查範圍完全取決於你貼了什麼、問了什麼；/code-review 有明確定義的預設行為(審查目前 diff,或指定的 PR),這代表你不需要自己手動把要審查的程式碼複製貼上,它會直接去讀取實際的變更內容。對於已經有明確 diff 或 PR 的情境,/code-review 通常比手動貼程式碼問更省事;但如果你只是想針對某一小段邏輯快速討論,直接在對話裡問可能反而更直接。
如果我不確定該用哪個 PR 編號,或不確定目前的 diff 範圍到底是什麼,有沒有簡單的方法先確認清楚?
最直接的做法是在下 /code-review 之前,先用一般的 git 指令確認狀態:git status 可以看到目前有哪些檔案被修改、新增或刪除;git diff 則可以看到具體的變更內容。如果你的變更已經推送成一個 PR,可以直接到 GitHub(或你使用的程式碼託管平台)上查看這個 PR 的編號,再把編號帶入指令。
如果不確定是不是有話還沒提交,一個實用的習慣是:在跑 /code-review 之前先問自己「如果現在這個審查結果只涵蓋我還沒提交的變更,會不會漏掉我想要它檢查的東西」——如果答案是會,代表你可能想要審查的是一個已提交的 PR 而不是目前工作區的 diff,這時候直接在指令後面帶上 PR 編號會更準確。
背景執行的審查完成後,如果我覺得某條建議寫得不夠具體、看不懂它到底在說什麼,該怎麼追問比較有效率?
比較有效率的追問方式,是直接引用審查結果裡那句讓你看不懂的具體文字,並問清楚兩件事:「這條建議具體指的是哪一行、哪個函式」以及「為什麼這會是個問題,不改的話實際會發生什麼狀況」。這種具體的追問通常比模糊地問「這條是什麼意思」更快得到有用的回答,因為你已經幫忙把問題範圍縮小了。
如果追問後發現這條建議其實跟你們專案的實際情況不符(例如它建議的寫法在你們專案裡有特定原因不能這樣做),可以直接說明這個背景脈絡,讓對話回到「這個建議在我們的情境下該怎麼調整」,而不是單純接受或拒絕。這種來回討論本身,也是判斷這條建議是否真的該採納的過程,不需要急著在第一時間就做決定。
如果我是團隊裡第一個嘗試把 /code-review 導入日常流程的人,該怎麼跟團隊其他成員說明、建立起大家對它的合理期待?
比較實際的做法,是先自己實際跑過幾次、蒐集具體案例,再拿這些案例去跟團隊溝通,而不是空泛地說「這個工具很好用」。例如可以整理出「這幾次審查裡,它確實抓到了我自己沒注意到的邊界情況」跟「這幾次它給的建議跟我們團隊的慣例不符,需要人工判斷」這兩類具體例子,讓大家清楚知道它的強項跟限制分別在哪裡,而不是誤以為它是萬能的自動化把關機制。
對團隊溝通來說,最重要的一個心態校準是:/code-review 提供的是一份值得參考的意見,不是取代人工審查的機制。把它定位成「在人工審查之前先跑一輪,篩掉一些明顯問題,讓人工審查可以把力氣放在更需要專業判斷的地方」,通常比讓大家誤以為「有這個工具就不需要人工 review 了」更貼近實際使用效果,也比較不會因為過度期待而在第一次踩到限制時就對這個工具失去信任。
如果你是第一次在 Claude Code 裡跑 code review，最直接的入門方式是打開一個已經有一些程式碼變更（尚未提交，或已經提交成一個 PR）的專案，在對話裡輸入 /code-review。這個指令會分析目前的差異（diff）或指定的 PR，逐項檢查程式碼問題，並在完成後回報結果。以下用一個第一次使用者最常遇到的完整流程，說明每一步實際會發生什麼、以及新手容易在哪裡卡住。
/code-review 預設審查的是目前的 diff——也就是你已經修改、但可能還沒提交的變更內容。如果你想審查一個特定的 PR，可以直接在指令後面加上 PR 編號：/code-review <level> <pr#>。新手常見的困惑點是不確定「現在到底審查的是什麼範圍」，比較保險的做法是先用 git status 或 git diff 確認一下目前實際有哪些變更，再下 /code-review 指令，避免審查範圍跟預期不符。
目前 /code-review 是以背景 subagent 的形式執行，這代表審查過程本身（逐檔讀取、分析）不會即時顯示在對話裡，你會看到的是審查完成後回報的結果，過程中你仍然可以在同一個對話串裡繼續處理其他事情。第一次使用的人容易誤以為「畫面沒有動靜代表卡住了」，實際上這是正常現象——背景執行的用意就是不讓審查過程佔滿對話畫面，耐心等待回報即可，如果想確認進度，也可以觀察它是否還在背景執行中。
審查完成後，回報的內容通常會指出具體的問題點（例如潛在的邊界情況、可讀性建議、是否符合專案慣例）。這個階段容易出現的誤區是「把每一條建議都當成必須修改的規定」——實際上這些是建議，你仍然需要用自己對這段程式碼的理解去判斷哪些真的該改、哪些可以先擱置。如果某條建議看起來牽涉到你不熟悉的邏輯，直接在同一個對話裡追問「這條建議具體是指哪裡、為什麼會是問題」,通常比自己憑感覺猜測更快釐清。
第一個常見誤區,是把 /code-review 當成一次性、什麼都不用管的黑盒子操作。比較好的心態是把它當成「一位經驗豐富但不了解你們團隊慣例的同事」給的意見——它抓出的問題通常值得認真看，但最終要不要照做,還是要結合你對專案脈絡的理解。第二個誤區,是審查範圍抓錯,例如以為自己在審查整個檔案,結果其實只審查了 diff 裡的變更部分,導致漏看了沒改動、但其實也有問題的舊程式碼——如果需要審查整個檔案而不只是變更部分,要另外明確說明。
對第一次使用的人來說,最實際的建議是:先在一個影響範圍小、就算審查結果不完全準確也不會有嚴重後果的分支上試跑一次,實際感受一下它抓出來的問題型態跟你原本自己 review 的習慣有什麼異同,再決定要不要把它納入正式的開發流程。跑過一兩次之後,你會比較清楚它擅長抓哪類問題(例如明顯的邊界情況遺漏)、哪類問題可能還是需要你自己憑專案脈絡判斷(例如是否符合團隊內部不成文的慣例)。