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 撰写，引用真实代码，并在公开发布前清除任何私密信息。

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