在 Spec Kit 的方法論中，Constitution（憲法） 扮演着至關重要的角色。它是所有 AI Agent（如 Specify Agent）必須遵守的最高法律。

而在憲法中，技術棧（Tech Stack） 部分不僅僅是一份“我們用了什麼庫”的清單，它是指導 AI 如何寫代碼、如何架構項目、如何複用組件的 “技術立法”。

如果説 Spec 是在告訴 AI “做什麼”（業務需求），那麼 Constitution 中的技術棧就是在強制規定 “怎麼做”（工程標準）。

今天，結合一個後端技術規範（Java 25 + Spring AI + GraalVM），我們來拆解如何在 Constitution 中編寫技術條款，將資深架構師的經驗轉化為 AI 的長期記憶。

一、 為什麼技術棧要寫入“憲法”？

在Constitution沒有技術棧的情況下，AI 就像一個剛入職、只會查 StackOverflow 的“外包實習生”：

• 它懂 Java，但可能給你寫 Java 8 的老代碼，而你的項目是 Java 25。
• 它懂 Spring，但可能引入你不想用的 RestTemplate，而不是項目統一的 WebClient。
• 它會寫分層，但可能把 Controller 放在錯誤的包路徑下，導致架構混亂。

將技術棧寫入 Constitution，就是為了實現 Context as Code（上下文即代碼）：

1. 消除版本幻覺：強制鎖定版本，防止 AI 使用過時語法。
2. 架構一致性：強制目錄結構和分層邏輯，防止“隨地大小便”。
3. 防止重複造輪子：強制 AI 調用已有的基建代碼（Server-base），而不是自己手寫。

二、 編寫實戰：技術立法的四大支柱

基於 Spec Kit 的標準，一份優秀的技術棧憲法應包含以下四個維度：

1. 強制性版本約束 (Hard Constraints)

這是憲法中的“鐵律”。不要給 AI 模糊的空間，必須明確具體的版本號和技術選型。這能有效阻斷 AI 的“時間幻覺”。

✅ Constitution 寫法示例：

| 類別 | 強制約束 (Must Use) | 補充要求/目標 |
| :--- | :--- | :--- |
| **語言/運行時** | **Java 25** | 必須使用最新語法特性。 |
| **核心框架** | **Spring Boot 3.5.x** | API 定義必須使用 `@HttpExchange`。 |
| **AI集成** | **Spring AI** | **禁止**引入 LangChain4j，必須統一使用 Spring AI 抽象 LLM 交互。 |
| **構建目標** | **GraalVM** | Native Image 是強制交付目標，所有新代碼必須考慮 AOT 兼容性。 |
| **數據庫** | **Citus (PostgreSQL 16+)** | **必須**啓用 `pgvector` 擴展。 |

• 實戰解讀：通過明確 GraalVM 和 Spring AI，你直接剪斷了 AI 產生“反射濫用”或“引入競品庫”的可能性。AI 看到這些約束後，生成的代碼會自動適配 Native 編譯環境。

2. 代碼風格與語法糖 (Style & Syntactic Sugar)

這決定了代碼的“味道”。你需要把團隊的最佳實踐固化為 AI 的肌肉記憶，讓 AI 寫出的代碼像是由同一個資深工程師完成的。

✅ Constitution 寫法示例：

- **代碼簡潔性 (Lombok 規範)**:
  + 必須使用 `@Data`, `@Builder`, `@Jacksonized` (用於反序列化), `@Slf4j`。
  + 鏈式調用：Entity/DTO 必須標記 `@Accessors(chain = true)`。
  + **禁止**手動編寫 Getter/Setter 或 Builder 模式冗餘代碼。
  + **錯誤處理**：避免冗餘的 try-catch，默認依賴全局異常處理。

- **DTO 映射**:
  + 必須通過 `MapStruct` 進行對象轉換，減少運行時反射開銷。

• 實戰解讀：這樣寫之後，AI 生成的 Entity 就不再是臃腫的 Java Bean，而是清爽、現代的鏈式對象。它知道“少寫代碼”才是好代碼。

3. 基建複用與“不造輪子” (Infrastructure Reuse)

這是 Spec Kit 提效的關鍵。明確告訴 AI 家裏有哪些現成的工具，禁止它去外面“買”或者自己“造”。

✅ Constitution 寫法示例：

- **Server-base 公共庫引用**:
  + **消息隊列**: 發送必須使用 `NatsPublisher`，消費使用 `NatsConsumer`。
  + **緩存操作**: 必須使用 `RedisManager`，禁止直接注入 `RedisTemplate`。
  + **分頁處理**:
    * 請求：使用 `PageReq.toPageable()` 轉為 JPA 分頁。
    * 響應：使用 `PageResponse.fromPage(list)` 統一返回格式。
  + **工具類**: 序列化/反序列化優先使用 `ConvertUtils`。

• 實戰解讀：當 Spec 提到“分頁獲取用户列表”時，AI 會自動調用 PageResponse，而不是手寫一個 Map<String, Object> 返回。這保證了全項目接口格式的絕對統一。

4. 物理架構與路徑約束 (Physical Architecture)

告訴 AI 代碼具體該放到哪個文件夾，防止項目結構腐化。這是架構守護的最後一道防線。

✅ Constitution 寫法示例：

- **模塊化結構 (app-server)**:
  + 包路徑必須遵循：`com.yuxiaor.ai.appserver.module.[module_name].[layer]`
  + **Layer 定義**:
    * `controller`: REST API，調用 Service。
    * `service`: 業務邏輯，調用 Repository。
    * `entity`: JPA 實體，領域模型。
    * `config`: 模塊配置（如 NatsConfig）。
  + **AI 大腦**: 所有流程、算法相關代碼必須放入 `workflow-engine` 模塊。

- **數據庫遷移 (Flyway)**:
  + 位置：`xiaoyu-server/sql/db/migration/`
  + 命名：`V[版本]__[描述].sql`
  + 約束：每個 Spec 模塊下單獨維護，合併時生成唯一的 SQL 文件。

• 實戰解讀：這不僅僅是規範，這是給 AI 的“導航地圖”。AI 不會再迷路，它清楚地知道新建的 CallbackController 必須放在 module/callback/controller 下，而不是根目錄。

三、 Spec Kit 的聯動機制：從憲法到代碼

在 Spec Kit 的工作流中，Constitution 技術棧規範是如何生效的？

1. Input (輸入): 你輸入一個 Feature Spec（例如：實現回調處理）。
2. Lookup (檢索): AI 讀取 Constitution 中的 backend-tech-spec.md。

3. Validation (校驗):

   • AI 想要寫一個 SQL 文件 -\> 憲法檢查 -\> 路徑對嗎？命名符合 V[版本]__[描述] 嗎？
   • AI 想要引入 Jedis -\> 憲法檢查 -\> 拒絕，憲法規定必須使用 RedisManager。
   • AI 想要寫 Java 17 的 var -\> 憲法檢查 -\> 升級為 Java 25 特性。
4. Output (輸出): 生成符合“本公司規範”的完美代碼。

四、 結語：Code as Law

在 Spec Kit 中，技術棧憲法就是 AI 必須遵守的 “代碼法典”。

它不僅消除了 AI 的版本幻覺，更防止了架構腐化。當你把 backend-tech-spec.md 引入 Constitution 的那一刻起，你就不是在和一個僅僅“懂 Java”的 AI 合作，而是在和一個 懂你公司架構、懂你代碼潔癖、懂你技術偏好 的資深工程師並肩作戰。

讓憲法守住技術的底線，讓 AI 去拓展業務的上限。

本文由mdnice多平台發佈