信任它：驗證無人監督的執行
您把一項任務交給 Claude，讓它在沒有人盯著每一步的情況下執行。現在它說已經完成了。在您將這項工作交付出去之前，您需要一種方法來檢查一個您根本沒有監督過的過程。這種檢查，正是讓無人看管的 Claude Code 能夠安心依賴的關鍵。
這裡的想法很簡單：驗證的程度應該與您給這次執行多少自由度成正比。如果您在一個短暫的工作階段中看著訊息一行行捲過，那麼快速瀏覽一下就足夠了。但一次無人看管的執行，或是在持續整合中觸發、沒有任何人參與的工作，就需要真正的檢查。沒有人看到發生了什麼，所以您必須事後重建整個過程。
有個方法可以幫助您理解這一點：您看得越少，就越需要驗證。
讓無人看管的執行保持在自動模式
當工作中的某次執行處於無人看管狀態時，請讓它保持在自動模式，而不是繞過權限。在自動模式下，分類器仍會審查大多數動作是否有危險。這是一個值得保留的安全網。
但要清楚這個安全網能做什麼、不能做什麼。分類器從不判斷程式碼是否真的正確，它只會標記危險的動作。所以您的驗證標準應該維持不變。請根據這次執行的無人監督程度來設定這個標準。
從差異開始，而不是從摘要開始
不要從 Claude 對其所做工作的摘要開始，而要從差異本身開始。
- 執行
/code-review來檢視變更並標記問題。 - 接著親自檢視
git diff。
陷阱在於：一份讀起來完全合理的整潔摘要，而實際的差異卻動到了一個您完全沒預料到會被動到的檔案。摘要不會告訴您這件事，但差異會。
所以請閱讀實際變更的內容。先閱讀屬於計畫內的檔案，然後再尋找計畫之外的任何東西。一份乾淨的說明並不能證明程式碼是乾淨的。
把測試變成一道關卡，而不是一個承諾
無人監督執行過程中真正的關卡，在於測試是否通過，以及 Claude 是否真的執行了測試，還是只是聲稱執行過。不要把這件事交給信任來決定，而要把它接成一個 hook，讓 Claude 無法跳過它。
有幾個 hook 可以完成這項工作：
- 一個 stop hook，會執行您的測試，並在失敗時拒絕結束該回合。
- 一個 post-tool-use hook，會在每次編輯後進行 lint 與型別檢查。
關鍵細節在於結束代碼。一個以 exit 2 結束的 hook，會把失敗直接回饋給 Claude。Claude 讀到這個失敗後，會在您不用開口的情況下自行修正。最棒的是，這項檢查會在每次執行時觸發，無論您是否記得要求它這麼做。
取得一個冷靜的第二意見
您在發出 pull request 之前會執行的子代理程式碼審查，在這裡同樣適用。把它指向一次無人監督的執行。
開啟一個全新的工作階段或子代理，讓它在完全不知道程式碼是如何建構出來的情況下審查變更後的程式碼。因為它對所採用的方法沒有任何既得立場，所以它能抓出原本執行過程中自我說服而忽略掉的問題。一位帶著全新視角的第二審查者，能找出作者自己合理化掉的問題。
整合起來
讓檢查的嚴謹程度，與這次執行無人監督的程度相匹配：
- 親自閱讀差異。
- 把測試變成一個能把關該回合的 hook。
- 透過 JSON 結果與結束代碼來驗證無頭執行。
- 對任何重要的事情，取得一個冷靜的第二意見。
做到這些，「Claude 在我沒看著的時候完成了這件事」就不再需要靠信念來支撐。