很多团队对 AI 编程的第一印象是“生成代码又快又便宜”。需求描述清楚后AI 几分钟就能给出一版能跑的代码甚至还能顺带生成接口文档和单元测试骨架。但 AI 编程真正进入业务系统后尤其进入 Java 后端这种对类型、事务、并发、兼容性要求都比较高的环境情况会变得完全不同。代码量确实上去了但评审、争论、返工和线上问题也跟着上去了团队很容易陷入“效率看起来很高、交付质量不确定”的尴尬状态。真正的问题不在于代码生成得够不够快而在于代码生成完之后团队有没有能力判断、验证并维护它。当 AI 让编码变廉价软件工程的瓶颈会快速转移到两个容易被低估的环节一个是决策与争论另一个是可靠性。这篇文章想围绕这个判断用一个可落地的实战场景把问题讲透而不是停留在“AI 很强大”这类泛泛而谈的层面。这个场景代号是 Maven Clinic。它不是一个开源工具也不是某个官方项目而是一类非常典型的 Maven 多模块 Java 后端业务系统业务上类似诊所预约、病历管理、医生排班和支付回调。选择这个场景是因为医疗业务对正确性、并发控制和审计有天然高要求把 AI 生成的代码放进这种环境可靠性问题会暴露得更清晰也更容易总结出通用工程方法。读完后你会得到一套可复用的方法论AI 生成的代码该怎么评审争论时间怎么压缩可靠性测试怎么落地以及 Maven 项目中的依赖管理、CI 流水线、测试门禁如何与 AI 协作避免团队陷入“生成越多、返工越多”的恶性循环。1. 这篇文章真正要解决的问题先说一个很常见的场景。团队引入 AI 编程助手之后开发同学确实能在更短时间内写出大量代码。需求澄清完AI 能生成 Service、Controller、Mapper甚至还能给出乐观锁的实现方式。代码量上来之后Code Review 的成本也跟着上来了。很多评审会议从“看一个人写的代码”变成“看 AI 写的代码同时还要质疑人为什么评审通过了”。团队成员对同一段 AI 代码往往有不同意见有人认为并发控制可以接受有人认为必须上分布式锁有人认为 AI 生成的 SQL 没问题有人指出它忽略了索引和最左前缀原则。争论变得频繁却又很难得出结论。与此同时可靠性问题变得更加隐蔽。AI 生成的代码通常以“编译通过”为主要目标不会主动感知业务上下文。它可能忽略事务边界忘记处理唯一键冲突在循环里查询数据库对空值假设过于乐观。这些问题在测试环境不容易暴露一旦线上出问题往往就是数据错乱或资金异常。业务越复杂AI 代码的“默认假设”就越容易和真实业务相冲突。所以这篇文章要解决的不是“怎么用 AI 写更多代码”而是为什么 AI 编码变廉价后争论和可靠性会成为新的瓶颈在 Maven 多模块的 Java 项目中如何给 AI 生成的代码建立评审与协作机制如何设计可靠性测试避免 AI 生成代码在线上暴露问题如何用工程规范、测试基线、依赖管理和 CI 流水线把 AI 编码真正融入可靠交付链路。适合读者包括Java 后端工程师、正在推广 AI 编程的技术负责人、对可靠性系统设计感兴趣的架构师以及所有觉得“AI 代码看起来靠谱但不敢轻易上线”的开发者。如果你正在做 AI Agent、AI 编码工具链相关的探索这篇文章也能帮你从工程视角理解 AI 产出的边界。2. 编码变廉价后瓶颈为什么转移了2.1 成本结构的变化在没有 AI 编码之前开发团队最明显的瓶颈是“写代码慢”。一个中等复杂度的 CRUD 接口从建表到 Service 再到 Controller往往要半天甚至一天。这种情况下设计评审反而不需要拖太久因为就算设计得再好代码也要靠人一行行写完编码本身就是最大成本项。引入 AI 之后情况直接反转。CRUD 代码生成从半天压缩到几分钟写代码不再是主要成本但其他环节并没有跟着变快。设计取舍仍然需要人来做Code Review 仍然需要人来看测试和可靠性验证仍然需要人来搭线上问题定位和返工仍然需要人来承担。需求越复杂代码量越大这些非生成类工作的占比就越高。这里有一个核心结论AI 压缩的是“写代码”的显性成本而软件工程中真正决定质量的部分——判断、验证、维护——并没有被压缩反而因为代码量的增加被放大了。2.2 争论为什么变多AI 生成代码通常不是“唯一解”。同一个需求AI 可能给出三种实现第一种用 synchronized第二种用乐观锁第三种用 Redis 分布式锁。三种看着都能跑但业务含义完全不同带来的故障影响面也不一样。团队被迫更频繁地做技术决策如果系统里缺少明确的决策机制比如规范文档、ADR 架构决策记录、责任明确的架构负责人那么每次决策都会变成争论。更麻烦的是AI 可以快速生成多套候选方案这会让讨论对象变多而不是变少。过去团队可能在两个方案里二选一现在面对五个甚至八个候选版本每个人都有倾向性争论成本自然水涨船高。争论本身不是坏事但低质量的争论会大量消耗团队精力最后得出结论时大家已经疲惫反而放松了对可靠性的审查。2.3 可靠性为什么变难一块代码在 A 场景是对的在 B 场景可能就错了因为它没有项目全貌。AI 不知道你的表数据量有多大不知道哪些接口需要幂等不知道事务里不能包含远程调用不知道 MyBatis 的二级缓存曾经出过什么事故。所以可靠性问题会从传统的“编码错误”转移到“设计默认值错误”。AI 代码看着正常但它的默认假设比如“请求一定是一次性的”“数据量很小”“没有并发写入”很可能和你的业务冲突。可靠性测试要做的事情恰恰是把这些默认假设暴露出来。没有可靠性测试时AI 代码的“能跑”只是表象有了可靠性测试才能判断它是真的满足业务约束还是仅仅在编译和 happy path 上侥幸通过。这也是为什么我会说编码变廉价之后可靠性会成为新瓶颈。3. Maven Clinic 项目背景与 AI 编码初体验3.1 项目设定为了把问题具体化假设一个 Maven 多模块的 Java 项目代号 Maven Clinic。业务上它提供诊所预约、病历管理、医生排班、支付回调等功能。技术栈通常包括 JDK 17 或更高版本、Spring Boot、MyBatis 或 Spring Data JPA、MySQL以及 Redis 用于缓存和分布式锁。模块划分一般长这样maven-clinic/ ├── clinic-common/ ├── clinic-patient/ ├── clinic-appointment/ ├── clinic-medical-record/ ├── clinic-payment/ └── clinic-gateway/这类业务系统对可靠性有天然高要求不能重复预约病历不能串号支付回调需要幂等所有操作需要留审计日志。你会发现这些约束恰好是 AI 生成代码时最容易忽略的部分因此 Maven Clinic 是一个很适合观察 AI 编码真实影响的项目。3.2 用 AI 编码的典型方式团队把 AI 编程助手接入 IDE 和命令行之后典型用法分三类第一类按接口文档生成 CRUD 代码第二类生成单元测试和接口测试骨架第三类在已有代码里补日志、异常处理、状态流转。从效率看前两周通常体感很好CRUD 模块的产出速度明显提升接口文档和测试骨架也省了很多时间。尤其是建表语句、实体类、Mapper 接口这类重复性工作AI 完成度很高。但进入联调和评审阶段后问题开始出现。AI 在不同会话里生成的代码命名习惯会飘有时候写 AppointmentService有时候写 AppointmentManager包名和组织方式需要人工整理。更关键的是AI 对业务规则理解得过于表面。一个预约接口AI 只做了“插一条记录”的常规操作没有判断医生当天是否已经排满也没有对同一个患者同一时间段的重复预约做防重。3.3 初体验带来的反差这种反差非常有代表性AI 生成的代码解决了“有没有”的问题但“对不对”和“稳不稳”仍然完全依赖团队的人力投入。如果你的团队原本就没有严格的评审和测试体系AI 编码会让问题加速放大。相反如果团队已经把业务契约、测试基线、命名规范、依赖版本管理都定义得很清楚AI 编码反而是很好的放大器它在框架内生成代码你只需要检查边界和异常分支是否覆盖到位。Maven Clinic 项目里的真实体会是AI 能显著提升 CRUD 和测试骨架的产出速度但可靠性设计不能指望 AI。可靠性靠的仍然是清晰业务规则、严格评审机制和可执行测试门禁。4. “看起来对”的代码可靠性在哪一层失效4.1 三种隐蔽失效模式结合 Maven Clinic 这类业务AI 代码最常见的可靠性失效有三种。第一种是编译通过但契约错误。AI 生成的接口方法签名可能不是团队约定的 DTO/VO 结构或者返回值取舍有问题比如应该返回业务错误码和提示信息AI 可能直接抛异常。第二种是并发场景被默认忽略。AI 默认把一次预约请求当作独立事件不会主动考虑重复提交、并发下单、状态覆盖这在普通 CRUD 里问题不大在预约、支付场景就是事故点。第三种是异常处理过于笼统。AI 生成的 catch 块经常是catch (Exception e) { return Result.error(系统错误); }丢了原始异常也没有日志。一旦线上出错排查成本极高。这三种失效模式有一个共同点它们不会在编译期暴露也不会在简单测试里暴露只有业务跑起来、数据积累到一定量、并发一旦上来才会真正显现。4.2 示例AI 生成的预约接口下面是一段 AI 很可能会生成的预约接口核心代码看起来没什么问题但仔细看会发现可靠性风险。这段代码能跑但没有考虑同一个患者在同一时间段重复预约也没有考虑医生排班冲突。两个请求同时进来数据库里可能出现两条记录。更麻烦的是数据库表可能已经建了唯一索引但 AI 不知道所以也没写冲突处理逻辑。// 文件路径clinic-appointment/src/main/java/com/clinic/appointment/service/AppointmentService.java Service public class AppointmentService { Resource private AppointmentMapper appointmentMapper; public Appointment createAppointment(Long patientId, Long doctorId, LocalDateTime startTime) { Appointment appointment new Appointment(); appointment.setPatientId(patientId); appointment.setDoctorId(doctorId); appointment.setStartTime(startTime); appointment.setStatus(BOOKED); appointmentMapper.insert(appointment); return appointment; } }4.3 修正后的可靠性版本如果要求 AI 带着业务规则生成代码或者人工在评审时补齐约束代码应该是下面这样。这个版本多了三样东西业务状态前置校验、事务边界、唯一约束冲突处理。它不是 AI 无法生成而是 AI 不会主动去考虑关键在于人要在评审时把这些要求加进去。// 文件路径clinic-appointment/src/main/java/com/clinic/appointment/service/AppointmentService.java Service public class AppointmentService { Resource private AppointmentMapper appointmentMapper; Resource private DoctorScheduleMapper doctorScheduleMapper; Transactional public Appointment createAppointment(Long patientId, Long doctorId, LocalDateTime startTime) { // 1. 参数校验时间不能为空不能是过去时间 if (startTime null || startTime.isBefore(LocalDateTime.now())) { throw new BusinessException(预约时间不能为空且不能早于当前时间); } // 2. 医生排班校验 int scheduleCount doctorScheduleMapper.countByDoctorAndTime(doctorId, startTime); if (scheduleCount 0) { throw new BusinessException(医生在该时间段没有排班); } // 3. 防重复预约数据库唯一约束 冲突捕获 try { Appointment appointment new Appointment(); appointment.setPatientId(patientId); appointment.setDoctorId(doctorId); appointment.setStartTime(startTime); appointment.setStatus(BOOKED); appointmentMapper.insert(appointment); return appointment; } catch (DuplicateKeyException e) { throw new BusinessException(请勿重复预约同一时间段, e); } } }这一节想强调的可靠性和 AI 编码的关系是可靠性不是“生成出来的”而是“设计出来并在测试中验证出来的”。如果没有可靠性测试AI 代码即使修正也可能在下一次生成时重新引入同样的问题。所以与其花时间反复审查 AI 生成代码不如把业务契约和测试先写好让 AI 在契约框架内生成代码。5. 争论成为瓶颈如何降低 AI 代码的评审成本5.1 减少“伪分歧”AI 编码会让争论变多但并不是所有争论都有价值。命名风格、缩进方式、日志格式、DTO 放哪个包这类争论本质上是伪分歧只要团队规范明确就不该进入评审会议。建议用一份轻量的编码规范文档解决伪分歧。Java 项目可以从下面几项开始。规范项约定示例说明命名Service / Manager / Helper 使用指南避免同类组件产生多个命名异常业务异常使用 BusinessException禁止在 catch 中吞掉异常事务Transactional 只在 Service 入口使用避免在 Controller 层添加事务日志关键操作打印入参、出参、耗时方便线上问题定位依赖版本统一由 BOM 管理禁止在子模块写死版本号5.2 用 ADR 收敛“真实分歧”真正需要争论的是事务边界、幂等策略、缓存一致性、锁方案这一类技术决策。这些争论不能回避但可以用 ADR也就是 Architecture Decision Record把讨论前移。规则是凡是影响全局的技术方案先写一页 ADR说明背景、备选方案、决策和影响范围。有了 ADRAI 生成的多个候选版本就只是“待考察方案”决策依据已经提前定好评审时不需要再重新吵一遍。在 Maven Clinic 项目里我们通常要求涉及状态机流转、支付回调、跨模块事务的方案都先提交 ADR。比如“预约状态从 BOOKED 到 COMPLETED 的流转是否需要分布式锁”这类问题讨论清楚后AI 后续生成的代码会被约束在一个明确框架里争论自然减少。5.3 PR 模板约束 AI 产出另一个非常有效的手段是把评审要求前置到 PR 模板里。AI 生成代码后开发者提交 PR 前必须按模板回答清楚。这个模板的作用是把评审者的注意力从“格式和命名”转移到“可靠性和影响面”。AI 生成的代码也可以在这个模板下逐步补齐信息而不是让评审者从零开始猜。## PR 说明 - 需求描述 - 涉及模块 - 数据库变更 - [ ] 无 MySQL 变更 - [ ] 有变更已同步 DDL - 可靠性自检 - [ ] 重复提交是否处理 - [ ] 并发场景是否考虑 - [ ] 失败时是否有回滚 - [ ] 是否补充了单元测试 - 是否需要扩容 / 配置变更 - 联调范围6. 可靠性设计从单元测试到 Maven 构建流水线6.1 可靠性测试的分层AI 编码时代可靠性测试不再是可有可无的收尾工作而是整个交付的核心。建议从四个层面设计可靠性验证。单元测试覆盖核心 Service 的状态流转和异常分支集成测试验证 Spring 容器、数据库、Redis 的真实协作契约测试保证服务间接口字段稳定并发和性能测试对预约、支付等关键链路做并发模拟。每一层都有它存在的意义缺一层AI 代码的问题就会晚一步暴露。6.2 Maven 中的测试插件配置在 Maven 多模块项目中测试分为单元测试和集成测试。通常用 Surefire 跑单元测试用 Failsafe 跑集成测试。下面是一个常见的 pom.xml 配置片段可以直接用在 Maven Clinic 这类项目中。这里的版本号是示例实际使用请根据你的项目 JDK 版本和 Maven 版本确认兼容性重点是理解 Surefire 管单元测试、Failsafe 管集成测试、JaCoCo 收集覆盖率。!-- 文件路径父 pom.xml 的 build 节点 -- build plugins !-- 单元测试mvn test -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version3.2.5/version configuration includes include**/*Test.java/include /includes /configuration /plugin !-- 集成测试mvn verify -- plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version3.2.5/version executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions configuration includes include**/*IT.java/include /includes /configuration /plugin !-- 覆盖率mvn verify 后生成报告 -- plugin groupIdorg.jacoco/groupId artifactIdjacoco-maven-plugin/artifactId version0.8.12/version executions execution goals goalprepare-agent/goal /goals /execution execution idreport/id phaseverify/phase goals goalreport/goal /goals /execution /executions /plugin /plugins /build6.3 示例并发测试如何“逼出”AI 代码问题前面提到的预约重复提交问题靠人工 Code Review 可能发现不了但一个简单的并发测试就可以让问题暴露出来。下面是基于 JUnit 5 的并发测试示例模拟 10 个线程同时为同一个患者预约同一个时间段。这个测试的价值不在于代码有多复杂而在于它定义了“正确性”同一患者同一时间段只能有一个预约。这个契约如果写进测试AI 生成的代码再出现重复插入CI 就会直接报红。// 文件路径clinic-appointment/src/test/java/com/clinic/appointment/service/AppointmentServiceTest.java SpringBootTest class AppointmentServiceTest { Autowired private AppointmentService appointmentService; Autowired private AppointmentMapper appointmentMapper; Test void testConcurrentCreateAppointment_shouldNotDuplicate() throws Exception { Long patientId 1001L; Long doctorId 2001L; LocalDateTime startTime LocalDateTime.of(2025, 6, 1, 10, 0); int threadCount 10; ExecutorService executor Executors.newFixedThreadPool(threadCount); CountDownLatch ready new CountDownLatch(threadCount); CountDownLatch start new CountDownLatch(1); CountDownLatch done new CountDownLatch(threadCount); AtomicInteger successCount new AtomicInteger(); AtomicInteger failCount new AtomicInteger(); for (int i 0; i threadCount; i) { executor.submit(() - { ready.countDown(); try { start.await(); appointmentService.createAppointment(patientId, doctorId, startTime); successCount.incrementAndGet(); } catch (Exception e) { failCount.incrementAndGet(); } finally { done.countDown(); } }); } ready.await(); start.countDown(); done.await(10, TimeUnit.SECONDS); executor.shutdownNow(); long total appointmentMapper.countByPatientAndTime(patientId, startTime); assertEquals(1, total