从惊艳到踩坑：AI结对编程的真实复盘

关注我的公众号：【编程朝花夕拾】，可获取首发内容。

01 引言

最近深度体验了一款AI编程助手（CodeBuddy），在一个Spring Cloud微服务项目中全程用它来写核心代码。从Feign接口到Service实现，从MyBatis查询到验证码改造，AI几乎参与了每一个模块。

这篇文章不吹不黑，只谈真实体验------那些让我眼前一亮的瞬间，那些不得不踩的坑。

02 项目背景

先交代一下环境，方便大家对后续内容有体感。

架构：Spring Cloud微服务，模块拆分（api定义Feign接口，service写实现，app写Controller）
数据访问：MyBatis，可以使用Example动态SQL，也可以使用xml
核心功能：用户关注/粉丝体系、分页查询、验证码登录
技术栈：Spring Boot 2.7.18、Feign、MyBatis、Guava、Lombok

我们主要重启了一个老项目，项目为分布式架构，使用SpringBoot + SpringCloud的主流架构，实体的生成采用逆向工程的方式。

项目结构：

03 让人惊喜的4个优势

3.1 跨模块一致性维护能力

这是最打动我的一点。之前还担心多模块之间怎么告诉给智能体，结果是我多虑了！

在微服务项目里，Feign接口在api模块，Service实现在service模块，Controller在app模块。当我要求实现一个列表查询方法时，AI能自动：

在FeignClient里加@RequestMapping
在ServiceImpl里写无注解的业务实现
在Controller里组装入参并调用

这种"跨模块上下文记忆"的能力，远超我以往用过的任何代码补全工具。 它不是给你一行建议，而是帮你完成一次完整的闭环。

逆向工程生成的代码，没有对应的FeignClient，需要通过对应的Service改造。这个交给智能体简直不要太爽，直接跨模块完美生成，顺便还能把相关联的地方一并修改。

3.2 工程化思维

它是懂项目结构的。在实现关注列表时，我要求：

markdown 复制代码

"查询关注列表，不要使用xml的方式，关注者姓名第一个字展示，后面是星号代替"

CodeBuddy不仅用了UvmMemberFollowExample，还自动：

调用了uvmMemberFeignClient.selectIds()批量查用户信息
用UvmMemberRole判断是角色类型
写了一个maskName()私有方法做脱敏

更关键的是，它自动识别了团队已有的代码范式 ------比如分页必须用example.setPagination(pagination)，返回必须包Pagination对象。这种对既有工程风格的尊重，让生成的代码可以直接合入，几乎不需要重构。

3.3 并行搜索

信息获取效率极高.

在实现getFileListByObjectIds方法时，CodeBuddy同时：

搜索UvmFileInfoFeignClient.java
搜索UvmFileInfoServiceImpl.java
全局搜索andObjectIdIn确认Example是否支持IN查询

三管齐下，10秒内就给出了精准修改方案。

3.4 快速纠错与模式适应

早期我曾错误地在Service实现类上加了@RestController和@RequestMapping，用户（也就是我）两次明确纠正：

markdown 复制代码

"清除实现类的requestmapping以及注解"
"实现类不需要requestmapping"

之后所有的ServiceImpl生成，CodeBudd都自动去掉了Web层注解，只在Feign接口和Service接口层面保留。这种从反馈中快速学习的能力，让后续协作越来越顺畅。

04 必须正视的2个问题

4.1 需要明确的"架构约束"输入

虽然CodeBuddy能记住项目结构，但它不会自动推断团队的硬性规范。比如：

Service实现类不能加@RequestMapping（我们花了两次纠正才稳定）
Feign接口必须继承GenericService
不允许手写XML，必须用Example模式

启示：第一次使用AI编程时，建议先用1-2个方法"调教"它，明确告知团队的命名规范、注解规范、分层规范。这比事后纠正效率高得多。

4.2 复杂业务逻辑需要人工兜底

复杂的业务逻辑，需要牵扯多张表以及梳理多张表之间的给关系。关系明确的情况下，智能体确实可以完美实现，但是最终的结果是否靠谱，还需要我们去验证验证，放置智能体自由发挥。

例如，在实现关注/回关逻辑时，需求是：

markdown 复制代码

"如果相互关注，需要更新之前的关注为已回关"

CodeBuddy生成的初版逻辑是正确的，但作为开发者，我必须确认：

followBack字段是Boolean还是Integer？（查BaseModel确认是Boolean）
互相关注的判断方向有没有反？（A关注B时，要查B是否关注了A）
软删除还是物理删除？（项目统一用del_flag软删）

AI能写代码，但业务正确性的最终责任人还是开发者。 特别是在涉及双向状态更新（A的状态影响B的状态）时，务必逐行Review。

05 小小经验

这段时间也算是用CodeBuddy完成了项目的开发，开发过程使用保持的怀疑的心态。从单模块到整个功能，逐步放开。也积累了一下小小经验。

5.1 分层指令

一次只改一层。虽然CodeBuddy能跨模块修改，但我发现最高效的模式是"先定义接口，再实现逻辑"：

markdown 复制代码

Step 1: 在FeignClient里定义接口 + @RequestMapping
Step 2: 在ServiceImpl里实现业务（不加Web注解）
Step 3: 在Controller里组装参数并调用

这样每层都够聚焦，Review时也清晰。开始使用的时候，可能会角色自己写提示词的功夫，代码都手搓完了，我们要慢慢适应写提示词。

5.2 善用参考

为了防止智能体自由发挥，我们可以让智能体参考之前类似的代码，这样更高效。当我要实现cancelFollow时，只说了一句：

markdown 复制代码

"参考`uvmMemberFollowFeignClient.follow`方法"

CodeBuddy就自动理解了：幂等校验、软删除、反向状态更新、时间戳维护。这比从零描述需求高效得多。

5.3 明确告知"不要做什么"

Java项目里有很多"约定俗成"的禁例，必须在指令里明确：

"不要使用xml的方式"
"实现类不要有RequestMapping"
"不要生成新的Mapper方法，用Example"

明明单表查询接口可以使用动态sql实现，就没有必要使用xml的方式手搓SQL了。

5.4 引用文件

引用文件是非常省token的方式，引用文件指出需要修改或者实现的方法，智能体可以快速找到，避免全工程扫描。

5.5 会话聚焦

AI能感知当前会话中的文件和结构。建议一次会话尽量围绕一个模块或一个功能闭环展开，避免在无关文件间频繁跳转。

06 小结

使用AI编程助手这段时间，我最大的感受是：它不会取代开发者，但它会重新定义"高效开发"的基准线。

那些重复性的模板代码、跨文件的机械跳转、容易手滑的boilerplate，AI都能以极高的准确性和一致性完成。而开发者可以把更多精力放在：

业务边界条件的梳理
性能隐患的识别
架构层面的Review

如果你还在犹豫要不要引入AI助手，答案是------先从一个小功能闭环试起。当你体验到"描述需求即得可用代码"的快感时，你就再也回不去了。