我的 review 旋鈕是看不看得懂，他的是影響範圍
我目前的做法：AI 直接 review 自己和他人的 code，我自己只做兩件事——大致看整份程式碼的可讀性（這很主觀），以及遇到不理解的商業邏輯就讓 AI 解釋給我聽。
把這個做法和影片的框架並排，會看到我們調的是不同的旋鈕：
| 我的旋鈕 | 影片的旋鈕 | |
|---|---|---|
| 決定要不要細看的是 | 我看不看得懂 | 這段改動的 blast radius |
| 典型行為 | 看不懂 → 請 AI 解釋；看得懂 → 過 | trunk → 細讀；leaf → 掃過 |
兩個旋鈕不重疊，而且錯開的方向很危險
- 看得懂的 trunk 改動：我會直接放過，但它的爆炸半徑一樣大——理解程度不等於安全
- 看不懂的 leaf 改動：我會停下來追問，但它其實被隔開了，值不值得花這個力氣是另一回事
也就是說，我現在的篩法和風險沒有對齊，它對齊的是我的舒適度。
可以保留的部分
「讓 AI 解釋不理解的商業邏輯」這件事本身是對的——影片最後那句 if you understand your codebase it's actually easier to review 說的就是理解程度會回過頭來降低 review 成本。差別只在它該是補強，不是篩選條件。
要換成影響範圍當旋鈕，第一個卡住的問題是 → 怎麼判斷一段改動的影響範圍？