我给 AI 当老师：训练它理解我的业务代码

本文链接：https://blog.csdn.net/2403_89107873/article/details/145437426

本文在创作过程中借助 AI 工具辅助，以提升内容的参考价值，并确保语言表达更加流畅自然。文中的观点和思考，既整合了广泛查阅的前沿资料，也融入了我在查阅和理解中的拙见。希望这些内容能为大家带来启发，其中的观点和建议，期待与大家共勉。

在探索使用 AI 辅助开发的过程中，我发现让 AI 完全理解我们的业务代码并非易事。就拿我尝试让 DeepSeek 生成 Spring Cloud 代码来说，其中就遇到了不少问题。

一、当 AI 连 Bean 注入都搞不定时

微服务间 Feign 调用常漏掉 @EnableFeignClients：在微服务架构中，Feign 是一种常用的声明式 Web 服务客户端，用于简化微服务之间的调用。但 DeepSeek 生成的代码经常会漏掉 @EnableFeignClients 注解，这就导致 Feign 无法正常工作。这说明 AI 在理解微服务架构的配置和依赖关系上，还存在一定的不足。
生成的 MyBatis Plus 代码总忘记加 @TableLogic 软删除：MyBatis Plus 是一个 MyBatis 的增强工具，提供了很多便捷的功能。在涉及数据删除操作时，@TableLogic 注解可以实现软删除，即逻辑删除而非物理删除。然而，AI 生成的代码总是忽略这一点，这可能会导致数据的丢失和不一致性。
多数据源配置混淆了 AbstractRoutingDataSource 的使用场景：在多数据源配置中，AbstractRoutingDataSource 是一个关键的类，用于动态切换数据源。但 AI 生成的代码常常混淆其使用场景，导致数据源切换出现问题。

二、驯化 AI 的三大实战技巧

为了让 AI 更好地理解我的业务代码，我总结了以下三大实战技巧：

技巧 1：用注释写需求说明书：在定义方法时，通过详细的注释来描述需求。例如：

// 需要：带分页的模糊查询，按创建时间倒序，返回VO包装类  
// 注意：使用MyBatis Plus的QueryWrapper实现  
public Page<UserVO> findUsers(String keyword, Pageable pageable) {  
    // 在此生成方法体  
}

这样，AI 就能根据我们的注释，生成更符合需求的代码。

技巧 2：用单元测试教逻辑：当 AI 生成的支付回调服务有并发问题时，我们可以通过编写单元测试来教导它。首先，编写测试代码模拟 100 个并发请求，然后使用 @Transactional 注解和版本号验证乐观锁，最后将错误案例返回给 AI，让它重新生成代码。通过这种方式，AI 可以逐渐学习到正确的业务逻辑。
技巧 3：业务语义绑定：在生成医疗挂号系统代码时，要明确业务语义。例如，禁止出现 “订单” 而要用 “预约单”，科室排班必须关联 @HospitalAnnotation 注解，用自定义异常代替 RuntimeException。这样可以确保生成的代码符合业务规范和语义。