人定架构,AI 实现:高效人机协作写代码实战
用 AI 写代码,用得多了会发现一个规律:同样一个需求,不同人让 AI 写出来的结果差距巨大。
- 有的人拿到的是可以直接合入的代码,结构清晰、逻辑完整。
- 有的人拿到的看起来很漂亮,但跑起来却到处是坑——依赖乱引、异常没处理、事务边界全无。
差距不在 AI,而在于人怎么用 AI。
一、核心原则
最稳妥的流程很简单:
人先搭骨架 → AI 生成实现 → 人做验收
听起来像废话?但大多数人用法正好反过来——把需求扔给 AI,然后等着收代码,中间没有任何校验环节。
二、流程总览
| 步骤 | 人的工作 | AI 的工作 |
|---|---|---|
| 第一步 | 定义方法签名、业务流程、异常点,明确事务边界和外部调用顺序 | — |
| 第二步 | — | 补全参数校验、对象转换、日志、异常处理和 if-else 流转 |
| 第三步 | 检查事务、异常、并发风险、幂等性、外部调用边界 | — |
一句话总结:人写施工图 → AI 按图施工 → 人验收
三、第一步:人搭骨架
以"下单接口"为例,不要让 AI 从零写。先在 IDE 里建好类,定义方法签名、入参、出参、事务边界,并在方法体里写带序号的业务流程注释。
@Override@Transactional(rollbackFor=Exception.class)publicOrderResponsecreateOrder(OrderRequestrequest){// 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(Exceptione){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 容易写出这种——并发必超卖intstock=queryStock(productId);stock-=quantity;save(stock);// ✅ 正确做法——DB 层原子扣减UPDATEinventorySETstock=stock-#{qty}WHEREstock>=#{qty}进阶方案:配合乐观锁(版本号或 CAS)进一步防止超卖。库存扣减必须在数据库层完成,不能在应用层算好再写回去。
5. 外部调用缺幂等性
发消息、支付回调、扣库存,重试会不会导致重复扣减?AI 很少主动处理幂等性,必须人工检查边界状态。
六、写在最后
用多了你会发现,这套工作流的价值不在于“让 AI 写出更漂亮的代码”,而在于让代码真正按你的意思来。
AI 执行力很强,但它不懂你的业务,不知道哪些坑已经踩过,也无法判断哪些边界绝对不能越。代码质量最终靠人 + AI 的闭环验证,而不是单靠生成工具。
记住:任何 AI 生成的代码,都需要你的验收和控制。
所以,下次接需求,别急着让 AI 开工。先把方法名敲好,把步骤注释写好,让它按你的大纲填空。
你会发现,代码终于真正受你掌控了。
你用 AI 写代码时,遇到过哪些“看起来没问题,跑起来全是坑”的情况?欢迎在评论区聊聊,说不定你的经历能帮到别人。
