blast-radius

影响范围

在改动发布前，找出它会在其他地方破坏什么。适用于“X 的影响范围”“这可能会破坏什么”或审查一个尚未完全信任的小型差异。

与 how 和 why 配套。how 告诉你代码做什么。why 告诉你代码为何采用这种结构。影响范围则告诉你它会在其他地方破坏什么。

列出调用方不是这项工作的重点。Agent 可以稍后用 grep 查出来。重点是找出 grep 看不到的破坏。

别轻信自己的说明

一份听起来有道理的影响范围说明毫无价值。无论它是否属实，读起来都可能令人信服。所以别直接交出说明。找出整件事所依赖的一两个事实，并通过运行代码证明它们。

你有多确定

对于改动安全性所依赖的每个事实，尽可能以低成本把它推进到下列列表中的更高层级，并说明验证停在哪一步。

1. 你这么说了。单凭这点毫无价值。
2. 你指出了代码行。提供真实的 file:line，或该库自身的源码。
3. 你证明了坏情况不可能发生。你逐步检查了故障路径，确认它无法走到那里。
4. 你运行了代码。脚本或测试调用真实代码，并在你判断错误时明确失败。
5. 你在运行中的应用里复现了它。

第 4 步通常只需一个小脚本：导入应用实际使用的同一个库，并调用你担心的确切函数。

步骤

1. 阅读改动。查看差异，以及它新增、更改和删除的符号，还有它现在与之前不同的行为，包括差异中未明说的部分。使用 why 技能的第 2 步来获取 PR 和提交。如果仓库有 GitNexus 索引（存在 .gitnexus/），且 gitnexus 位于 PATH 中，先刷新索引（gitnexus analyze --index-only；增量更新，且索引已是最新时会执行空操作），然后建立映射：gitnexus detect-changes 将差异关联到受影响的符号和流程，gitnexus impact <symbol> 给出直接影响范围。这只是 grep 能看到的部分——你的工作仍然是找出它遗漏的破坏，并且仍要运行真实代码来证明。
2. 找出改动之所以安全的那个事实。大多数看起来有风险的改动，之所以安全，是因为一个事实，例如“这个调用只会丢弃已经失效的缓存条目，不会做其他事”。找到这个事实。如果它成立，大多数风险情况就能一次排除。把时间花在这里，而不是列出一长串可能性。
3. 查看 grep 无法触及的部分。阅读你所调用库的源码，并检查其固定版本和任何本地补丁。弄清楚代码何时运行：微任务、卸载和拆除、Solid 与 React 的区别。追踪符号搜索无法发现的内容：API 返回的 JSON、数据库列、线格式、另一个语言如何读取相同字节、功能标志、下游三层的代码。
4. 如实评估每项风险。说明它发生的实际可能性和发生后的实际代价。保留已确认的风险，并单独列出你检查后排除的风险。遵循与 why 相同的规则。引用真实的 file:line；搜索无结果本身也是一种答案；绝不要捏造调用方或 API。
5. 证明那个事实。编写脚本或测试来运行真实代码，运行它，并粘贴结果。
6. 对于大型或影响广泛的改动，使用 arena 技能来运行审查。向多个模型提出同一个问题，再综合答案。不同模型能发现不同的真实 Bug。

需要提交的内容

• 它做了什么。 说明改动内容，包括不明显的部分。
• 它之所以安全的那个事实。 陈述该事实，说明你将其验证到了哪一步，并展示证明。如果无法证明，就写明尚未证明。
• 风险。 每项都要说明会如何造成破坏、对应的 file:line、发生可能性和后果严重程度，以及如何检查。粘贴关键风险的证明。
• 已排除。 说明你检查了什么，以及为什么没有问题。
• 合并前。 给出能捕获真实 Bug 的成本最低的测试或复现，包括你编写的脚本。

使用 unslop 技能撰写内容。引用真实代码，并在公开发布前删除任何私人信息。

**回复：**提交上面的说明，并证明那个安全事实或标记为尚未证明。