别再让同一个 agent 既找 bug 又给自己打分：Cloudflare 的审计技能逼它换一个人来证伪

Cloudflare 开源的 security-audit-skill，解决的是 coding agent 做安全审计时最常见的自欺：同一个模型先猜一个漏洞，再自己给自己盖章。本周趋势盘点里它仍在涨，一周新增上万星，总数随快照日期在变，这篇不钉死总数，只用“在涨”这个判断。它的出身要先说准：2026 年 6 月 Cloudflare 内部漏洞发现系统的种子技能，约 450 行指令演化成扫描 128 个仓库的内部 harness，技能本身是 MIT 协议的免费开源，不用 Cloudflare 账号、不绑某一家模型。
它的做法是六个阶段，缺一不可。第一阶段侦察，先把架构、信任边界、输入面画进 architecture.md 和 coverage-ledger.json；第二阶段按账本派互不干扰的猎手去查，另有专职批评者只找猎手漏掉的覆盖缺口；第三阶段是关键一环，每个候选漏洞都交给一个全新的验证者，任务不是确认，而是想办法证伪；第四阶段把结果写进 findings.json，按 schema 校验，分成 confirmed、needs_validation、rejected 三档，其中 needs_validation 不给严重度，只写清楚哪一个事实还没定；第五阶段再派新 agent 复核最终报告里的每一条来源说法；第六阶段才由核实过的记录生成 REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md。规则只有一句话：查的人永远不是找的人。
装法不复杂：装 Skills CLI 后跑 npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit，再对 agent 说一句 security audit this codebase。结果默认写在仓库外面，~/security-audit-skill/<仓库名>/run-<N>，不会污染你的工作区。但有三个硬门槛别跳过：agent 的模型必须支持工具调用和并行子代理；验证器要用到 Node.js；想让验证者真正动手执行验证，必须放在无外部网络的操作系统级沙箱里，没有沙箱，线索只能停在 needs_validation，不能算确认。
我的判断：先在干净的提交上跑 quick 档，读 REPORT.md 时只把 confirmed 当作待修清单，把 needs_validation 当作待办清单，不要把“跑过审计”读成“已经安全”。还有一条成本要先算进日程：一份约 3 万行代码的仓库，一次完整审计要 3 到 4 小时，而且单次运行只能找到多次运行结果的一半左右——把它排进夜里跑，别指望午饭前出结论。
什么情况下这篇结论不成立：你的 agent 不支持并行子代理，那六个阶段里的“换人证伪”跑不起来；或者你只是想快速看一眼代码风格问题，那全套审计全是 overhead，换轻量检查更合适；又或者你拿它去扫不属于你的代码——它只读源码直到进沙箱的前提是“你有权测”，授权之外的代码不在这篇的适用范围里。