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 XX 的爆炸半径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、下游三跳之后的代码。二、不要相信你自己的书面分析技能的第一大原则是Dont trust your own writeup不要相信你自己的书面分析。一份听起来合理的爆炸半径分析毫无价值因为它无论真假读起来都同样有说服力。因此不要交回一篇分析文章而要找出整个结论所依赖的一两个事实并用运行代码来证明它们。这正是用事实说话的工程态度安全结论必须建立在可复现的证据上而不是建立在措辞上。三、五级可信度阶梯How sure are you技能给出了一个证据强度阶梯要求对每个影响安全的事实尽可能沿此列表向下推进并在交付时说明它停在了哪一级级别证据形态评价1You said so你说是就是单独出现时毫无价值2You pointed at the line你指向了某一行给出真实的file:line或引用库本身的源码3You showed the bad case cant happen你演示了坏情况不会发生一步步走查失败路径证明它到不了4You ran it你运行了它用脚本或测试调用真实代码如果你错了它会大声失败5You reproduced it in the running app在运行中的应用里复现最高等级贴近真实运行环境技能特别强调任何安全事实若无法推进到第 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 分析交付物应严格包含以下五个部分它做了什么What it does什么变了包括不明显的那部分。因为它才安全的那一个事实The one fact its safe because of陈述该事实说明它被推进到了第几级并展示证明。若无法证明就写 unproven。风险Risks只列真实的。每项说明它如何破坏、对应的file:line、可能性与严重程度、如何检查。对重要的项粘贴证明。已排除项Cleared你检查过什么、为什么没事。合并前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:linegrep 无结果也是答案禁止编造调用方。区分已确认与已排除。两者分开呈现不要让读者把猜测当成结论。大改动交给多个模型。用 arena 方式并行让多个模型分析同一改动合并答案以捕捉单模型漏掉的真实 bug。对外输出前净化。通过unslop去除表达噪音并剥离任何私有信息。同时要注意适用边界这是一个审查技能面向小改动与小 diff 但你不信任的场景它不替代how的代码讲解也不替代why的动机追溯而是专注回答会破坏什么这一个问题。它强调在发布前完成配合仓库中的prove-it-works原则保证任何安全声明都有可复现的证据支撑。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考