接手这个活儿的时候我本来没抱太大期望。一个2022年落地的Java老项目代码量不大不小刚好两万来行涉及订单同步、库存扣减和对账几个模块属于典型的“能跑就行”的内部系统。让我意外的是把代码丢给AI做审查竟然在几轮对话里挖出20个值得讨论的坑。更让我意外的是团队里几个老炮一起复核之后大家一致认可的问题只有15个另外5个属于典型的“AI看到了代码但没看懂业务”。这篇文章就围绕这15:20的比例展开说说我是怎么用AI做Java老项目代码审查的AI的哪些判断能信、哪些不能信资深工程师的价值为什么恰恰体现在过滤AI输出这件事上。如果你手里也有一堆写于两三年前的Java代码想系统清理技术债又不想投入太多人力这篇内容应该能给你一条可行的路径。1. 为什么拿2022年的老项目开刀1.1 老项目的“技术债”比新代码更值得交给AI新项目的代码通常还保持着良好的纪律性约束文档、规范插件、Code Review流程都在场即使有问题也是零星散落。而2022年的老项目经历过需求快速迭代、人员流动、临时hotfix的反复捶打代码里沉积的往往是“当时赶工没来得及想清楚”的产物。这种项目有个特点问题分布极不均匀。一个模块可能写得很讲究另一个模块则整个是“屎山”。让资深工程师从头到尾逐个方法去读精力的投入产出比很低而AI没有疲倦感可以把所有文件扫完把可疑点全部列出来。我这次就是把全部Java源码压缩成项目结构索引分批喂给AI让它按模块逐层审查效率比人工通读高出几个量级。1.2 AI审查和传统静态扫描的根本差异做Java的人多数用过SonarQube、PMD或者FindBugs它们靠规则库匹配代码模式能准确但笨拙地找出“魔法数字”“未捕获异常”这类标准问题。AI审查则完全不是同一套逻辑。我用的是对话式大语言模型。它不匹配规则而是像一个读过大量代码的工程师带着上下文去理解类与类之间的关系、方法的职责边界、事务的传播行为再从代码气味和逻辑漏洞两个维度给出判断。换句话说传统静态扫描是“查字典”AI审查是“读文章”。两种方式各有用处但面对老项目AI的灵活性明显更有价值因为老项目最大的问题不是单个错误而是设计层面的不协调——比如两个模块用了两套并发控制方案、事务被拉得太长、缓存和数据库的更新顺序不统一。这些问题靠规则库永远发现不了AI却能识别出来。1.3 适合用AI审查的项目特征经过这次实践我总结出适合AI审查的Java项目画像特征说明代码量适中1万到10万行最好太少AI没上下文太多则输出质量问题有一定技术债如果全是新代码且严格遵守规范AI的价值会大打折扣属于内部业务系统不涉及特别敏感的加密逻辑可以安全地交给AI分析团队能人工复核AI只是筛子真正的判断必须由懂业务的人来做如果你手里的项目符合这张表的特征那接下来的实战流程可以直接照搬。2. 审查准备给AI搭好“舞台”2.1 上下文打包的三个要点AI审查的效果很大程度上取决于你怎么把项目交给它。我一开始图省事直接丢了一个核心Service的代码给它结果AI给出的反馈全是对单文件风格的点评完全没有涉及类之间交互层面的问题。后来调整了做法分三步走。第一步生成项目全貌的结构索引。把各模块的包名、类名、关键方法名整理出来让AI先知道整个项目的骨架。第二步按业务链路切分代码块。比如“订单创建链路”涉及OrderService、StockService、PaymentClient三个类就把这三个类连同对应的Mapper接口一起喂进去保持业务语义的完整性。第三步在喂代码前用一句话说明这个模块的业务背景和预期行为AI就不会把一些正常流程误判成问题。这里最容易被忽略的是POJO和工具类。它们看起来不重要但AI在判断“这个字段有没有被并发修改”“这个对象能不能安全发布”时需要看到完整的定义。缺了这些AI的判断依据不完整误报率会明显上升。2.2 环境问题的前置处理我这次遇到一个典型的环境坑项目里某个模块使用的JDK版本不统一有的地方用了Java 11语法有的地方却在pom.xml里配置了Java 8的编译目标。这类问题在编译时往往只表现为一句警告比如“源发行版 17 需要目标发行版 17”这种提示老项目里特别常见。严格来说这不算AI审查的范畴但它会影响AI理解代码。如果连项目用的是什么Java版本都没确定AI对“这个写法是否可以简化”的判断就会失真。所以我先把pom.xml和build.gradle都整理好统一下JDK版本信息再开始审查工作。如果你也有这个警告先在IDE里做两件事检查Project Structure里的SDK设置再检查Maven或Gradle的编译参数确保source和target一致。这个问题不解决AI审查过程中会一直被无关的环境噪音干扰。2.3 审查会话的分层策略一次把所有代码塞给同一个AI会话输出质量会迅速下降。我的做法是分层开三个独立会话第一层静态资源会话只审查Controller、Service、Mapper的骨架和接口定义关注API设计和分层合理性。第二层核心逻辑会话挑出涉及金额计算、库存扣减、状态流转的代码重点审查。第三层并发与数据一致性会话把所有出现synchronized、Lock、ThreadLocal、事务注解的地方集中分析。三个会话各查各的最后把结论汇总到一张表里。这个分法让每个AI会话的上下文窗口都塞满了相关信息输出的问题列表质量高很多。如果你用的是上下文窗口较大的模型可以适当合并但分层审查的思路一定要保留。3. AI扫描出的20个坑按类拆解3.1 线程与并发隐患老项目的并发问题是最多的一类AI在这一块的表现相当突出。它能敏锐地识别出“这个HashMap被多个线程写”“这个SimpleDateFormat是共享的”“这个static变量没有加volatile”等经典问题。印象最深的一个坑项目里有个缓存工具类用了双重检查锁来初始化一个Map但Map本身用的还是HashMap没有用ConcurrentHashMap。AI直接指出即使初始化过程被锁保护后续的读写仍然是并发不安全的。这种判断需要理解“锁保护的是初始化而不是后续操作”AI做到了。还有一处涉及线程池的坑。老代码里对每次请求都执行Executors.newFixedThreadPool(5)导致频繁创建线程池。AI指出这既浪费资源也容易在请求量上来时造成4个线程的空转消耗。这两个问题我只认了第一个第二个修复成本不高但属于性能优化而非正确性问题优先级排后。3.2 数据一致性与事务边界这个模块是AI输出的重灾区因为它最容易“看到一半就下结论”。比如某个Service方法里先更新订单状态再调用远程接口通知物流系统。代码里没有事务注解。AI立刻标注“缺少事务控制”但业务逻辑本身要求“订单状态更新成功后必须通知物流如果通知失败需要重试”这实际上是个最终一致性的场景强行加事务反而会拉长数据库锁时间。我们复核后把这类问题归为“需要人工判断”。AI看到了“没有Transactional”的代码事实却没有理解“这里本就不该有分布式事务”的业务语义。这就是20个坑里最典型的伪命题。但AI也抓到了真问题。比如在库存扣减方法里更新库存的SQL先执行然后捕获异常试图回滚扣减操作但同一个Service方法被类内部调用时Transactional注解根本不会生效因为Spring的代理机制只对跨类调用生效。这个坑很隐蔽AI不仅标了出来还解释了“自调用”的成因和我们核实后的结论完全一致。3.3 代码风格与技术债老项目的技术栈往往停留在两三年前的“标准写法”上。AI对这类问题的识别非常稳定因为它读过海量的不同代际代码能一眼看出“这行的写法应该升级了”。举几个典型的大量使用new SimpleDateFormat()每次格式化都重新创建对象。AI建议用DateTimeFormatter替换并且是线程安全的。笨拙的字符串拼接s item循环了几千次性能损失明显。AI建议改用StringBuilder。类型判断用if (obj instanceof String)后强转AI建议用Java 16的instanceof模式匹配优化。数据拷贝用BeanUtils.copyProperties做深拷贝AI指出这个工具本质是浅拷贝对嵌套对象无能为力。第4点值得多说一句。团队里有几个年轻人觉得“AI连这个都要管不是小题大做吗”但老炮一致认为这是值得改的因为项目里已经出现过一次因为浅拷贝导致两个对象共享同一个内部List进而互相污染数据的线上事故。IO问题总在周末爆发深拷贝的问题也一样。3.4 安全与异常处理AI在安全检查上的表现让人惊喜。它发现了一个存储型XSS入口一个SQL参数拼接还有一个文件上传路径穿越问题。这些都是实打实的安全风险虽然这个老项目只在内网使用但如果未来暴露到公网就是致命漏洞。异常处理方面的问题则要辩证看待。AI对“catch了Exception但什么都没做”的代码非常敏感十次有九次会标出来。但老项目里大量这种空catch块有些十确确实实是“吞异常”的坏味道需要至少打一行日志另一些则是“这里出错不影响主流程”的刻意设计。我复核时给每条都补上了注释但并没建议全部修掉。最终AI列出的20个问题分布是这样的类型数量AI认为严重度并发与线程安全6高事务与数据一致性4高外部接口调用与异常吞没3中性能低效写法3中安全风险2高代码可读性与维护性2低4. 老炮只认15个人工复核的艺术4.1 5个“假坑”是怎么被排除的团队一起过AI报告时争论最多的是5个被标记为高严重度的“事务缺失”和“空循环等待”。这5个之所以被老炮枪毙原因各不相同但核心逻辑是一致的AI缺少业务上下文。举一个典型例子。AI在某段库存同步代码里看到了一段while (queue.size() 0) { Thread.sleep(100); }立刻标注“空转占用CPU可能造成死循环”。但我们知道这段代码的上游是一个定时任务每5分钟才向queue里写一批数据这个循环的最大空转时间不会超过5分钟而且任务本身被管理在独立的线程中对主流程无影响。再比如一个“循环里调用远程接口且没有超时设置”的问题。AI建议加超时配置但实际调用的是内网的一个常驻服务历史上从未出现过超过2秒的响应而且服务调用的失败会由外层补偿任务兜底。老炮的判断是这个循环是合理等待不是缺陷。这类差异是资深工程师和AI最本质的区别。看得懂代码结构的工具很多看得懂业务意图的人很少。AI从代码出发老炮从系统和业务的目标出发两者结合才是完整的审查。4.2 15个问题按优先级重新排序排除5个误报后我们按“线上风险 技术债偿还 可读性提升”三个维度重新排了优先级P0本周修库存扣减自调用导致事务失效、存储型XSS入口、线程池每次创建、登录接口的口令哈希算法过旧。P1本月修SimpleDateFormat共享读写、深拷贝污染、SQL参数拼接、共享HashMap并发读写、空catch块补日志。P2下季度修字符串拼接、重复的魔法数字、过长方法拆分、DTO拷贝歧义、命名风格统一。P0这5个问题里有两个是线上出现过故障但定位为“偶发”的另一个是安全审计发现的“低风险”漏洞。AI把它们一股脑翻出来给了我们一次性解决的机会。以前这些分散在文档、故障复盘、审计报告里的内容从来没有被系统地汇总过。4.3 我的筛选规则经过这轮磨合我总结了一套自己的AI审查结果分级法分享出来供大家参考信任AI的判断当它说的是“事实性”问题时例如一个共享对象被多线程读写、一个不存在的导入、一个数组越界这类有明确正误答案的问题AI基本不会错。参考AI的判断当它说的是“改进型”问题时例如“建议用StringBuilder”“建议拆分方法”这些方向没错但改不改要看你项目当前阶段的稳定性需求。核实AI的判断当它说的是“设计型”问题时例如“缺少事务”“循环等待”“没加缓存”。这些往往是业务约束的结果必须结合需求文档判断。4.4 一个被AI发现却被我们低估的问题这里多说一句最初老炮们把“外部接口响应未校验”排在了P2级别理由是“内网服务很稳定”。但AI的表述措辞是“该接口返回结果未进行空值判断若上游变更协议将直接导致未解包的NullPointerException”这句“若上游变更协议”点醒了我们。实际上这个外部接口就是团队另外一个项目提供的对方在三个月前就调整过字段命名当时因为是新增字段所以没暴露问题但如果未来对方把某个必填字段标记为可空我们这边直接炸。我们把这个项升到了P1这个决策不能算AI的功劳也不能算老炮的功劳而是两者讨论过程中撞出来的。5. 实操过程中的问题与排查技巧5.1 喂代码时的隐私与切分问题如果你手头的是公司内部老项目使用外部AI审查服务时务必注意数据脱敏和审查范围。我的做法是先把代码里的数据库连接地址、密钥、内部服务域名全部替换成占位符再交给AI。同时只审查业务代码不审查基础设施配置和密钥文件。切分上还有一个容易踩的坑同一个类里的多个方法被分到不同会话里审查时AI对上下文的理解会割裂。比如UserService里有validateUser和updateUser两个方法单独看updateUserAI看不出任何问题但把两个方法放在一起AI才能发现“validateUser的结果根本没被updateUser使用”这一逻辑断点。切分时尽量保持方法组完整。5.2 老项目编译环境与JDK版本导致的干扰前面提到过JDK版本不统一的问题。这次审查期间pom.xml的编译参数是Java 8但某台开发机上装了Java 17代码里有些地方用了Java 11才支持的API。AI看到源码后本能地用较新的API规范去套老代码结果产生了几条误导性建议。解决办法审查前先统一项目编译信息把它作为Context告诉AI“本项目的目标编译版本是Java 8因此基于Java 9以上的API新特性不建议引入”。这样AI的建议会更贴合项目的实际情况。如果你想让AI给你的Java代码提建议这个步骤一定要做否则它会一直拿最新规范来批评几年前的代码。5.3 如何避免AI“睁眼说瞎话”AI在我这次审查中也出现了两次硬编造一次声称某处调用了项目里不存在的方法另一次指认“某类中定义了static变量但从未使用”实际上那个变量是在父类里定义的。这类情况的应对思路是要求AI给出修复建议时顺带说明代码定位。我在会话里固定追加了这样一句话所有结论必须附上类名、方法名和行号或者整段代码引用没有定位信息的问题条目直接丢弃。加了这条约束后AI的输出严谨了很多。5.4 20个坑里的“伪修复”教训团队里有人按AI的建议修了一个“共享HashMap改为ConcurrentHashMap”的问题看似完美结果在压测时发现性能下降得很明显。原因是这个Map的读操作远高于写操作而ConcurrentHashMap的读路径在竞争激烈时也有同步开销。老炮把实现方式换成了读写锁 LinkedHashMap性能才恢复正常。这个案例说明了一个道理AI给的建议方向是对的但实现方式的权衡需要人工决定。老项目里尤其如此因为老代码往往是“某一次性能压测后形成的妥协产物”任何改动都可能导致性能回归。我整理了一个简易的选择表场景推荐做法读多写少且热点集中的Map读写锁 LinkedHashMap读写均衡且并发量高ConcurrentHashMap数据量小且允许丢失CopyOnWriteArrayList 或直接用锁块有顺序要求的并发MapConcurrentSkipListMap5.5 高效的复核会议怎么开最后一点实操建议不要拿着AI报告直接开全员评审会那样大家只会盯着报告逐条过效率极低。我建议两轮会议第一轮是“老炮闭门会”只有3名核心开发参加先把AI报告的20个问题筛一遍。对每个问题回答三个问题——这个会不会引发线上事故修的成本高不高有没有其它地方依赖当前行为得到“修/不修/缓修”的结论。第二轮是把筛选后的15个问题同步给全员但会上只讨论P0和P1P2放到日常迭代里消化。会议时间控制在一个半小时以内问题讨论基于代码示例和线上故障记录进行气氛会务实很多。6. 复盘AI审查的价值与边界这轮AI审查的实际收益超出了我最初的预期。20个坑里我们最后确认值得处理的15个中有5个是过去一年线上故障的间接原因6个会在未来某次流量突增时引爆4个属于纯粹的技术债。如果没有AI这些不显眼的坑很可能继续潜伏。更重要的是AI改变了我对老项目的维护思路。以前对于两年前的项目团队的态度是“能不动就不动”怕修出一个新问题。现在AI先把代码扫过一遍把改动影响面缩小到可预测的范围修复的恐惧感下降了一大截。技术债依然是债务但债务要还的前提是——你至少得知道债主是谁。再分享一个过程中的小体会AI给出问题报告以后最先认可的往往不是团队里最年轻的成员而是工作经验最久的那位。老炮看到“自调用导致事务失效”这类问题时会立刻联想起自己当年踩过的坑而新人对这些坑完全没有直觉。所以AI真正作用的是放大有经验者的判断半径而不是替代没有经验者的成长过程。7. 后续还能往哪扩展这套AI审查流程并不是只做一次就完结的。我目前正在做两件延伸的事情。第一件事是把筛选后的15个坑固化成审查模板。给AI配置一份持续使用的审查提示词明确要求它检查“事务自调用、并发容器选择、外部调用结果校验、异常吞没、深拷贝、日志规范”这几类老项目高发问题。下次任何同事接手老项目时都可以直接复用这套提示词做初筛。第二件事是建立代码审查的基线档案。把这次审查的代码版本、AI输出报告、人工复核意见、修复记录全部归档作为以后Review同类项目的对照标准。间隔半年后再跑一次AI审查对比新旧报告就能量化出“质量到底提升了多少”。如果你手上也有一个2022年甚至是更早的Java项目可以按我上面的流程跑一遍。不用追求审查出多少个坑关键是让AI先帮你把“可能有问题的地方”圈出来再让最懂业务的人去判断哪些是真坑、哪些只是看起来像坑。这个过程本身就是一次投入产出比极高的技术债盘点。