用途
Blast Radius 用于在代码变更发布前，找出该变更在别处可能造成的破坏。它适用于以下场景：询问“X 的影响范围”“这可能会破坏什么”，或者审查一个你还不信任的小型 diff。它也建议在设计阶段之前就运行，而不仅仅是在发布前——当一份需求断言现有代码的某种行为（例如“把端点 X 设为公开”）时，这个断言只是一个假设，而消费者的普查结果才是决定设计的依据。
它与 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。
- 证明那一个事实。编写一个运行真实代码的脚本或测试，运行它，并粘贴结果。
- 对于大型或广泛的变更，将其作为竞技场运行：向多个模型提出同一个问题并合并答案。不同的模型会捕捉到不同的真实 bug。
交付内容
该技能要求交回以下内容：
- 它做什么。变更了什么，包括不明显的那部分。
- 它之所以安全的那一个事实。陈述它，说明你把它推进到了哪一步，并展示证明。如果无法证明，就写“未证明”。
- 风险。每个风险需说明它如何破坏、file:line、发生概率与严重程度，以及如何检查。对重要的风险粘贴证明。
- 已清除项。你检查了什么，以及为什么它没问题。
- 合并前。能捕捉真实 bug 的最便宜的测试或复现，包括你写的脚本。
最后，通过 unslop 撰写，引用真实代码，并在任何公开之前剥离所有私密内容。回复内容为上述书面报告，其中那一个安全事实要么已被证明，要么标记为未证明。
适用场景
适合在以下情况使用：准备合并一个你不完全信任的小型 diff；某个需求对现有代码行为做出断言，需要先验证再设计；变更涉及跨语言、跨服务、功能开关或下游多跳的间接影响；需要向团队证明某个变更为何安全。
限制
资料未提供该技能的具体安装命令、支持的平台、收费方式或价格信息。其效果依赖于能否找到并证明那一个关键安全事实；如果无法证明，报告只能标记为“未证明”。它不替代 how 和 why 技能，而是与它们配合使用。