写代码的人都清楚代码审查这件事在理论上是“质量底线”在实践里经常是“最后一个没人愿意干的活儿”。尤其是安全审查普通的 Code Review 看逻辑、看风格、看可维护性而安全审计要在同一段代码里找出攻击面、数据流漏洞、越权风险、敏感信息泄漏。真靠人一个个文件过一个中大型后端项目审下来两三天搭进去很正常最后还不一定能覆盖到位。我自己最早也试着把代码直接丢给大模型让它“帮忙看看漏洞”结果模型把我的登录接口夸了一遍然后把重点放在了“建议增加输入校验”这种正确但没用的废话上。直到我认真研究了 security-audit-skill 这一类把安全审计流程系统化封装成技能包的思路才意识到AI 做代码审查不是不能干而是大部分人用错了方式。security-audit-skill 这个名字把它拆开看就是“安全检查专业能力包”。它的核心逻辑不是给你一个更聪明的聊天机器人而是把安全审计专家脑子里的那套检查顺序、漏洞分类、证据链、评级的打法全部结构化地灌输给大模型让 AI 从“被动回答问题”变成“主动找茬”。这篇文章我打算从项目思路、核心链路、实操接入、问题排查几个维度完整拆一遍适合正在做安全工程、后端研发、DevOps 平台建设以及想在公司内部落地 AI 辅助代码审查但还没找到正确姿势的团队参考。1. 项目思路AI 做安全审计为什么需要专门的技能包先说一个我踩过的坑。有一回我拿一个 Java 后端项目测裸模型的安全审查能力项目里有一个明显的 SQL 拼接查询模型确实报出来了我挺高兴又让它继续查接口鉴权结果它对一个没有加任何权限注解的管理员接口只给出了一句“建议关注权限设计”。这种回答放在技术讨论里没什么问题放在安全审查场景里就是典型的不及格。原因不在模型笨而在于通用对话模型和“审计工作流”之间缺了一层工程化的衔接。你问它“这段代码有没有漏洞”它的默认行为是给你一个尽量全面但不敢把话说死的答复你问一个安全审计老手同样的问题他会先列攻击面再追数据流再核对防御点最后只输出有把握的结论。security-audit-skill 做的事情就是把第二种思考方式变成模型可以执行的指令链。为什么普通的提示词做不到我在实际测试里发现裸 Prompt 就算你把“请检查 SQL 注入、XSS、越权、硬编码密钥”全部列上模型输出的稳定性还是取决于它对上下文的临场理解。它容易陷入“什么都沾一点”的泛化回答很多真正致命的漏洞恰恰藏在不显眼的数据转换、错误处理、反序列化位置模型不会主动去深挖。技能包本质上是用一套固定的规则框架强迫模型按顺序走过“资产识别 - 入口枚举 - 数据流追踪 - 防护检查 - 漏洞定级”的完整流程。这就好比给一个聪明但没有经验的新人一本老专家的检查手册他即使不知道具体套路照着手册一步步执行产出也至少能到及格线。我上手 security-audit-skill 的时候第一个感受是它在“角色设定”上做得很克制。它不会花一大段告诉你“你是一位资深安全专家”而是直接给出审查目标、审查边界、以及一套漏洞分类表每条漏洞类型都带着判断标准和对应的代码特征。这种设计其实很关键——大模型的注意力是有额度的你把额度耗在角色扮演上真正留给代码分析的上下文就少了。技能包把稀缺的上下文预算全部用在规则和分析路径上最终输出的判断密度完全不一样。这套思路真正解决的实际问题有三类。第一类是人手不足团队里没有专职安全工程师靠开发互相 review安全视角基本缺失第二类是海量代码与有限人力之间的矛盾一个几十万行的项目人不可能逐行过AI 可以按批次扫第三类是经验不可沉淀某个老开发者凭直觉发现的问题没有形成文档人一走经验就丢了而技能包把检查逻辑固化下来了。这三个痛点叠加在一起才是 security-audit-skill 这类技能包真正值得投入时间去研究的原因。2. 核心链路一个安全审计技能包是怎么工作的2.1 输入侧先解决“AI 到底该看什么”很多人在用 AI 做代码审查时喜欢把整个项目目录打包扔给模型这是第一个错误。模型确实能读代码但如果你不告诉它哪些文件是业务核心、哪些是配置文件、哪些是自动生成的代码它会在低价值文件上浪费大量上下文。我在配置 security-audit-skill 时第一步做的不是写规则而是改造输入侧。输入内容通常要分成四类。第一类是高危文件白名单比如涉及鉴权、支付、数据导出、用户管理、文件上传的代码这类必须完整读第二类是依赖清单像 package.json、pom.xml、requirements.txt模型可以通过这些文件判断第三方依赖是否存在已知漏洞版本第三类是数据流上下文尤其是用户输入从哪个入口进来、经过哪些处理、最终落到哪个敏感操作如果只给单个文件模型很难追踪完整的链路第四类是运行环境信息比如框架版本、中间件类型这些决定了某些漏洞是否真正可利用。我在实际项目中会把输入组织成一套标准化的审查清单先让模型识别项目类型和框架再让它标注出“用户可控数据的主要入口”最后再进入具体的漏洞扫描阶段。这样看起来多了一步但模型后续的判断会有明确的方向感。你可以把这理解为给审计员一张项目地图而不是把他扔进一个陌生的大楼里自己找房间。从我实测的效果来看加了这一步之后高优先级漏洞的捕获量提升了非常明显漏报率下降了一大截而代价只是多消耗一次调用。2.2 规则层漏洞分类和权重是怎么设计的security-audit-skill 的另一个核心部件是漏洞分类与风险权重体系。这里不能简单地把漏洞列一个清单因为模型判断“ SQL 注入”和判断“业务逻辑漏洞”的难度完全不一样你给的规则描述越精确模型的表现越好。我自己整理的规则层由三个部分组成。第一部分是漏洞类型目录包括注入类、越权访问类、敏感信息泄漏类、身份认证与会话管理类、加密安全类、反序列化类、文件操作类、依赖风险类等。每一类都配了具体的代码特征描述。比如注入类漏洞不仅描述“字符串拼接 SQL”还要提示模型检查“参数化查询是否真的生效”、“存储过程中是否还有动态拼接”、“MyBatis 的${}写法与#{}的区别”这类细节。模型对越具体的特征越敏感这是通用 AI 一个非常明显的特性。第二部分是严重程度评分。这个不能完全照搬 CVSS因为大模型对 CVSS 的向量计算并不擅长你让它算分它会给你一个“看起来合理但实际不可复现”的数字。更稳妥的做法是采用简化的分级规则可被未授权用户直接利用的远程代码执行或越权访问定为严重需要登录后才能触发的注入或敏感数据泄漏定为高危只影响开发环境、或利用条件非常苛刻的定为中危或低危。我给每一级都写了判断边界让模型把“漏洞类型”和“利用前提”分开描述最后再给出等级而不是一上来就抛分数。第三部分是审计深度配置。你可以设置这次审查是“快速巡检”还是“深入审计”。快速巡检只扫明显的高风险模式适合每次提交代码后跑一遍控制在几分钟内深入审计则要求模型对每个关键入口做完整的数据流追踪、模拟攻击者构造请求、检查缓解措施适合发版前的大规模审查。同一个技能包通过调整这个配置能适配两种完全不同的工作节奏。我把这个设计类比成“静态扫描”和“人工渗透测试”之间的区别前者追求覆盖面后者追求情报深度。2.3 输出设计把漏洞讲清楚比找到漏洞更难AI 代码审查的产出格式直接决定了这套东西能不能在团队里落地。如果模型只是说“这段代码存在 SQL 注入风险”开发同事看完只会回你一句“具体哪里怎么改”。所以 security-audit-skill 的输出模板必须同时包含几个关键字段。第一个是漏洞定位要精确到文件和行号同时引用触发漏洞的那几行关键代码让开发不用在几千行代码里大海捞针第二个是漏洞描述要讲清楚这是什么类型的漏洞、攻击者怎样才能触发它、最终的影响是什么这一段要避免使用“可能存在”这类模糊表达而是直接说“未授权用户通过userId参数遍历可访问任意用户订单”这种描述才有讨论价值第三个是修复建议最好给出“修改前 - 修改后”的对照示例模型在写修复建议这件事上表现还算稳定前提是你在规则里要求它给出可执行的代码片段而不是“建议使用参数化查询”这种一句正确的废话第四个是严重等级和优先级方便团队排期。我自己的经验是输出模板越严格后续处理越顺畅。你可以让模型每次都按固定格式输出比如用 JSON 或者带标记的 Markdown 表格这样无论是人工阅读还是接入自动化流水线都非常舒服。我一开始没有在输出格式上做约束结果模型撒欢似的用各种小标题、列表、引用虽然内容也在了但解析起来特别费劲尤其想接进内部系统时非结构化的输出会让你想摔键盘。2.4 为什么结构化技能包比裸 Prompt 的误报率低我统计过一轮对比测试同样是审查一个包含 30 个文件的 Express 项目裸 Prompt 的误报率接近四成而用技能包装备过的流程误报率能压到两成以下。这个差距主要来自两个机制。第一个机制是“证据链要求”。我在技能包里明确写了任何漏洞判断必须附带触发路径和代码证据没有证据链的观察不能算漏洞只能算提示。这个约束极大压缩了模型“瞎猜”的空间。模型在回答问题时本来就有一种讨好用户的倾向你要求它找漏洞它就会努力找点东西出来哪怕只是风格问题。加了证据链约束后它必须找到真实的调用关系才算数这相当于给它的“创作冲动”装上了一个闸门。第二个机制是“复核步骤”。每次审查收尾前技能包会让模型重新审视自己列出的每个高危漏洞检查漏洞等级是否合理、利用条件是否真实、修复建议是否会导致新的安全问题。这一步其实就是让模型做一次自我质疑。你可能觉得模型自己复核自己没什么用但实测下来这个步骤能过滤掉不少“假高危”。因为模型第一次列漏洞时容易放大风险重新读一遍证据后它反而会更客观地收敛结论。这个现象和人类审计员写完报告再复核一遍很像——不是不信任第一遍的判断而是第二遍的视角更冷静。3. 实操落地从接进项目到产出真正能用的审计报告3.1 怎么把技能包接进你的工作流接入方式上不同的人适合不同的路线。如果你主要在类似 Claude 这类支持自定义技能的 AI 工具里做审查最简单的方式是把技能包作为项目级指令文件放进仓库然后在对话中直接引用如果你习惯用代码方式跑完整流程也可以把技能包编译成一套标准 Prompt用脚本读取代码文件、拼接关键信息、调用模型接口再把结果落成 Markdown 报告。我推荐后一种方式因为可控性更好审计记录可追溯也方便接入后续的 CI/CD。无论哪种方式有一个准备工作都躲不开那就是先做一个项目信息清单。我在项目根目录放了一个security-context.md内容包含项目类型、主要技术栈、框架版本、登录鉴权方案、数据存储方式、第三方依赖列表。技能包在开始审计时会自动读取这个文件把基础结论带进分析上下文。这个文件看起来简单但价值极大它相当于把“项目概览”这件事从模型的一次性猜测变成了确定性的输入审计结果的稳定性和真实性都提升了一大截。3.2 关键参数配置五个最值得调的地方第一是温度参数。安全审计和写诗不一样我们不需要模型发挥创造力所以温度建议直接调到 0 或者 0.1越低输出越稳定越不容易出现幻觉。我见过有人用默认温度跑审查结果同一个文件跑两次给出了两个完全不同的漏洞清单这种不可复现性在工程上是灾难。第二是最大输出长度。安全审计报告可能很长尤其是审计大项目时输出很容易被截断。建议把 max tokens 设到你能承受的上限同时拆分子任务限制每次审计的文件数量。不要贪心地一次审二十个文件宁可多跑几轮保证每个文件的报告都是完整的。第三是需要审计的文件范围。我的标准做法是自动排除node_modules、vendor、dist、生成的 ORM 实体类、测试 fixture 这类文件。这些文件要么是第三方代码要么是机械生成的审了既浪费上下文还容易产生噪声干扰。第四是漏洞等级的阈值设定。在快速巡检模式里我会要求模型只输出“严重”和“高危”两类问题中危低危全部折叠到附录。这样团队在第一时间看到的是最需要关心的内容而不是一份良莠不齐的长报告。第五是审查语言。如果团队内部沟通用中文建议在输出模板里直接指定中文描述加英文代码标识。模型在代码注释和行号引用上偶尔会犯小错误但整体上语言一致性对解读帮助很大。3.3 一次真实审查过程的全记录为了直观展示我拿一个精简过的 Node.js Express 应用举个例子。项目里有用户登录、订单查询、文件上传三个模块。我按技能包流程跑了一遍深挖环节的关键交互如下。我先让它输出项目安全上下文模型识别出这是一个 Express 4.x 应用使用 JWT 做登录态校验Multer 做文件上传MySQL 存储数据。接着进入入口枚举阶段模型列出了/api/login、/api/order/:id、/api/upload三个入口。然后我对/api/order/:id这条链路展开了完整的数据流追踪。模型发现了一个意料之外的漏洞接口只在中间件里校验了 JWT 是否有效但没有校验该用户是否有权访问这个订单 ID。换句话说任何登录用户只要篡改 URL 里的订单号就能遍历查看其他用户的订单数据。模型在报告里写得很清楚漏洞类型是“越权访问IDOR”触发条件是“登录用户发送 GET 请求并修改订单 ID”影响是“任意已登录用户可读取他人订单信息”修复建议是“在查询订单前增加当前用户 ID 与订单归属用户 ID 的一致性校验”。这份报告可以直接丢给开发看不用任何翻译。对比一下裸提示词的输出它大概率只会告诉你“注意越权风险”不会把利用路径和修复代码给你写到这一步。更让团队省心的地方是模型把同一个接口里一个低危的日志信息泄漏也标了出来——接口错误处理时直接返回了数据库原始异常信息可能把表结构泄露给攻击者。这种问题在人工 review 里很容易被忽略因为它不影响功能但在安全视角下确实值得修。你能明显感受到技能包的规则给了模型一个“找茬滤镜”它不再只盯着功能代码而是开始用攻击者的眼睛看这整条链路。3.4 从审计报告到真正落地修复拿到报告只是第一步真正麻烦的是推动修复。我在团队里通常按这样一个流程处理。先让模型把全部漏洞按“严重程度 * 可利用性 * 影响范围”排序生成一张优先级表然后把“严重”和“高危”项直接指派给相关模块负责人要求在本迭代内修复中危项进 backlog低危项记录在案。这里有一个很多人容易忽略的动作每次修复完代码要把修复后的文件重新喂给技能包做一次增量复审只针对这次修过的文件。这样既能验证修复质量也能防止模型给出的修复建议本身引入新的问题。我在一次复审中还真遇到过这种事。模型最初建议一个文件上传接口增加文件类型白名单校验开发照做了但复审时模型发现白名单里包含了.html后缀这会导致存储型 XSS 的风险。这个发现再次证明了一个观点AI 审计不是一次性动作它必须和代码变更循环绑定每一次变更都是新审计的起点。4. 常见问题与排查技巧实录4.1 误报太多怎么压下来最大的误报来源是模型把“看起来不对劲”当成“漏洞”。最常见的是把代码风格问题、性能提示、甚至是一些安全加固的建议统统定性成中高危漏洞。我第一次完整跑一个大项目时报告里整整三十条问题真正值得改的不到八条其余全部是噪声。后来我摸索出来的压误报方法是三条线同时用一是在规则里增加“证据链强制要求”所有高危项必须写出触发路径二是设置“双重确认机制”模型在第一遍列出问题后必须逐条验证才能保留在正式报告里三是在输出阶段加一道分类闸门把“确定漏洞”“疑似风险”“改进建议”三档严格分开。确定漏洞才计高危疑似风险单独列列表改进建议不进漏洞总数。你这么坚持跑两三轮模型会越来越“听话”因为它输出的结构化格式被反复强化了它自然会收敛到更保守和精确的判断风格。4.2 严重漏报明明有漏洞AI 就是没发现漏报比误报更可怕。误报浪费的是时间漏报浪费的是信任。我发现漏报的主因通常不是模型能力不足而是输入上下文里缺少关键信息。你只给了一个 controller 文件模型看不到对应的 service 和数据库操作它自然无法建立完整的调用链也就识别不出真正的风险点。解决办法是在输入阶段就提前把所有关键文件聚合进去。我在技能包里加了一个“关联文件聚合”的步骤每次分析一个入口时自动把相关的路由文件、服务文件、数据访问层文件、权限中间件文件一起带上。这样模型看的是完整的数据流而不是孤立的碎片。另外一个很有效的技巧是让模型先“复述”它对这段代码的理解再开始审计。复述的过程会逼迫模型真正读懂代码逻辑而不是只做模式匹配。很多时候模型把代码逻辑复述出来时漏洞自己就浮出水面了。4.3 上下文窗口不够用怎么办代码审计对上下文的需求非常夸张一个真实项目的核心文件动辄几十万 token再大的窗口也装不下。我的应对策略是分层审计。第一次跑只审入口层文件也就是路由和 controller第二次跑审服务层和数据处理层第三次跑专门审权限、加密、文件处理等横切逻辑。每一层只关注本层能发现的问题同时要求模型把可疑的跨层调用记录到一份“待追踪清单”里。最后再单独跑一轮专门针对这份清单做跨层数据流确认。这样等于把一次性的大工程拆成了几个可重复的小任务窗口不够的问题自然就不存在了。还有一个非常实用的技巧是“摘要接力”。第一轮模型会把每个文件的要点浓缩成摘要第二轮带着前一轮的摘要继续分析而不是重新读原始代码。这样虽然牺牲了一部分细节但在超大项目的快速巡检场景里能用更少的成本覆盖更大的范围性价比很高。4.4 想把 AI 审查接进 CI/CD 要注意什么把 security-audit-skill 接到 CI/CD 里要注意几个比模型本身更现实的问题。第一是调用时长。深度的代码审计往往要一到三分钟直接挂在合并请求的阻塞检查里开发会被卡到不耐烦。建议只在主分支合并前或者发布前跑一次全量审计普通的 PR 检查里只跑快速巡检模式并且把审计结果作为“建议意见”而不是“阻塞条件”。第二是结果解析的稳定性。模型即使给了规定的输出格式也偶尔会不遵守导致 JSON 解析失败。我建议自己写一层容错逻辑如果结构化解析失败就 fallback 到普通文本提取如果整个调用超时就跳过这次检查并记录告警而不是把构建直接挡死。第三是敏感信息的保护。你在审查中可能会把包含数据库密码、API 密钥的配置文件也送进模型这里一定要先把真实密钥脱敏掉再进审计流程。这既是对公司资产负责也是避免把机密信息无意识地暴露给外部模型服务。5. 一轮实战下来我对 AI 代码审查的看法变了5.1 它解决不了所有问题但能把团队的审查水位抬上来我现在对 AI 代码审查的态度已经从“用它替代人工”转变成“用它放大人工”。security-audit-skill 这类技能包最明显的效果是让团队在没有专职安全工程师的情况下依然能对每次提交保持一个基础的安全审查水位。过去大量被忽略的低危信息泄漏、越权路径、依赖版本问题现在能在代码合并前被自动捞出来这就已经值回搭建成本了。我自己实际使用中的一个体会是不要一开始就追求“AI 能找到所有漏洞”这个不切实际的目标。你只要把它当成一个帮手让它在 80% 的常规场景里覆盖掉那些最容易被人眼漏掉的问题剩下 20% 的高难度逻辑漏洞仍然留给人工深度 review。这种组合打法在实际落地时最顺团队接受度也最高。5.2 后续打算扩展的方向最近我在琢磨把技能包和依赖漏洞数据库做一层联动。目前的审计主要针对源码本身的逻辑漏洞如果能把npm audit或各种依赖扫描工具的产出也汇总进模型的分析上下文那模型就能把“项目用了有漏洞的库版本”和“这个库的漏洞是否在当前项目里真正被触发”结合起来判断这样可以大幅减少依赖层面的误报。另一个方向是把技能包扩展到基础设施即代码去审查 Terraform、Dockerfile、Kubernetes 配置里的安全问题。在现代应用里很多漏洞并非写在业务代码里而是藏在云基础设施的配置中。这些都是后续值得继续折腾的方向但不管怎么扩展核心思路依然是同一个把安全专家的方法论变成 AI 可以稳定执行的工程标准。