企业官网建设流程全解析

pstack blast-radius 技能解析：用可运行证据证明一次改动的"爆炸半径"

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins

导读：本文围绕 pstack 插件中的blast-radius技能展开，讲解它如何回答"这次改动会破坏哪些别处代码"这一问题。它不是普通的调用方搜索，而是一套把"安全事实"推进到可运行证据的排查流程，包含五级可信度阶梯、六步执行法与最终交付格式。读完本文，你将掌握如何在合并前用脚本或测试真正证明改动安全，而不是交出一份听起来合理的书面分析。

一、blast-radius 要解决的问题

改动一小段代码，最危险的往往不是 diff 本身，而是 diff 之外、三跳之后的下游。pstack 的blast-radius正是为此设计的技能：在改动发布之前，找出它会破坏的别处代码。它的适用场景非常明确，description字段中写得很清楚：

• "blast radius of X"（X 的爆炸半径）
• "what could this break"（这会破坏什么）
• 审查一个你还不信任的小 diff

在 pstack 的技能体系中，它和how、why是三个互补的视角，README 与技能文档共同说明了这种关系：

• how：回答代码做了什么、如何工作，产出子系统级架构讲解；
• why：回答代码为什么长成这个样子，追溯设计动机与权衡；
• blast-radius：回答改动会在别处破坏什么。

技能文档中有一句核心论断："Listing the callers is not the job."（列出调用方不是这份工作。）Agent 用 grep 一秒钟就能找出调用者。真正的任务是发现grep 不会显示给你的破坏方式——例如 API 返回的 JSON 结构、数据库列、线上传输格式、另一个语言读取的同一批字节、feature flag、下游三跳之后的代码。

二、不要相信你自己的书面分析

技能的第一大原则是"Don't trust your own writeup"（不要相信你自己的书面分析）。一份听起来合理的爆炸半径分析毫无价值，因为它无论真假读起来都同样有说服力。因此，不要交回一篇分析文章，而要：

找出整个结论所依赖的一两个事实，并用运行代码来证明它们。

这正是"用事实说话"的工程态度：安全结论必须建立在可复现的证据上，而不是建立在措辞上。

三、五级可信度阶梯（How sure are you）

技能给出了一个证据强度阶梯，要求对每个影响安全的事实，尽可能沿此列表向下推进，并在交付时说明它停在了哪一级：

技能特别强调：任何安全事实若无法推进到第 4 级，就必须明说，不能当作既定结论写出来。第 4 级通常只需要一个很小的脚本：导入应用实际发布的同一个库，调用你担心的那个确切函数。这与 pstack 的prove-it-works原则一脉相承——完成一项任务后，要针对真实工件验证，而不是对着代理指标或"能编译"自我汇报。

四、六步执行法

技能定义了标准执行流程，每一步都有明确的着力点：

第 1 步：读懂改动。阅读 diff、它新增/修改/删除的符号，以及它现在行为上的差异——包括 diff 没有直接写出来的部分。可以借助why技能的第 2 步去拉取 PR 和提交记录。

第 2 步：找出"因为它才安全"的那一个事实。大多数看起来危险的改动，其实只因为一个单一事实而安全，例如"这个调用只会丢弃已经死亡的缓存条目，除此之外什么也不做"。找到这个事实，只要它成立，大多数高风险情况立刻被排除。技能明确要求把时间花在这里，而不是花在一长串"可能"清单上。

第 3 步：在 grep 止步之处继续看。阅读你调用的库的源码，检查它锁定的版本以及任何本地 patch；厘清运行时机：微任务（microtasks）、卸载与清理（unmount/teardown）、Solid 与 React 的差异；追踪符号搜索发现不了的东西：API 返回的 JSON、数据库列、线上传输格式、读取同一批字节的另一种语言、feature flag、下游三跳之后的代码。

第 4 步：对每个风险诚实。给每个风险一个真实的发生概率和真实的发生代价。保留已确认的风险；把检查过并排除的项单独列出。规则与why相同：引用真实的file:line；"搜索无结果"本身也是一个答案；绝不允许编造调用方或 API。

第 5 步：证明那一个事实。写一个运行真实代码的脚本或测试，运行它，然后粘贴实际输出。如果无法低成本证明，就标记为"未证明"（unproven），不要夸大。

第 6 步：大改动走 arena。对于大范围或影响面广的改动，按arena方式运行：让多个模型回答同一个问题并合并答案——不同模型能抓到不同的真实 bug。

五、最终交付格式（What to hand back）

一次标准的 blast-radius 分析，交付物应严格包含以下五个部分：

1. 它做了什么（What it does）：什么变了，包括不明显的那部分。
2. "因为它才安全"的那一个事实（The one fact it's safe because of）：陈述该事实，说明它被推进到了第几级，并展示证明。若无法证明，就写 unproven。
3. 风险（Risks）：只列真实的。每项说明它如何破坏、对应的file:line、可能性与严重程度、如何检查。对重要的项粘贴证明。
4. 已排除项（Cleared）：你检查过什么、为什么没事。
5. 合并前（Before you merge）：能抓住真实 bug 的最便宜的测试或复现方式，包括你写的脚本。

技能的结尾规则同样重要：通过unslop打磨文字，引用真实代码，在对外公开前剥离任何私有信息。最终回复（Reply）的形态是：上述分析报告，其中那个关键安全事实要么已被证明，要么被明确标记为 unproven。

六、在 pstack 中的定位与调用方式

从 pstack README 的技能表可以看到，/blast-radius被描述为：

你有一个看起来很小的改动，想知道它还会破坏什么，并且"因为它才安全"的那一个事实要通过运行代码来证明，而不是断言。

它通常在poteto-mode的 playbook 流程中被按需调用。在orchestrateplaybook 中也能看到其思想的延伸——高爆炸半径（high-blast-radius）的验证单元值得用不同模型族的专用验证 agent 来把关。此外，验证与发布指南直接给出了推荐用法：

对于你不太信任的小 diff，/blast-radius会找出它在别处可能破坏什么。它挑选出"改动因为其而安全"的那一个事实，并用运行代码来证明，而不是写一篇关于它的文章。

这印证了本技能在整个 pstack 工作流中的角色：它位于"验证"环节，服务于"ship 之前"这个时间点，与how（理解）、why（溯源）、unslop（净化表达）、arena（多模型交叉）共同构成一套完整的审查链条。

七、实践建议与适用边界

结合技能全文，可以提炼出几条可直接落地的实践要点：

• 一个 diff 只抓一个关键事实。把精力集中在那一个"因为它才安全"的事实上，一次性清空大多数风险，而不是罗列一堆可能的隐患。
• 证据要落到第 4 级。写一个导入应用同一版本库、调用同一函数的脚本，用它的真实输出来支撑结论；到不了第 4 级就老老实实标注 unproven。
• 引用要真实。每个风险都要给出真实的file:line；"grep 无结果"也是答案；禁止编造调用方。
• 区分"已确认"与"已排除"。两者分开呈现，不要让读者把猜测当成结论。
• 大改动交给多个模型。用 arena 方式并行让多个模型分析同一改动，合并答案以捕捉单模型漏掉的真实 bug。
• 对外输出前净化。通过unslop去除表达噪音，并剥离任何私有信息。

同时要注意适用边界：这是一个审查技能，面向"小改动"与"小 diff 但你不信任"的场景；它不替代how的代码讲解，也不替代why的动机追溯，而是专注回答"会破坏什么"这一个问题。它强调在发布前完成，配合仓库中的prove-it-works原则，保证任何"安全"声明都有可复现的证据支撑。

【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins