不被它唬:怎麼又快又準地審 Claude Code 的 diff

你已經敢讓 Claude Code 在你的 repo 跑任務，也設好了權限。最後一個上手技能，是它把 diff 交回來時——怎麼審，才不會收進一個有 bug 的版本，也不會把它的工作整個重做一遍。

先認清楚：測試綠 ≠ 正確

最該內化的一件事：AI 寫的 code 出錯時，不會長得很可疑。它會交一段排版整齊、命名漂亮、測試還綠的 code——而問題藏在測試沒涵蓋的地方，或它順手寫的一個其實不存在的 API、一個它「以為」的函式簽名。模型自信地產出錯誤的東西，這叫幻覺;在寫 code 上，它特別會「編一個看起來很合理的 API」。

它說「測試綠了」只代表「它寫的測試過了」，不代表「它寫的測試是對的、涵蓋夠的」。綠燈是起點，不是結論。

把它當一個 PR 來 review

最簡單的心態：它交的 diff，就是一個資淺同事開的 PR。 你不會盲 merge 別人的 PR，也別盲 merge 它的。你本來就會的 code review 技能，原封不動拿來用。

抽查風險最高的地方，別逐行重寫：

• 邏輯與邊界:核心邏輯對嗎？空值、錯誤、邊界情況有處理嗎？——這是 bug 最愛藏的地方。
• 它用的 API／函式真的存在嗎:特別是你不熟的 library。它可能很篤定地呼叫一個不存在的方法。
• 它寫的測試測對了嗎:測試是不是只測了 happy path?有沒有測到你真正在乎的那個情況？斷言是不是真的有意義(別只是 expect(true).toBe(true))?
• 它沒改到的地方:有沒有漏掉該一起改的呼叫端？有沒有順手改壞、或刪掉不該刪的東西？

至於排版、命名這種，有 hooks 跑 formatter／lint 把關，你不用花眼力。力氣花在「機器擋不掉、錯了代價大」的地方。

讓它幫你縮小審查範圍

你不用獨自硬看。可以直接要求它把審查變簡單：

• 「改完後，跟我說你動了哪些檔、每個檔為什麼改。」
• 「列出你不確定、或我可能想再確認的地方。」
• 「你用到的外部 API，標出來，我要核對文件。」

它常會老實列出幾個它沒把握的點。這不是讓它自我背書，是用它的速度幫你標出可疑區，你再針對那幾處親自看。

力道對準後果

不是每個 diff 都要同樣嚴格，用後果決定：

• 拋棄式的腳本、本地實驗:跑得動、結果對就好，快速掃過。
• 要進 main、會上 production、別人會依賴的 code:每一行都讀、邊界都想、測試的品質都查——而且這類動作本來就該停在你核准那一關。

審查和權限是同一件事的兩面：權限閘擋的是「它做之前」，review 擋的是「你收之前」。 兩道都過，這段 code 才真的能算你的。

你仍是負責的人

說到底：不管是誰、哪個 agent 寫的，進了你 repo、掛你名字 merge 的 code,負責的是你。 Claude Code 讓你寫得更快，不讓你不用負責。把這個心態擺正，你會自然養成讀 diff 的習慣——而這正是用 AI 寫 code 不出事的關鍵。

上手階段：你已經會用了

走到這裡，你學會了這條路線最核心的三件事：把任務講成規格、設好權限與 hooks、像審 PR 一樣審它的 diff。加上入門的動手經驗，你已經能放心讓 Claude Code 處理真實工作了。

接下來進階階段，把效益放大：用子代理與 Dynamic Workflows 跑單一 session 扛不動的大任務，再用 MCP 與自訂指令把 Claude Code 接進你的系統、自動化你的工作流。

林子睿（編輯：廖玄同），《不被它唬:怎麼又快又準地審 Claude Code 的 diff》，矽基前沿 [Si]gnals，2026-06-19。https://signals.tw/articles/claude-code-verify-diff/