Spec Kit 实战：如何编写 Constitution 中的“技术栈” (Tech Stack)

在 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（上下文即代码）：

消除版本幻觉：强制锁定版本，防止 AI 使用过时语法。
架构一致性：强制目录结构和分层逻辑，防止“随地大小便”。
防止重复造轮子：强制 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 技术栈规范是如何生效的？

Input (输入): 你输入一个 Feature Spec（例如：实现回调处理）。
Lookup (检索): AI 读取 Constitution 中的 backend-tech-spec.md。
Validation (校验):
- AI 想要写一个 SQL 文件 -> 宪法检查 -> 路径对吗？命名符合 V[版本]__[描述] 吗？
- AI 想要引入 Jedis -> 宪法检查 -> 拒绝，宪法规定必须使用 RedisManager。
- AI 想要写 Java 17 的 var -> 宪法检查 -> 升级为 Java 25 特性。
Output (输出): 生成符合“本公司规范”的完美代码。

四、结语：Code as Law

在 Spec Kit 中，技术栈宪法就是 AI 必须遵守的 “代码法典”。

它不仅消除了 AI 的版本幻觉，更防止了架构腐化。当你把 backend-tech-spec.md 引入 Constitution 的那一刻起，你就不是在和一个仅仅“懂 Java”的 AI 合作，而是在和一个 懂你公司架构、懂你代码洁癖、懂你技术偏好 的资深工程师并肩作战。

让宪法守住技术的底线，让 AI 去拓展业务的上限。

本文由mdnice多平台发布

Spec Kit 实战：如何编写 Constitution 中的“技术栈” (Tech Stack)