Trellis 在 Java 中的实战指南：从 DDD 到 SpringBoot 的最佳配置

最近在用 Claude Code 辅助开发的时候，顺手接入了 Trellis，这东西上手简单，默认配置跑起来也没什么门槛，但说实话，一旦项目复杂度上来（比如我手头这套基于 DDD 和 SpringBoot 的系统），默认 spec 就显得有点“力不从心”了。

Trellis 配置界面示例

Trellis 配置界面示例

官方的远程模板确实好用的多，但翻了一圈，发现针对 Java 生态的优质 spec 简直是凤毛麟角。很多配置都是 Python 或者通用型的，直接套用到 Java 里效果总是差强人意。

今天就借着这个机会，聊聊怎么把 Trellis 调教成 Java 开发的“趁手兵器”，特别是对于 DDD 架构和 SpringBoot 项目，有哪些必须要避开的坑和必须要做的优化。

Java 架构优化示意图

Java 架构优化示意图

对于 Java 开发者来说，Trellis 的默认 spec 有几个天然的痛点：

领域模型识别弱：DDD 强调限界上下文和领域模型，但通用 spec 往往只看到了类和方法，忽略了对聚合根、值对象的语义理解。这就导致 AI 生成的注释或者重构建议，经常把一个 Entity 当成了普通 DTO 乱用。
Spring 生态割裂：SpringBoot 项目里有大量 Bean 的生命周期、AOP 切面、自动配置等逻辑。默认 spec 很难读懂 @Service 和 @Component 在业务逻辑上的深层区别，生成的测试用例往往没法注入 Mock 依赖。
类型系统冗余：Java 的强类型系统在 AI 眼来有时候是“噪音”。默认 spec 可能会在泛型擦除、接口实现关系上纠结太久，反而忽略了核心业务流程的上下文。

既然没有现成的轮子，那就得自己造。针对 DDD + SpringBoot 的技术栈，我总结了几个定制 spec 的核心方向：

在 spec 中显式定义分层规则。告诉 Trellis，controller 层只负责参数校验和路由，不要在这里生成业务逻辑；service 层负责编排，domain 层才是核心。可以通过注解识别或者包路径约定，让 AI 明白代码的“宪法”。

把“仓储”、“工厂”、“策略模式”这些 DDD 概念喂给 spec。让它明白当我们说“查询用户”时，不仅是在调 SQL，更是在通过 Repository 接口访问聚合根。这样生成的代码才不会变成纯粹的 CRUD 脚本。

利用 Spring 的注解作为元数据。比如看到 @Transactional，spec 就应该意识到这里涉及到事务管理，生成的建议要考虑回滚和隔离级别；看到 @Async，就得提醒并发安全的问题。

自定义 Prompt 片段：不要指望一个通用的 System Prompt 解决所有问题。在具体项目中，我会把项目的包结构定义、命名规范作为一段“上下文”输入给 Trellis。比如明确告诉它：“所有的订单相关操作必须经过 OrderService，严禁直接操作 OrderMapper。”

测试生成的 trick：对于 SpringBoot 项目，让 AI 生成测试代码时，强制它使用 @SpringBootTest 或者 @WebMvcTest，并显式要求 Mock 掉外部依赖。默认 spec 生成的测试经常因为缺少 Bean 定义而跑不起来，这一步人工干预很关键。

代码审查的辅助：利用 Trellis 做 Code Review 时，重点关注它是否识别出了“贫血模型”的反模式。如果它能把一套充血的领域模型重构建议给出来，说明 spec 已经调教得相当不错了。

Trellis 是个好工具，但就像 IDE 的快捷键一样，默认设置永远只是“能用”，谈不上“好用”。对于 Java 开发者，特别是深耕 DDD 和微服务架构的同学，花点时间打磨一套专属的 Spec，绝对是事半功倍的投资。

如果你也在摸索这块，欢迎在评论区交流你的配置心得，或者吐槽你遇到的那些奇葩 Bug。