为什么一次性评审不够
插件评审是一张快照。背后的 npm 包会发新版本，维护者会失联，依赖会爆出漏洞。这些都不会出现在你三个月前做的那次评审里。如果唯一的闸门是人读一遍 README，那你信的其实是一个会过期的决定。
按信号强度排序，该扫什么
- 维护活跃度——上次发布时间，仓库是否还活着
- 依赖面——你顺带继承了多少个传递依赖
- 安装脚本——任何 postinstall 都想清楚再让它在你机器上跑
- 权限范围——插件要的权限和它实际需要的对不对得上
- 文档质量——连自己都讲不清的插件，你一定会配错
闸门放在哪
放在插件清单发生变化的那一点，而不是部署时。加插件本质是改依赖，所以它应该和清单修改在同一个 PR 里。这样 diff 同时展示代码改动和质量变化。
最小流水线形态
- PR 触发时解析插件清单，输出当前插件集合
- 拉取每个插件的质量信号（发布时间、依赖数、安装脚本）
- 和上一次集合对比，只在出现退化时失败
- 把差异作为 PR 评论贴出来，让人看到变了什么
怎么让闸门不变成噪音
杀死一个安全闸门最快的方法就是误报。如果每次提交都失败，人就会开始无视它，然后它什么都保护不了。所以按退化失败，而不是按绝对阈值：一个一直很平庸的插件，不是今天的问题。
常见问题
扫描该阻塞合并吗？
只对高风险类别的退化阻塞——安装脚本和权限范围。其余只警告。
信号多久刷新一次？
每次插件清单变化时，加一个每周定时任务，让缓慢腐坏也能浮出来。
它能替代人工评审吗？
不能。它替代的是机器做得更好的那部分，把人的时间腾出来读真正要紧的代码。