一句话

在改动合并前找出它会波及 diff 之外的什么地方：找到「它安全是因为哪一条事实」，用真实跑代码证明那条事实，而不是交一份听起来有理的 writeup。

何时用

• 适合：blast radius of X、what could this break；对一个小 diff 不放心；评审要改公共路径的提交。
• 不适合：只想列调用方（grep 就行）；大范围改动时改用 pstack-arena 让多个模型各查一遍再合并。

怎么用

/blast-radius 这个缓存失效逻辑的改动，会波及 diff 之外什么

1. 读 diff 和它没明说的行为变化；可用 pstack-why 拉 PR 和 commits。
2. 找出它安全所依赖的那一两条核心事实，时间花在这里，不撒网列 maybes。
3. 查 grep 够不到的地方：所调库的源码和锁定版本、执行时序、JSON 协议、DB 列、跨语言字节、feature flag。
4. 每条风险给真实概率和代价；确认过的和排除过的分开列，引用 file:line。
5. 写脚本或测试跑真实代码证明核心事实，贴出结果；证明不了就标 unproven。

产出

• 一段结构化报告：改动做了什么、安全所依赖的事实（含证明等级）、风险清单、已排除项、合并前最便宜的复现手段。

要点与坑

• 确定性分级：说了不算，指到行，推演走不通，跑脚本，在运行中的 app 里复现；通常第 4 档一个小脚本就够。
• 与 pstack-how（做什么）、pstack-why（为什么这样）互补，本技能回答「会连累谁」。
• 核心是方法不是工具，Devin CLI 里可完整照搬。

关联

• 同类：pstack-interrogate · 相关：pstack-how、pstack-why
• 所属：00-pstack-概览 · 工作流：W6-高风险加固层