多人協作
審查看行為，不挑語法
別人請你看程式時，你的工作不是找括號。你的工作是問：成功標準還在不在，壞的時候會怎樣。
你看得懂的那一層
你可能讀不完全部實作，這沒有關係。你讀得了請求上的行為描述，也讀得了畫面上的句子、規則的條件、什麼情況會轉人工。就從這一層開始。若這一層和範圍單不一致，不用再往下讀，先把不一致指出來。
語法、命名、效能，交給會對那些負責的人。你插進去挑這些，會讓真正的行為問題沒有人問。團隊需要你當那個一直問「空白時會不會猜」的人。
要問的風險很具體
問輸入：訂單編號空白、超過七天、已經退過、訂單系統沒回答，這四種各會發生什麼。問權限：沒有客服身份的人送出同一個請求，會不會也被寫進退貨。問收回：這次若錯了，回到上一版會不會把別的好改動一起拿走。
這三問都是 PM 的語言。工程師若答「應該沒問題」，請他改成這四種輸入的其中一種會看到什麼句子。答不出句子，就還沒有被看過。
留下你真的看過的證據
核准時寫下你檢查了哪一筆。例如「我用空白編號走了一次，畫面停在轉人工，沒有結論。」這比「LGTM」對下週的你有用。你不需要假裝看過程式的每一行才有資格留這句。
若你沒走那一筆，就不要寫你走了。寫「我只看了行為描述，還沒走案例」是誠實的部分核准，團隊可以再請人補走。假裝看過，是之後事故裡最難解開的那句。
範例 · PM 在審查裡留的三句
- 空白編號：我走了一次，只有轉人工，沒有可退。
- 超過七天：描述寫不可退。我還沒走，請補一筆。
- 不討論變數怎麼命名。那不是這次要我看的風險。
練習
拿一張想像的退貨改動，寫三個你會問的行為問題，不要寫任何語法意見。
再寫一句你核准時會留下的證據，必須是你真的做得到的檢查。
完成的時候
- 你能說明 PM 審查看的是行為和風險。
- 你核准時留得下一句可核對的證據，而不是一句稱讚。