📖 工具简介
是 GitHub 开源的规范驱动开发(Specification-Driven Development, SDD)工具包,它彻底颠覆了传统软件开发模式。在传统开发中,代码是王者,规范服务于代码;而 Spec Kit 实现了——规范成为主导,代码服务于规范。规范不再是指导实现的文档,而是能够直接生成实现的可执行文件。
GitHub Spec Kit 是 GitHub 开源的规范驱动开发(SDD)工具包,通过可执行规范直接生成代码,实现规范主导代码生成的权力反转。核心工作流包含/specify 创建规范、/plan 生成计划、/tasks 分解任务。内置九大架构原则(项目宪法)强制测试优先、库优先等标准。支持 Python 环境及多种 AI 助手,适用于 MVP 开发、团队协作及企业级项目,能显著提升文档与代码的一致性。

是 GitHub 开源的规范驱动开发(Specification-Driven Development, SDD)工具包,它彻底颠覆了传统软件开发模式。在传统开发中,代码是王者,规范服务于代码;而 Spec Kit 实现了——规范成为主导,代码服务于规范。规范不再是指导实现的文档,而是能够直接生成实现的可执行文件。
该项目在过去 30 天内星标数量约 20k,近期平均每天新增超 1k 星标,这反映出其高速增长趋势和社区的积极反馈。这种受欢迎度源于其易用性和强大的功能,帮助开发者高效处理标准化工作流。
传统模式:规范 → 指导 → 代码实现
SDD 模式:规范 → 直接生成 → 代码实现
必需软件:
uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
uvx --from git+https://github.com/github/spec-kit.git specify init --here
支持多种 AI 编程助手:
# Claude Code(推荐)
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai claude
# GitHub Copilot
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai copilot
# Gemini CLI
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai gemini
# Cursor
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ai cursor
支持 Bash 和 PowerShell 两种脚本:
# 使用 Bash 脚本(Linux/macOS 默认)
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --script sh
# 使用 PowerShell 脚本(Windows 默认/跨平台)
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --script ps
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --skip-tls
# 跳过 AI 工具检查
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --ignore-agent-tools
# 跳过 Git 初始化
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --no-git
# 启用调试模式
uvx --from git+https://github.com/github/spec-kit.git specify init my-project --debug
# 系统环境检查
uvx --from git+https://github.com/github/spec-kit.git specify check
安装完成后,项目中会自动生成以下结构:
📝 目录结构更新说明:从 v0.0.34 版本开始,Spec Kit 将配置文件和脚本统一放在
.specify/隐藏目录中,以避免与用户项目文件冲突并提供更清晰的项目结构。
your-project/
├── .specify/ # Spec Kit 配置目录(v0.0.34+)
│ ├── memory/ # 项目知识库
│ │ ├── constitution.md # 项目宪法(九大架构原则)
│ │ └── constitution_update_checklist.md
│ ├── scripts/ # 自动化脚本
│ │ └── powershell/ # PowerShell 脚本版本
│ │ ├── create-new-feature.ps1
│ │ ├── setup-plan.ps1
│ │ ├── check-task-prerequisites.ps1
│ │ ├── common.ps1
│ │ ├── get-feature-paths.ps1
│ │ └── update-agent-context.ps1
│ └── templates/ # 模板文件
│ ├── spec-template.md # 规范模板
│ ├── plan-template.md # 计划模板
│ ├── tasks-template.md # 任务模板
│ └── agent-file-template.md # AI 助手配置模板
├── specs/ # 功能规范目录(用户创建的规范)
│ └── 001-feature-name/ # 自动编号的功能目录
│ ├── spec.md # 功能规范
│ ├── plan.md # 实现计划
│ ├── research.md # 技术研究
│ ├── data-model.md # 数据模型
│ ├── contracts/ # API 契约
│ ├── quickstart.md # 快速验证指南
│ └── tasks.md # 任务列表
└── CLAUDE.md # AI 助手配置(自动生成)
Spec Kit 的核心是结构化的三步工作流,每一步都有明确的输入、处理和输出:
/specify - 规范创建:将自然语言需求转化为结构化规范/plan - 计划生成:基于规范生成技术实现计划/tasks - 任务分解:将计划拆分为可执行的开发任务/specify 命令 - 功能规范创建核心作用:将自然语言功能描述转化为结构化技术规范
执行机制:
003-user-management-system)specs/003-user-management-system/spec.md使用方法:
/specify 构建一个实时聊天系统,支持消息历史记录和用户在线状态显示。用户可以创建聊天室,邀请其他用户,发送文本消息,查看消息历史,并实时看到其他用户的在线状态。系统需要支持多个并发聊天室,每个房间可以有无限数量的用户。
重要约束:
自动生成内容:
/plan 命令 - 实现计划生成核心作用:读取功能规范,生成详细的技术实现计划
执行机制:
使用方法:
/plan 使用 WebSocket 实现实时消息传输,PostgreSQL 存储消息历史,Redis 管理用户在线状态和会话。后端使用 FastAPI,前端使用 React 和 Socket.IO 客户端。实现 RESTful API 用于房间管理,WebSocket 用于实时通信。
架构合规检查:
### 阶段 -1:实现前门控
#### 简化门控(宪法第 VII 条)
- [ ] 使用≤3 个项目?
- [ ] 无未来证明?
#### 反抽象门控(宪法第 VIII 条)
- [ ] 直接使用框架?
- [ ] 单一模型表示?
#### 集成优先门控(宪法第 IX 条)
- [ ] 契约已定义?
- [ ] 契约测试已编写?
自动生成的文档:
/tasks 命令 - 任务列表生成核心作用:分析设计文档,生成按依赖关系排序的可执行任务列表
执行机制:
使用方法:
/tasks
任务生成规则:
[P](可并行)[P](可并行)[P](可并行)任务依赖顺序:
设置任务 → 测试任务 → 实现任务 → 集成任务 → 完善任务
↓ ↓ ↓ ↓ ↓
T001 T002 T005 T008 T010
T003 T004 T006 T009 T011
T007 T012
输出示例:
## 任务列表
### 设置阶段
- **T001**: 项目初始化和依赖安装
- **T002**: 代码检查和格式化配置
### 测试阶段(可并行执行)
- **T003 [P]**: WebSocket 事件契约测试
- **T004 [P]**: REST API 契约测试
- **T005 [P]**: 用户模型单元测试
### 实现阶段
- **T006**: 实现用户认证服务
- **T007**: 实现聊天室管理服务
- **T008**: 实现 WebSocket 消息处理
### 并行执行示例
```bash
# 可以同时运行的任务组
Group 1: T003, T004, T005
Group 2: T010, T011, T012
### 🏛️ 九大架构原则(项目宪法)
Spec Kit 的核心是内置的**项目宪法**(`.specify/memory/constitution.md`),这是一套不可变的架构原则,确保所有生成的代码都遵循一致的质量标准和设计哲学。
#### 📜 宪法核心条款
##### 第 I 条:库优先原则(Library-First Principle)
```markdown
每个功能必须首先作为独立库实现。
不允许直接在应用代码中实现功能,必须先抽象为可重用的库组件。
约束效果:强制模块化设计,确保代码可重用和可测试。
所有 CLI 接口必须:
- 接受文本输入(通过 stdin、参数或文件)
- 产生文本输出(通过 stdout)
- 支持 JSON 格式的结构化数据交换
约束效果:确保所有功能都可观察、可测试、可自动化。
这是不可协商的:所有实现必须遵循严格的测试驱动开发。
在编写实现代码前必须:
1. 编写单元测试
2. 测试经用户验证和批准
3. 确认测试失败(红色阶段)
约束效果:彻底颠覆传统 AI 代码生成,强制'测试先行'的开发模式。
第 7.3 节:最小项目结构 - 初始实现最多 3 个项目
额外项目需要文档化理由
约束效果:对抗过度工程化,确保简单性优于复杂性。
第 8.1 节:框架信任 - 直接使用框架特性而非包装它们
避免创建不必要的抽象层
约束效果:防止 AI 创建过度抽象的代码架构。
测试必须使用真实环境:
- 优先使用真实数据库而非模拟
- 使用实际服务实例而非桩
- 实现前必须有契约测试
约束效果:确保生成的代码在真实环境中可用,而非仅在理论上可行。
每个实现计划都必须通过以下门控:
### 阶段 -1:实现前门控
#### 简化门控(第 VII 条)
- [ ] 使用≤3 个项目?
- [ ] 无未来证明?
#### 反抽象门控(第 VIII 条)
- [ ] 直接使用框架?
- [ ] 单一模型表示?
#### 集成优先门控(第 IX 条)
- [ ] 契约已定义?
- [ ] 契约测试已编写?
如果违反原则,必须在'复杂度追踪'部分记录理由:
### 复杂度追踪
**违反第 VII 条**:使用了 4 个项目
**理由**:微服务架构需要独立的认证服务
**批准者**:架构师审核通过
**审核日期**:2024-01-15
虽然核心原则不可变,但应用方式可以演进:
第 4.2 节:修订程序
对本宪法的修改需要:
- 明确记录变更理由
- 项目维护者审查批准
- 向后兼容性评估
这确保了方法论能够学习和改进,同时保持稳定性。
Spec Kit 通过精心设计的模板来约束 AI 行为,确保生成高质量的规范和代码。这些模板不仅是文档结构,更是智能的行为引导系统。
规范模板明确指示:
- ✅ 专注于用户需要什么和为什么
- ❌ 避免如何实现(无技术栈、API、代码结构)
效果:强制 AI 维持适当的抽象层次,确保规范稳定性。
创建规范时:
1. 标记所有模糊性:使用 [需要澄清:具体问题]
2. 不要猜测:如果提示没有指定某些内容,标记它
效果:防止 AI 做出可能错误的假设,确保规范的准确性。
### 需求完整性检查
- [ ] 没有 [需要澄清] 标记
- [ ] 需求可测试且明确
- [ ] 成功标准可衡量
- [ ] 所有用户故事有验收标准
效果:为 AI 提供自检框架,确保输出质量。
重要:实现计划应保持高层次和可读性。
任何代码示例、详细算法或扩展技术规范
必须放在相应的 implementation-details/文件中
效果:防止文档变成不可读的代码转储,保持清晰的信息架构。
位于 .specify/memory/constitution.md,可以在标准九大原则基础上添加项目特定原则:
# 项目宪法
## 标准原则(来自 Spec Kit)
[自动包含九大架构原则]
## 项目特定原则
### X. 数据隐私优先
所有用户数据处理必须:
- 遵循 GDPR/CCPA 合规要求
- 实现数据最小化原则
- 提供明确的用户同意机制
### XI. 性能标准
- API 响应时间 < 500ms (P95)
- 数据库查询 < 2s
- 支持 100 并发用户
- 内存使用 < 2GB
### XII. 安全要求
- 所有 API 端点必须认证
- 敏感数据必须加密
- 定期安全扫描
可以修改 .specify/templates/ 目录下的模板文件来适应团队需求:
<!-- .specify/templates/custom-spec-template.md -->
# 功能规范:[功能名称]
## 业务背景 [BUSINESS_CONTEXT]
- 为什么需要这个功能
## 用户画像 [USER_PERSONAS]
- 目标用户群体
## 核心价值 [CORE_VALUE]
- 这个功能为用户带来什么价值
## 功能需求 [FUNCTIONAL_REQUIREMENTS]
## 验收标准 [ACCEPTANCE_CRITERIA]
## [需要澄清] 项目
- [需要澄清:认证方式 - OAuth、SAML 还是简单密码?]
- [需要澄清:数据保留政策 - 保存多长时间?]
可以修改 .specify/templates/plan-template.md 来适应特定的技术栈或架构模式:
### 技术上下文(自定义部分)
- 强制使用公司标准技术栈
- 必须符合企业安全政策
- 集成现有的监控和日志系统
- 遵循公司 API 设计规范
这是 Spec Kit 官方文档中的完整示例,展示了从需求到实现的完整流程:
/specify 构建一个照片管理应用,帮助我将照片整理到单独的相册中。相册按日期分组,可以在主页面上通过拖拽重新排序。相册永远不会嵌套在其他相册中。在每个相册内,照片以磁贴界面预览。
自动执行的操作:
001-photo-management-appspecs/001-photo-management-app/spec.md/plan 应用使用 Vite 构建,尽量减少库的使用。尽可能使用原生 HTML、CSS 和 JavaScript。图片不上传到任何地方,元数据存储在本地 SQLite 数据库中。
自动生成的文档:
plan.md - 详细实现计划research.md - Vite 和 SQLite 技术研究data-model.md - 相册和照片数据模型contracts/api-spec.json - 本地 API 接口定义quickstart.md - 本地开发环境设置/tasks
生成的任务列表:
### 设置阶段
- T001: 初始化 Vite 项目和 SQLite 数据库
- T002: 配置开发环境和构建工具
### 测试阶段(可并行执行)
- T003 [P]: 相册管理 API 契约测试
- T004 [P]: 照片元数据 API 契约测试
- T005 [P]: 拖拽功能集成测试
### 实现阶段
- T006: 实现 SQLite 数据库模型
- T007: 实现相册管理功能
- T008: 实现照片导入和预览
- T009: 实现拖拽排序功能
这是一个更复杂的企业级应用示例:
/specify 开发 Taskify,一个团队生产力平台。允许用户创建项目,添加团队成员,分配任务,评论并在看板风格的板块间移动任务。在这个初始阶段,我们要有多个用户但用户是预定义的。我需要 5 个用户分为两个类别,一个产品经理和四个工程师。让我们创建三个不同的示例项目。我们要有标准的看板列,如'待办'、'进行中'、'审查中'和'完成'。应用没有登录功能,这只是第一个测试版本。
规范特点:
/plan 使用.NET Aspire 生成,使用 Postgres 作为数据库。前端应使用 Blazor 服务器,具有拖放任务板和实时更新。应创建 REST API,包括项目 API、任务 API 和通知 API。
架构合规检查:
#### 简化门控(第 VII 条)
- [x] 使用≤3 个项目?(Web 应用 + API + 数据库)
- [x] 无未来证明?(仅实现当前需求)
#### 反抽象门控(第 VIII 条)
- [x] 直接使用框架?(直接使用 Blazor 和.NET Aspire)
- [x] 单一模型表示?(统一的任务和项目模型)
/tasks
强制 TDD 流程:
### 测试优先阶段
- T001: 编写项目管理 API 契约测试
- T002: 编写任务 CRUD 操作契约测试
- T003: 编写看板拖拽行为集成测试
- T004: 获得用户对测试场景的确认
- T005: 验证所有测试均失败(红色阶段)
### 实现阶段(仅在测试通过后)
- T006: 实现项目管理服务使 T001 通过
- T007: 实现任务服务使 T002 通过
- T008: 实现前端拖拽使 T003 通过
传统开发方式(12 小时文档工作):
1. 编写 PRD 文档(2-3 小时)
2. 创建设计文档(2-3 小时)
3. 手动设置项目结构(30 分钟)
4. 编写技术规范(3-4 小时)
5. 创建测试计划(2 小时)
总计:约 12 小时的文档工作
SDD 方式(15 分钟):
# 5 分钟:创建功能规范
/specify 实时聊天系统,支持消息历史和用户在线状态
# 5 分钟:生成实现计划
/plan WebSocket 实时消息,PostgreSQL 历史,Redis 在线状态
# 5 分钟:生成可执行任务
/tasks
# 结果:完整的项目规范、技术计划、API 契约、数据模型、任务列表
质量对比:
✅ 好的规范:
"用户需要能够在断网情况下继续浏览已下载的内容,确保用户体验不受网络状况影响"
❌ 错误的规范:
"实现 Service Worker 缓存策略,使用 IndexedDB 存储离线数据,配置 Webpack 离线插件"
✅ 正确做法:
"用户可以邀请其他用户加入聊天室 [需要澄清:邀请方式 - 邮件链接、用户名搜索还是邀请码?]"
❌ 错误做法:
"用户通过邮件链接邀请其他用户加入聊天室"(除非明确指定)
✅ 可测试:
"当用户拖拽任务卡片到'完成'列时,系统应在 2 秒内更新状态并向项目成员发送通知"
❌ 不可测试:
"任务完成后系统会合理地通知相关人员"
# 阶段 1:核心 MVP
/specify 用户认证和基本任务管理
# 阶段 2:协作功能
/specify 任务评论和团队通知
# 阶段 3:高级功能
/specify 项目分析和报告功能
同一规范生成多种实现方案:
现有系统的逐步改进:
1. 业务分析师 → 使用/specify 创建初始规范
2. 技术负责人 → 审查技术可行性,添加约束
3. 产品经理 → 验证业务逻辑,确认优先级
4. 架构师 → 确保宪法合规性
5. 全体确认 → 解决所有 [需要澄清] 项目
# 功能分支命名自动化
/specify → 自动创建 003-user-management-system
# 合并策略
git checkout main
git merge 003-user-management-system
# 包含完整规范和计划
### 可并行执行的功能
- 001-user-authentication [开发团队 A]
- 002-product-catalog [开发团队 B]
- 003-order-processing [开发团队 C]
### 依赖关系
- 003 依赖 001(订单需要用户认证)
- 共享的数据模型需要协调
每个/plan 命令都会自动检查:
# 自动检查规范质量
- 所有 [需要澄清] 标记已解决
- 每个功能需求都有对应的验收标准
- 用户故事格式正确(作为...我希望...以便...)
- 成功标准可量化测量
传统问题:规范与代码逐渐偏离
SDD 解决方案:规范是代码生成的唯一来源
变更流程:需求变化 → 更新规范 → 重新生成计划 → 更新任务 → 重新实现
❌ 错误:在规范中描述数据库表结构、API 端点、类名
✅ 正确:描述用户需要什么数据、什么操作、什么体验
❌ 错误:假设'用户登录'就是邮箱密码认证
✅ 正确:标记 [需要澄清:认证方式] 并与干系人确认
❌ 错误:为了'更好的架构'创建复杂的抽象层
✅ 正确:遵循简化和反抽象原则,直接使用框架
❌ 错误:一次性规范整个系统
✅ 正确:每个功能一个独立规范,逐步迭代
特征:每日多次部署,需求变化极快
建议:可以使用简化的 SDD 流程,专注/specify 阶段
特征:目标不明确,大量试错
建议:等研究结果稳定后再应用 SDD
特征:<100 行代码,单一功能
建议:直接编码比规范编写更高效
症状:uvx 命令不存在
解决方案:
# Linux/macOS
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
# 验证安装
uv --version
症状:安装时提示 Python 版本要求
解决方案:
# 检查 Python 版本
python --version
# 需要 >= 3.11
# 使用 pyenv 管理 Python 版本
pyenv install 3.11.0
pyenv global 3.11.0
症状:/specify、/plan、/tasks 命令无效
解决方案:
# 检查 CLAUDE.md 是否正确生成
ls -la CLAUDE.md
# 重新初始化项目
uvx --from git+https://github.com/github/spec-kit.git specify init --here --ai claude
# 确认 AI 助手配置
cat CLAUDE.md | grep -A 5 "specify\|plan\|tasks"
症状:生成的规范过于简单、缺少关键信息或偏离需求
根本原因分析:
解决方案:
# ✅ 改进输入描述示例
/specify 构建一个团队任务管理系统。产品经理需要能够创建项目和分配任务给开发人员,开发人员需要能够更新任务状态并添加进度评论,团队负责人需要能够查看项目整体进度和团队工作负载。系统应该支持 5-50 人的团队规模,任务状态包括待办、进行中、审查中、已完成。用户界面应该直观易用,适合技术和非技术人员使用。
# ❌ 避免的输入方式
/specify 用 React 做个看板系统,有拖拽功能,用 MongoDB 存数据
症状:/plan 命令生成的计划不符合宪法原则
解决方案:
# 检查并修复常见违规
#### 简化门控失败
问题:生成了超过 3 个项目
解决:合并相关项目,如将 API 网关和业务服务合并
#### 反抽象门控失败
问题:创建了过多的抽象层
解决:直接使用框架特性,移除中间包装层
#### 测试优先门控失败
问题:没有契约测试计划
解决:在 contracts/ 目录添加 API 规范,生成对应测试
症状:/tasks 生成的任务顺序不合理或依赖关系错误
解决方案:
# 检查输入文档质量
ls specs/001-feature-name/
# 确保存在:plan.md, data-model.md, contracts/
# 手动调整任务顺序
# 编辑 specs/001-feature-name/tasks.md
# 遵循:设置 → 测试 → 实现 → 集成 → 完善
症状:多个功能规范时工具响应慢
解决方案:
# 分模块处理
每个功能独立一个分支和规范目录
001-user-management/
002-product-catalog/
003-order-processing/
# 清理旧的规范文件
find specs/ -name "*.md" -mtime +30 -type f
症状:分支创建失败或合并冲突
解决方案:
# 检查 Git 状态
git status
git branch -a
# 清理未完成的功能分支
git branch -D 001-incomplete-feature
# 重新开始功能开发
git checkout main
/specify [新的功能描述]
# .github/workflows/sdd-pipeline.yml
name: Spec-Driven Development Pipeline
on: [push, pull_request]
jobs:
validate-specs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Spec Kit
run: |
pip install uv
uvx --from git+https://github.com/github/spec-kit.git specify check
- name: Validate Specification Quality
run: |
# 检查所有 [需要澄清] 是否已解决
if grep -r "\[需要澄清" specs/; then echo "ERROR: Found unresolved clarification markers"; exit 1; fi
- name: Constitutional Compliance Check
run: |
# 验证宪法合规性
python scripts/check-constitution-compliance.py
- name: Generate Implementation Report
run: |
# 基于规范生成实现报告
uvx --from git+https://github.com/github/spec-kit.git specify generate-report
# scripts/spec-review.sh
#!/bin/bash
echo "🔍 自动规范审查..."
# 检查规范完整性
for spec_file in specs/*/spec.md; do
if ! grep -q "验收标准" "$spec_file"; then
echo "❌ $spec_file 缺少验收标准"
exit 1
fi
done
echo "✅ 所有规范通过基本检查"
enterprise-workspace/
├── shared/
│ ├── constitution.md # 企业统一宪法
│ ├── templates/ # 共享模板库
│ └── standards/ # 编码标准
├── frontend-app/ # 前端项目
├── backend-api/ # 后端 API
├── mobile-app/ # 移动应用
└── data-pipeline/ # 数据管道
# 创建企业工作区
mkdir enterprise-workspace
cd enterprise-workspace
# 设置共享资源
mkdir shared/{templates,standards}
# 初始化各个项目并链接共享资源
for project in frontend-app backend-api mobile-app data-pipeline; do
uvx --from git+https://github.com/github/spec-kit.git specify init $project --ai claude
ln -sf ../shared/constitution.md $project/memory/constitution.md
ln -sf ../shared/templates/* $project/templates/
done
<!-- shared/templates/enterprise-api-spec.md -->
# 企业 API 规范模板
## 业务上下文 [BUSINESS_VALUE]
- 这个 API 为业务带来什么价值
## 安全要求
- OAuth 2.0 认证 (企业标准)
- 所有端点必须 HTTPS
- 敏感数据字段加密
## 性能标准
- P95 响应时间 < 500ms
- 支持 1000 QPS
- 99.9% 可用性
## 合规要求
- GDPR 数据保护
- SOX 审计跟踪
- PCI DSS 安全标准 (如涉及支付)
# 创建可重用的架构模式
shared/patterns/
├── microservices-pattern.md # 微服务架构模式
├── event-driven-pattern.md # 事件驱动模式
├── auth-pattern.md # 认证授权模式
└── data-consistency-pattern.md # 数据一致性模式
# scripts/spec-analytics.py
"""
分析历史规范质量,提供改进建议
"""
def analyze_spec_quality(spec_path):
"""分析规范质量指标"""
metrics = {
'clarity_score': calculate_clarity(spec_path),
'completeness_score': check_completeness(spec_path),
'testability_score': assess_testability(spec_path),
'compliance_score': verify_constitution(spec_path)
}
return metrics
def suggest_improvements(metrics):
"""基于指标提供改进建议"""
suggestions = []
if metrics['clarity_score'] < 0.8:
suggestions.append("建议增加更多业务上下文和用户价值说明")
if metrics['testability_score'] < 0.7:
suggestions.append("验收标准需要更具体和可量化")
return suggestions
# 定期更新模板基于项目反馈
# scripts/template-optimization.sh
#!/bin/bash
echo "📊 分析规范质量数据..."
# 收集过去 30 天的规范数据
find specs/ -name "spec.md" -mtime -30 > recent_specs.txt
# 生成质量报告
python scripts/spec-analytics.py recent_specs.txt > quality_report.json
# 更新模板
python scripts/update-templates.py quality_report.json
echo "✨ 模板已根据质量数据优化"
# .github/workflows/spec-review.yml
name: Specification Review
on:
pull_request:
paths: ['specs/**']
jobs:
auto-review:
runs-on: ubuntu-latest
steps:
- name: Constitutional Compliance
run: scripts/check-constitution.py
- name: Business Logic Review
run: scripts/business-review.py
- name: Technical Feasibility
run: scripts/tech-review.py
- name: Request Human Review
if: failure()
run: |
gh pr review --request-reviewer=architect-team
gh pr comment --body "🚨 自动审查发现问题,需要人工审查"
# 检查跨项目 API 依赖
python scripts/check-api-dependencies.py \
--consumer specs/frontend-app/contracts/ \
--provider specs/backend-api/contracts/ \
--report dependency-report.json
GitHub Spec Kit 是开源项目,欢迎社区参与:
git checkout -b feature/your-contributiongit commit -m "Add: 描述你的贡献"对于企业用户的特殊需求:
本项目采用 MIT 开源许可证,详见 LICENSE 文件。
GitHub Spec Kit 不仅仅是一个工具,它代表了软件开发模式的根本性变革。通过规范驱动开发 (SDD),我们从'规范指导代码'进化到'规范生成代码',实现了:
🌟 拥抱未来:让 AI 理解你的业务需求,通过可执行规范直接生成高质量代码!这就是规范驱动开发的强大威力!

微信公众号「极客日志」,在微信中扫描左侧二维码关注。展示文案:极客日志 zeeklog
生成新的随机RSA私钥和公钥pem证书。 在线工具,RSA密钥对生成器在线工具,online
基于 Mermaid.js 实时预览流程图、时序图等图表,支持源码编辑与即时渲染。 在线工具,Mermaid 预览与可视化编辑在线工具,online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具,curl 转代码在线工具,online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具,Base64 字符串编码/解码在线工具,online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具,Base64 文件转换器在线工具,online
将 Markdown(GFM)转为 HTML 片段,浏览器内 marked 解析;与 HTML 转 Markdown 互为补充。 在线工具,Markdown 转 HTML在线工具,online