用 AI 写代码，用得多了会发现一个规律：同样一个需求，不同人让 AI 写出来的结果差距巨大。

• 有的人拿到的是可以直接合入的代码，结构清晰、逻辑完整。
• 有的人拿到的看起来很漂亮，但跑起来却到处是坑——依赖乱引、异常没处理、事务边界全无。

差距不在 AI，而在于人怎么用 AI。

---

一、核心原则

最稳妥的流程很简单：

人先搭骨架 → AI 生成实现 → 人做验收

听起来像废话？但大多数人用法正好反过来——把需求扔给 AI，然后等着收代码，中间没有任何校验环节。

---

二、流程总览

步骤	人的工作	AI 的工作
第一步	定义方法签名、业务流程、异常点，明确事务边界和外部调用顺序	—
第二步	—	补全参数校验、对象转换、日志、异常处理和 if-else 流转
第三步	检查事务、异常、并发风险、幂等性、外部调用边界	—

一句话总结：人写施工图 → AI 按图施工 → 人验收

---

三、第一步：人搭骨架

以"下单接口"为例，不要让 AI 从零写。先在 IDE 里建好类，定义方法签名、入参、出参、事务边界，并在方法体里写带序号的业务流程注释。

@Override
@Transactional(rollbackFor = Exception.class)
public OrderResponse createOrder(OrderRequest request) {

    // 1. 校验 userId、productId、quantity 是否合法，不合法抛 ParamException

    // 2. 查询商品库存，库存不存在或库存不足时抛 BizException

    // 3. 扣减库存，扣减失败时抛 BizException

    // 4. 创建订单记录，订单状态设置为 PENDING

    // 5. 保存订单到数据库

    // 6. 发送延迟取消消息，30 分钟未支付自动取消订单

    // 7. 返回订单编号
}

骨架的价值：

• 方法名、入参出参明确
• 调用顺序锁死（先查后扣、先建单再发消息）
• 异常抛出点明确
• 全局事务边界已定

一旦骨架搭对了，AI 补再偏也偏不到哪里去。

---

四、第二步：AI 生成实现

选中骨架代码，唤醒你的 AI 助手——无论是 Copilot、Claude 还是 ChatGPT，发下严格指令就行。

请严格按照方法内数字注释补全业务逻辑。

要求：
1. 不修改已有类名、方法名、方法签名、入参和出参
2. 只使用本项目已有的 Service、Mapper、Enum、Exception，不引入新第三方依赖
3. 严格按注释步骤顺序实现，不要擅自调整业务流程
4. 参数错误抛 ParamException，业务错误抛 BizException
5. 库存扣减和订单创建必须在同一个事务中完成
6. 关键步骤打印日志，日志需包含 userId、productId、orderNo
7. MQ 消息发送失败必须抛出 BizException，绝对不能吞异常导致无法回滚
8. 缺少必要类或方法先列出来，不要凭空创造

把开放题变成 “完形填空题”，AI 就会老老实实按你的施工图写，生成结构清晰、依赖干净、可维护的代码。

提示
在 2026 年，多模态 AI（Copilot X、ChatGPT Enterprise、Claude）可直接生成单元测试和接口契约文档，进一步提升协作效率。

---

五、第三步：人做验收

AI 写完代码直接 git commit？不行！第一版只是草稿。以下 5 个坑必须人工排查：

1. 异常被吞，事务不回滚

try {
    orderMessageProducer.sendDelayCancelMessage(orderNo);
} catch (Exception e) {
    log.error("send delay message failed", e); // ⚠️ 异常被吞了！
}

后果：消息没发出去，但订单事务成功提交。必须让异常抛出触发回滚。

2. 事务注解位置或生效问题

不要只看有没有加 @Transactional，要检查：

• 是不是加在了 private 方法上？
• 内部调用是否导致 Spring 代理失效？
• MQ 发送失败的异常有没有抛出导致事务依然提交？

Spring Boot 3+ 的动态代理机制有变化，内部调用默认不走代理，事务行为可能和你预期不一样。

3. 日志缺关键信息

// ❌ AI 容易写成这样
log.info("create order success");

// ✅ 实际排查时你需要的是
log.info("create order success, userId={}, orderNo={}", userId, orderNo);

4. 并发库存扣减导致超卖

// ❌ AI 容易写出这种——并发必超卖
int stock = queryStock(productId);
stock -= quantity;
save(stock);

// ✅ 正确做法——DB 层原子扣减
UPDATE inventory SET stock = stock - #{qty} WHERE stock >= #{qty}

进阶方案：配合乐观锁（版本号或 CAS）进一步防止超卖。库存扣减必须在数据库层完成，不能在应用层算好再写回去。

5. 外部调用缺幂等性

发消息、支付回调、扣库存，重试会不会导致重复扣减？AI 很少主动处理幂等性，必须人工检查边界状态。

---

六、写在最后

用多了你会发现，这套工作流的价值不在于 “让 AI 写出更漂亮的代码”，而在于让代码真正按你的意思来。

AI 执行力很强，但它不懂你的业务，不知道哪些坑已经踩过，也无法判断哪些边界绝对不能越。代码质量最终靠人 + AI 的闭环验证，而不是单靠生成工具。

记住：任何 AI 生成的代码，都需要你的验收和控制。

所以，下次接需求，别急着让 AI 开工。先把方法名敲好，把步骤注释写好，让它按你的大纲填空。
你会发现，代码终于真正受你掌控了。

---

你用 AI 写代码时，遇到过哪些 “看起来没问题，跑起来全是坑” 的情况？欢迎在评论区聊聊，说不定你的经历能帮到别人。

---

如果你觉得多模型切换、工具订阅的流程太繁琐，也可以试试我们的「胜算云」平台，一站式搞定 AI 创作与开发相关需求。
官网：https://www.shengsuanyun.com/