用途
Blast Radius 用于在代码变更发布之前，找出这次改动可能在别处破坏什么。它适用于以下场景：询问「X 的影响范围（blast radius of X）」「这可能会破坏什么（what could this break）」，或者审查一个你还不完全信任的小型 diff。
它是 how 和 why 的配套技能。how 告诉你代码做了什么，why 告诉你代码为什么长成那样，而 Blast Radius 告诉你它会在别处破坏什么。
列出调用者并不是它的工作——智能体一秒就能 grep 出来。它的工作是找出 grep 看不到的破坏。
主要能力
不要相信自己的分析报告
一份听起来正确的 blast-radius 分析报告是没有价值的，因为无论真假它读起来都很有说服力。所以不要直接交回分析报告，而应找出整个结论所依赖的一两个关键事实，并通过运行代码来证明它们。
确定性分级
对于变更安全性所依赖的每一个事实，尽可能以低成本把它推进到下列列表的更低层级，并说明它停在了哪一层：
- 你只是这么说了——单独来看毫无价值。
- 你指向了具体行——一个真实的 file:line，或库自身的源码。
- 你证明了坏情况不会发生——你一步步走完失败路径，确认它到不了。
- 你运行了它——一个调用真实代码、并在你判断错误时大声失败的脚本或测试。
- 你在运行中的应用里复现了它。
第 4 步通常就是一个小脚本，导入应用实际发布的同一个库，并调用你担心的那个确切函数。
使用方式
- 阅读变更：查看 diff、它新增/修改/删除的符号，以及它现在行为有何不同，包括 diff 没有明说的部分。可用 why 的第 2 步拉取 PR 和提交。
- 找出它之所以安全的那一个事实：大多数看起来有风险的变更之所以安全，是因为某一个事实，比如「这个调用只丢弃已经失效的缓存条目，不做别的」。找到这个事实。如果它成立，大多数风险情况会一次性排除。把时间花在这里，而不是一长串的「也许」。
- 看 grep 停在哪里：阅读你所调用库的源码，检查它锁定的版本和任何本地补丁。弄清事情何时运行：微任务、卸载与清理、Solid 与 React 的差异。追踪符号搜索会漏掉的东西：API 返回的 JSON、数据库列、线上格式、另一种语言读取相同字节、功能开关、下游三跳之外的代码。
- 诚实对待每个风险：给它一个真实的发生概率和真实的代价。保留你已确认的风险，把你检查过并排除的单独列出。规则与 why 相同：引用真实的 file:line，搜索无结果也是一种答案，绝不编造调用者或 API。
- 证明那一个事实：写一个运行真实代码的脚本或测试，运行它，并粘贴结果。
- 大范围变更用竞技场（arena）：对大型或广泛的变更，向多个模型提出同一个问题并合并答案。不同模型会捕捉到不同的真实 bug。
交付内容
- 它做什么：改了什么，包括不明显的那部分。
- 它之所以安全的那一个事实：陈述它，说明你把它推进到了哪一步，并展示证明。如果无法证明，就写「未证明（unproven）」。
- 风险：每个风险说明它如何破坏、file:line、可能性与严重程度，以及如何检查。对重要的风险粘贴证明。
- 已排除项：你检查了什么，以及为什么没问题。
- 合并之前：能捕捉到真实 bug 的最便宜的测试或复现，包括你写的脚本。
通过 unslop 撰写，引用真实代码，并在任何公开之前剥离所有私密内容。
回复：上述分析报告，其中那一个安全事实要么已被证明，要么标记为未证明。
适用场景
- 在合并前评估一次代码变更的潜在影响范围。
- 审查一个你还不完全信任的小型 diff。
- 回答「这可能会破坏什么」这类问题。
限制
- 该技能强调不能仅凭听起来合理的分析报告下结论，必须通过运行真实代码来证明关键事实。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。