當您交給 Claude Code 一項在您的程式碼庫中完成的任務時，Claude 通常會以簡潔的方式回報結果。在 Claude 所做變更的說明下方，可能會列出各種被變更的檔案（從小幅修改到重大變更都有）。通常，撰寫程式碼變更本身（並加以說明）的那個對話階段，並不是判斷這些變更品質的最佳人選。養成習慣，在保留每項變更之前先自己檢視一遍，然後讓 Claude 在一個乾淨的上下文中、不帶這個對話階段歷史記錄的情況下，再次審查它，是個好做法。
審查實際的變更內容
差異（diff）是一項變更的前後對照：逐檔案列出被移除的行與新增的行。/diff 指令會以這種形式開啟一個互動式檢視器，顯示您尚未提交的變更，它也可以顯示 Claude 每一輪對話所做的變更。使用上下鍵在檔案之間移動，按 Enter 開啟其中一個檔案。
/diff每次都值得再看一眼的最重要事項是：
- 您沒有要求的變更。 例如在 Claude 處理某個檔案時，某個設定值被修改了，或是某個您沒有提到的輔助方法被重寫了。
- 變弱的測試。 如果您所處理的專案包含測試，請找出是否有任何測試被跳過、刪除，或被放寬條件直到通過為止。
- 新套件與寫死的數值。 例如只為了一個函式而新增的相依套件，或是直接寫在程式碼中的網址或金鑰。
如果整個變更都是錯的，請執行 /rewind（或在空白提示上按兩次 Esc），選擇產生該變更的提示，然後選擇還原程式碼與對話。有一個限制值得了解：由 Claude 執行的 shell 指令（例如安裝套件）所變更的檔案，不會被還原。
下方的練習使用一個小型的註冊表單任務：上方是 Claude 的摘要，下方是 Claude 所碰過的八個檔案。
請求第二意見
「探索 → 規劃 → 編碼 → 提交」課程提到，在提交變更之前，應該讓第二位審查者檢視該變更。一個長時間的對話階段會帶著它所讀過與決定過的一切。那正是您在上一課學到要管理的上下文，而這正是您不希望審查者帶有的歷史記錄。/code-review 就是那位第二審查者：它會在一個乾淨的上下文中審查變更，不帶有您這個對話階段的任何歷史記錄，並回報它的發現。除非您要求，否則它不會編輯任何內容。
/code-review審查會在背景執行，耗時從幾秒到幾分鐘不等，並且會像其他任務一樣計入您的用量，因此請把它留給值得再看一眼的變更使用。審查完成後，發現的問題會出現在您的對話中。您也可以用白話文詢問，Claude 可以根據您的請求啟動相同的審查。如果 Claude 直接在對話中回答而不是啟動審查，請自行執行該指令。
針對這個註冊表單的變更，審查回報了四項發現：
決定如何處理每項發現
將每項發現歸入以下三堆之一：
- 立即修復。 這是一個真實的問題，它很重要，而且必須修復。
- 詢問原因。 這一堆是給那些您無法完全確認，或感覺不太對勁的發現。審查者在冷讀程式碼變更時，也有可能會遺漏一些東西。
- 先放著。 這是一個真實的問題，但規模小或影響不大。這些通常可以批次處理，留到未來某個對話階段一併修復。
若要詢問原因，請把該發現原封不動地引述給 Claude，並請 Claude 再檢查一次。針對上面的第二項發現，您可以這樣輸入：
每當您要求修復時，最好一併要求提供證據：
如果某項修復最終演變成一個龐大的獨立變更，請再次執行審查。
什麼時候值得更仔細地審查
一個簡單的單行變更，通常只需要快速瞄一眼差異就夠了，不需要其他動作。當一項變更大到您無法在腦中完整掌握、當它觸及敏感內容或會造成破壞性後果時，以及在把工作交給團隊成員之前，您都應該同時使用人工審查與 Claude 審查。
實際試試看：將四項發現分類
重點回顧
- 在單憑摘要就信任之前，先閱讀檔案變更的實際差異。執行
/diff，留意您沒有要求的變更、變弱的測試，以及新套件或寫死的數值。 - 用
/code-review從乾淨的上下文取得第二意見（或用白話文詢問，讓 Claude 自行啟動）。審查者負責回報，除非您要求，否則 Claude 不會進行編輯。 - 把每項發現歸類為立即修復、詢問原因，或先放著，並且每次要求修復時都一併要求提供證據。
當審查者多次標記出同一個問題時，為 Claude 撰寫一條規則，讓它在每個對話階段開始時讀取，可能會是個好主意。那個檔案就是 CLAUDE.md，也是下一課的主題。