Java 项目中的 Claude Code 提效场景 Top 10

CC 你已经在用了，但大概率没踩到最爽的点。10 个 Spring Boot 高 ROI 场景，每个有命令、有翻车记录。

用了几个月 CC，你大概已经过了"哇这也能生成"的兴奋期。日常该用的地方在用，但总觉得哪里不对------有时候一个任务丢过去，CC 跑了 3 分钟给你一坨不能用的东西；有时候你手动改了半小时的活，事后才发现一行管道就能搞定。

问题不在工具，在场景选择。CC 不是什么都快，但在特定场景下快得离谱。 选对场景，你是审查员；选错场景，你是给 AI 擦屁股的人。

这篇是我在 Spring Boot 项目里反复验证过的 10 个高 ROI 场景。每个都有命令、有结果、有翻车记录------翻车的部分可能比命令本身更值钱。

场景 1：Maven 依赖冲突，30 秒定位

新需求来了，pom.xml 加了个第三方包，一跑 mvn compile，ClassNotFoundException 糊一脸。

mvn dependency:tree 敲下去，300 行输出。人眼看版本冲突，眼睛真的会瞎。

我现在这么搞：

bash 复制代码

mvn dependency:tree | claude -p "找出版本冲突的依赖，修复 pom.xml"

30 秒，CC 把冲突列出来，pom.xml 里 <exclusions> 都给你写好。以前排这种冲突我半小时起步，中间大概率还要开三个 StackOverflow 页面。

翻车记录 ：CC 偶尔会引入一个不存在的版本号------它不是在查 Maven Central，是在"猜"。解决简单：改完让它跑 mvn compile 自检，编译不过它自己会修正。

场景 2：贴堆栈→根因修复→验证，一条龙

线上报 NPE。堆栈 50 行，跨了 Controller → Service → Repository → Util 四个层。以前手动追踪：从堆栈顶上往下翻，找到第一个"自己的代码"，点进去看，往上追调用链，改，再跑测试......半小时起步。

现在直接贴：

复制代码

分析这个 NPE 堆栈，找到根因，修改代码加防御性编程，
跑相关单元测试验证修复

CC 会自动：

读堆栈里提到的每个文件
追踪参数从哪里传进来
定位根因（大部分时候不是报错那一行，是上游没做 null check）
改代码
跑 mvn test，不过就继续修

一套下来 2-3 分钟。我只需要最后 git diff 看一眼。

翻车记录 ：CC 有"防御过度"倾向------一个方法里加了 4 个 if (xx != null)。解法：提示词里加一句"只在外部入参处加 null check，内部方法加 @NonNull 注解"。

场景 3：CRUD 五件套，一句话生成

"加个收货地址管理功能。"

听到这句话，你脑子里已经开始过 Entity / Repository / Service / ServiceImpl / Controller / DTO 的模板了。一个功能六个文件，写完发现大部分是体力活。

我的做法：

css 复制代码

参考现有 src/main/java/com/example/order/entity/Order.java 的写法，
新增 Address 实体（用户收货地址），包含省市区+详细地址+收件人+手机号字段。
生成完整的 Entity/Repository/Service/Controller/DTO，
Service 层加上参数校验，和 User 实体做多对一关联

CC 一次性生成六个文件，关联关系、校验注解、RESTful 风格全部对齐项目现有规范。我给 CLAUDE.md 里写了"Controller 必须返回 ResponseEntity"，它就会照做。

翻车记录 ：新建文件的 package 声明偶尔和目录结构对不上。Java 对包路径极其敏感，差一个字母编译不过。解法：生成后第一件事 mvn compile。

场景 4：测试生成 + 自动修到绿灯

Service 写完了，单元测试一行没动。Mockito 那套 when(xxService.findById(anyLong())).thenReturn(Optional.of(user)) 写多了真的想吐------我知道怎么写，但就是不想写。

ini 复制代码

为 UserServiceImpl 写 JUnit 5 单元测试。用 Mockito 模拟所有依赖，
覆盖正常路径+异常路径。跑 mvn test -Dtest=UserServiceImplTest，
如果失败自动修复直到全部通过

CC 会生成测试 → 跑 → 红了 → 读报错 → 改 → 再跑 → 绿了。整个过程我切到浏览器刷了两分钟推，切回来全绿。

以前一个 Service 的测试我自己写大概 20-30 分钟，现在 2 分钟。

翻车记录：CC 生成的 Mock 场景偏"干净"------正常路径和最常见的异常覆盖很好，但边界条件（null、空字符串、超长输入）偶尔遗漏。我习惯生成后手动加一个边界 case 的测试方法，确保万无一失。

场景 5：字段注入批量改构造器注入

接手过一个 3 年陈的老项目。@Autowired 字段注入满天飞，满屏的 @Autowired private XxxService xxxService;。这种代码没法单元测试------字段注入让你 Mock 都注入不进去。

手动改？一个 Service 类 5-8 个依赖，十几个 Service 类，改完还要验证编译，一上午就没了。

css 复制代码

重构 src/main/java/com/example/service 包下所有 Service 类：
@Autowired 字段注入 → 构造器注入，使用 Lombok @RequiredArgsConstructor，
final 修饰依赖字段。不要改变任何业务逻辑。改完跑 mvn compile 验证

CC 批量改完，我 git diff 扫一眼，编译通过，5 分钟收工。

翻车记录 ：如果项目中存在循环依赖（A 注入 B，B 注入 A），字段注入时期不报错，改成构造器注入会直接启动失败。CC 不会检测到循环依赖。解法：编译过了一定要跑一下启动，mvn spring-boot:run 确认不炸。

场景 6：CI 红了，直接把报错管道丢给 CC

CI 流水线红了。打开日志一看：Checkstyle 违规 3 条 + 编译错误 8 条 + 单元测试失败 2 个。

以前：一条一条看，一个文件一个文件改，push，等 CI 重跑。运气好一轮过，运气不好三轮还在红。

现在我连看都不看：

bash 复制代码

./mvnw clean compile 2>&1 | claude -p "修复所有编译错误和 checkstyle 违规，跑单元测试确认"

CC 会自己读报错 → 定位文件 → 修改 → 跑验证。CI 日志越长，它越比人快------因为它不需要一行一行找，一次性读完所有错误，批量修复。

翻车记录 ：修太多文件时，CC 可能在某个改动里引入新 bug。解法：必须 git diff 逐文件扫一遍，不能闭眼信任。

场景 7：复杂 SQL → QueryDSL 代码

老项目里有个报表查询 SQL，JOIN 了 4 张表，WHERE 条件 8 行。现在要改成 QueryDSL，但团队里没人对 QueryDSL 语法特别熟。

自己搞：开 QueryDSL 文档 → 对着 SQL 一句一句翻译 → 跑 → 报错 → 调 → 再跑 → 半天过去了。

css 复制代码

将以下 SQL 转换为 QueryDSL 代码，集成到 CustomReportRepositoryImpl 中。
使用项目已有的 Q 类。

[贴 SQL]

CC 生成的 QueryDSL 代码直接可用，连 .fetchJoin() 优化都帮你加上。

翻车记录 ：如果项目 Q 类没生成（没跑过 annotation processor），CC 会假设它们存在并引用。解法：先确认 mvn compile 能生成 Q 类，再让 CC 干活。

场景 8：Spring Boot 2.x → 3.x 迁移

Spring Boot 2.7 还有几个月 EOS。javax → jakarta 的包名迁移，spring.factories → AutoConfiguration.imports 的文件迁移，application.yml 里废弃属性的替换------全是在文本里做替换的体力活。

markdown 复制代码

将当前项目从 Spring Boot 2.7 迁移到 3.2：
1. 所有 javax.* import → jakarta.*
2. spring.factories → AutoConfiguration.imports
3. @WebMvcTest 等注解确认是否需要调整
4. application.yml 废弃属性替换
5. 改完跑 mvn compile 验证

CC 一次性改完。十几个文件的 import 替换、配置文件调整，3 分钟。

翻车记录：第三方依赖（比如某些老版本的 MyBatis-Plus）还没适配 Jakarta，代码迁移了但依赖不兼容。CC 不知道你的第三方库版本支持情况。解法：先确认所有依赖都有了 Jakarta 兼容版本，再迁移。

场景 9：代码 review + commit message 一条龙

写完代码，改了一堆文件。自己 review 自己：看半天 git diff，容易"这不就是我刚写的吗"全跳过。Commit message 写到"fix bug"然后删掉重写，反复三次。

bash 复制代码

git diff --staged | claude -p "Review 改动：找潜在 bug、逻辑不一致、遗漏的边界情况。生成一条 conventional commit message"

CC 会给出 review 意见（"这里返回 null 但上游没判空"）和一条规范的 commit message（"fix(order): handle null address when user has no default shipping info"）。

比自己写的 commit message 靠谱多了。毕竟 AI 最擅长的事就是把一段话总结成一句话。

翻车记录：CC 的 review 对逻辑错误敏感度高，但对业务规则不了解------它不知道"这个优惠券不能叠加"是故意的还是 bug。解法：关键业务逻辑还是自己过一眼。

场景 10：多模块项目的精准上下文控制

公司项目 9 个子模块：common、auth、order、payment、notification......你让 CC "重构订单模块"，它可能会在 notification 模块里逛一圈回来，浪费 token 不说，还可能改错文件。

我学到的做法：

bash 复制代码

# 启动时直接限定路径
claude -p "分析 auth-service 的性能瓶颈" src/main/java/com/example/auth/

干活过程中用 /compact 定期清理上下文------等同于"刚才聊的你先忘了，记住结论就行"。

这套组合下来，token 消耗能控制在原来的 1/3，而且 CC 的输出更精准------被限定在单一模块里，它不会瞎关联其他模块的代码。

翻车记录：限定路径后 CC 读不到兄弟模块的代码。如果 auth 模块引用了 common 模块的工具类，CC 会因为看不到而"发明"一个。解法：必要时在提示词里 @ 引用关键依赖类。

组合拳：三个日常工作流

十个场景聊完了，但单看每个场景是一招一式。真正爽的是把它们串成工作流：

早上收尾：

bash 复制代码

git diff | claude -p "review 改动 + 生成 conventional commit message"

收掉昨天的代码，不用对着 diff 发呆。

开发中：新功能描述丢给 CC → 它生成六件套 + 测试 → 审查代码 → 跑测试验证。你写的是需求，它写的是代码。你不是在写代码，你是在审查 AI 写的代码。

CI 红了：

bash 复制代码

./mvnw clean compile 2>&1 | claude -p "fix all errors and run tests"

不看报错，不逐行修。管道丢过去，等结果。

这三招用熟了以后，你会发现一天下来真正敲键盘的时间越来越少，做架构决策和审查代码的时间越来越多。角色变了，体力活外包了，脑力活留给自己。