Spec Kit 实战教程：单体服务 vs 微服务多仓库

Awna2026-08-15 13:06

Spec Kit 实战教程：单体服务 vs 微服务多仓库

GitHub 官方出品的 Spec-Driven Development (SDD) 工具包，把「规范」从一次性脚手架变成可执行的开发流程。

本文是可照着做的教程，重点区分：单体服务（单仓库） 与 微服务多仓库 两种落地形态。

目录

  1. [Spec Kit 是什么](#Spec Kit 是什么)
  2. [核心概念（5 分钟读懂）](#核心概念（5 分钟读懂）)
  3. 安装与初始化
  4. 场景一：单体服务（单仓库）
  5. 场景二：微服务多仓库
  6. 两种场景对比与选型
  7. [与 AGENTS.md 的分层配合](#与 AGENTS.md 的分层配合)
  8. [常用 CLI 与 Slash 命令速查](#常用 CLI 与 Slash 命令速查)
  9. 常见问题
  10. 参考链接

1. Spec Kit 是什么

GitHub Spec Kit 是一套开源的 规范驱动开发（Spec-Driven Development, SDD） 工具包。核心理念：先定义要做什么，再让 AI 编程助手按结构化阶段落地。

与传统「写 spec 然后扔掉」不同，SDD 认为规范是可执行的------spec.md → plan.md → tasks.md → 代码，每个阶段产出 Markdown 工件，喂给下一阶段的 Agent。

解决什么问题

痛点 Spec Kit 的做法
一句 prompt 直接开写，需求跑偏 分阶段：specify → plan → tasks → implement
需求含糊，计划建在沙上 clarify、checklist、analyze 质量门禁
实现完不知道漏了什么 converge 对照 spec/plan/tasks 查漏
团队流程不统一 constitution 固化原则，preset/extension 扩展
换 AI 工具要重配流程 35+ agent 集成，一次 init 生成对应命令

Spec Kit vs Agent 内置 Plan

Agent Plan 模式 Spec Kit
持久化 多在单次会话 specs/ 目录进 Git
流程 灵活、无标准 9 步 SDD + 可选门禁
质量门禁 无 checklist、analyze、converge
组织扩展 难 extensions、presets、workflows
活文档 弱 取决于 persistence 模型选择

2. 核心概念（5 分钟读懂）

2.1 SDD 核心流程

复制代码 
Constitution → Specify → Clarify → Plan → Checklist → Tasks → Analyze → Implement → Converge
  原则         需求      消歧     技术方案   验需求    拆任务   一致性    实施      查漏

短路径（小功能）：

复制代码 
/speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement → /speckit.converge

2.2 目录与工件

Spec Kit 项目是 目录作用域 的：哪个目录包含 .specify/，哪个就是项目根。

text 复制代码 
my-project/
├── .specify/
│   ├── memory/
│   │   └── constitution.md     # 项目宪法：原则与约束
│   ├── templates/              # spec/plan/tasks 模板
│   ├── scripts/                # bash/ps/py 自动化脚本
│   └── feature.json            # 当前活跃 feature 指针（本机状态，默认 gitignore）
├── specs/
│   └── 001-add-remember-me/    # 按编号的功能目录
│       ├── spec.md             # 需求：what & why
│       ├── plan.md             # 技术方案：how
│       ├── tasks.md            # 可执行任务清单
│       └── checklists/
│           └── requirements.md # 内置需求质量检查单
└── src/                          # 业务代码

2.3 工件依赖关系

复制代码 
spec.md ──► plan.md ──► tasks.md ──► 代码实现
   ▲           ▲           ▲
   └───────────┴───────────┴── 可随时回溯修改（flow-back 模型）
工件 职责 写什么
constitution.md 全局原则 安全、测试、架构风格、禁止事项
spec.md 需求规格 用户故事、行为、边界；不写技术栈
plan.md 技术计划 技术栈、架构、模块划分、数据模型
tasks.md 任务分解 依赖有序、可并行标记、分阶段
checklists/ 需求质量 「需求的单元测试」，验 spec 是否完整

2.4 活跃 Feature 的跟踪

Spec Kit 通过 .specify/feature.json（或环境变量）跟踪 当前正在做的 feature ，不依赖 Git 分支：

json 复制代码 
{
  "feature_directory": "specs/001-add-remember-me"
}

切换 feature：更新 feature.json 或设置 SPECIFY_FEATURE_DIRECTORY。

可选 Git 扩展（specify extension add git）支持 001-feature-name 编号分支，但活跃 feature 仍以 feature.json 为准。

2.5 三种 Spec 持久化模型

团队需在 constitution 中明确选一种（Spec Kit 不强制默认）：

模型 规则 适合
Flow-forward 每个 feature 目录是历史记录，新需求新建目录 审计、追溯
Living spec spec.md 是契约，plan/tasks 可重新生成 spec 为单一真相
Flow-back 任何工件都可先改，再人工对齐 快速迭代

存量项目详见 Evolving Specs 指南。

3. 安装与初始化

3.1 前置条件

  • Python 3.11+
  • uv（推荐）或 pipx
  • Git（可选，启用 git 扩展时需要）
  • AI 编程助手：Cursor、Claude Code、Copilot、Gemini CLI 等

3.2 安装 Specify CLI

从 GitHub 安装（推荐，可钉版本）：

bash 复制代码 
# 将 vX.Y.Z 替换为 Releases 页最新 tag，保留前缀 v
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v0.12.11

从 PyPI 安装：

bash 复制代码 
uv tool install specify-cli
# 或
pipx install specify-cli

验证：

bash 复制代码 
specify version
specify self check    # 检查是否有新版本

3.3 初始化项目

bash 复制代码 
specify init my-project --integration cursor
# 或在当前目录
specify init --here --integration cursor

--integration 可选值见文档 Integrations 列表；非交互环境默认 copilot，可用 SPECKIT_INTEGRATION_DEFAULT 覆盖。

常用选项：

bash 复制代码 
specify init --here --force --integration cursor   # 非空目录强制合并
specify init my-project --script sh                # 脚本类型：sh / ps / py
specify init my-project --preset compliance      # 安装 preset

3.4 可选：启用 Git 扩展

bash 复制代码 
specify extension add git

启用后支持 feature 编号分支（如 001-add-remember-me），但活跃 feature 仍由 feature.json 管理。

3.5 更新

bash 复制代码 
specify self upgrade
cd my-project && specify init --here --force --integration cursor  # 刷新 agent 命令文件

更新前备份 .specify/memory/constitution.md 和自定义 templates/scripts。

4. 场景一：单体服务（单仓库）

4.1 适用条件

  • 一个 Git 仓库 = 一个可部署单元
  • 典型：Spring Boot 单体、Django 全栈、Next.js 全栈
  • 无跨仓库协作，流程在一处闭环

4.2 推荐目录结构

text 复制代码 
my-monolith/
├── .specify/
│   └── memory/constitution.md
├── specs/
│   ├── 001-user-auth/
│   ├── 002-order-checkout/
│   └── 003-payment-refund/
├── src/
├── AGENTS.md
└── .cursor/commands/             # 或 skills，由 init 生成

4.3 完整教程：给登录加「记住我」

Step 1：建立宪法（项目级，通常做一次）

在 Cursor 聊天框：

复制代码 
/speckit.constitution

本项目是 Java 17 + Spring Boot 3 单体应用。
原则：
- Security-First：所有入参校验
- 分层：Controller → Service → Repository
- 日志英文，POST 打印入参
- 枚举比较用 ==，时间用 DateHelper
- 详细编码规范见根目录 AGENTS.md
持久化模型：flow-forward（每个 feature 目录保留历史）

生成/更新 .specify/memory/constitution.md。

Step 2：描述需求（不写技术栈）
复制代码 
/speckit.specify

为登录功能增加「记住我」选项。勾选后会话保持 30 天；未勾选保持现有 24 小时超时。
需支持：用户勾选后下次自动登录；用户主动退出后清除持久会话；
多设备登录时各设备独立会话。
本阶段不涉及第三方 OAuth。

创建 specs/002-add-remember-me/spec.md，并可能生成 checklists/requirements.md。

Step 3：消歧（推荐）
复制代码 
/speckit.clarify

聚焦：30 天会话是否滑动过期？「退出所有设备」是否在本期范围？

AI 追问并把答案写回 spec.md。

Step 4：技术方案
复制代码 
/speckit.plan

Spring Security + Redis session。
持久 Cookie 存 token 引用，Redis 存 session 详情。
Remember-me 用独立 Redis key 前缀，TTL 30 天。
复用现有 SecurityConfig，在认证过滤器后插入 remember-me 处理。

生成 plan.md。

Step 5：需求质量检查（生产功能推荐）
复制代码 
/speckit.checklist

生成自定义检查单，例如：

  • 是否定义了 token 刷新行为？
  • 是否定义了 Cookie 被篡改时的处理？
  • 是否定义了 Redis 不可用时的降级？

Reviewer 勾选 [x] 表示 需求质量达标（不代表实现完成）。

Step 6：拆任务
复制代码 
/speckit.tasks

生成 tasks.md，典型结构：

markdown 复制代码 
# Tasks

## Phase 1: Setup
- [ ] T001 确认 Redis session 配置

## Phase 2: Foundational
- [ ] T002 [P] 定义 RememberMeToken 模型与 Redis key 规范

## Phase 3: User Story - Remember Me Login
- [ ] T003 登录接口增加 rememberMe 参数
- [ ] T004 实现 RememberMeAuthenticationFilter
- [ ] T005 实现持久 Cookie 写入与校验

## Phase 4: Polish
- [ ] T006 退出登录清除 remember-me token

[P] 表示可并行执行。

Step 7：一致性分析（推荐）
复制代码 
/speckit.analyze

只读报告：spec / plan / tasks 之间的冲突、缺口。有问题则回到 specify/clarify/plan/tasks 修复后重跑。

Step 8：实施
复制代码 
/speckit.implement

  • 按 tasks 依赖顺序执行

  • 若 checklist 有未勾选项，会 询问是否继续

  • 大功能可分阶段：

    /speckit.implement Implement only Phase 2 and Phase 3. Stop before Polish.

Step 9：收敛验证
复制代码 
/speckit.converge

两种结果：

  • Converged：实现满足 spec/plan/tasks，可以开 PR
  • Tasks appended ：发现缺口，追加到 tasks.md → 再 implement → 再 converge

4.4 存量项目（Brownfield）要点

  1. 不必先 spec 全系统：第一个 feature 只描述你要改的那块
  2. 升级与演进分开 ：
    • 工具升级：specify self upgrade + specify init --here --force
    • 需求变更：按 persistence 模型更新 specs/ 工件
  3. 第一个 feature 选小的：熟悉 rhythm 比交付速度重要
  4. constitution 引用 AGENTS.md：避免重复写编码规范

4.5 单体场景最佳实践

实践 说明
生产功能走完整路径 constitution + clarify + checklist + analyze
小功能走短路径 specify → plan → tasks → implement → converge
feature 目录进 Git specs/ 是工程资产
feature.json 不提交 本机指针，已在 .specify/.gitignore
用 taskstoissues 跟踪 /speckit.taskstoissues 转 GitHub Issues
converge 循环直到干净 不要跳过最后一步

5. 场景二：微服务多仓库

5.1 适用条件

  • 每个微服务 独立 Git 仓库
  • 一次需求常跨 order、inventory、payment 等多个服务
  • 需要平台级契约与各服务实现计划分离
  • 团队要标准化 SDD，且可能与 GitHub Issues/PR 集成

5.2 Spec Kit 在多仓库中的定位

与 OpenSpec 的 Store 不同，Spec Kit 没有内置中央规划仓库。多仓库靠：

  • 每个仓库独立 .specify/ 项目
  • 平台文档仓库 承载跨服务 feature
  • 环境变量 跨目录定位项目
  • Multi-Root Workspace 多仓库同时打开
  • GitHub Issues 跨仓库任务跟踪

5.3 三种常见形态

形态 结构 适合
A. 每服务独立 各仓库各自 specify init 服务边界清晰、很少跨服务改
B. 平台仓 + 服务仓（推荐） platform-docs 管跨服务 spec，各服务管实现 典型微服务团队
C. Monorepo 多项目 一个 Git，多个 .specify/ 代码在一个 repo 但多 deployable

5.4 目标架构（推荐：平台仓 + 服务仓）

text 复制代码 
platform-docs/                         ← 平台 Spec Kit 项目
├── .specify/memory/constitution.md    # 跨服务原则、错误码、契约规则
├── specs/
│   └── 001-checkout-promo/            # 跨服务业务能力
│       ├── spec.md                    # 用户故事 + 跨边界行为
│       ├── plan.md                    # 涉及哪些服务、事件流
│       └── tasks.md                   # 平台级协调任务（非代码）
├── docs/
│   ├── service-dependencies.md
│   └── api-contracts/
├── AGENTS.md
└── platform.code-workspace

order-service/                         ← 服务 Spec Kit 项目
├── .specify/
├── specs/
│   └── 003-implement-checkout-promo-api/
├── src/
└── AGENTS.md

inventory-service/
├── .specify/
├── specs/
│   └── 002-implement-checkout-promo-consumer/
└── AGENTS.md

职责分层：

层级 仓库 Spec Kit 内容
跨服务需求 platform-docs 用户故事、Event 语义、API 契约、流程
跨服务协调 platform-docs 哪些服务要改、发布顺序、联调检查
服务实现 各服务仓库 本仓库 plan、tasks、implement
静态上下文 各服务 AGENTS.md 启动、目录、编码约定

5.5 教程：初始化多仓库 Spec Kit

Step 1：平台文档仓库
bash 复制代码 
cd platform-docs
specify init --here --integration cursor
specify extension add git   # 可选

平台 constitution 示例：

复制代码 
/speckit.constitution

平台级原则：
- API 契约统一维护在 docs/api-contracts/，禁止各服务重复定义 DTO
- 跨服务 Event 字段变更必须列出所有 Consumer
- 错误码使用 common-error-codes，不私自新增
- 数据库变更必须 migration 脚本
- 跨服务拓扑见 docs/service-dependencies.md
持久化模型：flow-forward
跨服务 feature 的 spec.md 描述业务能力，不写单服务实现细节
Step 2：各微服务仓库
bash 复制代码 
cd order-service
specify init --here --integration cursor

cd inventory-service
specify init --here --integration cursor

服务 constitution 引用平台规则：

复制代码 
/speckit.constitution

order-service：订单创建、状态流转。
遵循 platform-docs 中的 API 契约与 Event 定义。
本服务：Java 17 + Spring Boot 3，分层见 AGENTS.md。
跨服务拓扑：docs/service-dependencies.md（platform-docs 仓库）
Step 3：配置 Workspace

编辑 platform.code-workspace，聚合各仓库路径，用 Cursor 打开：

bash 复制代码 
cursor platform.code-workspace

5.6 教程：跨服务功能「结账促销码」

场景：add-checkout-promo 涉及 order-service（API）、inventory-service（Consumer）、gateway（路由）。

阶段 1：平台仓规划跨服务契约

在 platform-docs 目录（或设置 SPECIFY_INIT_DIR）：

复制代码 
/speckit.specify

结账页支持促销码：用户输入 promoCode，eligible 则减价，ineligible 展示原因。
涉及：gateway 路由、order-service API、inventory-service 库存校验、
activity-service 活动规则（如有）。
请写清 Event 字段、API 入参出参、错误码，不涉及单服务类设计。

/speckit.clarify

聚焦：促销码与活动 ID 冲突时优先级？库存不足时是否仍展示促销价？

/speckit.plan

事件流：CheckoutRequest → order-service 校验促销 → inventory 校验库存 → 返回价格明细。
OrderCreatedEvent 新增 promoCode、discountAmount 字段（需 inventory、activity consumer 同步）。
API 契约写入 docs/api-contracts/order-service.md。

/speckit.checklist
/speckit.analyze

平台 tasks.md 侧重 协调，而非写代码：

markdown 复制代码 
## Phase: Coordination
- [ ] T001 更新 docs/api-contracts/order-service.md
- [ ] T002 更新 docs/service-dependencies.md 影响面
- [ ] T003 通知 inventory-team、activity-team

## Phase: Service Implementation（在各服务仓库执行）
- [ ] T004 order-service: implement-checkout-promo-api
- [ ] T005 inventory-service: implement-checkout-promo-consumer

合并 platform-docs PR 后，契约文档即团队真相。

阶段 2：各服务仓库创建实现 feature

在 order-service：

复制代码 
/speckit.specify

实现 platform-docs specs/001-checkout-promo 中 order-service 部分：
POST /api/orders 增加 promoCode 参数，调用促销校验，返回 discountAmount。
参考 platform-docs/docs/api-contracts/order-service.md。
tasks 仅包含本仓库代码改动。

/speckit.plan

复用现有 OrderService，新增 PromoValidationHelper。
Redis 缓存促销规则 5 分钟。不改 OrderCreatedEvent 发布逻辑结构。

/speckit.tasks
/speckit.analyze
/speckit.implement
/speckit.converge

在 inventory-service 同理创建 implement-checkout-promo-consumer。

阶段 3：跨仓库任务跟踪

平台仓或服务仓：

复制代码 
/speckit.taskstoissues

将 tasks.md 转为 GitHub Issues，便于多团队并行。

各服务 PR 描述中链接 platform-docs 的 feature PR，便于追溯契约版本。

5.7 环境变量：不 cd 也能定位项目

多仓库 CI 或从 monorepo 根操作子项目：

bash 复制代码 
# 选定项目（包含 .specify/ 的目录）
export SPECIFY_INIT_DIR=apps/order-service

# 选定 feature
export SPECIFY_FEATURE_DIRECTORY=specs/003-implement-checkout-promo-api

# 然后运行 slash 命令或 CLI
specify workflow list

两个独立轴：

  • SPECIFY_INIT_DIR → 选哪个 项目 （哪个 .specify/）
  • SPECIFY_FEATURE_DIRECTORY → 选哪个 feature

路径必须存在且包含 .specify/，否则 报错且不 fallback，避免 spec 写入错误目录。

交互式 Agent：在启动 Agent 之前 export 环境变量，并验证 feature 落在预期目录。

5.8 Monorepo 微服务（一个 Git，多个服务）

若微服务在同一 Git 仓库（非多仓库），用 Monorepo 指南：

text 复制代码 
my-monorepo/
├── .git/
├── services/
│   ├── order-service/
│   │   └── .specify/          # 独立 Spec Kit 项目
│   └── inventory-service/
│       └── .specify/
└── apps/
    └── gateway/
        └── .specify/
bash 复制代码 
specify init services/order-service --integration cursor
specify init services/inventory-service --integration cursor

注意 ：Git 分支在 仓库根 共享。feature 分支 001-xxx 是整个 monorepo 的，spec 文件仍在各子项目 specs/ 下。需在根目录管理分支，或各子项目独立 init Git。

5.9 微服务场景最佳实践

实践 说明
契约只在平台仓维护 避免各服务 spec 重复定义 Event
平台 spec → 服务 spec 引用 服务 spec.md 写明遵循哪版平台 feature
PR 互链 平台 PR ↔ 各服务 PR
用 taskstoissues 跨团队 Issues 比 chat 更可追踪
constitution 分层 平台管契约规则，服务管实现规则
doctor 式自检 改 Event 前读 service-dependencies.md 影响表
不指望一次 implement 跨仓库 各仓库各自 implement + converge

5.10 与 OpenSpec Stores 的对比（多仓库选型参考）

Spec Kit 多仓库 OpenSpec Stores
中央规划 自建 platform-docs 项目 官方 Store 机制
跨仓库引用 文档链接 + workspace references 自动索引
质量门禁 checklist + analyze + converge 较弱，靠人工 review
活文档合并 flow-forward / living spec archive 自动合并 delta
学习曲线 流程完整，步骤多 轻量 4 步循环

可组合：platform-docs 用 OpenSpec Store 管契约，各服务用 Spec Kit 管 implement 流程（需注意目录不冲突）。

6. 两种场景对比与选型

6.1 对比表

维度 单体服务 微服务多仓库
项目根 仓库根一个 .specify/ 每仓库一个 .specify/ + 可选平台仓
feature 编号 001-、002- 独立递增 各仓库独立编号
跨边界需求 同一 spec/plan/tasks 平台仓 spec + 各服务 implement
契约管理 spec.md 或 docs/ platform-docs + api-contracts
协作 单仓库 PR 多 PR + Issues + workspace
环境变量 通常不需要 SPECIFY_INIT_DIR 常用
Git 扩展 单仓 feature 分支 各仓独立分支命名空间
converge 单仓验证 各仓分别 converge

6.2 决策树

复制代码 
你的部署形态？
│
├─ 单仓库单体
│   → 根目录 specify init，一套 constitution + specs/
│
├─ Monorepo 多服务（一个 Git）
│   → 每服务子目录独立 .specify/（见 Monorepo 指南）
│
└─ 多 Git 仓库微服务
    │
    ├─ 很少跨服务改
    │   → 各仓库独立 Spec Kit，契约用 docs 链接
    │
    └─ 经常跨服务改
        → platform-docs（跨服务 spec）
        + 各服务仓（implement feature）
        + platform.code-workspace 联调

6.3 路径选择：短路径 vs 完整路径

场景 推荐路径
单体小功能 specify → plan → tasks → implement → converge
单体生产功能 完整 9 步
平台跨服务规划 specify → clarify → plan → checklist → analyze（不 implement）
服务实现 specify → plan → tasks → analyze → implement → converge

7. 与 AGENTS.md 的分层配合

text 复制代码 
┌─────────────────────────────────────────────────────────┐
│  AGENTS.md / .cursor/rules                              │
│  仓库结构、启动命令、编码风格 --- 静态、少变                 │
├─────────────────────────────────────────────────────────┤
│  .specify/memory/constitution.md                        │
│  项目原则 --- 引用 AGENTS.md，加 SDD 流程约束               │
├─────────────────────────────────────────────────────────┤
│  specs/<feature>/spec.md                                │
│  本次功能的可测试需求 --- 动态、按 feature 演进             │
├─────────────────────────────────────────────────────────┤
│  specs/<feature>/plan.md + tasks.md                     │
│  技术方案与任务 --- 从 spec 派生                           │
└─────────────────────────────────────────────────────────┘

微服务模板对应：

文件 Spec Kit 用法
platform/AGENTS.md 平台 constitution 引用；跨服务 spec 不写实现细节
microservice/AGENTS.md 服务 constitution + specify context
docs/api-contracts/*.md 平台 feature 的 plan 产出物，或 living spec 维护
docs/service-dependencies.md clarify/analyze 的输入；改 Event 前必读

在 constitution 中写明：

markdown 复制代码 
编码规范见各服务 AGENTS.md。
跨服务契约见 platform-docs/docs/api-contracts/。
改 Event 前查 docs/service-dependencies.md 影响表。

8. 常用 CLI 与 Slash 命令速查

8.1 Slash 命令（AI 聊天框）

命令 作用
/speckit.constitution 创建/更新项目原则
/speckit.specify 从自然语言创建 spec.md
/speckit.clarify 追问歧义，更新 spec
/speckit.plan 生成技术 plan.md
/speckit.checklist 生成需求质量检查单
/speckit.tasks 生成 tasks.md
/speckit.analyze 只读一致性分析
/speckit.implement 按 tasks 实施
/speckit.converge 查漏，可能追加 tasks
/speckit.taskstoissues tasks 转 GitHub Issues

不同 Agent 格式可能为 $speckit-specify（Codex）或 /skill:speckit-specify（Kimi）。

8.2 CLI（终端）

命令 作用
specify init 初始化项目
specify version 版本信息
specify check 检查 agent CLI 工具
specify self check 检查 CLI 是否有新版本
specify self upgrade 升级 CLI
specify extension add git 启用 Git 扩展
specify workflow list 列出 workflows
specify integration status 集成状态

8.3 环境变量

变量 作用
SPECIFY_INIT_DIR 指定项目根（含 .specify/）
SPECIFY_FEATURE_DIRECTORY 指定活跃 feature 目录
SPECIFY_FEATURE 非 Git 场景指定 feature 名
SPECKIT_INTEGRATION_DEFAULT 非交互 init 默认 integration

9. 常见问题

Q1：是不是 waterfall？

不是。SDD 强调分阶段，但 artifact 可随时修改（尤其 flow-back 模型）。checklist/analyze 是 需求质量 门禁，不是审批瀑布。

Q2：老项目要先 spec 全部代码吗？

不需要。第一个 feature 只描述你要改的一块。工具升级与需求演进是两条维护线。

Q3：feature.json 要提交吗？

默认 不提交 （在 .specify/.gitignore）。团队通过 feature 目录名或 SPECIFY_FEATURE_DIRECTORY 对齐。

Q4：能否一次 implement 改多个仓库？

不能。 每个仓库各自 /speckit.implement。跨仓库用平台仓协调 + 各仓 feature + Issues。

Q5：checklist 勾选了算实现完成吗？

不算。 自定义 checklist 的 [x] 表示 reviewer 认为 需求质量达标。implement 完成看 tasks 和 converge。

Q6：Monorepo 里 Git 分支会冲突吗？

会。单 Git 根仓库下，feature 分支共享命名空间。在根管理分支，或子项目独立 Git。

Q7：和 OpenSpec 能一起用吗？

可以但需约定目录。常见：OpenSpec 管活文档与 delta，Spec Kit 管 feature 级 SDD 流程。避免两套流程同时指挥 implement。

Q8：企业内网怎么用？

支持 air-gapped：本地 wheel 打包、私有 PyPI。见 Enterprise Installation 指南。

10. 参考链接

资源 URL
Spec Kit 文档首页 https://github.github.com/spec-kit/
Quick Start https://github.github.io/spec-kit/quickstart.html
安装指南 https://github.github.io/spec-kit/installation.html
Agentic SDD 命令参考 https://github.github.io/spec-kit/reference/agentic-sdd.html
Monorepo 指南 https://github.github.com/spec-kit/guides/monorepo.html
Evolving Specs（存量项目） https://github.github.io/spec-kit/guides/evolving-specs.html
Spec Persistence 模型 https://github.github.io/spec-kit/concepts/spec-persistence.html
SDD 哲学 https://github.github.io/spec-kit/concepts/sdd.html
GitHub 仓库 https://github.com/github/spec-kit
社区 Extensions https://github.github.io/spec-kit/community/extensions.html

附录：快速启动命令清单

单体服务

bash 复制代码 
uv tool install specify-cli
cd my-monolith && specify init --here --integration cursor
# Cursor:
# /speckit.constitution → /speckit.specify → /speckit.clarify
# → /speckit.plan → /speckit.tasks → /speckit.analyze
# → /speckit.implement → /speckit.converge

微服务多仓库

bash 复制代码 
# 平台仓
cd platform-docs && specify init --here --integration cursor

# 各服务
cd order-service && specify init --here --integration cursor
cd inventory-service && specify init --here --integration cursor

# 跨目录操作（CI）
export SPECIFY_INIT_DIR=order-service
export SPECIFY_FEATURE_DIRECTORY=specs/003-implement-checkout-promo-api

# 联调
cursor platform.code-workspace

本文基于 GitHub Spec Kit 官方文档（2026 年初版本）整理。CLI 版本与命令以你本地 specify version 为准。

相关推荐
程序员老刘2 小时前
Flutter 3.47 更新要点：Material 正式分家，老项目先别急着更新
flutter·ai编程·客户端
全栈弄潮儿3 小时前
一周总结：AI 编程入门最重要的 3 个原则
chatgpt·openai·ai编程
Nturmoils4 小时前
鸿蒙健康教练接入蓝耘：一句话打卡，模型估热量，网关记账
ai编程
正在走向自律5 小时前
WorkBuddy AI工具使用介绍完全指南
人工智能·爬虫·ai编程·workbuddy·ai的力量
咸甜适中5 小时前
rust语言AI编程学习笔记（五）clap命令行参数解析
学习·rust·ai编程
必须会一定会6 小时前
DeepSeek API 峰谷定价实战：计算 8 月 17 日后的 Agent 成本，并启动 Harness 预览版
人工智能·ai编程
canonical_entropy6 小时前
关于《Mission Driver：Loop Engineering 的一种通用参考实现》的补充说明
后端·agent·ai编程
leeyi6 小时前
Agent 调了删库工具怎么办：5 层防线——DeepFlux 工具安全纵深防御（第84篇-E70）
aigc·agent·ai编程
plainGeekDev7 小时前
Loop —— 文档还是脚本？让 AI 自动干活的完整指南
ai编程·claude
热门推荐
01GitHub 镜像站点02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新042026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？05VSCode+CodeX扩展，无法启动06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07历年考研数学一、数学二、数学三真题试卷及答案PDF08AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片10如何新建文件夹？ 电脑新建文件夹的4种方法