blast-radius

影响范围

在变更发布前，找出它在其他地方会破坏什么。适用于“X 的影响范围”“这可能会破坏什么”或审查你还不放心的小型差异。

差异审查会告诉你变更做了什么。这里要找的是变更在差异之外会破坏什么。

列出调用方不是重点。Agent 可以再用 grep 找到它们。重点是找出 grep 看不出来的问题。

不要轻信自己的分析

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

你有多确定

对于变更安全性所依赖的每个事实，尽可能以低成本将它推进到以下列表中更靠后的位置，并说明验证停在了哪一步。

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

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

步骤

1. 阅读变更。查看差异，以及它新增、修改和删除的符号，还有它现在有哪些行为不同之处，包括差异中没有明确写出的部分。用 gh pr view 和 git log 拉取 PR 及其提交。
2. 找出它之所以安全的那个事实。大多数看起来有风险的变更，其实都是因为一个事实才安全，例如“这个调用只会丢弃已经失效的缓存条目，不会做其他事情”。找到这个事实。如果它成立，大多数风险情形就能一次性排除。把时间花在这里，而不是列出一长串可能性。
3. 查看 grep 找不到的部分。阅读所调用库的源码，并检查锁定的版本和任何本地补丁。弄清楚代码何时运行：微任务、卸载和清理、Solid 与 React 的差异。追踪符号搜索会漏掉的内容：API 返回的 JSON、数据库列、传输格式、用另一种语言读取相同字节的代码、功能标志，以及下游隔了三层的代码。
4. 如实评估每项风险。说明它实际发生的可能性，以及发生后的实际代价。保留你已确认的风险。另行列出你检查后排除的风险。引用真实的 file:line；搜索不到内容也算答案，绝不要捏造调用方或 API。
5. 证明那个事实。编写脚本或测试来运行真实代码，运行它，并贴出结果。
6. 对于大型或涉及范围广的变更，针对不止一个模型启动只读子 Agent，让它们回答同一个问题，然后综合答案（参见 code-review-panel 技能）。

需要交付的内容

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

引用真实代码，直白写清楚，删掉 AI 式套话；公开任何内容前，先移除私人信息。

**回复：**以上分析，并证明安全性所依赖的那个事实，或将其标记为尚未证明。