先说清楚这个项目是什么。security-audit-skill 是 Cloudflare 开源的一个编码智能体技能（coding-agent skill），装上之后，你的 agent 会按照一套固定流程对代码库做安全审计，而不是随便扫两眼就给结论。原项目在 GitHub 上有 45592 stars，主语言 JavaScript，MIT 协议。我这次介绍的是它的中文翻译版，仓库地址是 yangshun2005/security-audit-skill-cn，翻译日期标注为 2026-10-25，中文版刚发布，还没有积累自己的热度，这一点得说明白，别误会成什么爆款新项目。

我为什么觉得它值得单独写一篇？因为大部分“让 AI 找漏洞”的用法，问题不在模型能力，而在流程。你丢一个仓库给 agent，它给你列十条“可能存在 SQL 注入”，你逐条看下去，一半是误报，一半是它自己没验证就下的判断。这个技能想解决的正是这件事：把审计拆成可复核的工序，让找的人和查的人不是同一个。

它到底跑哪六个阶段

按 README 的描述，整个流程分六步，我按自己的理解复述一遍：

第一步是侦察。agent 会梳理架构、信任边界、输入面，把结果写进 architecture.md 和 coverage-ledger.json。这个账本文件挺关键，后面所有“哪里查过、哪里没查”都记在它上面。

第二步是覆盖驱动的狩猎。从账本单元里分配隔离的狩猎者，每个狩猎者记录自己检查了什么，再由覆盖评审者去找缺口。这里的设计意图是防止“查了三个文件就说全查完了”。

第三步是候选验证。每个候选问题交给一个全新的验证者，任务是尝试证伪它。注意，是证伪，不是确认。

第四步是结构化输出。把 confirmed、needs_validation、rejected 三类记录写进 findings.json，并对照 report-schema.json 做校验。

第五步是独立记录核验。换一个全新 agent 核验最终来源声明，实质性替换还要再过一名独立验证者。

第六步生成报告，产出 REPORT.md、FINDINGS-DETAIL.md 和 NEEDS-VALIDATION.md，报告本身是目标中立的。

三种判定的含义区分得很清楚：confirmed 要有完整来源追踪和有界观测结果；needs_validation 是事实没解决、且不给严重性评级；rejected 记录被证伪的候选。这个三分类我觉得比常见的“高危/中危/低危”实用，因为它把“我不确定”和“我确认了”分开了，而不是硬塞一个等级糊弄过去。

装起来只要一条命令

安装走 Skills CLI，命令照抄原文：

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

想装到用户级，加 --global：

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

装完在编码智能体里打开要审计的代码库，直接提请求就行，比如：

security audit this codebase

也可以指定目录或输出位置：

find security vulnerabilities in ./src

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

请求命中触发词（security audit、find vulnerabilities、pen-test the code 之类）时技能会自动激活。完整审计模式下如果没指定输出目录，默认写到 ~/security-audit-skill/ /run- 这个路径，原文就是这么写的，路径中间有个空格，我猜是模板变量没替换干净，你实际用的时候留意一下，别照抄这个路径。

国内网络这块提一句：安装是从 GitHub 拉取的，可能需要配 npm 镜像源或者走代理，这个不算项目的问题，但会卡住不少人。

环境要求里最容易被忽略的一条

依赖上有两样：一个支持工具调用和并行子 agent 的编码智能体及模型，以及 Node.js，用来跑那两个零依赖的校验脚本 validate-coverage-ledger.cjs 和 validate-findings.cjs。Node.js 具体版本原文没写，操作系统和硬件要求也没写，这几项我没法替你确认。

真正要命的是沙箱要求。README 明确说，需要一个由操作系统强制执行的沙箱，用来跑目标代码的构建、测试、进程、浏览器、模拟器、fuzzer 和 fixture。这个沙箱必须禁用外部网络、使用净化后的白名单环境、强制资源限制，并且只允许写入指定的临时路径。

缺了这些控制会怎样？工作流不会硬跑，而是把相关线索保留为 needs_validation，不执行目标代码。换句话说，没有合格沙箱，你的审计深度会明显受限，很多需要动态验证的东西只能停在“待验证”。这一条我建议在选型评估阶段就先确认，别装完了才发现跑不起来。

另一个前提是模型得支持并行子 agent。这个技能靠隔离分工来保证“找的人不是查的人”，模型不支持并行子 agent 时没法按设计运行，原文也没给降级方案。我的判断是，如果你的 agent 环境只能串行调用，这个技能的价值会打不少折扣，不如先别上。

中文版真正省掉的是什么

翻译版做的事情很朴素：把 README 正文译成中文，另外在顶部加了一段“中文快速上手”的补充导读，明确标注非原文内容，目的是让你不读完整篇 README 就能先把项目跑起来。翻译声明里也写了，如有不准确欢迎提 Issue 或 PR。

价值在哪？这类技能型项目的文档密度很高，SKILL.md、RECONNAISSANCE.md、HUNTING.md、ATTACK-CLASSES.md、MEMORY-SAFETY-AND-BINARY.md 一堆文件，每个都承载流程约定。英文读一遍能懂，但要边读边对照自己的仓库做映射，中文母语的工程师读中文版会快不少，尤其是“三种判定分别是什么意思”“账本什么时候校验”这种细节，读错一个字，落地就偏了。

不过我得说句保留的：中文版刚发布，翻译质量我只看了 README 摘录部分，没有逐文件比对，长期维护能不能跟上原项目的更新也还有待观察。如果你要做严肃的审计流程，建议中文版和 README_en.md 对照着看，关键约定以英文原文为准。

几个我踩过或者预判会踩的坑

第一，单次运行覆盖不全。原文写得很直白：测试中单次运行大约只找到重复运行所能发现漏洞总量的一半，多次运行是叠加的。所以别跑一次就收工，同一仓库多跑几遍，它会利用先前的账本和发现去定位缺口、重新验证变更的来源。这一点跟很多人的直觉相反，大家习惯“跑一遍出报告”。

第二，输出目录别乱指。只有在显式选择被版本控制忽略的目录时，工作流才会写入目标仓库内部。默认是写到用户目录下的运行目录，这个设计其实是对的，避免审计产物污染仓库。

第三，父级要在创建账本后以及每次账本更新后运行 validate-coverage-ledger.cjs，阶段 4 运行 validate-findings.cjs，阶段 5 每次替换后再跑一次。这几个校验点是流程的骨架，跳过就等于放弃了“可复核”这个核心卖点。

落地顺序上我的建议

如果你打算在团队里推这个技能，我的顺序是：先确认沙箱能力，再确认 agent 的并行子 agent 支持，然后拿一个小仓库跑通全流程，最后才谈接入常规研发流程。反过来做，大概率是在流程评审会上被问“这个结论谁验证的”然后答不上来。

选型时还有一个评估维度值得提前想清楚：你要的是“发现更多候选”，还是“结论可追溯”。这个技能明显偏后者，它宁愿把东西标成 needs_validation 也不给你一个好看的严重性数字。如果你的场景是上线前的强制门禁，这种保守取向是加分项；如果你只是想快速扫一遍找感觉，它可能显得啰嗦。

最后说一句，这个项目源自 Cloudflare 的漏洞发现框架，是那个多阶段、全舰队范围系统的单仓库起点版本。定位是起点，不是终态，用它的时候心里有这个预期会舒服很多。