1. 为什么我想把PR和Code Review交给AI来试一把团队里做后端的老周上个月跟我吐槽说他一天里最割裂的时间段就是下午三点到六点——自己手头的功能写了一半思路正热结果被拉去Review三个PR看完之后回到自己的分支脑子里那点上下文全凉了。这个场景我相信做开发的人都不陌生。PRPull Request和Code Review这两件事本质上是在团队协作里做质量兜底但它们对开发者个人而言是典型的高价值、高打断任务。也正因为如此我最近花了大概两周时间认真试了一遍用AI工具来辅助创建PR描述、做初步的Code Review甚至让它帮忙梳理diff里的逻辑风险。先说清楚这篇东西适合谁看。如果你是一个人写代码、偶尔提PR、团队规模在3到15人之间或者你正在评估要不要把AI引入到研发流程里那这篇内容应该能给你省不少试错时间。我不会吹AI能替代Reviewer也不会说它一无是处我只讲我实际跑下来的流程、踩过的坑以及哪些环节它确实能帮上忙、哪些环节它反而会添乱。核心关键词就三个AI工具、PR、Code Review全文围绕这三个词展开不跑题。我用的工具组合比较杂网页版的对话式AI比如Kimi、DeepSeek这类网页版登录就能用的、IDE里集成的代码助手、以及一个开源的PR分析脚本。为什么不用单一工具因为PR创建和Code Review其实是两个不同的任务前者偏表达和归纳后者偏逻辑推理和风险识别一个模型很难同时把两件事都做到位。这个判断是我试了三四轮之后才定下来的后面会详细讲。2. 整体设计思路AI在PR流程里到底该站哪个位置2.1 先想清楚PR和Code Review的本质区别很多人把这两件事混在一起谈其实它们的输入输出完全不同。创建PR的输入是一堆commit和diff输出是一段人类能快速读懂的文字描述——改了什么、为什么改、怎么验证。这是一个翻译任务把代码语言翻译成自然语言。而Code Review的输入是diff加上上下文代码输出是风险点、疑问、改进建议——这是一个审查任务需要理解意图、发现偏差、判断边界条件。这个区别决定了AI的用法。翻译任务对模型的表达流畅度要求高对深度推理要求相对低审查任务反过来需要模型能顺着代码逻辑走甚至要能识别出这段代码在并发场景下会出问题这种非表面信息。我一开始图省事用同一个对话窗口既让它写PR描述又让它Review结果发现它写描述写得挺漂亮但Review的时候经常漏掉关键逻辑因为它被前面的总结模式带偏了倾向于说好话。所以我的整体设计是分阶段、分工具、分提示词。创建PR阶段用对话式AI给它结构化的diff和commit信息让它输出规范描述Code Review阶段用IDE集成的代码助手加上自定义的审查清单让它逐条对照检查。两个阶段之间不共享上下文避免互相污染。2.2 为什么不让AI直接提交PR这里有个边界必须划清楚AI可以帮你写PR描述但不应该帮你点提交按钮。我见过有人写脚本让AI自动生成描述并直接创建PR结果描述里把修复了一个空指针写成了优化了异常处理逻辑Reviewer看了半天没找到重点。PR描述是给人看的人得对它的准确性负责。我的做法是AI生成草稿我改一遍再提交。多花两分钟但省掉了Reviewer来回问的时间。另一个原因是权限和安全。自动提交意味着AI工具需要仓库的写权限这个风险不用我多说。我的原则是AI只读diff和commit不碰仓库写操作。所有提交动作由人完成这样即使AI输出有问题也不会直接污染主干。2.3 工具选型的三个考量维度我评估工具时主要看三点。第一是上下文窗口PR的diff有时候几千行模型得能吞得下不然它只能看到片段Review就会漏。第二是代码理解能力这个只能实测同一个diff丢给不同模型看谁找出的问题更准。第三是是否支持自定义提示词因为每个团队的Review标准不一样有的看重命名规范有的看重测试覆盖通用提示词很难覆盖。实测下来网页版对话式AI在写PR描述这个任务上表现最稳因为它的语言组织能力强而且你可以把团队的PR模板直接贴给它当格式参考。IDE集成的代码助手在逐行Review上更方便因为它能直接读到项目里的其他文件理解上下文。开源脚本适合做批量初筛比如一次性扫十个PR把明显有问题的挑出来但它的判断精度不如前两者。3. 核心细节拆解PR描述到底该怎么让AI写3.1 给AI的输入不是diff而是结构化信息包我一开始直接把git diff的输出丢给AI结果它写出来的描述又长又碎把每一行改动都复述了一遍完全没有重点。后来我改成给它一个结构化的信息包包含四样东西commit message列表、变更文件清单、关键diff片段、以及这次改动的业务背景。业务背景这一项最关键因为diff本身不告诉你为什么要改而PR描述里为什么比改了什么更重要。举个例子我有个PR是给订单查询接口加缓存。如果只给diffAI会写在OrderService里增加了cache.get和cache.put调用。但我把背景告诉它——这个接口QPS高数据库压力大加缓存是为了降低DB负载——它就能写出为降低订单查询接口的数据库压力引入本地缓存缓存key为订单IDTTL 5分钟这种有信息量的描述。差别很大。3.2 提示词模板我用了两周没换过的那一版下面这个模板是我调了七八版之后固定下来的直接可以抄你是一个资深后端工程师需要为一次代码变更撰写PR描述。 请严格按以下结构输出不要添加额外章节 ## 变更目的 一句话说明这次改动解决什么问题不超过50字 ## 变更内容 分点列出主要改动每点不超过30字最多5点 ## 影响范围 列出受影响的模块、接口、配置 ## 验证方式 说明如何验证这次改动包括测试用例、手动验证步骤 ## 风险与回滚 说明可能的风险点和回滚方案 以下是变更信息 commit列表{commits} 变更文件{files} 关键diff{diff} 业务背景{background}这个模板的关键在于限制输出结构。不加限制的话AI会自由发挥写出一大段散文Reviewer还得自己提炼。加了结构之后它输出的东西直接可以贴进PR我只需要微调措辞。3.3 一个真实PR的生成效果对比我拿一个真实的PR做了对比。原始手写描述是这样的修改了用户登录逻辑增加了验证码校验修复了之前可以绕过验证码的问题。信息量其实还行但缺了影响范围和验证方式。AI按模板生成的版本是变更目的——修复登录流程中验证码可被绕过的安全问题变更内容——在LoginController中增加验证码前置校验、调整AuthService的校验顺序、补充验证码失效逻辑影响范围——登录接口/api/login、AuthService、验证码缓存验证方式——单元测试LoginControllerTest新增3个用例、手动验证绕过场景已拦截风险与回滚——风险是验证码服务不可用时登录会失败回滚方案是回退本次commit。对比下来AI版本在影响范围和验证方式上明显更完整这两项恰恰是手写时最容易漏的。但我也发现它有时候会编验证方式比如我实际没写单元测试它却写了新增3个用例。所以验证方式这一项必须人工核对不能直接信。3.4 注意事项这三类信息千万别喂给AI第一类是敏感配置比如数据库连接串、密钥、内部域名。diff里如果包含这些喂之前先脱敏。第二类是未公开的业务逻辑有些改动涉及商业策略写进PR描述本身没问题但发给外部AI服务就要谨慎。第三类是大段无关diff比如格式化改动、依赖版本升级这些会让AI的注意力分散最好单独拆出来。提示我习惯在喂给AI之前先跑一遍git diff --stat看看变更规模。如果超过2000行就拆成多个PR分别处理不要指望AI一次吞下超大diff还能给出准确Review。4. 用AI做Code Review能查什么查不了什么4.1 我让AI重点查的四类问题Code Review的范围很广但AI不是万能的。我实测下来它在四类问题上表现比较好。第一是命名和风格一致性比如变量名是否符合项目规范、方法名是否动词开头这类问题规则明确AI判断很准。第二是明显的边界条件遗漏比如数组访问没判空、循环边界写错AI能顺着代码逻辑发现。第三是重复代码它能识别出这段逻辑在另一个文件里已经存在。第四是注释与代码不一致比如注释说返回null但代码返回空列表。这四类的共同点是判断标准相对客观不依赖深层业务知识。反过来涉及业务语义的问题比如这个折扣计算逻辑是否符合最新的营销规则AI就无能为力因为它不知道规则。4.2 审查清单把团队规范变成AI能执行的指令通用提示词效果一般我改成给AI一份审查清单让它逐条对照。清单大概长这样请按以下清单审查这段diff每条给出通过/不通过/存疑三种结论 1. 所有新增的public方法是否有对应的单元测试 2. 所有外部输入是否做了非空和边界校验 3. 是否有硬编码的魔法数字或字符串 4. 异常处理是否吞掉了异常而没有日志 5. 数据库操作是否在事务内事务边界是否合理 6. 是否有N1查询风险 7. 日志是否包含敏感信息 8. 新增的配置项是否有默认值这份清单是我们团队Review时的实际检查项我把它翻译成AI能理解的指令。实测下来第2、3、4、7条AI查得最准第1、5、6条需要它读项目其他文件才能判断准确率会下降。第8条它经常漏因为配置项可能在另一个文件里定义。4.3 一个被AI抓到的真实问题有个PR是给批量导出功能加分页。开发者写了个循环每次查100条直到查完。AI在Review时指出循环终止条件依赖每次查询返回的数量如果某次查询返回恰好100条但实际已到末尾会多查一次空结果。这个问题人眼扫过去很容易忽略因为逻辑看起来是对的。虽然多查一次空结果不算严重bug但AI能指出这一点说明它确实在顺着逻辑走。另一个例子是AI发现某段代码里SimpleDateFormat被定义成了静态变量。它指出这个类不是线程安全的静态共享会导致并发问题。这个属于经典坑但新人确实容易犯AI能主动提出来省了Reviewer的口舌。4.4 AI Review的盲区这三类问题它基本查不出来第一类是架构层面的问题比如这个功能应该放在Service层而不是Controller层AI缺乏对项目分层规范的理解它只看局部代码。第二类是业务逻辑错误比如这个优惠券叠加规则算错了AI不知道业务规则算不出来。第三类是性能问题比如这个查询在数据量到百万级时会慢AI没有数据量概念除非你明确告诉它。所以我的定位很明确AI做第一轮初筛人做第二轮深审。AI把明显的、规则性的问题挑出来人专注于业务逻辑和架构判断。这样Reviewer的时间花在刀刃上而不是浪费在找命名不规范这种小事上。5. 完整实操流程从提交代码到AI辅助Review5.1 第一步整理commit让AI有干净的输入我习惯在提PR之前先git rebase -i把commit整理一下把fix typowip这类无意义commit合并掉。为什么这一步重要因为AI读commit message来理解改动意图如果commit message是update它就完全不知道你在干嘛。整理后的commit应该是每个都对应一个完整的逻辑改动message写清楚做了什么。整理完之后我跑一条命令把需要的信息导出git log --oneline main..HEAD commits.txt git diff --stat main..HEAD files.txt git diff main..HEAD full.diff这三个文件就是喂给AI的基础材料。full.diff如果太大我会用git diff main..HEAD -- src/只取核心目录的diff把测试文件和配置文件的diff单独处理。5.2 第二步生成PR描述并人工校对把三个文件和业务背景一起按3.2节的模板发给AI。拿到输出后我重点校对三处变更目的是否准确有没有夸大或缩小、影响范围是否完整有没有漏掉受影响的模块、验证方式是否真实有没有编造不存在的测试。校对完直接贴进PR创建页面。这一步我实测大概花3到5分钟比纯手写快而且质量更稳定。手写的时候状态好就写得好状态差就写得潦草AI至少能保证结构完整。5.3 第三步AI初筛ReviewPR创建后我把diff按4.2节的清单发给AI做初筛。这里有个技巧不要一次性把整个diff发给它而是按文件分批。因为一个PR可能改了十几个文件一次性发过去AI的注意力会分散后面的文件它可能草草扫过。我一般按文件重要性排序核心逻辑文件单独发测试和配置文件合并发。每批的输出我整理成一个表格记录AI提出的问题和我的判断文件AI提出的问题我的判断处理方式OrderService.java缓存key未包含租户ID可能串数据确认是问题已修复LoginController.java验证码校验未处理服务超时确认是问题已加降级UserMapper.xml新增查询未加索引提示存疑查了执行计划现有索引够用config.yml新增配置项无默认值确认是问题已补默认值这个表格后来成了我们团队Review的记录模板AI提的问题即使不采纳也记录下来方便回溯。5.4 第四步人工深审AI不参与AI初筛完之后Reviewer做深审。这一步AI不参与因为需要业务判断。但我有个习惯把AI的初筛结果附在PR评论里让Reviewer知道哪些是AI已经查过的他可以直接跳过专注在业务逻辑上。这样Reviewer的心理负担会小很多不会觉得我是不是漏看了什么。5.5 参数与成本核算这套流程到底省了多少时间我拿最近十个PR做了统计。纯人工流程下写PR描述平均8分钟Review平均25分钟合计33分钟。引入AI后写描述平均4分钟含校对AI初筛平均3分钟人工深审平均15分钟合计22分钟。单个PR省了大约11分钟降幅33%。但要注意这个统计里人工深审的时间下降最明显因为AI把规则性问题提前挑走了。写描述的时间下降有限因为校对还是要花时间。如果团队PR量大比如一天十个那省下来的时间就很可观了。6. 常见问题与排查技巧实录6.1 AI生成的PR描述假大空怎么办这是最常见的问题。AI倾向于写优化了性能提升了可维护性这种空话。解决办法是在提示词里明确禁止抽象词汇要求它只写具体改动。我加了一条指令禁止使用优化提升改进等抽象动词必须写出具体改了什么。加了之后输出质量明显提升。另一个办法是给它反例。我会在提示词里写不要写优化了查询性能要写为order_id字段增加了索引查询耗时从200ms降到20ms。给了具体范例它就知道你要什么粒度。6.2 AI Review误报太多怎么降噪误报主要来自两类。一类是它不理解项目约定比如项目里统一用log.info打日志它却建议用log.debug。另一类是它过度谨慎把正常代码标成风险。降噪的办法是在提示词里补充项目约定比如本项目日志统一使用info级别记录关键路径不要建议修改日志级别。约定写得越细误报越少。还有一个技巧是让它给出置信度。我在提示词里加了一句对每个问题标注置信度高/中/低。低置信度的问题单独列出。这样我可以优先看高置信度的低置信度的快速扫过不用每条都细究。6.3 diff太大导致AI看不过来前面提过超过2000行的diff要拆分。但有时候一个PR就是很大拆不开。这时候我的做法是分层Review先让AI只看接口层Controller、API定义确认接口契约没问题再看核心逻辑层Service确认业务逻辑最后看数据层DAO、SQL确认查询和事务。每层单独发每层给不同的审查清单。这样虽然多花几轮但准确率比一次性发高很多。6.4 AI把测试代码当业务代码Review这个坑我踩过。AI看到测试文件里的assertNotNull会建议增加空值处理其实那是测试断言不需要处理。解决办法是在提示词里明确区分以下diff包含业务代码和测试代码请分别处理。业务代码按审查清单检查测试代码只检查覆盖场景是否完整不要对测试代码提健壮性建议。6.5 常见问题速查表问题现象可能原因解决方式PR描述全是空话提示词未限制抽象词汇加禁止抽象动词指令给具体范例Review误报多未告知项目约定提示词补充项目规范漏掉关键问题diff太大注意力分散按文件或按层拆分Review把测试代码当业务代码未区分文件类型提示词明确区分业务/测试代码编造验证方式模型倾向于补全信息人工核对验证方式不直接信缓存/并发问题查不出缺乏运行时上下文人工重点审查这类场景6.6 一个我踩过的坑AI建议重构导致PR膨胀有次AI在Review时建议我把一个300行的方法拆成五个小方法说这样可读性更好。我一时手快采纳了结果PR从原本的50行改动膨胀到400行Reviewer看了直摇头说你这个PR到底在干嘛。后来我定了个规矩AI的重构建议一律不在当前PR里做记到技术债清单里单独开PR。PR的原则是单一职责一个PR只做一件事AI的建议再合理也不能让它把PR搞膨胀。7. 我实际用下来的一些体会这套流程我跑了两周多最大的感受是AI在PR流程里的价值不在于替代而在于前置。它把那些规则性的、重复性的检查提前做了让人可以把精力放在真正需要判断力的地方。但它也有明确的边界业务逻辑、架构决策、性能评估这些它目前还接不住。另外有个细节值得说AI生成的PR描述和Review意见语气要调。默认输出往往太正式像机器人写的。我会在提示词里加一句用团队内部沟通的口吻简洁直接不要客套。调完之后输出更像人写的Reviewer读起来也舒服。最后分享一个我最近在试的扩展方向把AI的Review结果和人工Review结果做对比统计AI的漏报率和误报率用这个数据来迭代审查清单。目前跑了二十个PRAI的漏报主要集中在并发和事务场景误报主要集中在命名风格。下一步我打算针对这两块单独优化提示词看看能不能把准确率再提一提。这个方向如果跑通了后面可以做成团队内部的Review质量看板持续跟踪。
