AI 辅助 Java 开发实战：我用 Codex 写完了一个生产级项目

AI 辅助 Java 开发实战我用 Codex 写完了一个生产级项目不是 AI 替代程序员而是会 AI 的程序员替代不会 AI 的程序员。一、介绍2024-2025 年AI 编码工具彻底改变了我的开发方式。从最初的好奇尝试到现在的日常依赖——我的代码量中约 60% 由 AI 生成但我花在思考和审查上的时间反而增加了 40%。这不是一篇工具教程。这是一篇实战复盘记录我用 AI 辅助完成一个生产级 Java 项目的真实经验踩过的坑、总结出的方法论、以及我认为每个 Java 开发者都应该知道的 AI 编码心法。二、选对工具我的 AI 编码工具箱目前主流的 AI 编码工具有几个阵营工具适合场景我的评价GitHub Copilot日常补全、单元测试补全准确率最高但复杂逻辑生成不稳定Codex CLI / Claude Code复杂功能、重构、架构设计理解上下文能力强适合大块代码生成Cursor / Windsurf全流程开发Agent 模式强但 Java 项目支持略弱Continue (VSCode 插件)自定义模型接入灵活可接本地模型适合隐私敏感场景如果你主要写 Java我的建议是Copilot 做主补全 Codex/Claude 做复杂功能生成两者互补。三、实战项目背景一个真实的微服务模块订单履约中心Order Fulfillment Center技术栈Spring Boot 3.2 MyBatis-Plus RocketMQ Redis核心功能订单拆分、库存预占、物流路由、状态机流转代码量约 1.5 万行下面我用这个项目的真实片段展示 AI 到底能帮到什么程度。四、AI 编码的 5 个实战场景场景 1生成 POJO 和基础 CRUD —— 最快最稳这是 AI 最擅长的——重复、规律、模板化的工作。我的提示词生成一个订单明细表 OrderItem 的实体类包含字段 id, orderId, skuId, productName, quantity, price, totalAmount, createdAt, updatedAt 使用 LombokMyBatis-Plus 注解继承 BaseEntity 同时生成 Mapper 接口和 Service 类AI 输出节选DataEqualsAndHashCode(callSupertrue)TableName(order_item)publicclassOrderItemextendsBaseEntity{TableId(typeIdType.AUTO)privateLongid;privateLongorderId;privateLongskuId;privateStringproductName;privateIntegerquantity;TableField(price)privateBigDecimalprice;privateBigDecimaltotalAmount;privateLocalDateTimecreatedAt;privateLocalDateTimeupdatedAt;}MapperpublicinterfaceOrderItemMapperextendsBaseMapperOrderItem{}ServiceRequiredArgsConstructorpublicclassOrderItemServiceextendsServiceImplOrderItemMapper,OrderItem{privatefinalOrderItemMapperorderItemMapper;publicListOrderItemgetByOrderId(LongorderId){returnlambdaQuery().eq(OrderItem::getOrderId,orderId).list();}TransactionalpublicvoidbatchSave(ListOrderItemitems){saveBatch(items);}}实战体会这种代码 AI 生成基本不需要改直接复制粘贴就行。单文件生成准确率 95%。场景 2复杂业务逻辑 —— AI 做框架你做细节这是最考验 prompt 能力的场景。看一个订单拆分逻辑我的提示词实现订单拆分逻辑 1. 订单可能包含多个商品OrderItem 2. 根据商品所属的仓库warehouseId进行拆分 3. 同一仓库的商品合并为一个子订单 4. 每个子订单需要计算商品总金额、总数量 5. 如果某个商品库存不足抛出 BusinessException(商品xxx库存不足) 6. 拆分完成后保存子订单并发送 RocketMQ 消息 用策略模式实现考虑到未来可能有其他拆分规则AI 生成了一个完整的SplitStrategy接口 WarehouseSplitStrategy实现类。我只需要调整仓库分配的细节逻辑。// AI 生成的核心策略ComponentpublicclassWarehouseSplitStrategyimplementsSplitStrategy{OverridepublicListSubOrdersplit(Orderorder,ListOrderItemitems){// 按 warehouseId 分组MapLong,ListOrderItemgroupeditems.stream().collect(Collectors.groupingBy(OrderItem::getWarehouseId));// 每组生成一个子订单returngrouped.entrySet().stream().map(entry-createSubOrder(order,entry.getKey(),entry.getValue())).collect(Collectors.toList());}privateSubOrdercreateSubOrder(Orderorder,LongwarehouseId,ListOrderItemitems){SubOrdersubOrdernewSubOrder();subOrder.setParentOrderId(order.getId());subOrder.setWarehouseId(warehouseId);subOrder.setStatus(SubOrderStatus.PENDING);BigDecimaltotalAmountitems.stream().map(OrderItem::getTotalAmount).reduce(BigDecimal.ZERO,BigDecimal::add);subOrder.setTotalAmount(totalAmount);subOrder.setTotalQuantity(items.stream().mapToInt(OrderItem::getQuantity).sum());subOrder.setItems(items);returnsubOrder;}}实战体会80% 的骨架代码 AI 能写对。但库存预占的锁逻辑、事务边界、异常处理的粒度——这些需要我亲手加。AI 不擅长你不知道它不知道的边界条件。场景 3单元测试 —— AI 是真香写单元测试是大部分开发者的痛点AI 在这块是超强辅助。我的提示词为 OrderSplitService.split(order) 方法写单元测试 1. 用 Mockito JUnit 5 2. 覆盖正常拆分场景 3. 覆盖商品跨仓库拆分场景 4. 覆盖库存不足异常场景 5. 覆盖订单为空异常场景 6. 验证 RocketMQ 消息是否正确发送AI 生成的测试代码直接可运行度很高ExtendWith(MockitoExtension.class)classOrderSplitServiceTest{MockprivateOrderItemServiceorderItemService;MockprivateRocketMQProducerrocketMQProducer;InjectMocksprivateOrderSplitServiceorderSplitService;TestvoidshouldSplitOrderByWarehouse(){// givenOrderordernewOrder();order.setId(1L);ListOrderItemitemsArrays.asList(createItem(1L,SKU-A,1001L,newBigDecimal(99.00),2),createItem(2L,SKU-B,1002L,newBigDecimal(199.00),1),createItem(3L,SKU-C,1001L,newBigDecimal(59.00),1));// whenListSubOrdersubOrdersorderSplitService.split(order,items);// thenassertThat(subOrders).hasSize(2);SubOrderwarehouse1001subOrders.stream().filter(s-s.getWarehouseId().equals(1001L)).findFirst().orElseThrow();assertThat(warehouse1001.getItems()).hasSize(2);// SKU-A SKU-CassertThat(warehouse1001.getTotalAmount()).isEqualByComparingTo(newBigDecimal(257.00));SubOrderwarehouse1002subOrders.stream().filter(s-s.getWarehouseId().equals(1002L)).findFirst().orElseThrow();assertThat(warehouse1002.getItems()).hasSize(1);// SKU-Bverify(rocketMQProducer).send(any(Message.class));}}实战体会测试覆盖率从 45% 飙升到 92%。AI 生成的测试覆盖面广各种边界情况都考虑到了。我只需要检查断言是否符合预期逻辑。写测试的时间从 40% 降到 10%。场景 4代码审查 —— AI 是第二双眼睛把代码贴给 AI 做 Code Review// 这是我写的原始代码publicOrdercreateOrder(CreateOrderRequestrequest){OrderordernewOrder();order.setUserId(request.getUserId());order.setTotalAmount(request.getItems().stream().map(i-i.getPrice().multiply(BigDecimal.valueOf(i.getQuantity()))).reduce(BigDecimal.ZERO,BigDecimal::add));orderMapper.insert(order);for(OrderItemitem:request.getItems()){item.setOrderId(order.getId());orderItemMapper.insert(item);}returnorder;}AI Review 结果⚠️事务问题orderMapper.insertorderItemMapper.insert没有事务保护中间失败会导致数据不一致⚠️金额精度BigDecimal乘法要用setScale(2, RoundingMode.HALF_UP)确保精度⚠️批量插入性能逐条 insert 在大数据量下慢建议用insertBatch⚠️空指针风险request.getItems()可能为 null修正后的代码Transactional(rollbackForException.class)publicOrdercreateOrder(CreateOrderRequestrequest){if(CollectionUtils.isEmpty(request.getItems())){thrownewBusinessException(订单商品不能为空);}OrderordernewOrder();order.setUserId(request.getUserId());order.setTotalAmount(request.getItems().stream().map(i-i.getPrice().multiply(BigDecimal.valueOf(i.getQuantity())).setScale(2,RoundingMode.HALF_UP)).reduce(BigDecimal.ZERO,BigDecimal::add).setScale(2,RoundingMode.HALF_UP));orderMapper.insert(order);ListOrderItemorderItemsrequest.getItems().stream().map(item-{OrderItemorderItemnewOrderItem();BeanUtils.copyProperties(item,orderItem);orderItem.setOrderId(order.getId());returnorderItem;}).collect(Collectors.toList());orderItemService.saveBatch(orderItems);returnorder;}实战体会AI Review 发现了我忽略的 4 个问题。我现在任何代码合并前都会让 AI 过一遍比自己两眼一抹黑看三遍管用。场景 5重构老代码 —— AI 是真正的救星一个 300 行的OrderService方法if-else 嵌套 5 层。我的提示词这个方法太长了帮我重构 1. 提取每个分支为独立方法 2. 用策略模式替代 if-else 3. 状态流转用枚举 状态机 4. 保持原有业务逻辑不变 5. 每个新方法都要有 JavaDocAI 把 300 行拆成了OrderStateMachine— 状态机引擎OrderStateHandler接口 5 个实现类OrderEventPublisher— 事件发布代码量从 300 行变成了 600 行但可维护性翻了几倍。后来需求变更加一个新状态只需要加一个 Handler 类零改动旧代码。五、我的 AI 编码心法建议收藏心法 1写好 Prompt 比写好代码更重要❌ 差的 prompt写一个订单服务 ✅ 好的 prompt 写一个 OrderService需要 1. 创建订单校验库存→扣库存→保存订单→发消息 2. 取消订单校验状态→回滚库存→更新状态→发消息 3. 使用 Transactional 管理事务 4. 异常使用 BusinessException 5. 用 MyBatis-Plus 操作数据库原则给 AI 足够的信息但不要让它猜。心法 2分步生成不要一次搞定不要这样写一个完整的订单履约系统要这样生成 Order 实体类生成 OrderMapper生成创建订单的业务逻辑生成单元测试AI 在单步任务上准确率高多步长任务容易跑偏。心法 3AI 生成人工审查缺一不可这是我给自己定的铁律AI 写 → 我审 → 我改 → AI Review → 合入每个环节不可跳过。AI 生成的代码至少有一个隐晦的 bug这是我几十次实战验证的结论。可能是竞态条件、事务边界、或者是 JDK 版本的 API 差异。心法 4让 AI 做擅长的事AI 擅长AI 不擅长生成样板代码架构决策写单元测试领域建模代码审查找漏性能瓶颈定位重构提取方法全局一致性保证解释遗留代码安全漏洞防护生成文档注释业务规则挖掘六、真实收益数据这个项目做完后我统计了一下指标使用 AI 前使用 AI 后提升单功能开发周期2.5 天1 天60% ↓测试覆盖率45%92%104% ↑线上 Bug 率平均 3 个/版本0 个追零代码重复率18%6%67% ↓最意外的是Bug 率下降——不是因为 AI 写的代码没 bug而是因为我多出来的时间全用来做 Code Review 和测试了。七、总结AI 不会取代你但会用 AI 的开发者会取代你。我自己也走过弯路——一开始觉得 AI 写的代码不放心每行都自己改后来发现太浪费时间开始信任 AI 处理模板化工作现在找到了平衡点AI 做执行我做决策。这不是偷懒而是把精力花在真正有价值的事上——理解业务、设计架构、保障质量。最后送各位三句话不要抗拒 AI— 学起来把它变成你的超级实习生不要盲信 AI— 它写的代码你要负全责不要停止思考— AI 能做 80% 的工作但那 20% 的决策和判断才是你的价值互动话题你平时用 AI 写代码吗有没有什么神 prompt 或者踩坑经历评论区见