blast-radius

爆炸半径

在改动发布之前，找出它会在别处弄坏什么。用于「blast radius of X」「what could this break」，或者审一个你还不放心的小 diff。

和 how、why 配套使用。how 告诉你代码做了什么。why 告诉你它为什么长成这样。爆炸半径告诉你它会在别处弄坏什么。

列出调用方不是这里要做的事。agent 一秒钟就能 grep 出来。要做的，是找出 grep 看不出来的破坏。

别信自己写的分析

一篇听起来很对的爆炸半径分析一文不值。不管内容真假，读起来都一样有说服力。所以不要交一篇分析。找出整件事依赖的那一两条事实，用运行代码来证明。

你有几分把握

改动的安全依赖哪些事实，每一条都在成本不高的前提下，沿下面这个清单尽量往下推，并说明停在了哪一级。

你说是这样。单凭这一条毫无价值。
你指出了那一行。真实的 file:line，或者库自己的源码。
你说明了坏情况不会发生。你把出错的路径一步一步走了一遍，走不到那里。
你运行过了。写一个脚本或测试，调用真实代码，你错了它就会明明白白地失败。
你在运行中的应用里复现了。

第 4 级通常就是一个小脚本：导入应用实际发布时用的同一个库，调用你担心的那个函数。

步骤

读改动。读 diff，读它新增、修改、删除的符号，以及它现在的行为有什么不同，包括 diff 没明说的部分。用 why 的第 2 步把 PR 和 commit 拉出来。
找出它之所以安全所依赖的那一条事实。大多数看起来有风险的改动，安全都系于一条事实，例如「这个调用只清掉已经失效的缓存条目，别的什么都不做」。找到这条事实。它成立，大多数有风险的情况就一次排除了。时间花在这里，不要花在一长串「也许」上。
去 grep 到不了的地方看。读你调用的那个库的源码，查它锁定的版本和本地打的补丁。弄清楚东西在什么时候运行：microtask、卸载和清理阶段、Solid 和 React 的区别。顺着符号搜索漏掉的东西走：API 返回的 JSON、数据库的一列、线上传输的格式、用另一种语言读同一份字节的代码、feature flag、往下游走三跳的代码。
老实评估每个风险。给出它真实的发生概率，和发生之后真实的代价。确认过的风险留下。查过并排除的单独列出来。规则和 why 一样：引用真实的 file:line，什么都没搜到也是一个答案，绝不编造调用方或 API。
证明那一条事实。写一个运行真实代码的脚本或测试，跑一遍，把结果贴出来。
改动大或者波及面广时，按 arena 来跑。把同一个问题交给几个模型，再把答案合起来。不同的模型会抓到不同的真 bug。

交回什么

它做了什么。 改了什么，包括不明显的部分。
它之所以安全的那一条事实。 写出来，说明推到了哪一级，附上证明。证明不了，就写「未证明」。
风险。 每条写清怎么坏、在哪个 file:line、可能性多大、后果多重、怎么检查。要紧的那几条附上证明。
已排除。 查了什么，为什么没问题。
合并之前。 能抓到真 bug 的成本最低的测试或复现，包括你写的那个脚本。

用 unslop 过一遍文字，引用真实代码，发到任何公开的地方之前，删掉一切私密内容。

回复： 上面这份内容，其中那条安全事实要么已证明，要么标为「未证明」。