Back to Details

blast-radius

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Blast radius

Blast radius

Find what a change breaks somewhere else, before it ships. Use for "blast radius of X", "what could this break", or reviewing a small diff you don't trust yet.
Companion to 
how
and 
why
. 
how
tells you what the code does. 
why
tells you why it's shaped that way. Blast radius tells you what it breaks somewhere else.
Listing the callers is not the job. The agent can grep those in a second. The job is the breakage grep won't show you.
在变更发布前，找出该变更可能在其他地方造成的破坏。适用于评估“X的Blast radius”、“该变更可能破坏什么”，或审核你目前尚不放心的小型代码差异（diff）。
作为
how
和
why
的配套工具。
how
用于说明代码的功能，
why
用于解释代码为何是当前的结构，而Blast radius则用于找出变更会在其他地方破坏什么。
列出调用者并非核心任务，Agent一秒就能通过grep找到。核心任务是找出grep无法发现的潜在破坏点。

Don't trust your own writeup

不要相信自己撰写的文档

A blast-radius writeup that sounds right is worthless. It reads as convincing whether or not it's true, and that is the trap you are walking into. So don't hand back the writeup. Find the one or two facts the whole thing depends on and prove them by running code. Words are where you start, not what you ship.
听起来合理的影响范围分析文档毫无价值。无论内容是否真实，它读起来都很有说服力，这正是你会陷入的陷阱。因此不要只提交文档，要找出整个分析依赖的一两个关键事实，并通过运行代码来证明它们。文字只是起点，而非最终交付物。

How sure are you

你的确定性有多高

For each fact the change's safety depends on, get it as far down this list as is cheap, and say where it stopped.
  1. You said so. Worthless on its own.
  2. You pointed at the line. A real 
    file:line
    , or the library's own source.
  3. You showed the bad case can't happen. You walked the failure step by step and it doesn't reach.
  4. You ran it. A script or test that calls the real code and fails loud if you're wrong.
  5. You reproduced it in the running app.
Any safety fact you can't get to step 4, say so out loud. Don't write it up as settled. Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.
对于变更安全性所依赖的每个事实，尽可能推进到以下步骤中的更高级别，并说明停留在哪个步骤：
  1. 你这么说的。本身毫无价值。
  2. 你指出了具体代码行。真实的
    file:line
    ，或是库的源代码。
  3. 你证明了异常情况不会发生。逐步推演失败路径，确认其不会触发。
  4. 你运行了代码。编写脚本或测试调用真实代码，如果判断错误会直接报错。
  5. 你在运行中的应用里复现了结果。
任何无法推进到步骤4的安全性事实，都要明确说明。不要将其写成已确认的结论。步骤4通常只需要一个小型脚本，导入应用使用的相同库，并调用你担心的具体函数。

Steps

步骤

  1. Read the change. The diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. Use 
    why
    step 2 to pull the PR and commits.
  2. Find the one fact it's safe because of. Most changes that look scary are safe because of a single fact, like "this call only drops already-dead cache entries and does nothing else". Find that fact. If it holds, most of the scary cases die at once. Spend your time here, not on a long list of maybes.
  3. Look where grep stops. Read the source of the library you call, and check its pinned version and any local patch. Work out when things run: microtasks, unmount and teardown, Solid versus React. Follow what a symbol search misses: the JSON an API returns, a DB column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
  4. Be honest about each risk. Give it a real chance of happening and a real cost if it does. Keep the risks you confirmed; list the ones you checked and cleared separately. Same rules as 
    why
    . Cite a real 
    file:line
    , a search that finds nothing is still an answer, and never make up a caller or an API.
  5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened. If you can't prove it cheaply, mark it unproven. Don't round up.
  6. For a big or wide change, run it as an 
    arena
    . Ask several models the same question and merge the answers. Different models catch different real bugs.
  1. 理解变更内容。查看代码差异（diff）、新增/修改/删除的符号，以及变更后的不同行为，包括代码差异未明确体现的部分。使用
    why
    步骤2来拉取PR和提交记录。
  2. 找出安全性依赖的核心事实。大多数看似危险的变更，其安全性往往依赖于单一事实，比如“该调用只会清除已失效的缓存条目，不会执行其他操作”。找出这个核心事实。如果该事实成立，大多数潜在风险会立即消除。把时间花在这一步，而非罗列大量可能性。
  3. 探索grep无法覆盖的范围。查看你调用的库的源代码，检查其固定版本和任何本地补丁。理清代码的执行时机：微任务、卸载与清理、Solid与React的差异。追踪符号搜索遗漏的内容：API返回的JSON、数据库列、传输格式、读取相同字节的其他语言、功能标志、下游三层的代码。
  4. 如实评估每个风险。给出其实际发生的概率和一旦发生的影响程度。保留已确认的风险；将已检查并排除的风险单独列出。遵循与
    why
    相同的规则：引用真实的
    file:line
    ，未找到结果的搜索也是一种答案，绝不要虚构调用者或API。
  5. 证明核心事实。编写脚本或测试来运行真实代码，执行后粘贴结果。如果无法低成本证明，则标记为未验证。不要含糊其辞。
  6. 对于大型或影响范围广的变更，以
    arena
    模式运行。让多个模型回答同一个问题，然后合并结果。不同模型能发现不同的真实bug。

What to hand back

交付内容

  • What it does. What changed, including the part that isn't obvious.
  • The one fact it's safe because of. State it, say which step you got it to, and show the proof. If you couldn't prove it, write unproven.
  • Risks. Only the real ones. Each names how it breaks, the 
    file:line
    , how likely and how bad, and how to check. Paste the proof for the ones that matter.
  • Cleared. What you checked and why it's fine.
  • Before you merge. The cheapest test or repro that catches the real bug, including the script you wrote.
Write it through 
unslop
, cite real code, and strip anything private before it goes anywhere public.
Reply: the writeup above, with the one safety fact either proven or marked unproven.
  • 变更内容：变更的具体情况，包括不明显的部分。
  • 安全性核心事实：陈述该事实，说明推进到了哪个步骤，并展示证明过程。如果无法证明，标注为未验证。
  • 风险：仅保留真实存在的风险。每个风险需说明破坏方式、对应的
    file:line
    、发生概率和影响程度，以及检查方法。粘贴重要风险的证明过程。
  • 已排除风险：你检查过的内容，以及确认其无风险的原因。
  • 合并前建议：能发现真实bug的最低成本测试或复现方案，包括你编写的脚本。
通过
unslop
整理内容，引用真实代码，在公开前删除任何私密信息。
回复要求：上述分析文档，其中安全性核心事实需已证明或标记为未验证。