blast-radius

影响范围

在变更发布前，找出它会在其他地方造成什么问题。适用于询问“X 的影响范围”“这可能会破坏什么”，或审查尚不确定是否可靠的小型差异。

与 how 和 why 配套使用。how 会告诉你代码的作用。why 会告诉你代码为何如此设计。影响范围则会告诉你它会在其他地方造成什么问题。

列出调用方不是重点。Agent 可以随后再 grep 这些内容。重点是找出 grep 查不出来的问题。

别相信自己的分析

听起来有理有据的影响范围分析毫无价值。无论真假，读起来都很有说服力。所以不要直接交付分析。找出整件事所依赖的一两个事实，并通过运行代码证明它们。

你有多确定

对于变更安全性所依赖的每个事实，尽可能用下面的方式逐步验证，并说明验证停在哪一步。

1. 这是你自己说的。单凭这一点毫无价值。
2. 你指出了代码行。提供真实的 file:line，或该库自己的源码。
3. 你证明了坏情况不会发生。逐步梳理故障路径，确认它无法到达。
4. 你运行了代码。编写脚本或测试，调用真实代码；如果你的判断有误，程序会明确失败。
5. 你在运行中的应用里复现了问题。

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

步骤

1. 阅读变更。检查差异，以及它新增、更改和删除的符号，并了解它现在有什么不同，包括差异中未明确说明的部分。使用 why 的第 2 步获取 PR 和提交记录。
2. 找到它之所以安全的那个事实。大多数看起来有风险的变更之所以安全，都依赖某个单一事实，例如“这个调用只会丢弃已失效的缓存条目，不会做其他任何事”。找到这个事实。如果它成立，大多数风险情形就能一次性排除。把时间花在这里，而不是罗列一长串可能性。
3. 查看 grep 查不到的内容。阅读你所调用的库的源码，并检查其锁定版本和任何本地补丁。弄清楚代码何时运行：微任务、卸载和清理过程、Solid 与 React 的差异。追踪符号搜索遗漏的内容：API 返回的 JSON、数据库列、线缆格式、其他语言对相同字节的读取、功能标志、下游第三跳的代码。
4. 诚实评估每个风险。判断它实际发生的可能性，以及一旦发生会造成多大损失。保留已确认的风险。另行列出你检查并排除的风险。遵循与 why 相同的规则。引用真实的 file:line；即使搜索没有结果，也应作为答案写明；绝不要捏造调用方或 API。
5. 证明那个事实。编写脚本或测试来运行真实代码，运行它，并贴出结果。
6. 对于大型或影响广泛的变更，以 arena 的方式处理。让多个模型回答同一个问题，然后整合答案。不同模型能发现不同的真实缺陷。

交付内容

• 变更的作用。 说明发生了什么变化，包括不明显的部分。
• 它之所以安全的那个事实。 陈述该事实，说明验证到了哪一步，并展示证据。如果无法证明，请写明未证明。
• 风险。 对每个风险，说明它会如何造成问题、对应的 file:line、发生可能性和影响程度，以及如何检查。对于重要风险，贴出证据。
• 已排除。 说明你检查了什么，以及为何没问题。
• 合并前。 给出能发现真实缺陷的最低成本测试或复现步骤，包括你编写的脚本。

通过 unslop 编写分析，引用真实代码，并在公开发布前删除所有私密内容。

**回复：**上述分析，并将那个安全事实标记为已证明或未证明。