把 codebase 想成一棵樹：trunk 與 leaf 的分界是有沒有被隔開
AI 產出的程式碼量暴增之後，一個人連 review 完自己的 code 都幾乎不可能。所以問題不是「要不要 review」，而是哪些要細讀、哪些可以掃過。
| 是什麼 | 怎麼 review | |
|---|---|---|
| Trunk（樹幹） | 主要進入點（app.js 那種）、基礎設施（影像處理、網路層）、有大量 shared state 的模組（例如 reducer）；下游依賴多，出事會影響整個 app | 花大量時間逐行讀 |
| Leaf（葉子） | 孤立寫成的、或被 feature gate 完全隔開的程式碼：一次性元件、新 endpoint、新邏輯，沒有接進既有 production codebase | 讓 agent 跑 component／snapshot test，看 PR 裡的證據＋目視確認 |
判準是 blast radius，不是難易度
Review 的深度應該取決於那段改動的「爆炸半徑」。
同一份力氣，花在爆炸半徑大的地方。注意 leaf 的定義裡**「被 gate 隔開」和「孤立寫成」是等價的**——這代表你可以用 Feature gate 最簡單就是一個 boolean flag 把一段改動「變成」leaf，從而合法地少讀它。
反過來說：改既有行為而且沒有 gate 起來，就一定是 trunk 等級的 review，因為它直接改到 production，有連鎖與副作用。
一切錨定在 safety 的三個問題
- 不該改變的**對照體驗（control experience）**是什麼？
- 這個改動出錯會有多糟？
- 能不能 roll back？（取決於有沒有 gating）
第三題答得出來，前兩題的 review 成本就能大幅下降。改動越是單向門（one-way door），讀得越久。
這個模型要求你本來就懂 codebase
影片最後補了一句：越理解自己的 codebase，review 越容易——因為你能很快看出哪些動到危險地帶。但「大型應用怎麼判斷影響範圍」他沒有給方法 → 怎麼判斷一段改動的影響範圍？
我自己目前用的旋鈕其實不是這個 → 我的 review 旋鈕是看不看得懂，他的是影響範圍