最近有个研究结论在圈子里挺火的：
AI 写代码，效率反而下降 19%。
很多人看到这个结果，第一反应就是：
- “我早就说 AI 没用”
- “写代码还是得靠人”
- “AI 只是个高级搜索引擎”
但当我仔细看过这份研究后，第一感觉并不是 AI 不行。
而是：你可能 用错地方了。
作为一名用了两年多 AI 写代码的 Java 后端开发者，从 Copilot → ChatGPT → Cursor → Claude 我基本都用过。真实的感受很直接：
- 在特定场景下，AI 能让你的 效率直接翻倍。
- 但在另一些场景里，AI 确实帮不上什么忙。
如果你把 AI 用在了它不擅长的地方，效率不下降才怪呢。
今天，我就结合自己的 Java 后端开发经验，跟大家聊聊 AI 写代码最有价值的 5 个场景。每个场景我都会给出效率提升的估算、真实案例、可能遇到的坑以及我的使用方法，希望能帮你找到 AI 的正确打开方式。
场景一：CRUD 生成 | 提效 70% ~ 80% ⭐⭐⭐⭐⭐
这绝对是 AI 最强的场景，没有之一。
先回想一下传统的开发流程。要写一个简单的“订单”增删改查接口，Java 后端通常需要创建这些文件：
Entity
Mapper
Mapper XML
Service
ServiceImpl
Controller
如果再加上参数校验、分页、Swagger 文档、统一返回体，一套 CRUD 40分钟起步是很正常的，复杂一点耗上 1小时 也不稀奇。
AI 的做法
我现在的基本操作是，把 数据库表结构 + 明确的需求描述 直接丢给 Cursor 这类工具。
生成订单 CRUD
使用 MyBatis Plus
包含分页查询
加 Swagger 注解
统一返回 Result
通常 5~10分钟，它就能直接生成 Entity、Mapper、Service、Controller、DTO、VO 等一整套代码。而且生成的代码规范度不错：注解齐全、字段映射正确、Swagger 注解也自动加好了。
但别高兴太早
AI 写 CRUD 有几个 经典的坑，需要你特别留意：
坑一：参数校验不完整
AI 通常只会生成基础的 @NotNull 注解，但对于业务中更细致的校验规则，比如 @Size、@Pattern，它往往考虑不到。
坑二：分页是“假分页”
很多 AI 会生成类似下面的内存分页代码，数据量一大，性能立刻出问题。
list.stream()
.skip()
.limit()
坑三：异常处理过于粗糙
AI 很喜欢写笼统的 catch (Exception e)，但在真实项目中，我们需要精细地区分业务异常、系统异常、数据异常等。
我的做法
AI 负责生成代码骨架，我负责检查核心逻辑。这样一来，效率比纯手写高得多，同时又不会因为盲目相信 AI 而在代码里埋下地雷。
结论：CRUD 是 AI 的主场，但你仍然需要 Review 每一行代码。因为 AI 写的 Bug，往往比人写的更隐蔽。
场景二：Bug 排查 | 提效 40% ~ 60% ⭐⭐⭐⭐
举个真实例子：系统突然抛出 NullPointerException。
传统的排查流程是：看日志 → 定位报错行 → 向上追溯调用链 → 打断点 → 尝试复现。顺利的话可能 15分钟，不顺利 半小时起步 都很常见。
现在我的做法是，把 异常堆栈信息 + 相关代码片段 直接丢给 Claude。
分析这个异常
通常 2分钟内 它就能给出分析结果，包括报错的根本原因、触发条件以及修复建议，准确率其实相当高。
SQL 优化同理
面对慢查询，把 EXPLAIN 的结果丢给 AI，它能帮你分析是否进行了全表扫描、是否缺少索引、JOIN 顺序是否合理。大部分建议 是靠谱的。
但复杂问题不行
遇到分布式事务、跨服务数据不一致、棘手的并发问题时，AI 基本就帮不上忙了。原因很简单：它不了解你的完整系统上下文和业务复杂性。
结论：AI Debug 就像一个经验丰富的实习生。标准问题它能秒解，但复杂问题最终还得靠你自己。
场景三：代码重构 | 提效 30% ~ 50% ⭐⭐⭐
重构可以分几个层级来看，AI 的能力也各不相同。
方法级重构（很好用）
例如，面对一团糟的 if-else 逻辑：
if(type==1){
}
else if(type==2){
}
else if(type==3){
}
你可以直接让 AI：“用策略模式重构”。它真的能生成 Strategy、StrategyFactory、StrategyImpl 等结构清晰的代码。
模块级重构（能力一般）
比如，一个积累了2000行代码的 Service 类，让 AI “拆分职责”。它能给出一个大致方案，但在类命名、职责边界划分上往往不够精准，需要你进行大量的人工调整。
架构级重构（基本不行）
涉及到单体拆微服务、分库分表、领域驱动设计拆分时，AI 给出的方案通常只能作为参考。因为这其中牵涉到业务理解、架构权衡和数据迁移等复杂决策。
结论：重构的本质是 深刻理解业务。AI 能帮你 搬砖（实施具体变换），但不能帮你 画蓝图（制定重构战略）。
场景四：写单元测试 | 提效 50% ~ 70% ⭐⭐⭐⭐
写单元测试，尤其是 Mock 各种依赖，可能是很多 Java 程序员最头疼的任务之一。为一個 Service 方法编写测试，通常要 mock Mapper、构造正常和异常用例，花上 30分钟 再正常不过。
AI 的做法
把 Service 代码丢给 AI，并指示：“用 JUnit5 + Mockito 生成测试”。
用 JUnit5 + Mockito
生成测试
2~3分钟，一套测试代码就生成了。例如，对于下面这个查询订单详情的方法：
public OrderDetailVO getOrderDetail(Long orderId) {
Order order = orderMapper.selectById(orderId);
if (order == null) {
throw new BizException(ErrorCode.ORDER_NOT_FOUND);
}
List<OrderItem> items = orderItemMapper.selectByOrderId(orderId);
OrderDetailVO vo = OrderConverter.toDetailVO(order);
vo.setItems(OrderConverter.toItemVOList(items));
vo.setTotalAmount(calcTotalAmount(items));
return vo;
}
AI 生成的测试骨架如下，质量完全可以直接使用或稍作修改：
@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
@Mock
private OrderMapper orderMapper;
@Mock
private OrderItemMapper orderItemMapper;
@InjectMocks
private OrderServiceImpl orderService;
@Test
void getOrderDetail_success() {
Order order = buildMockOrder();
when(orderMapper.selectById(1001L)).thenReturn(order);
OrderDetailVO result = orderService.getOrderDetail(1001L);
assertNotNull(result);
}
}
但 AI 会漏掉边界情况
比如“商品列表为空”、“金额为零”等特殊业务边界，需要你人工补充测试用例。
我的策略是：让 AI 完成 80% 的基础测试代码编写，我负责补充 20% 的关键边界和复杂场景测试。这样组合起来，效率极高。
场景五：写技术文档 | 提效 80% ~ 90% ⭐⭐⭐⭐⭐
这是 AI 最被低估的一个应用场景。
很多 Java 程序员宁愿多写两行代码，也不愿动手写文档。比如，面对一个简单的地址管理 Controller：
@PostMapping("/address/add")
public Result<Long> addAddress(@RequestBody AddressAddReq req)
@GetMapping("/address/list")
public Result<List<AddressVO>> listAddress()
把代码丢给 AI，让它“生成 Markdown 格式的接口文档”。2分钟，一份包含接口路径、参数说明、甚至能解析出部分校验规则的文档就出来了。
做技术方案设计也一样。给 AI 需求描述和技术选型倾向，10分钟 它就能生成一份包含项目背景、详细方案、风险评估和技术选型依据的完整文档初稿。
如果你还在坚持 纯手写技术文档，那可能真的在 浪费宝贵的开发时间。利用 AI 辅助文档创作，能极大解放你的生产力。
总结与思考
我们来快速回顾一下这五个场景：
| 场景 |
提效幅度 |
推荐度 |
核心结论 |
| CRUD生成 |
70-80% |
⭐⭐⭐⭐⭐ |
AI 的绝对主场 |
| Bug排查 |
40-60% |
⭐⭐⭐⭐ |
标准问题秒解，复杂问题无效 |
| 代码重构 |
30-50% |
⭐⭐⭐ |
AI 只能“搬砖”，不能“画图” |
| 单元测试 |
50-70% |
⭐⭐⭐⭐ |
AI 写 80%，人工补 20%，效率奇高 |
| 技术文档 |
80-90% |
⭐⭐⭐⭐⭐ |
最被低估的提效场景 |
关于“效率下降19%”的研究
那个研究有一个关键背景：测试对象是一个超过 110万行代码 的超大型代码库。AI 的上下文窗口有限，难以理解如此庞大的项目全貌，效率自然下降。
但现实中的项目往往模块清晰、代码量适中、需求明确。在这些场景下，AI 的优势就能充分展现出来。
所以问题的关键，不是 AI 本身行不行，而是 你有没有把它用在对的场景里。
我的 AI 使用原则
- 做 AI 擅长的：CRUD 生成、技术文档、单元测试、标准 Bug 分析。把这些重复性高、模式固定的工作交给它。
- 自己做 AI 不擅长的：系统架构设计、复杂业务逻辑梳理、分布式难题解决。这些需要深度思考和业务理解的工作，依然要牢牢掌握在自己手中。
- 永远保持 Review：对 AI 生成的代码，需要投入比对人写代码更仔细的审查。因为它可能会犯一些人类不易察觉的隐蔽错误。
作为一名写了几年 Java 的后端开发，合理使用 AI 工具后，我每天大概能节省 1~2小时 的重复劳动时间。但最后必须说一句实话：AI 不会让你立刻年薪百万。不过，它的确能 让你的开发效率显著提升，前提是，你得 用对地方。
对于如何在具体场景中更好地实施 AI 辅助的单元测试，你可以 在云栈社区的软件测试板块 找到更多深入的讨论和实战案例。
发表于 8 小时前
|
查看: 4|
回复: 0
