Spec-Kit 深度实战：GitHub 开源的 AI 规格驱动开发工具包，让 Vibe Coding 走向工程化

前言：Vibe Coding 的繁荣与困局

2025 年，Andrej Karpathy 提出的 Vibe Coding（氛围编程）概念引爆了开发者社区。它的核心思想很简单：用自然语言描述意图，让 LLM 自主生成代码，人类只负责最终验收与迭代。在原型验证、创意探索的场景下，这种模式的威力惊人——一个周末就能把脑海中的 idea 变成可运行的原型。

但当这套方法论进入企业级系统和大型团队协作的深水区，问题迅速暴露：

• AI 生成的代码质量飘忽不定，这次能跑下次可能就埋雷
• 多轮对话后 AI 开始"自由发挥"，偏离原始需求
• 团队成员对 AI 产出的代码理解不一致，无法 Code Review
• 没有可追溯的决策记录，下次接手发现"天书"

Vibe Coding 加速了代码产出，却引入了新的复杂性。 当开发从"写代码"变成"审 AI 代码"，我们发现最大的瓶颈不再是打字速度，而是"说清楚要什么"。

正是在这个背景下，GitHub 于 2025 年 9 月正式开源了 Spec-Kit（GitHub/spec-kit，119K Star）——一套 AI 规格驱动开发（Spec-Driven Development，SDD）工具包。它将软件开发的核心从"代码实现"上移至"规范定义"，让人类专注"谱子"，AI 专注"演奏"。

本文将带你从零掌握 Spec-Kit，深度剖析其架构设计、六步工作流、企业级工程实践，以及它与 OpenSpec、Amazon Kiro 等竞品的核心差异。

一、为什么需要规格驱动开发（SDD）

1.1 从"人写代码"到"人定规则，AI 执行"

传统编程范式中，开发者是代码的唯一作者。他们通过代码表达业务逻辑，同时代码本身也是规格的最终载体——函数签名、类型约束、注释，共同构成了"活的文档"。

AI 编程改变了这一范式：LLM 是代码的直接生产者，而人类变成了需求表达者和验收者。这种转变带来了一个根本问题：AI 的输出具有概率性，同一需求在不同轮次可能产出完全不同的代码。

规格驱动开发（SDD）的核心解法是：在 AI 产生代码之前，先用结构化文档建立不可违背的"契约"。AI 的每一步操作都从这个契约出发，而不是从模糊的自然语言出发。

1.2 SDD 与传统敏捷的本质区别

很多人会把 SDD 误解为"写了需求文档再开发"的老套路，但两者有本质区别：

SDD 的文档不是写给人看的参考手册，而是给 AI 看的执行指令。这个定位的转变，是理解 Spec-Kit 一切设计的基础。

二、Spec-Kit 核心架构深度解析

2.1 项目结构

Spec-Kit 在项目根目录下生成一套标准化的目录结构：

my-project/
├── spec/                          # 规格文档目录
│   ├── constitution.md             # 开发宪法（最高原则）
│   ├── spec.md                     # 功能规格（当前需求）
│   ├── clarify.md                 # 澄清问答记录
│   ├── plan.md                     # 技术实施计划
│   └── tasks.md                    # 任务清单
├── .spec/
│   └── config.yaml                # Spec-Kit 配置
└── scripts/
    └── speckit.sh                 # 入口脚本

核心文件职责：

• constitution.md：项目的"宪法"，定义不可违背的最高原则。相当于公司章程，所有后续规格不能与之冲突。
• spec.md：功能规格，描述"做什么"而非"怎么做"。不涉及具体技术栈。
• clarify.md：AI 与人类就模糊需求进行 Q&A 的对话记录。
• plan.md：技术决策文档，包含架构选择、依赖关系、数据流设计。
• tasks.md：可执行的任务列表，每条任务对应具体代码改动。

2.2 Constitution 的设计哲学

Constitution 是 Spec-Kit 最独特的设计。我见过很多团队尝试为 AI 编写"行为规范"，但往往流于形式。Spec-Kit 的 Constitution 之所以有效，在于它借鉴了主权式约束的思想——不是建议，而是禁令。

## 技术禁令
- 必须使用 TypeScript 5.x，严禁 any 类型
- 禁止直接操作 DOM，必须通过框架抽象
- 禁止 SQL 拼接，必须使用参数化查询
- 禁止 console.log 生产代码，必须使用结构化日志

## 安全红线
- 严禁硬编码 API Key，所有密钥必须通过环境变量注入
- 所有外部输入必须经过验证，不信任任何 client 数据
- 禁止上传包含敏感信息的文件到 Git

## 性能标准
- 首屏加载不超过 2 秒（4G 网络）
- API 响应时间 P99 不超过 500ms
- 单次函数执行内存不超过 100MB

当 AI 尝试违反这些规则时，Constitution 就成了"拒绝指令"的依据。每次 AI 生成代码后，人类（或 CI 脚本）可以扫描 Constitution 检查是否有违规。

2.3 Agent 命令体系

Spec-Kit 定义了一组 slash commands（斜杠命令），AI Agent 在对话中识别这些命令并执行对应工作流：

/speckit.constitution    # 初始化/编辑宪法
/speckit.specify        # 创建功能规格
/speckit.clarify        # 澄清模糊需求
/speckit.plan           # 生成技术计划
/speckit.tasks          # 拆解任务清单
/speckit.implement      # 执行实现
/speckit.self-check     # 自检宪法合规性
/speckit.self-upgrade   # 升级 specify CLI

这些命令是 Spec-Kit 与 AI Agent 交互的协议层。每个命令都对应一个标准化的输出格式，确保 AI 的行为可预期。

三、六步工作流实战详解

3.1 环境准备

Spec-Kit 通过 specify CLI 驱动整个流程。安装方式（推荐 uv）：

# 方式一：uv（推荐，隔离环境）
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# 方式二：pipx（Python 包隔离）
pipx install git+https://github.com/github/spec-kit.git

# 方式三：临时试用（无需安装）
uvx --from git+https://github.com/github/spec-kit.git specify version

# 验证安装
specify version
specify self-check  # 检查更新和健康状态

注意事项： 不要从 PyPI 安装同名包 specify，那是第三方维护的非官方版本，功能和安全性均无法保证。

3.2 Step 1：初始化项目 (specify init)

# 进入项目目录（可以是已有项目）
cd my-api-service

# 初始化，支持多种 AI Agent
specify init . --integration claude-code    # Claude Code
specify init . --integration copilot       # GitHub Copilot
specify init . --integration cursor        # Cursor
specify init . --integration codex        # OpenAI Codex

# 高级：同时启用 Codex skills 集成
specify init . --integration codex --integration-options="--skills" --script sh

初始化完成后，项目根目录会生成 .spec/config.yaml 配置文件：

# .spec/config.yaml
version: "1.0"
integration: claude-code
constitution:
  path: spec/constitution.md
  autoEnforce: true    # 是否在每次 implement 后自动检查合规性
spec:
  path: spec/spec.md
plan:
  path: spec/plan.md
tasks:
  path: spec/tasks.md

3.3 Step 2：制定宪法 (/speckit.constitution)

# 通过 AI 引导创建宪法
/specckit.constitution

AI 会引导你回答一系列问题，生成初始宪法。以下是一个完整的 TypeScript REST API 项目宪法示例：

# Constitution.md - 项目宪法

## 技术栈约束
- 语言：TypeScript 5.5+，严格模式
- 框架：Express.js 5.x + Zod 输入验证
- ORM：Prisma 6.x，数据库 PostgreSQL 16
- 测试：Vitest + Supertest，覆盖率 ≥ 80%
- 代码风格：ESLint + Prettier，使用 ESLint no-unsafe-*
- 禁止：any 类型、var、== 比较、eval

## API 设计原则
- RESTful 风格，资源名词复数形式
- 统一错误响应格式：`{ error: string, code: string, details?: object }`
- 所有 POST/PUT 请求体必须通过 Zod schema 验证
- 状态码：2xx 成功，4xx 客户端错误，5xx 服务端错误
- 分页：Cursor-based pagination，不使用 offset

## 安全约束
- 所有路由必须认证（除 /health）
- SQL 使用 Prisma 参数化查询，禁止 raw SQL 拼接
- 禁止在错误响应中泄露内部信息（堆栈、路径）
- 敏感操作需记录审计日志

## 代码组织
- 单一职责：每个文件不超过 300 行
- 错误处理：统一使用自定义 AppError 类
- 依赖注入：通过构造函数，不使用全局变量

宪法不是一次成形的，随着项目推进，你可能需要添加新的约束。每条新增的宪法规则都应该经过团队评审，确保是"必须"而非"偏好"。

3.4 Step 3：编写规格 (/speckit.specify)

这是最关键的一步。规格文档要描述业务价值，而非技术实现。

❌ 错误示范（实现导向）：

## 用户注册功能

使用 Prisma 连接 PostgreSQL，实现以下 API：

POST /api/users
Body: { email: string, password: string }
返回 201，包含 user 对象和 JWT token

✅ 正确示范（价值导向）：

## 用户注册功能

### 用户故事
作为新用户，我希望通过邮箱注册账号，这样我可以在平台上管理自己的内容。

### 功能需求
1. 用户可以使用邮箱和密码注册
2. 密码必须满足：至少 8 位，包含大小写字母和数字
3. 邮箱必须唯一，注册时检查是否已存在
4. 注册成功后返回 JWT token，有效期 7 天
5. 不允许注册 admin、root、system 等保留用户名

### 验收标准
- [ ] 有效邮箱 + 强密码 → 返回 201 和 token
- [ ] 已存在邮箱 → 返回 409，提示"该邮箱已注册"
- [ ] 弱密码 → 返回 422，列出密码要求
- [ ] 保留用户名 → 返回 422，提示不可使用
- [ ] 无效邮箱格式 → 返回 400，提示格式要求
- [ ] 缺少必填字段 → 返回 400

### 边界条件
- 邮箱大小写不敏感（`User@Example.com` 等同于 `user@example.com`）
- 并发注册同一邮箱，只有第一个成功

3.5 Step 4：澄清需求 (/speckit.clarify)

/speckit.clarify

AI 会分析 spec.md，识别出模糊或有歧义的地方，主动向你提问：

我注意到以下几点需要澄清：

Q1: "保留用户名"具体包含哪些？
   建议的列表：admin, root, system, superuser, moderator
   这个列表需要可配置吗？

Q2: JWT token 刷新机制是否在本次范围内？
   如果 7 天后 token 过期，用户需要重新登录，还是实现 refresh token？

Q3: 注册邮件确认（email verification）是否需要？
   还是注册后立即可用？

你的回答会被记录到 spec/clarify.md 中，形成完整的决策上下文。这些问答记录在后续 Code Review 和人员交接时非常有价值。

3.6 Step 5：制定技术计划 (/speckit.plan)

/speckit.plan

基于已确定的规格，AI 生成技术实施计划：

## 技术计划

### 架构决策
1. **认证方案**：JWT（jsonwebtoken 包）+ bcrypt 密码哈希
2. **数据库表**：`users(id, email, password_hash, created_at)`
3. **唯一约束**：email 字段加唯一索引，大小写不敏感

### 依赖变更
- 新增依赖：`bcrypt@5.x`，`jsonwebtoken@9.x`，`zod@3.x`
- 数据库迁移：`npx prisma migrate dev --name add_users_table`

### 实现顺序
1. 创建 Prisma schema 并执行迁移
2. 实现 UserService（注册逻辑、邮箱去重）
3. 实现 AuthController（API 路由）
4. 添加 Zod 验证 schema
5. 编写单元测试（Vitest）
6. 编写集成测试（Supertest）

### 数据流

HTTP POST /api/users
→ Zod 验证请求体
→ 检查保留用户名（内存判断）
→ 检查邮箱唯一性（Prisma 查询）
→ bcrypt.hash(password, 12)
→ Prisma.user.create()
→ JWT.sign({ userId })
→ HTTP 201 { user, token }

### 风险评估
- **并发邮箱冲突**：通过数据库唯一约束 + Prisma 事务处理，P99 冲突率预计 < 0.01%
- **密码哈希性能**：bcrypt 12 rounds，约 250ms/hashing，可接受

3.7 Step 6：拆解任务 (/speckit.tasks)

/speckit.tasks

AI 将计划拆解为原子化的任务：

## 任务清单

### Phase 1: 数据库层
- [ ] TASK-001: 在 `prisma/schema.prisma` 添加 User 模型
  ```prisma
  model User {
    id           String   @id @default(cuid())
    email        String   @unique
    passwordHash String   @map("password_hash")
    createdAt    DateTime @default(now()) @map("created_at")
    @@index([email])
  }

• TASK-002: 执行 prisma migrate dev --name add_users_table

Phase 2: 业务逻辑层

• TASK-003: 创建 src/services/UserService.ts
  • register(email, password): Promise<{ user, token }>
  • isReservedUsername(email: string): boolean
  • 邮箱正则验证 + 保留名检查
• TASK-004: 创建 src/schemas/user.schemas.ts
  • registerSchema: Zod schema for registration

Phase 3: API 层

• TASK-005: 创建 src/controllers/auth.controller.ts
  • POST /api/users handler
  • 错误映射（Prisma P2002 → 409）

Phase 4: 测试

• TASK-006: 单元测试 UserService.test.ts
• TASK-007: 集成测试 auth.integration.test.ts

Phase 5: 验证

• TASK-008: 手动测试完整注册流程（curl）
• TASK-009: 宪法合规性自检

### 3.8 最终实现 (`/speckit.implement`)

```bash
# 单任务执行
/speckit.implement TASK-003

# 或让 AI 按任务清单顺序执行所有任务
/speckit.implement all

执行时，AI 会严格按任务清单行事，每个任务的产出都要与 tasks.md 中的描述对照。实现完成后，AI 自动运行宪法合规性检查：

# 自动执行的合规性检查
specify self-check
# 输出:
# ✓ constitution.md 存在
# ✓ 无 any 类型（扫描 src/**/*.{ts,tsx}）
# ✓ 无硬编码密钥（扫描所有文件）
# ✓ 测试覆盖率 ≥ 80%
# ⚠ 建议：添加 /health 路由免认证说明

四、团队协作与 CI 集成

4.1 Git 协作流程

Spec-Kit 的核心文件（constitution.md, spec.md 等）应该纳入 Git 版本控制：

git add spec/
git commit -m "feat: 添加用户注册功能的规格文档"
git push origin feature/user-registration

推荐分支策略：

feature/
├── spec/
│   ├── constitution.md     # 主分支维护，feature 继承 + 扩展
│   ├── spec.md             # 功能规格，按 feature 分支维护
│   ├── clarify.md
│   ├── plan.md
│   └── tasks.md

4.2 CI 自动化

将宪法合规性检查集成到 CI 流水线中：

# .github/workflows/spec-compliance.yml
name: Spec Compliance Check

on:
  pull_request:
    paths:
      - 'spec/**'
      - 'src/**'

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Spec-Kit
        run: uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

      - name: Run constitution compliance
        run: specify self-check --strict
        env:
          CONSTITUTION_PATH: spec/constitution.md
          SCAN_PATHS: src/

      - name: Verify spec coverage
        run: |
          # 扫描所有 src 文件中的函数/类，检查是否在 tasks.md 中有对应任务
          echo "Checking task completion..."

4.3 多 Agent 场景

Spec-Kit 支持团队中多个 AI Agent 协作。不同 Agent 可以有不同的 Constitution 片段：

# .spec/config.yaml
constitution:
  base: spec/constitution.md
  overrides:
    - path: spec/constitution.frontend.md   # 前端 Agent 专用规则
      when: "integration == 'cursor'"
    - path: spec/constitution.backend.md    # 后端 Agent 专用规则
      when: "integration == 'claude-code'"

这样，前端 Agent 遵守 React、样式隔离规则，后端 Agent 遵守 API 契约和数据库约束，各司其职，互不干扰。

五、Spec-Kit vs OpenSpec vs Amazon Kiro：SDD 生态全景

5.1 工具定位对比

5.2 OpenSpec 的增量变更模型

OpenSpec 提出了 Spec Delta 概念，特别适合存量系统的渐进式改造：

openspec/
├── specs/           # 真理仓库（只读快照）
│   ├── user-auth/
│   └── payment/
└── changes/        # 变更暂存区（活性变更）
    └── add-refresh-token/
        ├── proposal.md
        ├── spec.md
        └── tasks.md

AI 只需读取 changes/ 中受影响的规格片段，而不必扫描整个代码库，大幅降低上下文长度和 Token 消耗。

5.3 Amazon Kiro 的双向同步

Kiro 的核心理念是代码即规格：

# 你修改了代码，Kiro 自动反向更新规格文档
# /kiro.sync

# 或者让 Kiro 基于规格生成代码，并保持双向同步
# /kiro.generate --spec=user-auth --watch

当代码变更后，Kiro 会自动更新 spec.md，确保两者始终一致。这解决了 SDD 实践中最常见的"写了规格，后来代码改了就忘记更新规格"问题。

5.4 三者如何选型

• 全新项目，从零规范：Spec-Kit（宪法 + 阶段门禁）
• 存量系统，局部改造：OpenSpec（Spec Delta，低侵入）
• 需求模糊，追求端到端自动化：Amazon Kiro（双向同步）

最实际的做法：将三者组合使用。新功能用 Spec-Kit，存量系统变更用 OpenSpec，大规模重构引入 Kiro 双向同步。

六、常见陷阱与工程实践

6.1 规格文档的三大误区

误区一：规格等于实现方案
很多团队写的"规格"其实是详细设计文档，包含了具体的类名、函数名、甚至代码片段。这样 AI 就失去了选择的自由度，规格变成了另一种代码。

正确做法：规格描述"做什么"和"验收标准"，技术实现交给 plan 阶段。

误区二：宪法过于宽泛
如果宪法只有"代码要优雅"、"遵循最佳实践"这类空话，AI 会自行解释，最终产出一致性很差。

正确做法：宪法必须可枚举、可验证。例如："禁止 any 类型"→ 可以用 ESLint no-explicit-any 规则自动检测。

误区三：过度细化任务清单
将 tasks.md 写成"第 1 行写 import，第 2 行写 function 声明"这种粒度，反而限制了 AI 的优化空间，也会让任务清单变得脆弱（代码格式调整就导致任务过时）。

正确做法：任务粒度保持在"实现一个函数"、"添加一组路由"这个级别。

6.2 Constitution 的版本管理

随着项目演进，Constitution 会不断增长。建议按以下结构组织：

# constitution.md

<!-- 核心约束（永久，不删除） -->
## 语言 & 类型
- TypeScript 5.x，严格模式
- 禁止 any 类型 → ESLint no-explicit-any

<!-- 项目初期加入的约束 -->
## 初始架构约束（v0.1）
- Express.js REST API
- Prisma ORM

<!-- 后期新增的约束（可追溯来源） -->
## 性能约束（v0.3，#47 性能优化专项）
- API 响应 P99 ≤ 200ms
- 禁止 N+1 查询 → Prisma select 预加载

## 合规约束（v1.0，并购前 SOC2 准备）
- 所有 API 认证
- 审计日志保留 90 天

6.3 Token 成本控制

SDD 工作流中，规格文档会随对话增长，每次 AI 调用都需要读取历史上下文。以下是实测的 Token 消耗对比：

优化策略：

• clarify.md 和历史对话记录在问题解决后可以归档
• 定期将 plan.md 合并精简，只保留决策结论
• 使用上下文压缩工具（如 Claude 的上下文压缩 API）

七、实战：从零搭建一个符合宪法约束的 REST API

让我们用一个完整实例串联所有知识点。假设要实现一个任务管理 API。

7.1 初始化

mkdir task-api && cd task-api
git init
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init . --integration claude-code

7.2 创建宪法

# 引导式创建宪法（Claude Code 中）
/speckit.constitution

生成的宪法关键部分：

## 技术栈
- TypeScript 5.5 + Express 5
- Prisma 6 + PostgreSQL 16
- Vitest 测试
- Zod 验证

## 强制约束
- 无 any 类型（ESLint: @typescript-eslint/no-explicit-any）
- 无硬编码（ESLint: no-secrets）
- 所有输入验证（Zod schema）
- RESTful 路由（资源复数名词）
- 统一错误格式

7.3 编写规格

/speckit.specify

## 任务管理 API

### 用户故事
作为用户，我希望创建、查看、更新和删除任务，这样我可以管理我的待办事项。

### 功能范围
- 创建任务（标题、描述、优先级、截止日期）
- 列表查询（支持按状态、优先级筛选，分页）
- 更新任务（状态变更、字段编辑）
- 删除任务（软删除）
- 批量操作（批量标记完成）

### 验收标准
- [ ] 创建任务 → 201，返回任务对象（含自动生成的 ID 和 createdAt）
- [ ] 列表支持 ?status=pending&priority=high&page=1&limit=20
- [ ] 更新不存在任务 → 404
- [ ] 删除返回 204，更新 deletedAt 字段
- [ ] 批量完成超过 100 条 → 422

7.4 生成计划并实现

/speckit.plan    # 生成技术计划
/speckit.tasks   # 拆解为 12 个任务

AI 生成的第一个任务：

### TASK-001: Prisma Schema 设计

文件：`prisma/schema.prisma`

```prisma
model Task {
  id          String    @id @default(cuid())
  title       String
  description String?
  priority    Priority  @default(MEDIUM)
  status      Status    @default(PENDING)
  dueDate     DateTime?
  userId      String
  user        User      @relation(fields: [userId], references: [id])
  createdAt   DateTime  @default(now())
  updatedAt   DateTime  @updatedAt
  deletedAt   DateTime?
}

enum Priority {
  LOW
  MEDIUM
  HIGH
  URGENT
}

enum Status {
  PENDING
  IN_PROGRESS
  DONE
}

运行迁移：

npx prisma migrate dev --name add_tasks_table

```bash
# 执行实现
/speckit.implement TASK-001

# AI 输出：
# ✓ TASK-001 完成
# ✓ schema.prisma 创建
# ✓ migrate 执行成功
# 运行 self-check：
#   ✓ 无 any 类型
#   ✓ 枚举定义符合 Constitution

7.5 完整项目结构

经过 12 个任务后的项目结构：

task-api/
├── prisma/
│   └── schema.prisma
├── src/
│   ├── controllers/
│   │   └── task.controller.ts
│   ├── services/
│   │   └── task.service.ts
│   ├── schemas/
│   │   └── task.schemas.ts    # Zod schemas
│   ├── errors/
│   │   └── app-error.ts
│   ├── middleware/
│   │   ├── auth.ts
│   │   └── validate.ts
│   └── app.ts
├── tests/
│   ├── unit/
│   │   └── task.service.test.ts
│   └── integration/
│       └── task.api.test.ts
├── spec/
│   ├── constitution.md
│   ├── spec.md
│   ├── clarify.md
│   ├── plan.md
│   └── tasks.md
├── .spec/
│   └── config.yaml
└── package.json

八、局限性与未来展望

8.1 Spec-Kit 的局限性

1. 文档维护成本
规格文档需要持续更新，否则会成为"死文档"。在快速迭代的项目中，这是一笔不小的维护开销。

2. 不适合探索性开发
如果需求本身不清晰（例如 PoC 阶段），强行写规格反而会限制探索空间。SDD 更适合需求相对清晰的产品化阶段。

3. AI 依赖性
整个工具链重度依赖 AI Agent 的能力。如果 Agent 不支持自定义命令（如某些闭源 Copilot），Spec-Kit 的命令体系无法工作。

4. 跨 Agent 协作体验
目前多 Agent 场景下的 Constitution 覆盖机制还比较简陋，复杂的跨 Agent 协调需要手动配置。

8.2 SDD 生态的趋势

双向同步是未来
Spec-Kit 的阶段门禁模式解决了"AI 失控"问题，但维护成本高。OpenSpec 的 Spec Delta 模式和 Kiro 的双向同步，代表了更智能的方向——代码变更自动同步规格，减少人工维护负担。

规格即测试
未来的 SDD 工具可能会将验收标准直接转化为自动化测试用例（通过 LLM 生成 Vitest/Jest 测试），实现"规格即测试"的闭环。

多 Agent 规格治理
随着 AI Agent 生态的成熟，团队可能会引入专门的"规格 Agent"——负责维护 Constitution 的合规性，自动审查其他 Agent 的产出，形成人机协作的治理闭环。

总结：规格驱动开发的核心价值

Spec-Kit 的出现，代表了 AI 编程从"自由发挥"向"工程化约束"的范式转变。它的核心价值不在于工具本身，而在于背后的一套方法论：

1. 先定规则，再做实现：Constitution 将团队共识固化为不可违背的约束，从源头减少代码质量问题
2. 规格是 AI 的执行契约：规格文档不再是给人类看的参考手册，而是给 AI 看的执行指令
3. 过程可追溯：每一个代码决策都有对应的规格依据，Code Review 有据可查
4. 人机分工明确：人类负责定义"做什么"和"什么不能做"，AI 负责具体的实现细节

对于正在将 AI 编程引入生产项目的团队，Spec-Kit 提供了一套经过验证的工程化框架。它不能解决所有问题，但至少回答了最关键的问题：当你让 AI 写代码时，如何确保它不跑偏？

答案是：给它一部"宪法"。

选题来源：GitHub Trending 2026 年 7 月 | Spec-Kit SDD 工具链调研
相关标签：Spec-Kit, AI编程, SDD, Vibe Coding, Claude Code, GitHub, 工程化