文章目录
- 一、项目背景：我们要构建什么？
-
- [1.1 业务需求](#1.1 业务需求)
- [1.2 技术栈](#1.2 技术栈)
- [二、第一阶段：项目骨架搭建（Plan + Agent）](#二、第一阶段：项目骨架搭建（Plan + Agent）)
-
- [2.1 项目结构设计](#2.1 项目结构设计)
- [2.2 依赖配置生成](#2.2 依赖配置生成)
- [三、第二阶段：订单核心接口实现（Agent + Claude 3.5 Sonnet）](#三、第二阶段：订单核心接口实现（Agent + Claude 3.5 Sonnet）)
-
- [3.1 数据库表设计](#3.1 数据库表设计)
- [3.2 创建订单接口实现](#3.2 创建订单接口实现)
- [四、第三阶段：分布式事务处理（Debug + Plan）](#四、第三阶段：分布式事务处理（Debug + Plan）)
-
- [4.1 问题场景分析](#4.1 问题场景分析)
- [4.2 Seata 集成实现](#4.2 Seata 集成实现)
- [五、第四阶段：接口优化与测试（Ask + Agent）](#五、第四阶段：接口优化与测试（Ask + Agent）)
-
- [5.1 性能优化建议](#5.1 性能优化建议)
- [5.2 单元测试生成](#5.2 单元测试生成)
- 六、第五阶段：微服务拆分（WorkTree）
-
- [6.1 多任务并行开发](#6.1 多任务并行开发)
- [6.2 服务间调用优化](#6.2 服务间调用优化)
- 七、完整工作流总结
-
- [7.1 各阶段用时统计](#7.1 各阶段用时统计)
- [7.2 最佳实践总结](#7.2 最佳实践总结)
- 八、经验与教训
-
- [8.1 踩过的坑](#8.1 踩过的坑)
- [8.2 效率倍增技巧](#8.2 效率倍增技巧)
- 心得
当 AI 遇见 Spring Boot，当 Cursor 碰撞微服务------这不仅是效率的提升，更是开发范式的变革。本文将通过一个完整的电商订单服务案例，带你体验从零到一、从单体到微服务的全流程 AI 辅助开发。
一、项目背景：我们要构建什么？
1.1 业务需求
开发一个电商订单服务核心模块，包含：
- 订单核心功能：创建订单、取消订单、查询订单
- 库存联动：下单扣库存、取消退库存
- 支付回调：支付成功更新订单状态
- 分布式事务：保证最终一致性
1.2 技术栈
yaml
基础框架: Spring Boot 3.2 + Spring Cloud 2023
数据库: MySQL 8.0 + MyBatis-Plus
消息队列: RocketMQ
分布式事务: Seata
服务注册: Nacos
接口文档: OpenAPI 3.0二、第一阶段：项目骨架搭建（Plan + Agent）
2.1 项目结构设计
👉 在 Plan 模式输入：
"设计一个电商订单服务的项目结构，使用 Spring Boot 3.2，包含以下模块：
- order-api：接口定义层
- order-service：业务逻辑层
- order-dao：数据访问层
- order-common：通用工具类
- order-client：Feign 客户端
要求符合 DDD 分层思想"AI 生成的推荐结构：
order-parent
├── order-api
│ ├── controller
│ ├── dto
│ └── vo
├── order-service
│ ├── service
│ ├── service/impl
│ └── converter
├── order-dao
│ ├── entity
│ ├── mapper
│ └── repository
├── order-common
│ ├── exception
│ ├── util
│ └── constant
└── order-client
├── feign
└── fallback2.2 依赖配置生成
👉 在 Agent 模式输入：
"生成 order-parent 的 pom.xml，包含：
- Spring Boot 3.2.0
- Spring Cloud 2023.0.0
- MyBatis-Plus 3.5.5
- RocketMQ Spring Boot Starter
- Seata Spring Cloud Starter
- Nacos Discovery
- OpenAPI 3.0"三、第二阶段：订单核心接口实现（Agent + Claude 3.5 Sonnet）
3.1 数据库表设计
👉 在 Plan 模式输入：
"设计订单服务的数据库表，包含：
- 订单主表 order_info
- 订单明细表 order_item
- 订单流水表 order_log
要求：
1. 包含常用的时间字段（create_time, update_time）
2. 订单状态用枚举（0-待支付，1-已支付，2-已取消，3-已完成）
3. 考虑分库分表场景"生成的表结构示例：
sql
CREATE TABLE `order_info` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`order_no` varchar(32) NOT NULL COMMENT '订单号',
`user_id` bigint(20) NOT NULL COMMENT '用户ID',
`total_amount` decimal(10,2) NOT NULL COMMENT '订单总金额',
`status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0-待支付 1-已支付 2-已取消 3-已完成',
`pay_time` datetime DEFAULT NULL COMMENT '支付时间',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
UNIQUE KEY `idx_order_no` (`order_no`),
KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';3.2 创建订单接口实现
👉 在 Agent 模式输入：
"实现创建订单接口：
POST /api/orders
请求体：{userId, items: [{skuId, quantity, price}], addressId}
要求：
1. 生成唯一订单号（规则：时间戳+随机数+用户ID后四位）
2. 校验商品库存（调用库存服务）
3. 计算订单总金额
4. 保存订单主表和明细表
5. 发送订单创建消息到 RocketMQ
6. 统一异常处理
7. 使用事务注解"核心代码片段：
java
@Service
@Slf4j
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
private final OrderMapper orderMapper;
private final OrderItemMapper orderItemMapper;
private final StockServiceClient stockServiceClient;
private final RocketMQTemplate rocketMQTemplate;
private final IdGenerator idGenerator;
@Override
@Transactional(rollbackFor = Exception.class)
public OrderVO createOrder(OrderCreateRequest request) {
// 1. 生成订单号
String orderNo = idGenerator.generateOrderNo(request.getUserId());
// 2. 校验库存
List<StockCheckRequest> stockChecks = request.getItems().stream()
.map(item -> new StockCheckRequest(item.getSkuId(), item.getQuantity()))
.collect(Collectors.toList());
StockCheckResult stockResult = stockServiceClient.checkStock(stockChecks);
if (!stockResult.isSuccess()) {
throw new BusinessException("库存不足：" + stockResult.getFailedSkus());
}
// 3. 计算金额
BigDecimal totalAmount = request.getItems().stream()
.map(item -> item.getPrice().multiply(new BigDecimal(item.getQuantity())))
.reduce(BigDecimal.ZERO, BigDecimal::add);
// 4. 保存订单
OrderInfo order = new OrderInfo();
order.setOrderNo(orderNo);
order.setUserId(request.getUserId());
order.setTotalAmount(totalAmount);
order.setStatus(OrderStatus.PENDING_PAYMENT.getCode());
orderMapper.insert(order);
// 5. 保存订单明细
List<OrderItem> orderItems = request.getItems().stream()
.map(item -> {
OrderItem orderItem = new OrderItem();
orderItem.setOrderId(order.getId());
orderItem.setSkuId(item.getSkuId());
orderItem.setQuantity(item.getQuantity());
orderItem.setPrice(item.getPrice());
return orderItem;
})
.collect(Collectors.toList());
orderItemMapper.batchInsert(orderItems);
// 6. 发送消息
OrderCreatedEvent event = new OrderCreatedEvent(orderNo, request.getUserId(), stockChecks);
rocketMQTemplate.convertAndSend("order-created-topic", event);
return convertToVO(order, orderItems);
}
}四、第三阶段：分布式事务处理（Debug + Plan）
4.1 问题场景分析
👉 在 Debug 模式输入：
"当前流程有问题：
1. 创建订单成功
2. 扣减库存失败
3. 数据库已经保存了订单
如何解决这种分布式事务问题？"AI 分析结果：
问题分析：
- 这是典型的分布式事务场景
- 订单服务和库存服务跨数据库、跨应用
- 需要保证最终一致性
解决方案对比：
1. Seata AT 模式：适合对一致性要求高的场景
2. RocketMQ 事务消息：适合最终一致性场景
3. 本地消息表：传统可靠方案4.2 Seata 集成实现
👉 在 Plan 模式输入：
"设计使用 Seata AT 模式解决订单创建和库存扣减的分布式事务问题，给出具体的代码实现方案"关键配置：
java
@Configuration
public class SeataConfig {
@Bean
@ConditionalOnMissingBean
public GlobalTransactionScanner globalTransactionScanner() {
return new GlobalTransactionScanner("order-service", "my_test_tx_group");
}
}
@Service
@Slf4j
public class OrderServiceImpl {
@Override
@GlobalTransactional(name = "create-order-tx", rollbackFor = Exception.class)
public OrderVO createOrder(OrderCreateRequest request) {
// 1. 创建订单（本地事务）
OrderVO order = saveOrder(request);
// 2. 扣减库存（远程调用，参与全局事务）
stockServiceClient.deductStock(request.getItems());
// 3. 发送消息（如果失败，全局回滚）
sendOrderMessage(order);
return order;
}
}五、第四阶段：接口优化与测试（Ask + Agent）
5.1 性能优化建议
👉 在 Ask 模式输入：
"订单查询接口 GET /api/orders/{id} 目前响应时间 200ms，如何优化到 50ms 以内？"AI 优化方案：
yaml
优化策略：
1. 数据库层面：
- 添加合适的索引
- 使用覆盖索引查询
2. 缓存层面：
- Redis 缓存热点订单数据
- 缓存订单详情 30 分钟
3. 代码层面：
- 延迟加载订单明细
- 并行查询（订单信息 + 用户信息）
4. 架构层面：
- 读写分离
- 数据异构到 ES5.2 单元测试生成
👉 在 Agent 模式输入：
"为 OrderServiceImpl 的 createOrder 方法生成单元测试，包含：
- 正常创建订单场景
- 库存不足场景
- 参数校验失败场景
- 分布式事务回滚场景
使用 Mockito 和 JUnit 5"六、第五阶段：微服务拆分（WorkTree）
6.1 多任务并行开发
👉 在 WorkTree 创建三个分支：
branch-1: 订单服务拆分（保持主流程）
branch-2: 库存服务独立（实验新特性）
branch-3: 消息服务升级（尝试新版本）
每个分支独立开发，互不干扰6.2 服务间调用优化
java
// Feign 客户端配置
@FeignClient(name = "stock-service", fallback = StockServiceFallback.class)
public interface StockServiceClient {
@PostMapping("/api/stock/deduct")
Result<Void> deductStock(@RequestBody List<StockDeductRequest> requests);
@GetMapping("/api/stock/check")
Result<StockCheckResult> checkStock(@RequestParam List<Long> skuIds);
}
// 熔断降级处理
@Component
@Slf4j
public class StockServiceFallback implements StockServiceClient {
@Override
public Result<Void> deductStock(List<StockDeductRequest> requests) {
log.error("库存服务熔断，扣减库存失败");
return Result.error("库存服务暂时不可用");
}
}七、完整工作流总结
7.1 各阶段用时统计
| 阶段 | 任务 | 模式+模型 | 传统耗时 | AI辅助耗时 | 提升倍数 |
|---|---|---|---|---|---|
| 1 | 项目搭建 | Plan + Claude 3.7 | 2小时 | 20分钟 | 6倍 |
| 2 | 核心接口 | Agent + Claude 3.5 | 4小时 | 1小时 | 4倍 |
| 3 | 分布式事务 | Debug + GPT-4o | 3小时 | 45分钟 | 4倍 |
| 4 | 优化测试 | Ask + Claude 3.5 | 2小时 | 30分钟 | 4倍 |
| 5 | 微服务拆分 | WorkTree + 多种 | 8小时 | 3小时 | 2.7倍 |
7.2 最佳实践总结
markdown
🎯 关键成功因素：
1. **分阶段开发**：不要一次让 AI 生成全部代码
2. **明确指令**：给出具体的业务规则和约束
3. **及时确认**：每生成一个模块就验证一次
4. **善用 Plan**：复杂逻辑先设计后实现
5. **测试先行**：让 AI 先写单元测试再写实现八、经验与教训
8.1 踩过的坑
markdown
⚠️ 常见问题：
1. **上下文污染**：不同接口放在同一个对话，导致代码风格混乱
✅ 解决：每个独立功能新开对话
2. **过度依赖**：AI 生成的代码不经 review 直接上线
✅ 解决：建立 AI 代码审查流程
3. **忽视异常**：AI 常忽略边界条件和异常处理
✅ 解决：明确要求包含 try-catch 和自定义异常8.2 效率倍增技巧
markdown
⚡ 高阶玩法：
1. **模板化提示词**：保存常用的提示词模板
2. **代码片段库**：让 AI 生成常用工具类并保存
3. **自动化测试**：每次修改后让 AI 补充测试用例
4. **文档同步**：代码改动后让 AI 同步更新接口文档心得
通过这个完整的电商订单服务案例，我们看到了 AI 辅助开发的巨大潜力。从项目搭建到微服务拆分，从单体应用到分布式系统，Cursor + 合适的模型组合，让开发效率提升了 3-5 倍。
但更重要的是，我们学会了如何与 AI 协作------不是简单地让它写代码，而是把它当作一个智能的合作伙伴，在不同的阶段使用不同的模式，在合适的场景选择最优的模型。
这才是 AI 编程的正确打开方式。
如需获取更多关于 Spring Boot 微服务实战、分布式系统设计、AI 驱动开发工作流、Cursor 高阶玩法等内容，请持续关注本专栏 《AI 驱动的微服务实战》 系列文章。