前言

昨天的結論是：Claude 讀規格寫實作，也讀同一份規格寫測試，那 code review 呢？今天就拿系統裡那個已知的問題來測試。

同一份程式碼，三種問法拿到三種東西

昨天講掃描型檢查的時候提過「要清單不要結論」。放到 review 上更明顯，我把三種問法排開來看：

第三種才是 review 該有的樣子。差別不在它多聰明，而是我有沒有把判準給它。

這跟昨天那條分界線是同一件事：判準寫在文件裡的，它做得比我好；判準還在我腦子裡的，它只能猜。差別是 review 這裡多了一個選項——我可以在提問的當下把判準交出去，不一定要事先寫進規格。

怎麼驗證 review 本身

Review 會產出「發現」。發現這個東西的麻煩在於，它讀起來都很有說服力——有檔名、有行號、有推論鏈，看起來像結論其實是假設。

今天我自己讀 lib/api.ts 的時候就抓到一個。這段是 HTTP 那一層處理錯誤的地方：

    // 一張不再有效的 token 留著只會讓每個請求都 401。丟掉它，App 就會回到
    // 登入畫面——但**只丟 token，不碰使用者正在編輯的內容**。
    if (error.status === 401) clearToken()

然後 App.tsx 的第一行狀態是這樣：

const [token, setTokenState] = useState(currentToken)

useState 只讀一次。全 repo 沒有任何地方監聽 storage 變化。所以註解裡那句「丟掉它，App 就會回到登入畫面」，看起來是假的。

如果我就這樣寫進 review 報告，它會是一個錯的發現。

因為那句話裡其實藏了兩個獨立的主張，而它們不一定同真同假：

1. 401 之後，localStorage 裡的 token 真的被丟掉了
2. 丟掉之後，畫面會回到登入表單

所以我一條斷言寫一條測試：

it('後端回 401，localStorage 的 token 確實被丟掉', async () => { ... })
it('token 丟掉之後，畫面回到登入表單', async () => { ... })

跑出來：

× token 丟掉之後，畫面回到登入表單
TestingLibraryElementError: Unable to find role="button" and name "登入"
Tests  1 failed | 1 passed (2)

第一條綠、第二條紅。

所以真正的缺陷不是「token 沒被清掉」——它清得好好的。真正的缺陷是清掉了，但沒有人知道。React 的狀態沒有跟著變，使用者會坐在一個每個請求都失敗的畫面上，直到自己按重新整理。

這兩種說法會導向完全不同的修法。前者要去改 clearToken，後者要去改狀態怎麼傳。只差在有沒有拆開來驗。

驗證發現的三個動作

• 把發現拆成幾條各自可以獨立為真或假的斷言。 拆不開的發現，通常代表還沒想清楚，而不是代表它簡單。
• 每一條斷言寫一條會紅的測試。 不是去跑既有的測試——既有的測試如果會抓到，這個發現一開始就不會存在。
• 檢查它引用的東西還在不在。 AI 的 review 很愛引用行號、函式名、某個檔案裡的某句註解。這些是最容易過期的部分，尤其是隔了幾輪之後重跑的 review。引用對不上的發現，先當它不存在。

Review 抓不到的三類

整理一下今天實際撞到的：

• 缺席的東西。 沒有宣告的 dependency、沒有寫的測試、沒有處理的錯誤碼。diff 裡只有加號和減號，沒有「應該有而沒有」。
• 跨檔案的一致性，除非你明講要拿什麼對照什麼。
• 文件與程式的落差，除非文件剛好也在這次的 diff 裡——而通常不在，因為文件跟程式往往不同一筆 commit。

這三類的共同點是：它們都不在「這次改了什麼」裡面。

結論

• Review 的品質取決於你交出去多少判準，不取決於它多聰明。
• 一條 review 發現如果只有一句話，你沒辦法驗它。 先拆成幾條獨立可真可假的斷言，再一條一條寫測試。
• 引用具體的發現最不該被信任。 行號、函式名、註解原文——越具體越容易過期，而越具體的東西越沒有人會回去對。

明天：把這些檢查搬進 CI。