做这件事的时候是2022年初我接手一个典型的Java老项目做例行代码审计。这是个2017年启动的会员积分营销系统跑了好几年单服务多实例部署代码量大概40万行核心链路动不动就有半夜批任务、定时补发、并发扣减。团队平时催得紧很多代码是赶工出来的没人愿意回头翻。闲着也是闲着我试着把几个核心模块的代码丢给大模型做AI代码审查看它能不能帮我们摸底。第一次跑完AI拉了整整20个问题从SQL注入到并发修改HashMap都有看起来成果丰硕。但接下来我花了大半个下午逐条复核最后真正敢签要修的只有15个。剩下的5个不是项目里的真坑而是AI在缺少业务上下文的情况下把不符合规范和会导致故障画了等号。这篇文章就把整个过程拆开讲讲AI到底怎么审的、20个坑长什么样、为什么老炮只认15个、以及AI又漏掉了哪些真正的坑。1. 审前准备老项目喂给AI之前要先做这三件事1.1 先搞清项目真实的家底我接手这个项目时的技术栈很典型Java 8、Spring Boot 1.5.22、MyBatis 3.4、多模块Maven工程核心业务在三个模块里——交易流水、营销活动、用户账户。服务部署了两台ECS上面各跑一个Java进程定时任务用的是Spring注解没有分布式锁整库分表没做单表最大的一张流水表已经6000多万行。这意味着什么意味着你不能把整个工程一口气丢给AI也不能问帮我看看这个项目有什么问题那样得到的回答必然是一堆空洞的安全规范复读。要让AI审查有意义得先给它划定清晰的边界和任务。1.2 按风险排序选模块别整库乱扫我当时的做法是先自己用经验判断哪些链路最容易出事再把对应的源码挑出来交给AI。优先看三个地方——第一所有涉及金额计算、积分类流水写入的Service类第二所有被定时任务调用的方法第三所有直接拼接SQL的Mapper实现。这三个范围一划出来大概30个Java文件、1万多行代码分6批喂给AI。我用的是一款通用大模型API没有针对Java代码做过专门微调但它的代码理解能力已经足够做初筛了。1.3 提示词里必须写明输出格式和验收标准很多人用AI审代码提问方式就是一句你看这段代码有没有问题效果很差。AI不知道你是要它找Bug还是要它挑代码风格还是分析性能给的结果必然发散。我的提示词模板大概长这样你是一位有十年经验的Java后端技术专家正在审查一个生产环境的会员积分系统代码。 请只关注以下五类问题 1. 会导致线上故障的正确性Bug 2. 在高并发场景下可能触发的并发安全问题 3. 性能隐患尤其是循环内的SQL查询和资源使用问题 4. 外部输入未校验导致的安全风险 5. 明显的事务边界错误 对每个问题按下面格式输出 - 问题描述一句话说清楚 - 严重级别严重 / 中等 / 轻微 - 对应代码片段标明类名和方法名 - 触发条件什么场景下会出问题 - 修复建议给出最小改动方案 注意 - 有争议的代码可以先标出来但不要为了凑数硬凑问题 - 如果你不确定某个写法是否算Bug请标注上下文不足加上这个约束之后AI的回复质量明显高了一截。它会主动区分确定性问题和疑似问题而不是把构造函数里少了个final都当成高危漏洞列出来。2. 20个坑的完整画像AI扫出来的问题究竟准不准2.1 问题分类与数量分布第一轮AI输出20个问题我按类型做了个统计问题类型数量典型表现性能隐患6循环内查库、N1查询、逐条批量插入并发安全3共享SimpleDateFormat、HashMap并发写、线程池未复用事务失效2Transactional自调用、catch异常导致事务不回滚正确性6包装类型比较、异常只printStackTrace、时间日期处理错误、equals未重写导致集合判断失效安全风险2手工拼接SQL、前端订单金额直传后端未校验可维护性1大量魔法值散落各处这个分布本身就很说明问题AI对静态可见的缺陷敏感度很高凡是能从代码字面推断出来的问题它几乎都能抓到。我逐条看了一下20个里有15个确实是真问题这个命中率不算低。2.2 几个有代表性的典型案例拆解先说一个最典型的——N1查询。AI标记了一个积分任务发放方法里面是这么写的for (Order order : orderList) { Member member memberMapper.selectById(order.getMemberId()); rewardPoints member.getLevel() * 2; }一眼看过去就是在循环里查表。但AI能把这个当成严重级别输出是因为它进一步推算了影响orderList在双11批量补单时能达到几千条每一次发放任务都会产生几千条SQL数据库连接池迟早被打满。这不是理论上慢一点的问题而是峰值时期必挂的问题。后来的修复也很简单一次性查出会员ID集合再批量查询用MapLong, Member对接入逻辑处理SQL从几千条降到几十条。第二个代表性问题是事务失效出现在签到方法里Service public class SignService { Transactional public void sign(String userId) { this.updateSignRecord(userId); rewardService.addPoints(userId, 10); } public void updateSignRecord(String userId) { // 更新签到表 } }AI指出Transactional标记在sign()上但this.updateSignRecord()是内部方法调用绕过了Spring的代理对象事务切面根本不会生效。这种逻辑如果没人提醒确实很容易漏过去因为单看sign()方法本身注解、事务边界写得都没毛病。问题出在自调用这个隐蔽点上。第三类是SimpleDateFormat的线程安全问题private static final SimpleDateFormat SDF new SimpleDateFormat(yyyy-MM-dd HH:mm:ss);这是个老得不能再老的坑了但在这个项目里依然存在。AI给的解释很到位SimpleDateFormat不是线程安全的该类的内部日历状态在parse/format时会被修改。多线程并发调用同一个实例会导致日期错乱甚至出现不可识别的字符。随后建议换成ThreadLocal封装或使用Java 8的DateTimeFormatter。第四类说出来有点丢人——手工拼SQL。项目里有几个老Mapper方法是这么写的String sql SELECT * FROM t_member WHERE 11; if (StringUtils.isNotBlank(keyword)) { sql AND nickname LIKE % keyword %; }AI直接将这个问题标记为严重原因是keyword如果被恶意传入%; DROP TABLE ...; --之类的字符串会产生注入风险。虽然这个系统内部使用没有直接暴露给公网但作为长期维护的存量代码这种写法无论如何都不该留。第五类是包装类型比较这个也很有意思if (member.getId() user.getId()) { // 判断是否是本人 }两个Long对象用比较在值超过127时比较的是对象引用不是数值本身。AI把问题圈出来提醒改用longValue()或equals()。这类问题光靠人眼扫代码很容易滑过去因为只有在数据量大到超过Java包装类缓存阈值时才暴露。这五个case能看出来AI做静态审查的核心优势是覆盖面广、不疲劳、能穷举。它不靠运气不靠灵感只要代码里存在可被识别的模式它基本都能标出来。3. 老炮复核后只留15个被砍掉的5个到底冤不冤3.1 五个不认可的问题清单我复核的时候不是凭感觉砍而是把每个问题放到当前业务、当前架构、当前团队能力三个维度去重新审视。最终被砍掉的5个问题如下AI判定老炮复核结论Service层超长方法(300行)需拆分业务本身是高度耦合的结算流程拆散后更难追踪优先级低日志打印量过大建议减少该模块连续三年靠日志定位线上问题删日志会降低排障能力建议用StringBuffer替换StringBuilder该线程是单线程私有变量换成StringBuffer只是加了无谓的锁开销建议引入Lombok简化getter/setter老项目团队不熟悉Lombok引入新依赖的收益远低于学习成本建议统一用DateTimeFormatter替换SimpleDateFormat项目已有单例工具类做了synchronized隔离风险可控改动收益弱如果把AI当成代码规范老师这5个建议其实都说得通。但放在真实生产项目里有问题和值得改是两回事。3.2 误报的三种典型来源我复盘下来AI这5个误报基本可以归为三类第一类是把规范偏好当Bug。StringBuffer还是StringBuilderLombok还是手写getter这属于团队工程偏好不是故障隐患。AI并不知道这段代码所在的线程模型、并发环境、团队背景它只会看到这里有个StringBuilder但StringBuffer线程安全建议替换。但实际业务中这个局部变量根本没有被其他线程共享的可能替换就是负优化。第二类是缺少业务上下文导致误判。比如300行的复杂方法AI觉得太长、不好维护但它不知道这是财务结算逻辑里面十几个步骤强耦合拆成十几个小方法之后后续同事维护时反而要在多个方法之间来回跳。业务复杂度不是代码行数带来的拆分一个本身就很复杂的方法解决不了问题。第三类是不知道历史债务的存在。那些看着冗余的日志打印其实是几年前生产上出过一次严重故障当时日志不够详细整个团队排查了整整一通宵。从那以后这个模块的日志就是故意堆出来的。老炮看到的是每个日志背后的故事AI看到的是打印次数超过阈值。3.3 复核时我给AI补充过一轮追问我做过一个实验把那5个被砍的问题重新丢给AI并补了一句背景说明这个方法是单线程内使用的私有变量项目团队目标是Java 8不引入新依赖法律责任模块需要保留详细日志。结果AI很快改口承认其中4条在给定约束下可以不改。这个实验让我意识到一个关键点AI判断问题时会默认一个理想代码环境但现实项目里存在大量历史原因、团队约束和业务妥协。所以AI审查结果不能直接当工单派发必须有一个懂业务、懂历史、懂架构的人做最终裁决。3.4 复核本身也是团队的问题对齐过程这次复核还有一个额外收获。团队里四五个核心开发坐在一起过了一遍问题清单很多人第一次意识到哦原来这种写法在并发下会炸原来事务自调用一直没生效过。与其说这次任务是对旧项目的体检不如说它变相给团队做了一次针对老代码陷阱的集中培训。4. 五个漏网之鱼AI没看到、但老炮必须补上的真坑AI审查看似全面但它毕竟只能基于喂给它的代码做推断。一旦问题跨出了文件边界、脱离了源码层面AI就很容易漏掉。这次我复核完20个问题之后又另外揪出了几个AI完全没有提到的坑。4.1 定时任务重复执行AI的视线到不了部署架构项目里有个积分补发的定时任务注解是Spring的Scheduled固定时间点扫描前一天未发放的积分明细并补发。服务是两个实例部署这个任务在机器A和机器B上都会启动。这会导致什么结果如果某次调度因为数据库慢、任务超时下一次调度时间到了还没执行完两个实例就会出现并发重复补发用户账户里凭空多出一笔积分。AI看到的是一个孤单的Scheduled方法它不知道这个方法同时跑在多少台机器上也不知道项目有没有引入分布式锁。单看代码这方法没啥问题放到部署环境里这就是一个事故隐患。老炮的做法不需要引入复杂的分布式调度中心最简单的方案是在任务执行前尝试获取一个Redis分布式锁拿到锁才能跑拿不到就跳过。改动不过十来行代码但只有了解部署形态的人才会想到这一点。4.2 接口幂等性缺失AI看不见调用链上的隐患积分系统里有个参与活动领取积分的接口前端做了防重复点击但后端并没有做幂等控制。一旦用户手速快、网络重试、或者有人绕过前端直接调用接口同一条活动记录可以生成多笔积分流水。AI审查单看这个Controller方法会觉得逻辑没啥问题。但它不知道这个接口的调用来源、不知道上游系统是否会重试、也不知道用户行为模式。幂等性是个系统级属性需要从整条调用链去设计不可能在单个方法里通过代码审查发现。老炮的补充方案在进入领积分逻辑之前先查一下本次请求的幂等键在流水表里是否存在存在就直接返回成功用唯一索引兜底。4.3 依赖冲突引出的运行时异常AI看不到编译期的classpath还有一个坑更隐蔽。系统里某个内部工具jar和项目里的fastjson版本对不上导致在生产环境偶发NoSuchMethodError但本地开发环境怎么跑都正常。你把源码喂给AIAI看到的是JSON.parseObject()这个调用会觉得再普通不过。它不可能知道Maven依赖树里到底解析到哪个版本的fastjson也不可能知道这个版本里有没有那个方法。这类问题依赖的是编译期classpath解析结果和运行时环境纯静态审查根本无解。4.4 AI漏检的机制原因总结把这几类漏网之鱼摆在一起看原因很清晰AI的审查视野完全由你喂给它的材料决定。它没有部署视角、没有调用链视角、没有真实数据、不知道团队历史更没法主动问这个任务有没有跨机器执行这种问题。它能做的是在你划定的源码范围内做模式匹配和逻辑推断。5. AI代码审查的正确姿势把它当实习生别当裁判5.1 推荐的三阶段流程经过这一轮实战我现在给团队定的AI辅助代码审查流程是这样的第一阶段AI初筛。把核心代码按模块分批次交给AI明确输出格式和关注点让它产出疑似问题清单。这个阶段的核心指标是覆盖率宁可要一些误报也别让它漏掉明显Bug。第二阶段人工复核。安排资深开发逐条过结合业务上下文、部署架构、历史原因做裁决。每个问题都要回答三个问题它会不会发生发生了影响多大修改成本多高只有三个答案都指向该改才进工单。第三阶段修复后回归。改完的代码再丢给AI看一遍确认修复方案没有引入新问题。这样还能顺便验证AI的修复建议是否真的解决了它自己提出的问题。5.2 要求AI给出证据链不给结论我这次实践下来最好的一个用法是要求AI输出触发条件和为什么。比如它说这段代码存在性能隐患紧接着就会看到它标注出循环体的位置、对应的SQL语句、以及达到什么量级会触发风险。这种带证据链的输出复核起来非常省力不用自己再去翻代码验证它是不是瞎说。反过来如果AI只给结论不给理由比如建议采用更优雅的设计模式这类输出基本可以直接忽略因为它没有把问题落到具体场景里。用AI审代码还有一个绕不开的现实问题信噪比。AI发现20个问题其中5个是误报这个比例其实已经算不错了。我见过有些人直接把AI输出粘贴给团队成员让新人按单子修结果新人把不该改的也改了反而引入了回归。这就是没设置复核人这个角色的后果。5.3 一次AI审查最大的产出不是问题清单是团队标准复盘这次的整个过程我觉得最有价值的不是那15个被确认的坑而是复核过程中形成的一套判断标准。比如Java老项目里哪些写法是红线、哪些是建议、哪些可以不动什么情况下允许保留手工拼接SQL但必须加白名单校验定时任务上线前必须确认有没有多实例锁。这些标准以前散落在几个老开发脑子里现在变成了一张可以被检查、被讨论、被培训的清单。5.4 给准备尝试AI审查的人几个具体建议如果你想在自己项目里复刻这个流程我有几条实操建议第一批先拿已经出过事故的模块试水这样AI的输出可以对标已知问题方便评估准确率。提示词里务必写明不要为了凑数硬凑问题否则AI会把代码风格和真正的Bug混在一起增加你的复核负担。不要一次喂超过50个方法AI的处理质量会随上下文长度明显下降。分批次、按模块喂效果要比一次性全量丢进去好得多。遇到AI说上下文不足的标注优先重点关注。这往往意味着它看到了风险但缺业务信息无法确认这种地方最值得人工细看。老项目维护这件事本质上就是在一个不那么完美的代码库里持续做出理性的取舍判断。AI能帮你把水面下的礁石更快、更全地标出来但最终要承认哪些是真障碍、哪些只是看上去危险还是得自己动手潜下去看。以后我大概率会继续用AI做初筛但每一份审查报告我都会保留人工复核这一道工序。