先说结论：security-audit-skill 这个项目值得看的不是"AI 帮你找漏洞"这个卖点，而是它把一次安全审计拆成了六个有产物、有校验、有对抗的阶段。原项目在 GitHub 上有 45592 stars，主语言 JavaScript，MIT 协议。我最近把它的中文版通读了一遍，顺带照着 README 把流程跑了一遍，下面按工程视角讲清楚它到底解决了什么、怎么设计的、哪里会卡住。

为什么"让 agent 做安全审计"这件事一开始就不太可信

我试过直接让编码智能体审代码，问题很集中：它会给你一份语气笃定的报告，但你说不清它到底看了哪些文件、漏了哪些入口、哪条结论是它真的验证过、哪条只是"这段代码看起来像有注入"。更麻烦的是，同一个仓库跑两次，结论可能不一样，而且你没法判断第二次是不是覆盖了第一次的盲区。

安全审计这个活儿，工程上真正难的不是"发现",是"可复核"。一份报告如果不能让第二个人顺着证据链走一遍并得出同样结论，那它在流程里就是不可用的，哪怕里面真的有一条高危。

security-audit-skill 的设计基本就是冲着这个来的。它源自 Cloudflare 的漏洞发现框架，是那套多阶段、全舰队系统演化之前的单仓库起点版本。这一点挺重要：它不是一个"提示词合集",而是一套被真实漏洞挖掘流程打磨过的编排结构。

六个阶段，每个阶段都有落盘产物

README 里写得很清楚，流程分六步：

：梳理架构、信任边界、输入面、既有证据和确定性覆盖，产出 

：从账本单元分配隔离的狩猎者，记录检查过程，再由覆盖评审者找缺口。

：每个唯一候选交给全新的验证者，任务是

：全新智能体核验最终来源声明，实质性替换还要再过一名独立验证者。

：从已核验的记录和覆盖账本生成 

我个人最看重的是第 3 步和第 5 步。第 3 步的"查的人不是找的人"是典型的对抗式设计——找漏洞的 agent 天然有动机把自己的候选说成真的，换成全新的验证者去证伪，能压掉相当一部分自我确认偏差。第 5 步再对来源声明做一次独立核验，等于给结论加了两道关。

还有一个细节值得单独拎出来：三种判定是严格区分的。

 要求有完整的来源追踪和有界的观测结果；

 是"有确切未解决的事实、但不下严重性结论";

 记录的是被证伪的候选。这个三分法比常见的"高危/中危/低危"务实得多——它承认了"我现在验不了"是一种合法状态，而不是逼着模型给个等级。

账本和校验脚本：把"覆盖"变成可计算的东西

 这个设计我认为是整套方案里最有工程味的部分。它把"审了哪些单元"变成一份显式清单，而不是靠 agent 自己说"我都看过了"。父级在创建账本后、以及之后每次账本更新后都要跑 

,阶段 5 每次替换后还要再跑一次。

这两个脚本是零依赖的，只需要 Node.js。原文没写具体版本要求，我的建议是别用太老的 LTS。

这种"产物 + schema + 校验脚本"的组合，好处是很实际的：审计结果可以进 CI，可以 diff，可以做版本对比。你不需要信任模型的自述，只需要看 JSON 过没过校验、账本里的单元是不是都被标记了状态。

这一条必须说在前面，因为它直接决定你能不能用出效果。

，用来运行目标代码的构建、测试、进程、浏览器、模拟器、fuzzer 和 fixture。这个沙箱必须禁用外部网络、使用净化后的白名单环境、强制资源限制，并且只允许写入指定的临时路径。

如果这些控制不具备，工作流会把相关线索保留为 

换句话说，没有合格沙箱，你拿到的是一个"静态看了一遍、动态全没验"的结果。这不是缺陷，是设计上的安全取舍——审计工具自己去执行不可信代码，本身就是个巨大的攻击面。但对使用者来说，这意味着你得先有沙箱基建，才谈得上完整体验。我判断这一条会劝退不少个人开发者，它更像是给已经有隔离环境的企业团队准备的。

这个技能依赖并行子 agent 做隔离分工。模型或 agent 不支持并行子 agent 时，无法按设计运行，原文也没给降级方案。

这点在实际选型时容易被忽略。很多人会拿一个单线程的对话式 agent 去套，然后发现流程走不完或者退化成串行，最后得出"这东西不好用"的结论。我的建议是：先确认你的 agent 平台支持 tool use 和并行子 agent，再考虑引入，否则评估结论会失真。

原文里有一句我觉得很坦诚的话：测试中单次运行大约只找到重复运行所能发现漏洞总量的一半，多次运行是叠加的。

这个数字我原样引用，不做任何外推。它的工程含义是：

。同一仓库多次运行是累加的，技能会利用先前的账本和发现来定位缺口、重新验证变更的来源、延续已有证据，而不会把过时或未解决的工作当成已覆盖。

落到流程上，我倾向于把它排成周期性任务而不是一次性动作：每次代码有大改动就跑一轮，账本会自己长起来。这也顺带解释了为什么账本要做成持久化文件——它是跨轮次的记忆。

输出目录这件事，踩过一次就记住了

完整审计模式下如果没指定输出目录，默认写到 

。只有在显式选择被版本控制忽略的目录时，工作流才会写入目标仓库内部。

我的做法是永远显式指定输出路径。一是避免产物散落在 home 目录不好管理，二是如果误写进仓库又没被 ignore，很容易把审计中间产物提交上去。触发方式很直接，向 agent 提请求就行，比如 

do a security review, output to ~/audits/my-project

。当请求匹配 security audit、find vulnerabilities、pen-test the code 这类触发词时技能会自动激活。

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit

。国内网络从 GitHub 拉取可能不稳，配个 npm 镜像或代理会顺畅些，这点中文导读里也提到了。

说回中文版本身。原项目文档是英文的，而这类编排型技能恰恰是文档密度极高的东西——六个阶段的输入输出、三种判定的边界、账本字段的含义、反模式的说明，任何一处理解偏差都会让流程跑歪。中文版做的是文档中文化，并且在顶部加了一段"中文快速上手"的补充导读，明确标注为非原文内容，目的是让人不用读完整篇 README 就能先把项目跑起来。

这个处理方式我觉得是对的：原文翻译保持忠实，补充导读单独标出来，边界清晰。对国内团队来说，降低的主要是理解成本——尤其是 

 这一组文件，英文读一遍能懂，但要准确传达给团队里其他人，中文材料的效率高不少。

需要说明的是，中文版刚发布，stars 还是 0，没有任何社区反馈可参考，翻译质量目前只能靠自己比对原文判断。README 里也写了，翻译不准确可以提 Issue 或 PR。

如果要在团队里引入，我建议按这个顺序评估，而不是一上来就全量铺开：

 这是唯一的硬前置。没有 OS 级隔离环境，动态验证环节直接不跑，你评估的其实只是半个工具。有现成的容器隔离或 CI 沙箱，先接上去。

 tool use 和并行子 agent 两个条件要同时满足。这一步不通过，后面都不用谈。

第三步，挑一个有明确边界的仓库试。

 别拿最大的单体仓库开局，账本会长得你没法看。选一个模块划分清楚、输入面相对收敛的服务，跑两到三轮，看账本覆盖率和 

 的比例。后者比例过高，通常说明沙箱或环境没配好。

第四步，把校验脚本接进流水线。

 是零依赖的，接入成本很低。让 JSON 过校验成为准入条件，比人工看报告靠谱。

第五步，把审计变成周期任务。

 基于"单次约覆盖一半、多次累加"这个已知特性，一次性审计的期望值要放低，周期性跑才符合它的设计意图。

。SAST、依赖扫描这些确定性工具解决的是另一类问题，这个技能做的是需要推理和串联的审计工作，两者是互补关系，别指望它覆盖前者。

。这类记录恰恰是有价值的信息，它告诉你"这里有个确切的问题但当前环境验不了"。团队应该有人负责消化这部分，而不是只看 

。第六阶段叫"目标中立报告",意思是报告生成不依赖具体目标类型。这个设计让流程可以复用到不同技术栈，但也意味着具体到某个栈的深度，得靠 

。我目前只在有限几个仓库上跑过，对它在大型多服务仓库上的表现没有足够判断，这块还得再看。

整体讲，这个项目的价值不在"AI 找漏洞"这个层面，而在于它给出了一套让 AI 审计结论可以被复核、被校验、被累积的工程结构。45592 stars 说明这套思路在英文社区被认可，中文版把理解门槛降下来了。至于它在你自己的代码库上能挖出多少东西，取决于沙箱、agent 能力和跑的次数——这三件事，工具本身替不了你。

security-audit-skill 工程视角：让 AI 审计结论可复核，而不是又一份"看起来很像"的报告

人工智能

security-audit-skill项目核心价值在于其六阶段对抗式安全审计流程，通过独立验证、覆盖账本及校验脚本实现可复核的AI审计结论。需沙箱和并行子agent支持，多次运行累加覆盖，适合周期性执行。中文版降低理解门槛，但需自评翻译质量。

安全审计

JavaScript

智能体

容器

GitHub

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

security-audit-skill 工程视角：让 AI 审计结论可复核，而不是又一份"看起来很像"的报告

security-audit-skill 工程视角：让 AI 审计结论可复核，而不是又一份"看起来很像"的报告

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐