為什麼是 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 的價值，不在於它替你生成了多少行，而在於它讓“這行代碼該不該在這裏”變成一個可以回答的問題。