怎麼判斷一段改動的影響範圍？

把 codebase 想成一棵樹：trunk 與 leaf 的分界是有沒有被隔開 說「review 深度由 blast radius 決定」——但沒有說 blast radius 怎麼量。影響越大越要人確認，可是在一個龐大的應用裡，我怎麼知道眼前這段改動的影響範圍有多大？標準在哪？

材料給到哪裡

只有例子和一句免責：

• trunk 的例子：主要進入點、基礎設施（影像處理、網路層）、下游依賴多的、有大量 shared state 的（reducer）
• leaf 的判準比較明確：孤立寫成，或被 feature gate 完全隔開
• 唯一的方法論是最後那句：「你越理解自己的 codebase，越能很快看出哪些動到危險地帶」——等於把問題還回來

沒有提到任何工具或系統性做法：依賴圖、呼叫圖、變更影響分析、擁有者制度，一個都沒有。

要查清楚的

• 有沒有可以自動算 blast radius 的工具？（依賴圖／import graph／code-review 的 blast radius 分析）
• 「下游依賴多」要怎麼定量？import 次數？被幾個 route 用到？
• 大型 codebase 裡，這個判斷能不能交給 agent 做（它看得到全域依賴，我看不到）
• 有沒有不靠「我夠懂 codebase」也成立的代理指標？（檔案的 git 變更頻率？牽涉到的測試數量？）

為什麼這題對我特別重要

因為我現在的篩法根本不是影響範圍 → 我的 review 旋鈕是看不看得懂，他的是影響範圍。要換旋鈕，就得先有辦法讀出這個數字，否則換不過去。

一個現成的旁證：把改動 gate 起來就等於強制把 blast radius 降為零 → Feature gate 最簡單就是一個 boolean flag。也許實務上的答案不是「算得準」，而是「算不準就 gate」。（推論）