blast-radius 是一个技能，用途是在代码变更发布前，找出它在别处可能破坏什么，适用于评估某变更的影响范围、判断一个小 diff 是否可靠等场景。它与 how、why 配套：how 说明代码做什么，why 说明代码为何长成这样，blast-radius 则指出它会在别处破坏什么。
核心理念：只列出调用者不是重点，grep 一秒就能做到，真正的工作是 grep 看不出的破坏。不要相信自己的书面分析，听起来对的 blast-radius 报告无论真假都显得可信，因此要找出整个结论所依赖的一两个关键事实，并通过运行代码来证明。
对每个安全性依赖的事实，尽量沿确信阶梯推进并说明止步处：仅是你说的（单独无价值）；指向具体 file:line 或库自身源码；展示坏情况不可能发生（逐步推演失败路径且到不了）；实际运行它（脚本或测试调用真实代码，结论错就报错）；在运行中的应用里复现。第 4 步通常是写一个小脚本，导入应用发布的同一库并调用所担心的确切函数。
步骤如下：一、阅读变更，包括 diff、新增/修改/删除的符号及行为差异，含 diff 未明说的部分。二、找到安全所依赖的那一个事实，把时间花在这里，而非罗列大量可能。三、查看 grep 止步之处：读所调用库的源码，检查其锁定版本和本地补丁，厘清运行时机（微任务、卸载与清理、Solid 与 React），关注符号搜索漏掉的东西（API 返回的 JSON、数据库列、线格式、其他语言读取的同字节、特性开关、下游三跳的代码）。四、诚实评估每个风险，给出发生概率和代价，保留已确认风险，单独列出已检查并排除的项；引用真实 file:line，搜不到也算答案，绝不编造调用者或 API。五、证明那一个事实，写脚本或测试运行真实代码并附上结果。对大型或广泛变更，可当作 arena，让多个模型回答同一问题并合并结果。
交付内容：它做什么（含不明显的变化）；安全所依赖的一个事实（陈述、说明推进到哪一步、展示证明，无法证明则写 unproven）；风险（各自的破坏方式、file:line、可能性与严重度、如何检查，重要者附证明）；已排除项；合并前的检查（最便宜的能抓到真实 bug 的测试或复现，含所写脚本）。用 unslop 撰写，引用真实代码，公开前剥离任何私密内容。回复即上述报告，其中安全事实要么已证明，要么标记 unproven。