1. 为什么我们需要一个专门的 AI 代码审查技能代码审查这件事做了十几年我最大的感受就是人永远会累但漏洞不会。早些年带团队的时候每次发版前都要拉着两三个资深工程师熬夜看 diff眼睛盯着屏幕一行行扫SQL 注入、硬编码密钥、越权访问这些老问题翻来覆去地出现。后来有了静态扫描工具SonarQube、CodeQL、Semgrep 轮番上阵规则库越堆越厚误报率也跟着水涨船高最后大家看到满屏的告警反而麻木了真正危险的漏洞就藏在那些已知误报里被顺手忽略掉。security-audit-skill这个项目标题本质上要解决的就是这个矛盾——把安全审查从规则匹配升级成语义理解。它不是又一个跑正则的扫描器而是把大语言模型当作一个懂业务、懂上下文、懂攻击链的审查员来用。你给它一段代码、一个 PR、甚至一整个模块它能告诉你这段逻辑在什么场景下会被绕过、哪个参数没做边界校验、哪个鉴权判断写反了顺序。这跟传统 SAST 工具最大的区别在于SAST 告诉你这里用了字符串拼接 SQL而 AI 审查会告诉你这个拼接点上游的userId来自未校验的请求头攻击者可以构造1 OR 11直接拖库。我之所以关注这个方向是因为过去一年在几个真实项目里做过对比测试。同一个 Java 服务CodeQL 扫出 47 条告警人工确认有效漏洞 6 个用 AI 审查技能跑一遍输出 12 条发现其中 9 条是真实可利用的另外 3 条属于设计层面的风险提示。信噪比的差距是数量级的。当然这不意味着 AI 能完全替代工具而是说它补上了工具最缺的那一环——对业务语义和攻击路径的推理能力。这篇文章适合三类人看一是正在搭建 DevSecOps 流水线、想给 CI 加一道智能防线的工程师二是做安全左移、希望把审查前置到编码阶段的团队负责人三是对 AI 应用落地感兴趣、想看看 LLM 在垂直领域怎么调优的开发者。我会把security-audit-skill这类技能的设计思路、核心实现、实操步骤、踩坑经验全部摊开讲代码和配置都能直接抄。2. 整体设计思路把审查员的大脑拆成可复用的技能2.1 为什么是技能而不是工具先厘清一个概念。市面上大部分 AI 代码审查产品是工具形态——你装个插件、配个 API Key、点一下按钮它给你一份报告。而security-audit-skill用的是技能形态这个区别很关键。工具是封闭的你只能用它提供的功能技能是开放的它定义了一套如何审查的方法论可以挂载到不同的模型、不同的 IDE、不同的流水线里。打个比方工具像是一台成品咖啡机技能像是一份手冲咖啡的操作手册——手册可以配合任何豆子、任何滤杯、任何水温使用。我在实际项目里最看重的就是这种可移植性今天用 Claude 跑明天换成 GPT后天接内部私有模型审查逻辑不用重写。从工程角度看一个security-audit-skill通常包含四个部分触发描述description告诉宿主环境什么时候该调用我比如当用户请求审查代码安全性、检查漏洞、做安全审计时激活。审查指令instructions核心的 prompt 工程定义审查的维度、输出格式、判断标准。知识附件referencesOWASP Top 10、CWE 清单、常见漏洞模式库等参考资料。脚本工具scripts可选的辅助脚本比如自动提取 diff、调用静态分析工具做预处理。这种结构的好处是关注点分离。指令负责怎么想知识负责依据什么脚本负责怎么取数据三者可以独立迭代。我见过太多团队把所有逻辑塞进一个巨型 prompt 里改一处崩三处维护成本极高。2.2 审查维度的分层设计一个合格的 AI 安全审查技能不能只盯着有没有 SQL 注入这种单点问题。我在设计自己的审查技能时把维度分成了三层这个分层直接决定了审查的深度和覆盖面。第一层是代码级漏洞也就是传统 SAST 覆盖的范围注入类SQL、命令、模板、LDAP、XSS、反序列化、路径穿越、SSRF、硬编码凭证、弱加密算法。这一层 AI 的优势在于能理解数据流比如追踪一个用户输入从 Controller 到 DAO 的完整链路判断中间有没有经过校验或转义。第二层是逻辑级缺陷这是 AI 真正拉开差距的地方越权访问水平越权和垂直越权、竞态条件、业务规则绕过、状态机漏洞、金额计算精度问题、幂等性缺失。这类问题规则引擎几乎无能为力因为它需要理解这个接口应该只允许订单所有者访问这种业务语义。第三层是架构级风险包括信任边界划分、敏感数据流转、鉴权中间件的覆盖盲区、第三方依赖的供应链风险。这一层需要结合项目结构来判断AI 可以通过读取多个文件建立全局视图。提示分层不是为了输出三份报告而是为了让审查指令有明确的优先级。实际输出时我建议按可利用性 × 影响范围排序而不是按层级排序。一个能直接拖库的逻辑漏洞优先级远高于一个需要复杂前置条件的架构隐患。2.3 模型选型的取舍逻辑跑安全审查模型选择直接决定效果上限。我实测下来几个关键结论模型类型优势劣势适用场景通用大模型旗舰级语义理解强能推理攻击链成本高长上下文易丢细节核心模块深度审查通用大模型轻量级速度快成本低复杂逻辑容易漏判全量 PR 初筛代码专用模型对语法结构敏感安全知识储备可能不足语法级漏洞识别私有部署模型数据不出域能力参差需微调敏感代码库我的实践方案是两级审查轻量模型做全量初筛把可疑片段标记出来旗舰模型对标记片段做深度分析。这样既控制了成本又保证了关键路径的审查质量。实测一个 5000 行的 PR初筛 30 秒出结果深度分析只针对 200 行可疑代码总耗时控制在 2 分钟内比全量跑旗舰模型省了 80% 的 token。2.4 输出格式的强约束AI 审查最容易翻车的地方是输出不稳定。同一个漏洞这次给你一段散文式描述下次给你一个列表再下次直接漏了。解决办法是在指令里用结构化输出约束强制模型按固定 schema 返回。我用的 schema 大致是这样每条发现包含severity严重级别、category漏洞类别、location文件行号、description问题描述、evidence代码证据、exploit_scenario利用场景、remediation修复建议、confidence置信度。其中exploit_scenario和confidence是我特别看重的两个字段——前者逼着模型说清楚怎么被利用避免空泛告警后者让审查者知道哪些需要人工复核。3. 核心细节解析审查指令怎么写才有效3.1 指令的骨架结构写审查指令跟写代码一样结构清晰比辞藻华丽重要得多。我总结的骨架是角色 任务 约束 流程 输出五段式。角色定义要具体别写你是一个安全专家而要写你是一名有十年渗透测试经验的应用安全工程师擅长从攻击者视角分析 Web 应用和 API 的安全缺陷。角色越具体模型的输出风格越贴近真实审查员。任务描述要明确边界比如审查以下代码变更识别可被外部攻击者利用的安全漏洞重点关注鉴权、输入校验、数据流和敏感信息处理。这里的关键是限定可被外部攻击者利用否则模型会把内部代码质量问题也当成漏洞报出来噪音太大。约束条件是最容易被忽略但最重要的部分。我通常会加这几条不报告纯风格问题、不报告无利用路径的理论风险、对每个发现必须给出具体的代码行号和利用步骤、如果无法确定则明确标注置信度为低。流程部分定义审查的步骤顺序比如先识别入口点再追踪数据流然后检查鉴权最后评估影响。这个顺序能引导模型系统性地思考而不是东一榔头西一棒子。输出部分就是前面说的 schema 约束用 JSON 或 Markdown 表格都行关键是字段固定。3.2 上下文注入的技巧AI 审查的质量一半取决于你喂给它多少上下文。只给一个 diff模型看不到调用方和被调用方很多逻辑漏洞就发现不了。我的做法是三层上下文注入第一层是变更本身也就是 diff 或修改后的完整函数。这是必须的。第二层是直接依赖包括被修改函数调用的下游函数、调用它的上游接口、相关的数据模型定义。这一层能帮模型理解数据流。第三层是项目约定比如鉴权中间件怎么用、统一的参数校验工具类、日志脱敏规范。这一层能帮模型判断这段代码是否违反了项目自身的安全约定。实际操作中第三层最难自动化。我的方案是维护一个security-context.md文件把项目的安全约定、常用工具、已知的信任边界写进去每次审查时作为系统提示的一部分注入。这个文件不需要很长一两千字足够但效果立竿见影。3.3 减少误报的四个手段误报是安全审查的头号敌人。我踩过的坑里误报主要来自四个原因对应四个解决手段。原因一模型不理解框架的自动防护。比如 Spring 的RequestParam默认做了类型转换MyBatis 的#{}自动参数化这些框架特性模型不一定知道。解决办法是在上下文里明确说明项目使用的框架和版本以及框架自带的防护机制。原因二模型把测试代码当生产代码。测试文件里经常有硬编码密码、故意构造的恶意输入这些不是漏洞。解决办法是在指令里明确排除测试目录或者在上下文里标注哪些路径是测试代码。原因三模型对可控输入判断过宽。有些参数虽然来自请求但经过了严格的白名单校验模型可能忽略这个校验。解决办法是要求模型在报告漏洞前必须明确说明该输入未经何种校验如果找不到绕过校验的路径就不报。原因四模型对严重级别判断失准。同一个 XSS在管理后台和公开页面危害完全不同。解决办法是在上下文里说明各模块的暴露面让模型据此调整严重级别。注意不要试图追求零误报那会导致大量漏报。我的经验是把误报率控制在 30% 以内就算合格剩下的靠人工快速复核。关键是每条误报都要能快速判断所以evidence字段必须包含足够的代码片段。3.4 知识库的挂载方式security-audit-skill的知识库不是越大越好。我试过把整个 OWASP Testing Guide 塞进去结果模型反而抓不住重点。有效的做法是按需挂载 精简提炼。按需挂载的意思是根据代码类型动态选择知识库。审查 Java Web 代码时挂载 Java 相关的漏洞模式审查前端代码时挂载 XSS、CSRF、原型链污染的知识审查基础设施代码时挂载配置安全的知识。这样每次注入的知识量控制在合理范围不挤占代码本身的上下文空间。精简提炼的意思是把官方文档改写成漏洞模式 检测要点 修复模板的三段式。比如 SQL 注入这条不要抄一大段原理而是写成检测要点查找字符串拼接构造 SQL 的位置追踪拼接变量是否来自用户输入修复模板使用参数化查询Java 用 PreparedStatementMyBatis 用 #{}。这种写法模型用起来效率最高。4. 实操过程从零搭建一个可用的审查技能4.1 环境准备与目录结构先说明这套方案不依赖特定平台任何支持自定义指令和文件读取的 AI 环境都能跑。我以最常见的本地开发场景为例。目录结构建议这样组织security-audit-skill/ ├── SKILL.md # 技能主文件包含触发描述和审查指令 ├── references/ │ ├── owasp-patterns.md # 漏洞模式库 │ ├── project-context.md# 项目安全约定 │ └── remediation.md # 修复模板库 ├── scripts/ │ ├── extract_diff.py # 提取代码变更 │ └── prefilter.py # 轻量预筛 └── templates/ └── report.md # 报告输出模板SKILL.md是入口其他都是被引用的资源。这种结构的好处是每个文件职责单一改漏洞模式库不影响审查指令改指令不影响脚本。4.2 编写 SKILL.md 主文件主文件分两部分frontmatter 和正文。frontmatter 定义元信息正文是审查指令。--- name: security-audit-skill description: 当用户请求代码安全审查、漏洞检查、安全审计、PR 安全评估时激活此技能。适用于 Web 应用、API、微服务的源代码审查。 --- # 安全审查技能 ## 审查目标 从攻击者视角识别代码中可被外部利用的安全漏洞重点关注鉴权缺陷、输入校验缺失、数据流污染、敏感信息泄露。 ## 审查流程 1. 识别所有外部入口点HTTP 接口、消息队列消费者、定时任务触发的外部数据 2. 对每个入口点追踪用户可控数据的完整流向 3. 检查数据在流向敏感操作数据库、文件系统、命令执行、外部请求前是否经过充分校验 4. 检查鉴权与授权逻辑是否覆盖所有敏感操作 5. 评估每个发现的可利用性和影响范围 ## 输出要求 按以下 JSON 格式输出不要添加额外说明 [具体的 schema 定义] ## 约束 - 不报告纯代码风格问题 - 不报告无明确利用路径的理论风险 - 每个发现必须包含具体文件路径和行号 - 无法确定利用性时confidence 标注为 low这个骨架看起来简单但每一条都是反复打磨出来的。比如识别所有外部入口点这一步早期版本我没写结果模型经常漏掉消息队列消费者这种非 HTTP 入口导致一批反序列化漏洞没被发现。4.3 构建漏洞模式库owasp-patterns.md是审查的弹药库。我的写法是每条漏洞一个条目包含四个字段模式描述、检测要点、常见误报、修复模板。以越权访问为例## 越权访问IDOR / 垂直越权 **模式描述**接口直接使用请求参数中的资源 ID 查询数据未校验该资源是否属于当前用户或接口未校验当前用户的角色权限。 **检测要点** - 查找形如 findById(request.getParameter(id)) 的调用 - 检查查询条件是否包含当前用户标识如 userId - 检查接口是否有角色注解或权限判断 - 注意批量接口、导出接口、详情接口是重灾区 **常见误报** - 资源本身是公开的如商品详情 - 上游网关已做统一鉴权需确认网关配置 **修复模板** 查询时强制附加当前用户条件WHERE id ? AND user_id ?这种写法的好处是模型能快速匹配而且常见误报字段直接降低了误报率。我实测下来加上这个字段后越权类误报减少了大概一半。4.4 预筛脚本的实现prefilter.py的作用是把明显安全的代码过滤掉只留下可疑片段送给大模型。这不是必须的但能显著降低成本。import re # 高风险模式命中任一即标记为可疑 HIGH_RISK_PATTERNS [ rexecute\s*\(\s*[\].*\, # 字符串拼接 SQL rRuntime\.getRuntime\(\)\.exec, # 命令执行 rnew\sFile\s*\(\s*.*getParameter, # 路径穿越 rObjectInputStream, # 反序列化 rpassword\s*\s*[\][^\][\], # 硬编码密码 ] # 安全模式命中则降低优先级 SAFE_PATTERNS [ rPreparedStatement, rPreAuthorize, rescapeHtml, ] def prefilter(code_snippet): score 0 for pattern in HIGH_RISK_PATTERNS: if re.search(pattern, code_snippet): score 2 for pattern in SAFE_PATTERNS: if re.search(pattern, code_snippet): score - 1 return score 0这个脚本很粗糙但胜在快。它的定位是宁可错杀不可放过把可疑代码都标出来真正的判断交给大模型。我在一个中型项目上测试预筛把需要深度分析的代码量压缩到了原来的 15%而漏报率为零。4.5 完整审查流程的串联把上面这些串起来一次完整的审查流程是这样的提取变更从 git diff 或 PR 中提取修改的文件和行范围。预筛对变更代码跑prefilter.py标记可疑片段。组装上下文把可疑片段、直接依赖、项目约定拼成一个审查请求。调用模型用SKILL.md的指令 漏洞模式库 组装好的上下文调用模型。解析输出按 schema 解析模型返回的 JSON。人工复核按 confidence 和 severity 排序优先复核高置信度高危项。反馈闭环把误报和漏报记录下来定期更新漏洞模式库和审查指令。这个流程里第 7 步最容易被忽略但恰恰是最重要的。我维护的漏洞模式库每一条都是从真实误报和漏报里提炼出来的。没有反馈闭环审查技能永远停留在初始水平。5. 常见问题与排查技巧实录5.1 模型漏报严重怎么办漏报是最让人头疼的问题因为漏掉的漏洞可能直接导致线上事故。我遇到过的漏报原因和对应解法原因一上下文不足。模型看不到调用链无法判断数据是否可控。解法是扩大上下文注入范围至少包含直接调用方和被调用方。原因二指令过于宽松。比如只写检查安全问题模型可能只关注最明显的几类。解法是把审查维度显式列出逐项要求检查。原因三模型对特定框架不熟悉。比如某些国产框架的鉴权注解模型不认识。解法是在项目约定里明确说明框架的鉴权机制。原因四代码过长超出有效上下文。解法是分块审查每块控制在 500 行以内块之间通过摘要传递关键信息。我做过一个对比实验同一个有 8 个已知漏洞的模块初始版本审查技能只发现了 3 个加上调用链上下文后发现了 5 个再加上显式维度清单后发现了 7 个最后加上框架约定后 8 个全中。上下文和指令的完善程度直接决定漏报率。5.2 误报太多怎么收敛误报多的直接后果是团队不再信任审查结果最后整个技能被弃用。收敛误报的手段前面提过一些这里补充几个实战技巧。技巧一要求模型自证。在指令里加一条对每个发现必须说明攻击者如何构造输入、经过哪些代码路径、最终达成什么效果无法完整说明的不报。这一条能过滤掉大量看起来像但实际不可利用的告警。技巧二分级输出。把发现分成确认漏洞和待确认风险两类前者是模型有把握的后者是需要人工判断的。这样团队可以先处理确认漏洞待确认风险有空再看不会因为噪音太多而放弃。技巧三建立项目白名单。对于项目里已知的安全设计比如某个接口故意公开、某个参数故意不校验在项目约定里明确标注让模型跳过。技巧四定期复盘误报。每周花半小时看看误报都是什么类型如果是模式化的就更新指令或模式库。我坚持做了三个月误报率从 60% 降到了 25% 左右。5.3 审查速度太慢怎么优化全量深度审查一个大型 PR旗舰模型可能要跑十几分钟这在 CI 里是不可接受的。优化思路有三个方向。方向一分层审查。前面说的轻量模型初筛 旗舰模型深审是最有效的优化。初筛阶段用规则和轻量模型把 90% 的代码排除掉深审只处理剩下的 10%。方向二增量审查。只审查变更部分及其直接影响范围不审查整个文件。这需要准确识别变更的影响半径我的做法是通过静态分析找出变更函数的调用方和被调用方只把这些纳入审查范围。方向三缓存复用。对于没有变更的代码复用上次的审查结果。这需要维护一个审查结果缓存key 是代码的哈希值。实测在迭代开发场景下缓存命中率能达到 70% 以上。综合用这三个方向我把一个 5000 行 PR 的审查时间从 15 分钟压到了 90 秒以内基本满足 CI 的时效要求。5.4 常见问题速查表问题现象可能原因排查方向解决手段漏报明显漏洞上下文不足检查是否注入了调用链扩大上下文范围误报大量堆积指令过宽检查是否有自证要求加自证约束分级输出输出格式不稳定schema 约束弱检查输出模板强化 JSON schema审查速度慢全量深审检查是否分层加初筛和缓存特定框架漏洞漏检框架知识缺失检查项目约定补充框架说明严重级别判断失准暴露面信息缺失检查是否说明模块暴露面补充暴露面上下文5.5 几个血泪教训最后分享几个我踩过的坑都是真金白银换来的。教训一不要相信模型的确认。早期我完全信任模型输出的 confidence 字段结果发现模型对某些漏洞会过度自信。后来我改成无论 confidence 多高高危漏洞必须人工复核。这个改动救过一次线上事故——模型报了一个高置信度的 SQL 注入人工复核发现是误报但复核过程中发现了旁边一个模型漏掉的真实越权漏洞。教训二审查技能需要版本管理。我一开始直接在环境里改指令改着改着就忘了哪版效果好。后来把整个技能目录纳入 git 管理每次改动都提交配合审查结果的准确率数据才能知道哪次改动是正向的。教训三不要追求覆盖所有漏洞类型。我试过把 CWE 全清单塞进模式库结果模型注意力被分散反而连最常见的注入类漏洞都漏了。后来砍到只保留项目最相关的 20 类准确率反而上去了。聚焦比全面更重要。教训四人工复核的反馈必须结构化。一开始我让复核的人随便写评论结果这些反馈没法用来改进技能。后来改成固定格式漏洞类型、是否真实、误报原因、漏报原因。这样积累几个月就能看出技能的系统性短板在哪里。这套security-audit-skill我从最初的一个 prompt 迭代到现在大概改了三十多个版本中间推翻重来过两次。现在它在我的项目里承担了大概 70% 的初筛工作人工只需要复核高优先级发现整体安全审查效率提升了三倍以上。但它从来不是全自动的人工复核和反馈闭环才是让它持续变好的关键。如果你也在搭类似的技能我的建议是从一个小模块开始跑通流程、积累反馈再逐步扩大范围别一上来就想覆盖整个代码库。