为什么是 TG-boot
约 1904 字大约 6 分钟
AI 已经能在一分钟内写出几百行代码。真正稀缺的，不再是“生成”，而是 知道代码应该放在哪里、允许依赖谁、改完以后如何证明它没有越界。 TG-boot 不是一个更快的脚手架，而是一套把工程判断变成可执行约束的框架。
一、AI 编程最容易失控的三件事
1. 上下文失控：它不知道“整个系统”
大模型看到的往往是你贴进去的几个文件。它可以把一个 Controller 写得很漂亮，却不知道：
- 这个实体应该继承
BaseEntity，还是自己造一套审计字段； - 这个查询应该走本域
crud，还是调用别的模块； - 这个“用户”到底属于
system，还是dating里的客户； - 这个跨模块调用应该走
Api**Service，还是直接注入对方的 Mapper。
当项目只有几个文件时，这些问题靠人盯着就行。项目一旦有几十个模块，AI 的“局部最优”就会变成系统的“整体债务”。
2. 边界失控：代码能跑，但依赖已经乱了
最常见的 AI 生成结果是“能跑通”：
*-biz直接依赖另一个*-biz；*-api里塞进了crud.entity；- 为了省事，在业务模块里直接
new RabbitTemplate()； - 跨模块查询直接写 SQL JOIN 对方的表。
这些代码在本地能通过，却把未来拆服务、独立部署、权限隔离的路全部堵死。能跑不等于可维护，更不等于可演进。
3. 验收失控：没人能说清“这样写对不对”
如果规范只写在文档里，AI 不会主动遵守；如果只靠 Code Review，人的注意力又不够稳定。最后常见的状态是：
架构文档写得很完整，代码却在另一条路上生长。
TG-boot 的核心选择，是把这些“应该”变成“必须”，再把“必须”变成一条命令。
二、框架给出的四个答案
| AI 编程的问题 | TG-boot 的机制 | 直接结果 |
|---|---|---|
| 不知道代码放哪里 | Maven 模块 + *-api / *-biz 固定分层 | 目录即答案，生成前先定位 |
| 不知道允许依赖谁 | 跨模块只认 Api**Service 与 MQ 契约 | 依赖方向单一，可静态检查 |
| 不知道改动影响谁 | 接口与事件都是显式契约 | 影响面可枚举、可测试 |
| 不知道是否越界 | ArchUnit + POM 规则 + CI | 越界直接失败，而不是“下次注意” |
2.1 模块化单体：先要交付，再谈拆分
默认形态不是微服务，而是模块化单体：
- 源码按 Maven 模块严格切分；
- 运行时把多个
*-biz打进同一个spring-boot-starter-runner； - 一个 JVM、一套日志、一次部署；
- 模块之间仍然只通过
*-api契约通信。
这解决了一个现实矛盾：小团队没有精力一上来就维护服务发现、网关、链路追踪和分布式事务，但也不希望未来被单体锁死。
TG-boot 的做法是先把边界写好，再把部署方式留成可选项。拆服务时，改的是 runner 装配和基础设施，不是业务用例。
2.2 Api 契约：让“调用”看起来像 Feign
业务代码里写：
@Resource
private ApiSysUserService apiSysUserService;
UserDTO user = apiSysUserService.getByUserCode(code);调用方不需要知道对方在同一个 JVM 还是另一个进程：
- 本进程有 Provider，走本地直调；
- 没有 Provider，自动走 MQ Request-Reply；
- 路由固定 AUTO，不需要为“单体模式 / 微服务模式”写两套代码。
对 AI 来说，这意味着一个非常稳定的生成模板：先找接口，再调接口，不碰实现。
2.3 异步事件：把副作用从主链路里拿出来
支付成功、用户注册、实名认证完成，这些事件天然会被多个域关心。TG-boot 用 @MqChannel 契约 + MqPublisher.publishAfterCommit 统一处理：
- 发布方只依赖契约，不依赖消费者；
- 消费者直接实现契约，按需过滤；
- 事件在事务提交后发布，避免“库没写成功，消息先飞了”；
- 每个消费者都要说明幂等键。
这比“在 Service 里依次调用五个模块”更慢一点，但换来了可扩展、可重试、可拆分的副作用链路。
2.4 架构门禁：把“团队共识”变成 CI 失败
框架内置架构测试，至少守住三类事情：
*-api不能依赖*-biz；- 一个
*-biz不能依赖另一个域的*-biz； *-api不能定义模块内 SPI。
这类规则的价值不在于“抓坏人”，而在于给 AI 一个确定的反馈回路。生成、编译、跑门禁、根据失败修正——这比在提示词里反复写“请注意架构规范”可靠得多。
三、和常见方案相比，它到底不同在哪
| 维度 | 传统分层单体 | 一开始就微服务 | TG-boot |
|---|---|---|---|
| 首次交付 | 快 | 慢，基础设施先行 | 快，一个 runner |
| 模块边界 | 靠包名与自觉 | 靠网络边界 | 靠 Maven + 契约 + 门禁 |
| 跨模块调用 | 直接注入 | HTTP / RPC | 统一 Api**Service，本地或 MQ 自适应 |
| 拆分成本 | 高，常需重写 | 低（已经拆了） | 低，主要改装配 |
| AI 友好度 | 上下文易混乱 | 契约清楚但基础设施复杂 | 契约清楚，且可单进程运行 |
| 运维复杂度 | 低 | 高 | 低，按需增加 |
TG-boot 不是“微服务框架”，也不是“低代码平台”。它更像一个带边界和验收标准的 Spring Boot 工程底座。
四、它的代价，也要说清楚
选择 TG-boot 并不意味着只有收益。至少有三类成本：
- 前期结构成本：新增一个能力域不是建一个包，而是建
*-api/*-biz两个模块，并想清楚契约。 - 规范学习成本：命名、双主键、状态字段、事件幂等，都需要团队达成一致。
- 基础设施认知成本：JDK 27、Spring Boot 4、Maven 多模块、MQ 抽象，对新手并不轻。
因此它不适合：
- 一次性脚本、极小的内部工具；
- 没有长期维护预期的 Demo；
- 团队明确不打算做模块化、也不准备遵守契约的项目。
它适合：
- 业务域多、生命周期长、需要多人协作的后台系统；
- 希望借助 AI 提升产出，但不愿牺牲边界与可维护性的团队；
- 现在要快速交付，未来又可能按域拆分的产品。
五、一句话结论
AI 时代的框架，不应该替人写完所有代码，而应该让人和 AI 在同一个可验证的结构里写代码。
TG-boot 的价值，不在于它替你生成了多少行，而在于它让“这行代码该不该在这里”变成一个可以回答的问题。