Cloudflare开源AI审计Skill：让AI Agent学会代码审查

Cloudflare 开源了一款给 AI 用的审计 Skill，一天涨了 3000 星。这条消息我是在刷项目动态时看到的，说实在话，先震到我的不是项目技术含量，而是这个涨星速度。一个以边缘计算和安全基础设施出名的公司，开源的居然不是 Workers 的周边工具，而是一份“怎么让 AI Agent 学会审计代码”的岗位说明书。评论区里没人玩梗，全在问怎么把它接进 Cursor、能不能替代人工 Code Review。

这其实是 AI 编程走到现在的必然结果。代码越来越多是 AI 写的，但能让 AI 写完直接上线的团队，目前我一个都没见过，连 Cloudflare 自己都不敢。这个 Skill 想解决的，就是“AI 写代码飞快、人审代码跟不上”的错位问题。我把它跑起来试了几天，审了好几个项目，把设计思路、安装方式、踩过的坑整理成下面这份文字，给那些正被 AI 代码质量搞得睡不着的朋友做个参考。

1. 为什么 AI 写的代码必须“过一道手”：从自动化焦虑说起

1.1 AI 写代码的三大坑：看着对、跑得通、经不住审

先说说我为什么特别关注这个东西。我自己过去一年里，AI 写的代码占日常提交的比例越来越高，但踩的坑也越来越诡异。最常见的第一类问题，是幻觉 API 和幻觉依赖。AI 会在代码里调用一个看上去很像样其实不存在的库，或者用一个早被废弃的 API。最离谱的一次，它给我生成了一段第三方支付 SDK 的调用代码，函数名、参数格式全是对的，但你一查版本号，根本不存在。代码能编译、测试能过，一上生产就直接 500。

第二类问题是安全边界缺失。AI 特别擅长把“功能”做出来，但非常不擅长意识到自己在越权。比如一个内部接口，AI 可能直接给你加上“任何人都能访问”的配置；一个导出功能，它不校验操作者是不是管理员；一份日志文件，它把用户的手机号原样打出来。这些问题在单测里几乎看不出来，因为测试数据是造出来的，没人会故意造一个“非法访问者”。

第三类问题，是“对测试负责、不对系统负责”的凑合主义。AI 生成的代码往往局部非常合理，渲染、状态管理、缓存设置一套又一套，但放在整个系统里就是灾难。比如在 for 循环里挨个发 HTTP 请求，比如把大数据量查询写成 N+1，比如临时目录被当成持久化存储来用。这些问题你不把代码放到真实场景里运行，根本意识不到存在。

我还记得有个朋友让 AI 把一个内部服务从 HTTP 改成 gRPC，AI 倒腾得很快，但是把服务发现地址写死成了 localhost。测试环境跑了整整两周才被注意到，所有人都以为在连远程开发机。这个事让我彻底明白，AI 代码审查不是可选环节，是必须环节。

1.2 审计为什么能变成 Skill：它天生就是一套可固化的方法

有一种观点认为，代码审计这种需要“经验”的事情，AI 干不了。我一开始也是这么想的，但后来发现这个判断有问题。代码审计恰恰是所有代码相关工作里最容易被标准化的那一类。为什么？因为它有明确的检查对象、明确的检查维度、明确的结论输出格式。

一个资深工程师做 Code Review，脑子里走的流程基本是固定的：先看变更范围，再跑依赖安全检查，然后看认证鉴权有没有缺，接着看数据流有没有注入点，最后看错误处理和可观测性。这个流程和菜谱没什么本质区别。你把它写成一份带步骤、带判据、带输出规范的文档，再交给 AI Agent 去执行，效果就会非常稳定。

Cloudflare 这个审计 Skill 的设计逻辑，其实就是把“资深安全工程师的审查脑回路”翻译成了 AI 能照着执行的指令集。我看了它的主文档之后，第一反应是：这不就是我一直想要但懒得写的东西吗。

1.3 一天 3000 星，抄的不是热点，是信任焦虑

这个项目一天涨了 3000 星，说明什么？说明全世界的开发者对 AI 生成代码的态度，已经从“哇，好快”变成了“等等，这玩意能信吗”。这跟十年前运维圈对“自动化一切”的焦虑一模一样：工具越强大，人越担心失控。现在的现实是，AI 把代码产出速度拉到了人类极限之上，但代码审查这件事还停留在老办法上。

所以一个能把“AI 写出来的东西再过一遍”的工具，踩中的是所有人最普遍的痛点，根本不是什么小众需求。

这背后还有一层更深的动机。Cloudflare 自己是做边缘计算和基础设施的公司，Workers 平台上跑着大量第三方业务代码，代码质量风险不只是开发者自己的问题，也是平台要背的成本。与其一遍遍优化 WAF 规则，不如把审计能力开源出来，让大家从源头把风险挡住。这个逻辑，比单纯追热点要站得住脚得多。

2. 拆解 Cloudflare 审计 Skill：它到底审什么

2.1 Skill 不是插件，是给 AI Agent 的“岗位说明书”

先把 Skill 的概念搞清楚。它不是传统的 IDE 插件，也不是一个独立的命令行工具，而是一组结构化的文件，一般包含一份 SKILL.md 主文件，外加规则、清单、示例、模板等子文件。

SKILL.md 是灵魂。它用自然语言定义这个 AI Agent 在执行审计任务时的身份、目标、流程和输出要求。要理解它，最合适的类比是“岗位说明书”——它不负责具体干活，但负责让 AI 知道“作为审计员，你应该先干什么、后干什么、什么算合格、什么算严重问题”。

我在实际用的时候，明显感觉到 Skill 和普通 Prompt 的区别。Prompt 是一次性的，这次写得好下次还得重新写；Skill 是沉淀下来的岗位流程，可以进版本库，可以跨工具复用，可以被社区 fork 和改进。你今天从 GitHub 拉下来，明天 Cursor 和 Claude Code 都能用。这也解释了为什么 Cloudflare 选的是 Skill 而不是一套私有工具。

2.2 审计清单拆解：从依赖安全到权限模型

我仔细看了这个 Skill 的审计维度，其实没搞什么玄学，就是踏踏实实的代码审查清单。核心大概可以分成这么几块：

这些检查点并不新鲜，新鲜的是它把这些东西全变成了 Agent 可执行的规则，并且要求输出规范的审计报告，而不是让工程师随手写几句“看起来还行”。规则一旦显式化，审计就不再依赖某个人的心情和记性。

2.3 和人工 Code Review 相比，它的三个核心差异

第一个差异是规则显式化。人工 review 依赖个人记忆和状态，今天记得检查加密，明天可能就忘了。Skill 的规则写在文件里，每一条都在那儿，不会遗忘，也不会因为评审人不同而出现双重标准。团队里最怕的就是“不同人审、审出不同结论”，Skill 天然规避这个问题。

第二个差异是上下文可复现。同样的代码，你让不同的工程师审，得到的是不同质量的反馈。你让同一个 Skill 审两遍，得到的是几乎一致的判断基准。这一点对团队协作特别重要，“我认为有问题”可以变成“规则第 3.2 条说了这是高风险”，扯皮的难度就大了。

第三个差异是链条变短。传统 review 是“写完代码 → 等人 → 返工”，现在 AI 写完代码后，立刻可以调用 Skill 审一遍，把大部分低级问题当场解决。真正需要人工介入的，只剩那些需要业务判断的复杂问题，一个团队的 review 等待时间可以压掉一大截。

3. 把审计 Skill 跑起来：环境准备与实操流程

3.1 前置准备：仓库、模型和宿主

先说要准备什么。第一，一个支持 Skills 机制的 AI 编程环境，比如 Cursor、Claude Code、Codex 这类支持自定义技能的工具；第二，一个可用的模型，API 或本地部署都行，但模型能力尽量强一点；第三，目标代码仓库，最好是一个真实项目，别拿几行示例代码糊弄。

Clone 下官方仓库之后，先把 Skill 放到工具指定的技能目录。常见做法是放在~/.claude/skills/或者项目下的.claude/skills/目录，Cursor 这类编辑器也有自己的导入入口。具体路径各家更新得很快，用之前先查一下官方文档，别凭记忆写死路径。

然后要做一件很多人忽略的事：在 AI 环境里补充项目的技术栈和业务背景。比如这是一个 Spring Boot 的私有化部署项目、没有外部用户、使用 PostgreSQL，这些信息对审计的准确度影响非常大。缺了上下文，AI 会把框架自带的方法当成危险调用，误报率能翻好几倍。

3.2 核心实操流程：从触发到报告的四步走

实操流程可以拆成四步：

第一步，触发审计。把审查对象指给 Agent，说“请用 audit-skill 审查 src/ 目录下最近提交的代码”。这一步不需要写复杂指令，Skill 加载之后，Agent 会自动进入审计员角色。

第二步，观察执行过程。Agent 会先加载 SKILL.md，然后按照流程开始逐段检查依赖、配置、业务逻辑、错误处理、测试代码和部署脚本。你会发现它输出的中间结果和普通代码问答明显不一样，更像是在走一套流程。

第三步，多轮追问。第一次审计结果出来之后，不要急着收工。问它“这个重点再展开一下”“这个风险点给出修复方案”，Skill 的规则会约束它在这些追问里继续按审计员的身份作答，而不是跳回“聊天助手”的模式。

第四步，汇总成报告。一份完整报告会按严重等级排列问题，每条带文件路径、行号和原因。到这一步，你就可以决定哪些问题当场改了，哪些转进 issue 列表。

3.3 一份真实审计报告的阅读重点

我模拟一个实际场景。假设你用这个 Skill 审查一个登录模块的代码，输出的报告简略形式会是这样：

• 高危：密码哈希使用了过时的 MD5 算法，建议替换为 bcrypt 或 argon2。
• 高危：登录接口没有加频率限制，存在暴力破解风险。
• 中危：日志中打印了用户邮箱明文，建议脱敏。
• 低危：会话过期时间设置过长，建议缩短到 2 小时以内。

读报告的时候，你要重点关注的不只是“高危”两个字，而是每一条里面的“证据位置”。好的 Skill 不会只甩一句话，它会明确到文件路径、代码行号和违规原因。如果报告里没有这种精细度，基本可以判断模型没理解规则，或者你给的上下文不够。

另外，看到“低危”也别直接忽略。低危问题往往不代表不重要，只是当前场景下影响面有限。比如“会话过期时间过长”在内部系统里可能无所谓，在面向公网的系统里就是实打实的风险。判断权还是在你手上。

4. 落地过程中的常见问题与排查技巧实录

4.1 误报太多怎么办：从“规则过死”到“上下文缺失”

用这类 Skill 审计，最大的问题是误报。你审一个大型项目，报告出来 80 条，里面 60 条是“检出但其实不是问题”的。我总结下来，误报来源基本是三个：第一个是模型不知道项目的技术栈和版本，把框架自带的方法当成了危险调用；第二个是模型不知道业务上下文，把数据校验的中间状态当成敏感信息泄露；第三个是模型对“危险”的判断标准过于激进，任何用户输入都标记为注入，不管有没有转义。

解决办法，最有效的是在触发审计时补充项目背景。我的习惯是先给出一段项目说明：“Spring Boot 3.2，私有化部署，仅内网可达，PostgreSQL 使用 JPA，无文件上传功能”，然后让它基于这些约束去做判断。

如果误报率还是高，第二招是调整报告模板，在输出格式里加一条“仅列出可确定的问题，可疑项单独归到‘需人工确认’分类”。这能让模型从“什么都报”转向“谨慎地报”，反而更接近资深工程师的产出。

4.2 和 CI/CD 流程怎么结合：别把它变成一次性的“仪式”

很多人拿到 Skill 的第一反应是接入 CI，让每次提交都自动审计。我的建议是：先别急着全量接入。原因有两个。

第一，成本。AI 审计一次大仓库的代码，Token 消耗非常可观，尤其是那种几千个文件的老项目，如果每次 push 都全量跑，月结账单会很难看。第二，噪音。全量接入之后，每天几十条保险丝级别的建议，团队很快就会麻木，最后没人看报告，形同虚设。

有一种比较稳妥的折中方案：先只在 staging 分支合并前跑，跑一周之后看误报率和有效发现率，评估之后再决定要不要往 CI 主链路加。我自己的经验是，把审计报告模板接到团队消息群里，高危问题直接机器人提醒，中低危问题进 issue 列表。这样既不淹没日常工作，又保证重要问题不会被漏掉。

4.3 团队推广的冷启动：从高危变更开始

另外一个常见的坑是团队不接受。开发者的第一反应通常是：我写的代码凭什么让 AI 挑刺。

我的经验是不要全面铺开，只挑高风险变更引入审计，比如涉及支付、鉴权、数据导出、用户隐私的 PR，必须附带 AI 审计报告。这样做有两个好处：一是让团队把“审计”理解成保护自己的工具，而不是监控自己的工具；二是通过几个高风险 case 证明价值，后面再逐步扩大覆盖范围就顺理成章了。

等团队习惯了，再把 Skill 的使用权交给所有人，大家自己写完代码自己先审一遍。到这一步，审计就从“流程要求”变成了“个人习惯”。

4.4 不同模型的差异：同样一份 SKILL.md，结果能差很多

这个值得单独说。Skill 能不能发挥效用，非常依赖底层模型的理解能力和遵循指令的能力。我用同一个审计 Skill 测过几个模型，差异非常明显：有模型的报告像资深安全工程师写的，逻辑清晰、定位准确、修复建议可行；有的模型输出一堆“代码没有明显问题”，然后给你三条正确的废话，气得人想摔键盘。

选型上，如果组织里有本地化或成本要求，优先选遵循指令能力强的模型，不要为了省钱用一个通用小模型跑审计，结果基本等于零。

还有个偷懒的判断办法：拿一段非常明显的硬编码密钥代码试它，看它报不报得出来。报不出来，就别指望它审出更隐蔽的问题，换模型比改 Prompt 更有效。

5. 从“审计代码”到“审计系统”：这个方向还能走多远

5.1 审计 Skill 的边界：它审的是快照，不是运行时

先泼一盆冷水。这类 Skill 审的是“代码快照”，它看不到运行时状态。一个分布式系统的故障，往往不是写代码时埋下的，而是多个服务在运行时互相作用才暴露的。比如鉴权绕过的案例，很多问题发生在服务间调用链上，单次代码审计很难发现这种跨服务的组合问题。

所以如果谁想靠一个 Skill 替代所有代码审查和安全测试，那是不现实的。它更适合的价值定位，是做一个精度可靠的“第一道防线”，把依赖风险、逻辑漏洞、配置缺陷这些静态问题在开发阶段拦截掉。运行时的问题，还是得交给监控、链路追踪和架构评审。

5.2 Skill 生态给了开发者一个新玩法

Skill 这个形态本身，挺有想象空间。它不只是一个代码审计工具，更是一种全新的“经验封装”方式。一个团队踩过的坑，可以沉淀成一份 Skill 让新同学复用；一个资深性能优化专家的排查方法，可以变成 Skill 让 AI 照着执行；一个运维老兵对告警的处理逻辑，也可以固化成自动化流程。

云时代里个人能力的边界，正在被这些开源 Skill 悄悄拉长。以后开源社区的竞争，不光是拼模型和框架，还拼“谁能把好经验更好地固化成规则”。

最后再分享一个实操中发现的小技巧：不要在仓库里放一份 Skill 就不管了，最好安排人定期维护规则库，把团队最近踩的坑不断往清单里补。这种规则库是会复利的。维护半年之后，你团队踩过的每个坑，都能变成 AI 帮你挡掉的下一发子弹。到了那个时候你再回头看这份一天涨了 3000 星的审计 Skill，会发现它带来的最大价值不是省了审代码的时间，而是让“代码审查”这件最需要经验的事，第一次变成了可以积累、可以复制、可以版本化的资产。