PR 解釋器 + 理解度測驗
AI 輔助編碼讓人很容易核准自己從未真正理解的程式碼。這個技能會以審查者所需的層級解釋變更，然後透過幾個關鍵問題來檢查理解程度——讓「LGTM」真正具有意義。
1. 收集變更
選擇適用的方式：
git pr view <num> --json title,body,baseRefName,headRefName,files # GitHub PR
gh pr diff <num>
git diff <base>...<head> # 分支
git show <sha> # 單一提交
閱讀 PR 描述及相關 issue（如果有）。然後閱讀受影響函式的周遭程式碼（呼叫者、被呼叫者、測試）——單獨的 diff 會隱藏重要的上下文。
2. 解釋——按此順序
- 一段摘要：使用者或呼叫者的行為有何變化。不是檔案列表。
- 原因：根據描述/issue/提交訊息，說明正在解決的問題。如果任何地方都沒有說明原因，請指出——這是一個審查發現。
- 圖表：一個 Mermaid
sequenceDiagram或flowchart，呈現新的流程，並標示出新/變更的部分（使用note或:::changedclass）。保持在約 15 個節點以下；只圖表核心路徑，不圖表所有內容。 - 依概念解說，而非依檔案：將相關的 hunks 分組（「重試邏輯」、「新的設定標誌」）。針對每個分組：說明其作用，以及任何不顯而易見的部分（並發、錯誤處理、邊界情況、效能）。
- 風險筆記：審查者應最仔細審查的事項——變更的公開介面、遷移、被刪除的測試、被吞沒的錯誤路徑、安全敏感程式碼、缺少測試的新分支。具體指定
檔案:行號。
3. 測驗
提出 3 到 5 個問題，一次一個，等待回答後再問下一題。好的問題需要理解，而非記憶：
- 「如果
<相依項目>在<操作>期間超時，現在會發生什麼事？」 - 「哪個現有的呼叫者受到簽名變更的影響，以及如何影響？」
- 「為什麼
<行>必須在<行>之前？」 - 「如果我們在遷移執行後回滾此變更，什麼會壞掉？」
避免瑣碎問題（「新函式叫什麼名字？」）。混合題型：至少一題關於失敗/邊界行為，一題關於為何做出某個設計選擇。
每個回答後：說明是否正確，並用 1 到 3 句話及程式碼參考給出正確的解釋。如果他們在重要事項上答錯，建議重新閱讀 diff 的哪個部分。
4. 總結
評分（例如 4/5）以及簡短的結論：「準備好審查」，或「核准前請重新閱讀 X」。針對發現的任何風險，提議草擬審查意見。
依請求範圍調整
完整的流程（摘要 → 原因 → 圖表 → 解說 → 風險 → 測驗）是「帶我瀏覽這個」或「幫我審查」的預設模式。當使用者縮小請求範圍時，請尊重：
- 「不用測驗」/「跳過測驗」：步驟 1–2，不含步驟 3。
- 「只要摘要和風險」：一段摘要和風險筆記，其他都不需要：沒有圖表，沒有解說。在最後一行提供其餘部分。
- 「只要圖表」：圖表加上兩句說明。
列出的第一個風險應該是會改變使用者行為或金錢的風險（例如無聲的錯誤收費），而不是技術上最有趣的風險。