接手这个活儿前我对“AI代码审查”这四个字多少是有点保留的。项目是一个2022年上线的Java老系统业务跑了好几年代码风格混乱技术栈固执地停在JDK 8和Spring Boot 2.5上连前端都还是JSP。我原本只是想拿它试试水让AI扫一遍看能不能在代码质量和潜在缺陷上给出点人工Review容易漏掉的判断。结果这一试试出了274条静态扫描告警聚合归类后变成20个核心问题再拿给团队里的资深开发过了一遍老炮只认了其中15个剩下5个被当场驳回。这5个被驳回的问题比那15个还被认可的坑更值得聊。因为它把AI代码审查的边界、误报的来源、以及人和机器怎么分工这件事一次性摊开了。这篇文章不聊概念只聊我实际干下来的整套流程用的什么组合工具怎么配置的20个坑具体是哪些哪些被老炮否了为什么被否以及这套方法怎么在别的老项目上复现。1. 为什么拿2022年的老项目开刀背景与整体流程1.1 这个项目到底“老”在哪2022年的项目其实不算特别老但在Java这个生态里它已经显露出明显的“遗产生态位”JDK 8打包用的还是MavenSpring Boot 2.5MyBatis的XML里塞着快两百行的动态SQL部分模块用Apache POI生成Word合同和结算报表代码仓库里混着至少三个人的命名风格——有匈牙利命名法的残留有全小写单词堆一起的也有一言不合就写缩写注释的。最让我头疼的不是技术栈旧而是没有单元测试。不是“覆盖不全”是几乎没有。这意味着AI扫描出来的任何“可能存在并发问题”或者“这段逻辑可能NPE”的告警都没有测试用例可以作为快速验证的工具。你要确认一个问题是不是真的能触发得一边追调用链一边在脑海里人肉模拟并发效率极低。这类项目有一个共同特点业务依赖极高、所有人都怕动、出了问题饭都吃不好。它对变化的容忍度极低所以任何代码审查结论都必须附带“改动风险有多大”的评估而不仅仅是“这里有毛病”。1.2 为什么选AI而不是纯人工和纯静态扫描纯人工Review的问题不在于人不行而在于惯性。一个跑了三年的系统老开发看到一处可疑代码第一反应往往是“这段逻辑虽然丑但线上一直没问题先别动”。这个判断并不全错但它会掩盖真正的风险滋长。而且人工Review的效率上限太低一个核心类三五百行逐行过一遍就需要半小时二十号人的团队不可能每周都这么干。纯静态扫描比如SonarQube能规模化发现问题但它不带业务语义。它知道“这里有个魔法数”不知道“这个魔法数对应着线上支付渠道的固化编号改掉会炸”它知道“有逻辑分支没被测试覆盖”不知道“这个分支是留给三个月后新业务用的”。这一层语义缺口正好是AI能补的位置。我的结论是AI代码审查不是拿来替换静态扫描的也不是拿来替换人工Review的它应该夹在两者中间。静态扫描负责尽可能多地“看见”嫌疑点AI负责把嫌疑点聚类、排序、去重、给出初步判断而人工负责做最终决策。这个定位直接决定了我的工具选型。1.3 我用的完整审查流程整个流程我只跑了一遍但每一步都踩出不少细节值得直接抄作业全仓库拉取代码先用SonarQube做一次基线扫描把原始告警全部导出成结构化数据。写了一个Python脚本把SonarQube输出的每个问题的文件路径、行号、规则名、代码片段连同项目的基础说明一起打包分批喂给大模型API。让AI只做四件事把重复根因合并、按风险等级排序、标注影响范围、给出本文件内可行的修复建议。不要求它做设计评审也不许它天马行空。拿到AI输出的问题清单后我把它整理成一张表决表拿给团队里两位资深的Java工程师一个一看就是老炮一个属于闷头写代码但特稳的类型逐条做“认可/驳回”裁定。最后把被认可的15个问题转成可执行的整改项同时把被驳回的5个误报记录为“AI规则黑名单”避免下次再报。这套流程跑下来最核心的一个体会是AI代码审查的价值不是“替你发现所有问题”而是“把原本需要20人天的人工排查压缩到1人天以内并且给出一个让团队讨论的靶子”。没有这个靶子很多人对所谓隐患是没感知的。2. 工具选型与配置调校这样搭配AI才不会瞎报2.1 为什么不能直接拿大模型扫全仓库最开始的尝试很粗暴把整个项目的源码压缩成文本直接让大模型读。结果惨不忍睹三层问题一是token成本高得离谱一个中型仓库几十万行代码跑一轮就要烧掉上百万token二是上下文窗口根本装不下模型读到后面已经忘了前面的代码结构给出的判断开始自相矛盾三是大模型在缺乏全局信息时会脑补编造出不存在的类名、方法、甚至修复方案里的API这是最致命的。后来我换了个思路不让AI直接面对原始代码海先让SonarQube做一道粗筛。SonarQube的规则引擎是确定性的它不会脑补命中的每一条告警都有准确的代码位置和规则依据。它的问题只是“不够聪明”而AI恰好擅长处理“信息过载后的归纳和判断”。两者是互补的。2.2 静态扫描当眼睛AI当大脑的组合方案具体做法是这样先跑一轮SonarQube得到的告警通常数量很大我们这次是274条。我不会把这274条直接扔给AI因为里面有很多是同一种模式在不同文件里的重复比如“在循环中拼字符串”这种告警可能出现在20个文件里这本质上只是一个根因。我先写了一个预处理脚本把告警按“规则类型代码结构特征”做一次粗聚类再把这些聚类的代表样本、文件路径、相关上下文代码片段整理成JSON格式分批次调用大模型API。每一批大约包含15到20个原始告警AI需要在这一次调用里完成四件事判断这些告警是否属于同一个根因如果是合并成一个问题项给每个合并后的问题标注风险等级高/中/低依据是“触发概率”和“影响面”说明它影响的是哪些调用链路或业务场景给出修复思路严格限制在单个文件内可落地的修改不提倡跨模块重构。这个组合方案没什么黑科技但它把一个关键问题解决了AI不再需要同时面对“找出问题”和“判断问题”两大任务前者交给确定性工具后者才是模型的强项。两步各干各擅长的误报率才可能压得住。关于调用大模型API的具体配置我用的提示词大概长这样你可以按自己的场景改# 伪代码把SonarQube告警转换为AI可判断的结构化任务 system_prompt 你是一名Java静态代码分析结果的判断助手。你的工作是 1. 合并根因相同的告警多个文件出现同一模式时只保留一条并在涉及文件中列出全部位置 2. 对每条合并后的问题标注风险等级观察点是线上真实触发概率和影响面大小 3. 给出修复建议但只允许在单个文件范围内修改禁止提议大规模重构 4. 如果你不确定某个判断必须标注不确定禁止编造代码事实。 输出格式为JSON数组字段summary, risk_level, reason, affected_files, fix_suggestion。 for batch in split_issues(sonar_issues, batch_size15): user_prompt build_user_prompt(batch) # 包含文件路径、代码片段、项目说明 response llm_chat(system_prompt, user_prompt) merged_issues.extend(parse_json(response))2.3 提示词这么约束踩坑率才降下来之前我犯过一个大忌提示词太开放。第一次我让AI“审查这个项目的代码质量并给出改进建议”它给出的答案像一篇通用架构文章说的全是“建议引入设计模式”“建议增加单元测试”这种放之四海而皆准但无法落地的废话甚至有几条建议改的法儿在JDK 8下根本编译不过。后来我总结出三个约束原则效果立竿见影第一告诉它“你不是Reviewer你是分析助手”。这个词的差异很重要。Reviewer会被默认要求挑毛病、给方向而“分析助手”只需要对给定输入做归纳整理不会主动往外发散。第二要求它“只处理输入范围内的问题不得新增输入范围之外的建议”。这一条直接堵死了AI自己脑补新问题的路子。第三强制输出JSON结构化数据并且规定不确定的内容必须标注。结构化输出的好处是后续直接可以进表格更重要的是它逼着AI把判断拆成可验证的“结论依据”而不是模棱两可的一句话。这一套约束跑完一轮后我统计过告警总数从274条合并成20个独立问题项其中大概只有5条属于AI拿不准或者明显误报。这个比例是完全可以接受的。3. 20个坑的完整清单按风险等级和价值排序3.1 总览表这就是我最后拿给老炮表决的那张单子整理之后的20个坑我按风险等级分成了四类并发安全类、资源与生命周期类、业务与数据正确性类、可维护性与规范类。我先把完整的表决表贴出来后面挑几个重点展开讲。编号问题项风险等级老炮裁定1多线程环境下共用SimpleDateFormat实例高认可2批量导出Word报表时未关闭嵌套流高认可3Transactional自调用导致事务失效高认可4MyBatis动态SQL中某分支漏拼租户隔离条件高认可5捕获异常后没有任何日志输出高认可6Service层循环依赖导致启动和变更困难中高认可7缓存key前缀设计混乱跨业务可能冲突中高认可8大事务内调用远程接口导致锁持有的时间过长中高认可9循环中拼字符串产生大量无谓对象中认可10使用过期的日期API存在时区隐患中认可11数据导出时用拼接SQL语句未走参数化中认可12对象拷贝只拷了引用源数据后续修改污染结果中认可13工具类大量未使用的import与废弃注释块中认可14日志全用System.out打印无法按级别过滤中认可15方法命名不达意真假退货逻辑混在同一个入口中认可16建议把大if-else分支改造成策略模式低驳回17建议所有接口统一返回全局响应体低驳回18建议测试覆盖率提升到80%低驳回19建议把Apache Commons Lang工具方法迁移到JDK自带低驳回20部分“可能NPE”提示实际调用链上游已保证非空低驳回3.2 并发安全类老项目的高发区AI的强项并发问题是我最希望AI能抓的地方因为人工Review时它对心智负担要求很高你得在脑子里模拟多个线程同时跑。这次抓到的第一个就是经典的SimpleDateFormat线程安全问题。项目里有这样一个工具类代码大意是public class DateUtils { private static final SimpleDateFormat sdf new SimpleDateFormat(yyyy-MM-dd HH:mm:ss); public static String format(Date date) { return sdf.format(date); } }在低并发场景下它可能几年都碰不到出问题的那次竞争可一旦某个促销活动把单量顶上去了两个线程同时调用format方法就可能出现格式化结果错乱甚至直接抛NumberFormatException。这种bug属于“线上不死不活偶发头疼”是最恶心的一类问题。修复方案也很简单要么改成JDK 8的DateTimeFormatter它本身是线程安全的要么用ThreadLocal包一层SimpleDateFormat。我选了前者因为项目已经在JDK 8上了没有理由继续背着历史包袱。AI在这类问题上表现很好因为规则明确、语义清晰它给出的建议基本不用改就能用。3.3 资源与生命周期类POI那个坑是最实打实的项目里有一个重要功能用Apache POI生成Word格式的结算报表。这个功能平时用得不算频繁但每次生成的都是带表格和图表的大文档流程涉及XWPFDocument、XWPFTable、多个OutputStream嵌套中间任何一层流没关干净都会导致文件句柄泄漏。AI在这个模块里抓到的问题是这样的最外层用了try-with-resources但内部持有的多个ByteArrayInputStream和嵌套的FileOutputStream并没有纳入自动关闭范围。在Windows服务器上这种泄漏的后果是文件被占用的时间越来越长最后报表生成接口会无缘无故地卡住重启才能恢复。这一类资源泄漏问题AI能抓到的关键在于SonarQube已经把可疑的流操作位置全部标记出来了AI只需判断“哪些路径确实存在泄漏风险”。这件事的成本极低但人工要是没经验很容易看一眼try-with-resources就以为万事大吉。3.4 业务与数据正确性类这里AI的判断需要业务知识第4号坑是20个里面最值钱的一个。项目的订单查询功能里MyBatis的XML写了一个多分支的动态SQL其中一个分支是“运营后台的汇总导出”这个分支拼接查询条件时漏掉了租户ID的过滤条件导致运营人员导出的数据会把所有租户的数据都拉出来。这在多租户系统里属于严重越权问题。为什么这个坑值得单独说因为SonarQube对这类问题是完全没感知的它的规则里根本没有“租户条件必须强制拼接”这一条。AI能抓到它是因为我在喂上下文的时候把项目描述里“所有查询必须带租户条件”这条业务约束放了进去AI才在分析时把这个分支单独拎出来说这里没有遵守项目既定的数据隔离约束。这个案例说明了上下文对AI审查的重要性。你要是拿一个裸仓库让AI审它能找出空指针、并发问题、资源泄漏但绝不可能找出业务规则被绕过的隐患。我把这个体验放在后文“怎么喂上下文”里再展开。3.5 可维护性与规范类噪音很多但有两三个值得改剩下的10到15号问题不少属于“老生常谈”型比如循环里拼字符串、过期的Date API、System.out.println打日志、命名不达意等等。这些问题的特点是AI报出来老炮也认可但优先级并不高属于“茶余饭后改一改”的范畴。但其中有一条我想单独标出来第15号方法命名不达意。这个方法叫queryOrderInfo核心逻辑却是先判断当前请求是否来自售后渠道如果是就走退货查询逻辑否则走正常订单查询。一个名字叫“查订单”的方法暗地里干了“查退货”的活调用方完全看不出语义差异。这种问题对可维护性的杀伤力比一个潜在的NPE大多了因为它是长期性的认知负担。AI能发现它靠的是对比了方法名和方法体里的业务分支这种跨语义的判断恰恰是AI相对人类有优势的地方——人看书名就不一定会翻到那页细看。4. 老炮只认15个那5个被否决的坑全复盘4.1 被驳回的5条到底长什么样表决结果出来的时候我其实没有太意外但每条驳回理由都值得记下来因为它们是AI代码审查“边界”的最好样本。第16号AI建议把一个大if-else分支改造成策略模式。老炮的回复是“这个分支就两个条件且三年来没有新增过第三种团队里没人熟悉策略模式改完后维护成本反而更高。”这话糙理不糙。引入设计模式的目的是应对变化代码里根本没有变化趋势的位置强行套模式就是给未来维护者增加理解负担。第17号AI建议所有接口统一返回全局响应体。这听着很优雅但它完全没考虑项目现状接口对外已运行多年调用方都是按旧的响应格式解析的一旦改动就要协调所有对接方升级风险覆盖范围根本不是一次代码审查该决定的。第18号AI建议把测试覆盖率提升到80%。方向没错但老项目的现实是连测试框架都没搭好业务逻辑深深耦合在数据库和文件系统里造假数据成本极高。老炮说得很直接“这个钱应该花在补日志和监控上而不是补测试。先把线上出问题时能不能快速定位解决再谈覆盖率。”第19号AI建议把Apache Commons Lang的用法替换成JDK自带方法。它没注意到仓库里还有一个单独的模块需要兼容JDK 7那个模块编译时必须依赖Commons Lang。一个看上去人畜无害的现代化建议在混编场景下就是埋雷。第20号AI提示某个方法里存在可能NPE的风险。老炮翻了一下调用链发现这个方法的所有入口在上游都做过非空判断并且有契约约定不允许传空。AI看不到跨方法的约定它看到的是“这个入参没有被显式判空”于是给出了一个在当前代码环境下不成立的告警。4.2 误报的根源不是AI蠢而是它缺了三种信息把上面5条放在一起看会发现一个规律AI不缺技术判断力缺的是业务上下文、历史原因和团队规范。它不知道这个接口要兼容外部调用方不知道项目之前因为升级依赖炸过一次不知道团队的技术栈偏好和约定。如果把这些信息都喂给它它大概率能给出接近老炮的判断。这让我想明白一件事AI代码审查的输出本质是“可能性清单”而不是“事实清单”。它说“这里有NPE风险”是在说“在缺少约束的条件下这里有可能发生NPE”老炮说“这里不会NPE”是在说“在现有代码约定的条件下这里不会”。两个人其实都对只是假设的前提不一样。这个差异不是AI的缺陷而是AI使用的逻辑起点。你如果把AI的输出当成终审判决去执行那它就是满嘴跑火车但如果把它当成一份“值得讨论的候选问题表”它的价值就出来了。4.3 表决过程本身的价值把隐性知识逼出来这轮表决我最看重的收获不是15个被认可的坑而是老炮在驳回5条建议时给出的理由。这些理由以往只存在于老开发脑子里从来没有被写进任何文档。AI审查就像一根杠杆硬生生把这些隐性知识撬了出来。比如第18号那条“先补监控再补测试”这句话本身就是一条很高级的工程决策经验。如果没有AI报出这个问题你可能永远不会听到老炮主动跟你讲这个。所以我的做法是把老炮驳回的每一条理由都记录在案形成了团队的“技术决策备忘录”。下次再有新人问为什么这个模块不引入策略模式直接翻备忘录就行不用再拉老炮开一场说明会。5. AI代码审查最佳实践拿这套方法去审你的老项目5.1 审查范围怎么定全量基线和变更审结合经过这次实战我建议团队把AI代码审查拆成两件事全量基线和变更即时审。全量基线建议一个月跑一次目标就是给存量代码做体检像我们这次做的这样。它产出的问题清单不追求马上全改但必须有人维护跟踪每季度更新一次状态。变更即时审则是把AI接入每次MR的流程中只审查本次改动的代码目标是防止新代码继续引入老毛病。这两件事的分工很清楚全量为了还债变更为了不欠新债。老项目尤其要注意的一点是不要试图一次性把存量问题全部修复。这个我试过结果就是两周后大家全疲了改到一半的新代码和没改完的老代码混合在一起出问题的概率成倍增加。分批次、按影响面排序、每批控制在3到5个问题才有可能长期坚持下来。5.2 上下文怎么喂不要嫌麻烦效果差三倍如果你想让AI在审查时更贴合项目实际就一定要给它喂上下文。我这次喂了四样东西项目README、核心数据库表设计的文字描述、最近20条commit message的摘要、以及项目历史上发生过故障的事件纪要。喂进去之前AI审查那种“通用感”特别重报出来的问题总感觉换一个项目也适用喂进去之后AI开始说一些“你这个问题和支付回调重试场景相关”这种带项目气息的话了。我统计过一个粗数据不加上下文时20条建议里大概有6到8条会被驳回加了之后这个数字降到了3到5条。更关键的是AI给出的风险排序更贴近真实因为它在判断“影响面”时有了业务依据。5.3 人工仲裁机制让AI闭嘴和让它开口同样重要AI代码审查自动化程度再高最后还是需要人工仲裁。我建议在团队里设一个“规则否决权”的角色不一定是架构师但一定要是写码年头足够多、踩坑足够深的老开发。他对AI输出说“不”的时候必须附带一句理由这句理由直接进规则库。我们的实际操作是每周固定拿出半小时集中过一遍本周AI新报出的问题老炮负责逐条表态能改的直接分配出去驳回的写进“白名单”。两周之后我统计过AI的误报率确实在下降因为白名单里积累了项目自身的规则我再把这些规则写进提示词的约束条件里AI就不会再犯同样的“外行判断”。5.4 安全边界敏感代码不要裸传外部API这一点可能有人不爱听但我必须说不要让AI代码审查变成数据泄露的口子。老项目里经常混着密钥、账号、用户手机号这些敏感信息直接把整个仓库喂给外部API风险是不可控的。我的习惯是本地部署模式优先如果必须用外部API就做脱敏预处理——把代码里的字符串常量替换成占位符把注释里的业务信息抹掉只保留代码结构。如果连脱敏都做不到就退一步只把SonarQube的结构化告警发给AI不给完整源码。少一点智能但安全底线守住了。6. 常见问题与排查技巧实录6.1 AI报出的行号对不上实际代码这个我遇到过好几次。SonarQube拿到的行号是精确的但AI在分析时如果碰过上下文输出的行号偶尔会因为代码截断或者注释处理而错位。别硬找那个行号按“方法名规则模式”去搜索更高效。我后来在提示词里明确要求“不确定行号时只输出方法名和文件名不要输出具体行号”错误率立刻小了很多。6.2 模型上下文不够导致漏报大模型有上下文窗口上限这是硬限制绕不过去。我的做法是拆模块处理而不是一口气全丢进去。先按包层级拆把几个核心业务包单独拎出来审边缘工具类放到最后统一处理。另外一个小技巧是分层摘要先让AI读一个包下面的类摘要再读关键类最后才定位到具体方法。这样它能对全局有一点感觉不会一头扎进细节里出不来。6.3 误报率太高怎么办如果你的AI误报率超过了三成先别急着怪模型回看一下提示词。大概率是你的提示词太开放没有明确告诉AI什么该做、什么不该做。我自己的经验把“只做判断、不做建议”“只处理输入范围内问题不新增”这两条加进提示词后误报率能掉一半。剩下的就靠项目自身的白名单规则慢慢磨。6.4 老炮不配合AI审查怎么办这事儿我得说点实际的。团队老开发对AI审查有抵触非常正常他见过太多给团队带来额外工作量的“新工具”。想让他们配合别开大会宣导也别强制要求必须采纳AI结论先从一两个谁看了都认的问题下手比如那个SimpleDateFormat并发隐患修起来三分钟风险几乎没有效果立竿见影。等老炮通过AI的工具修掉几个真问题他对这个工具的信任自然就起来了。后续再逐步放开范围让AI成为他Review的辅助而非替代。我个人的体会是AI代码审查想在团队里真正扎根不是靠它多能挑毛病而是靠它能在多大程度上帮老开发节省时间、减少踩坑。这次实战跑完之后我自己最大的转变是不再拿AI当判定工具而是当讨论对象。那15个被认可的坑给我带来了实打实的修复清单但那5个被驳回的建议才真正推动了团队把“为什么这么写”这层窗户纸捅破。最后补一个小偏方下一次你给AI喂上下文的时候把项目发生过的事故纪要加进去它给出的风险排序会明显变准。这是我把事故记录从两份扩大到十几份后对比出来的经验。