1. 为什么研发一听到“代码审查”就头疼1.1 传统代码审查的真实困境做过几年开发的人都有体会代码审查这件事理论上很美好实践起来很折磨。一个中等规模的团队每天产生的合并请求少则十几个多则几十个。每个合并请求都要人去看去理解上下文去判断逻辑有没有漏洞、边界条件有没有覆盖、命名是不是规范、有没有硬编码的密钥。一个人一天能认真看完三四个合并请求已经算高效了再多就是走马观花。问题在于审查者本身也有自己的开发任务。你让一个正在赶迭代进度的工程师抽出两小时去逐行看别人的代码他心里是抗拒的。结果就是两种极端要么草草点个“同意”放行要么在一些无关痛痒的格式问题上反复拉扯真正有风险的逻辑缺陷反而被忽略。安全扫描的情况更尴尬。传统静态应用安全测试工具跑一遍动辄几百上千条告警其中大量是误报。研发看到那一屏红红黄黄的列表第一反应不是去修而是想办法绕过。久而久之安全扫描就成了流水线里一个“必须存在但没人认真看”的环节。1.2 AI 介入后到底改变了什么把 AI 引入 CI/CD 流水线核心要解决的不是“能不能扫出问题”而是“能不能让研发愿意看、看得懂、改得动”。这两件事的差别很大。传统工具的输出是规则匹配的结果它告诉你“第 47 行存在 SQL 拼接疑似注入风险”但它不理解这段代码的业务意图也不知道这个参数是否真的来自用户输入。大模型驱动的审查则不同。它能把代码上下文、调用链路、甚至提交信息一起读进去然后给出一个带解释的判断“这个接口的入参经过了白名单校验但校验逻辑在异常分支下会被跳过建议在 catch 块里补一道兜底。”这种反馈研发是愿意看的因为它像是一个懂业务的同事在跟你讨论而不是一台机器在念规则。注意AI 审查不是替代人工审查而是把人工从“找明显问题”中解放出来让人专注于架构合理性、业务逻辑正确性这些 AI 目前还搞不定的部分。1.3 适合什么团队、什么阶段引入不是所有团队都适合一上来就搞 AI 驱动的流水线。我的经验是团队至少满足以下两三个条件引入效果才明显合并请求频率较高人工审查已经成为瓶颈已经有一套能跑通的 CI/CD 基础流程不是从零搭建团队对误报有一定容忍度愿意花时间调优提示词和规则有至少一个人愿意负责维护这套 AI 审查环节而不是装完就不管如果团队只有三五个人、一周合并不了几次代码那老老实实人工看就行引入 AI 反而增加维护成本。2. 整体方案设计AI 在流水线里该站在哪个位置2.1 三种常见的集成位置对比AI 介入 CI/CD 不是只有一种做法不同的插入点效果和维护成本差别很大。我整理了一个对比表方便你根据自己团队的情况选集成位置触发时机优点缺点适合场景提交前本地钩子开发者本地 commit 时反馈最快不占用流水线资源依赖个人环境容易被跳过小团队、个人项目合并请求阶段发起 MR/PR 时反馈及时与审查流程结合紧密需要与代码托管平台深度集成大多数团队的首选流水线构建后CI 构建完成后可结合构建产物、测试结果综合判断反馈链路长研发感知弱对安全要求高的场景我个人的建议是优先做合并请求阶段。原因很简单这个时间点研发的注意力还在这次改动上你给他反馈他马上就能改。等到构建完成后才告诉他有问题他可能已经切到别的任务去了回头再捡起来成本很高。2.2 为什么选择“审查扫描”双轨并行代码审查和安全扫描虽然都叫“检查代码”但它们的关注点完全不同。审查关注的是可维护性、逻辑正确性、命名规范、设计模式扫描关注的是注入、越权、敏感信息泄露、依赖漏洞这些安全层面的问题。如果只用一个大模型提示词把两件事混在一起做效果往往不好。因为安全问题的判断需要更严格的规则约束而代码风格问题需要更灵活的语境理解。混在一起模型容易顾此失彼。我的做法是拆成两条独立的分析链路各自有独立的提示词模板和输出格式最后在评论区分开发布。这样研发看的时候也清晰哪些是“建议优化”哪些是“必须修复的安全问题”。2.3 数据流向与隐私边界这一点必须单独拿出来说。把代码送到大模型做分析意味着代码离开了你的内网环境。对于大多数公司的业务代码这是需要谨慎对待的。常见的处理方式有三种使用私有化部署的模型把模型部署在自己的服务器上代码不出内网。缺点是模型能力通常比云端旗舰模型弱一些需要更多调优。使用云端 API 但做脱敏在送分析之前把密钥、内部域名、真实用户数据替换成占位符。缺点是脱敏逻辑本身要维护且可能影响分析准确性。混合方案敏感项目走私有化模型普通项目走云端 API。提示无论选哪种方案都要在团队内明确告知开发者“你的代码会被送到哪里分析”这是基本的尊重也能避免后续的合规纠纷。3. 核心细节拆解提示词、上下文与输出格式3.1 提示词工程是这套方案的心脏很多人以为接个大模型 API 就完事了实际上提示词的质量直接决定了这套系统是“有用”还是“噪音制造机”。我踩过的坑是一开始提示词写得太宽泛比如“请审查这段代码”结果模型返回一堆“建议添加注释”“变量命名可以更清晰”这种废话。后来我把提示词拆成了几个固定模块角色设定你是一名有十年经验的[语言]工程师专注于代码可维护性与安全性审查。 审查范围 1. 逻辑缺陷边界条件、空值处理、异常分支 2. 安全隐患注入风险、敏感信息硬编码、权限校验缺失 3. 可维护性重复代码、过长函数、魔法数字 输出要求 - 每条问题必须指明具体行号和代码片段 - 必须解释为什么这是问题而不是只给结论 - 按严重程度分级阻断、警告、建议 - 如果某类问题没有发现明确说“未发现”不要编造 禁止事项 - 不要评论代码格式和缩进 - 不要建议添加注释除非逻辑确实晦涩 - 不要对业务逻辑的正确性下绝对结论这套提示词跑下来输出的质量比最初版本高了不止一个档次。关键就在于“禁止事项”那一块它把模型最容易产生的废话提前堵住了。3.2 上下文怎么给才有效只给模型一个 diff 是不够的。很多问题需要看完整文件、甚至看调用方才能判断。比如一个函数把用户输入直接拼进 SQL如果只看这个函数你会报注入风险但如果你看到调用方已经做了参数化处理这个告警就是误报。我的做法是给模型三层上下文第一层本次改动的 diff这是核心第二层改动涉及的完整文件内容让模型理解函数全貌第三层如果改动涉及接口签名变化把调用方的相关代码也带上当然上下文不是越多越好。模型的上下文窗口有限塞太多反而会稀释重点。我的经验是控制在改动代码量的 5 到 10 倍左右比较合适。3.3 输出格式必须结构化如果让模型自由发挥它可能给你写一篇小作文。研发在合并请求页面看到一大段文字大概率直接跳过。所以输出必须是结构化的我通常要求模型返回 JSON然后由流水线脚本渲染成评论。一个典型的输出结构长这样{ summary: 本次改动共发现 3 个问题其中 1 个阻断级, issues: [ { severity: blocker, file: src/service/user.js, line: 47, code: const sql SELECT * FROM users WHERE id ${userId}, reason: userId 来自请求参数直接拼接存在注入风险, suggestion: 改用参数化查询db.query(SELECT * FROM users WHERE id ?, [userId]) } ] }这样渲染出来的评论每条问题都有定位、有原因、有改法研发看起来一目了然。4. 实操落地从零搭一条带 AI 审查的流水线4.1 环境准备与依赖安装假设你用的是主流的代码托管平台加自建流水线整体需要准备这些东西一个能调用大模型的 API 凭证云端或私有化都行流水线里能跑脚本的运行环境Python 或 Node 都可以代码托管平台的 API 权限用于读取 diff 和发布评论一个存放提示词模板和配置的仓库或配置中心我习惯用 Python 写这层胶水逻辑因为处理文本和调 API 都方便。核心依赖就几个pip install requests pyyaml不需要什么重型框架越轻量越好维护。4.2 获取 diff 与上下文组装第一步是从代码托管平台拉取本次合并请求的 diff。大多数平台都提供了对应的 API返回的是标准的 diff 格式。拿到 diff 之后需要做几件事解析出哪些文件被改动、每个文件改了哪些行对每个改动文件拉取完整内容作为上下文如果改动涉及函数签名尝试找到调用方这里有个细节diff 里可能包含二进制文件、锁文件、自动生成的代码这些要提前过滤掉不然既浪费 token 又干扰分析。def should_skip_file(path): skip_patterns [ r\.lock$, rpackage-lock\.json$, r\.min\.js$, rdist/, rnode_modules/ ] return any(re.search(p, path) for p in skip_patterns)4.3 调用模型与结果解析组装好提示词和上下文之后就是调用模型。这里要注意几个实操要点超时设置模型响应可能比较慢超时要给足建议 60 秒以上重试机制网络抖动很常见至少重试两次结果校验模型返回的 JSON 不一定合法要有兜底解析逻辑def call_model(prompt, context, retries2): for i in range(retries 1): try: resp requests.post( API_ENDPOINT, json{prompt: prompt, context: context}, timeout90 ) return parse_response(resp.json()) except Exception as e: if i retries: raise time.sleep(2 ** i)解析结果的时候一定要做 schema 校验。我遇到过模型返回的 JSON 里 severity 字段写成了中文“阻断”导致后续渲染脚本报错。所以解析层要足够健壮遇到不符合预期的字段就降级处理而不是直接崩掉。4.4 发布评论与阻断策略分析结果出来后有两种处理方式一种是只发评论提醒不阻断合并另一种是发现阻断级问题就直接让流水线失败禁止合并。我的建议是分阶段来。刚上线的时候只发评论让团队先适应这套东西观察误报率。等误报率降到可接受范围比如 20% 以下再对阻断级问题开启强制拦截。评论的发布也有讲究。不要把几十条问题一股脑全发出来那样评论区会很乱。我的做法是阻断级问题逐条发每条一个评论必须让研发看到警告级问题合并成一条评论列出所有警告建议级问题只在总结里提一句数量不展开这样既保证了重要问题不被淹没又不会让评论区变成刷屏现场。5. 常见问题与排查技巧实录5.1 误报太多怎么办这是上线初期最常见的问题。模型把一些正常的代码模式误判成风险研发被骚扰几次之后就开始无视所有告警。解决思路有几个在提示词里加入项目特定的白名单比如告诉模型“本项目使用 ORM 框架所有数据库操作都经过框架的参数化处理不要报注入风险”对历史告警做人工标注把误报的案例整理出来作为反例写进提示词调整严重程度阈值把不确定的问题降级为“建议”不要动不动就报阻断我实测下来经过两三轮提示词迭代误报率能从最初的 50% 以上降到 15% 左右。5.2 模型漏报关键问题怎么排查漏报比误报更危险因为它会让团队产生虚假的安全感。排查漏报通常从这几个方向入手排查方向具体做法上下文是否完整检查送分析的代码是否缺少调用方信息提示词是否覆盖确认该类问题是否在审查范围内明确列出模型能力边界有些问题需要跨文件推理模型可能力不从心输出解析是否丢数据检查解析层是否把某些问题过滤掉了我遇到过一次典型的漏报一个权限校验缺失的问题没被扫出来原因是校验逻辑在另一个文件里而我只送了改动文件的上下文。后来把调用链上的相关文件也带上问题就暴露了。5.3 流水线变慢的优化思路引入 AI 分析后流水线时间变长是必然的。如果原来 3 分钟能跑完现在变成 8 分钟研发的体验就会下降。优化方向并行分析把代码审查和安全扫描拆成两个并行任务而不是串行增量分析只分析本次改动的文件不要每次全量扫缓存机制同一个文件如果没改动直接复用上次的分析结果异步发布分析完成后先让流水线通过评论异步发布不阻塞合并最后一条要慎用因为如果评论发出来的时候研发已经合并了那这条评论就失去意义了。适合那些对时效性要求不高的建议级问题。5.4 团队抵触情绪怎么化解技术问题好解决人的问题难。研发对 AI 审查的抵触通常来自几个方面觉得被监视、觉得误报烦人、觉得增加了工作量。我的经验是上线初期一定要做一件事让研发参与提示词的调优。把提示词模板开放给团队谁觉得哪条规则不合理可以提出来改。这样他们从“被审查者”变成了“规则制定者”抵触情绪会小很多。另外定期公布数据也很有用。比如“本月 AI 审查共发现 23 个真实问题其中 5 个是阻断级”用实际价值说话比任何说服都管用。6. 这套方案的实际效果与边界6.1 哪些问题 AI 确实擅长跑了大半年下来我发现 AI 在几类问题上表现相当稳定敏感信息硬编码API key、密码、token 直接写在代码里基本一抓一个准明显的注入风险字符串拼接 SQL、命令拼接识别率很高空值和边界处理数组越界、空指针、除零这类模式化问题模型很敏感依赖版本漏洞结合依赖清单分析能发现已知漏洞的版本这些问题有个共同特点模式相对固定判断标准明确不太依赖业务语境。6.2 哪些问题 AI 目前还搞不定同样也有几类问题 AI 目前力不从心业务逻辑正确性比如“这个折扣计算在特定用户等级下会算错”模型没有业务背景判断不了架构层面的问题模块划分是否合理、抽象层次是否恰当这些需要全局视角性能问题虽然模型能看出一些明显的低效写法但真正的性能瓶颈往往需要压测才能发现并发安全竞态条件、死锁这类问题模型的分析能力有限所以我的定位一直很明确AI 负责把明显的问题筛出来人负责判断那些需要业务理解和架构视角的问题。两者是互补不是替代。6.3 后续可以扩展的方向这套东西跑顺之后还有几个方向可以继续挖结合历史数据做趋势分析统计哪类问题反复出现针对性做团队培训自动修复建议对于模式化的问题让模型直接生成修复后的代码研发一键采纳与测试环节联动AI 审查发现的问题自动生成对应的测试用例多模型交叉验证用两个不同的模型分别分析取交集作为高置信度问题我个人最看好的是自动修复这个方向。现在模型给出的修复建议已经相当靠谱了如果能把“建议”变成“可直接应用的补丁”研发的采纳率会大幅提升。最后分享一个我在实操中总结的小技巧提示词里加上一句“如果你不确定就说你不确定不要强行给结论”能显著降低误报。模型有时候会为了显得“有用”而编造问题这句话能有效抑制这种倾向。