blast-radius

影响范围

以粗体或反引号标出的技能名称，或以 /<name> 的形式运行的技能，是本技能目录旁边的 ../<name>/SKILL.md 文件；未带前缀的原则名称对应 ../principle-<name>/SKILL.md。读取该文件并遵循其中的指引。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。

在变更发布前，找出它会在其他地方造成哪些问题。适用于“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 撰写，引用真实代码，并在公开前删除任何私人信息。

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