解读 GitHub 项目：security-audit-skill——让 AI 审计先学会别瞎报
工作台今日候选里排第一的，是 Cloudflare 的 security-audit-skill。它不是又一个“让 AI 帮你看代码”的提示词合集，而是一个给 coding agent 用的审计技能：把一次安全审计拆成固定流程跑完，最后只认有证据的结论。
这篇文章不复述 README，重点说三件事：它跟普通 AI 代码评审到底差在哪、适合谁上手、以及你第一次跑最容易踩的坑。
一、为什么值得关注：它治的是 AI 审计最常见的毛病
普通 agent 做代码评审，常见毛病不是找得少，而是报得多、证据少。一段看着可疑的代码，它能讲出一套很像那么回事的攻击链，但你顺着源码一查，发现前提根本不成立。修这种“假漏洞”比不修更浪费时间，还会把真正的风险淹没。
这个技能的核心设计，就是把“找”和“验”分给不同的人。找漏洞的 agent 不能自己给自己盖章，验证的 agent 必须想办法证伪它。证伪不了、证据链完整的，才进 confirmed；证据不完整、还差一个关键事实的，不给严重程度，只记成 needs_validation；被证伪的，记成 rejected，并且留着记录。
这个区分比结论本身更重要。对做审计的人来说，最怕的不是漏报一个低危问题，而是把“还没搞清楚”当成“已经确认”，然后按严重程度排期去修。
二、它怎么跑：六个阶段，其实就三句话
流程说起来是六个阶段，理解起来可以压成三句话。第一句，先画地图：侦察阶段把架构、可信边界、输入面和已有的覆盖情况写成 architecture.md 和 coverage-ledger.json，后面所有工作都对照这张地图查缺补漏，而不是想到哪查到哪。
第二句，分头找、分头验：按覆盖清单派不同的猎手去查，覆盖评审员专门找没覆盖到的地方；每个候选漏洞都交给一个全新的验证者去证伪。第三句，只从已验证的记录生成报告，报告不是 agent 现场发挥写出来的，而是从 findings.json 和覆盖清单里推导出来的。
多次跑同一个仓库，结果是累加的：它会用以前的清单和结论去盯改动过的地方、重新验证变了的源码，而不是把旧结论当成已覆盖。这个设计很对审计的胃口，因为代码审计本来就不是一次性工作。
三、适合谁，不适合谁
适合三类人。第一类，自己维护一个有一定规模的代码库，想定期跑一次结构化审计，但请不起外部审计团队的人。第二类，团队里已经在用 Claude Code、Codex 这类支持并行子 agent 的工具，想把“AI 评审”从聊天变成可复查流程的人。第三类，想学习安全审计方法论的人：它自带的攻击面清单覆盖 Web、客户端、供应链、云和部署、协议、资源耗尽、数据隔离这些方向，照着清单走一遍，比零散看漏洞文章系统得多。
不适合两类人。一类是只想快速扫一遍、马上要一份漏洞列表交差的人，这个流程本来就慢，而且故意不给你“看起来很严重但没证据”的结论。另一类是完全没有安全基础、希望 agent 直接告诉你“修这里就行”的人：它给的是证据和待验证项，最终判断还是要人做。
四、上手体验和坑：先把这四条看完再跑
安装本身不难，用 Skills CLI 装好技能，在代码库里对 agent 说一句“security audit this codebase”就能触发。真正的坑在运行条件上。
第一，沙箱是硬要求。README 明确要求一个操作系统级沙箱：跑目标代码、测试、浏览器、模糊测试这些动作时必须断外网、环境白名单、资源受限、只写指定的临时目录。没有这个沙箱，流程不会替你冒险执行目标代码，相关线索会一直停留在 needs_validation。你以为是审计没跑完，其实是它在等一个安全的执行环境。
第二，成本和时间要按“多次跑”来算。官方自己的测试里，单次跑找到的漏洞大约只有多次跑总和的一半左右。这意味着只跑一次就下结论，很可能漏掉一半；但多次跑也意味着 token 和时间成倍涨。第一次试，建议先拿一个自己熟悉的小仓库跑，别直接上生产大仓。
第三，别把输出目录搞错。完整审计模式下，默认输出在 ~/security-audit-skill/<仓库名>/run-<编号>，只有当你明确选了一个版本控制忽略的目录时，它才会在目标仓库里写东西。跑之前先确认输出落在哪，别事后才发现审计产物混进了提交里。
第四，验证脚本别跳过。它自带两个零依赖的 Node 验证器，分别校验覆盖清单和 findings.json，流程里会在关键阶段跑它们。如果你手动改了结论文件，跑一下验证器比肉眼检查靠谱。
五、怎么试，第一次这样试最划算
先装技能，再找一个你自己写过、规模不大的项目，对 agent 说做一次安全审计。跑完先别看报告正文，先看 findings.json 里三类结论各有多少：如果 confirmed 很少、needs_validation 一大堆，问题大概率出在沙箱或执行条件上，而不是代码真的很干净。
然后挑一个 confirmed 结论，顺着它的源码追踪自己复现一遍；再挑一个 needs_validation，看看它到底卡在哪一个没确认的事实上。这个过程走完，你就知道这个技能在你手里是“能用的审计流程”，还是“又一个报得多、证据少的评审工具”。
我的判断是：它值得关注，不是因为 Cloudflare 背书，而是因为它把审计里最难的一步——“别轻信自己的发现”——做成了流程。AI 审计以后拼的不是谁找得多，而是谁的结论经得起复查，这个技能就是往那个方向走的。
项目地址：https://github.com/cloudflare/security-audit-skill