最近GitHub上新开源的SpecKit引起了我的注意,上线不到一周就收获了大量关注。

不同于市面上那些"一键生成代码"的AI工具,SpecKit提出了一个更本质的问题:在让AI写代码之前,我们是否应该先让AI帮我们想清楚要做什么?
这就是SpecKit倡导的"Spec-Driven Development"(规范驱动开发)理念。
它颠覆了传统的开发模式过去我们写完代码就扔掉规范文档,现在规范本身就能直接生成可执行的实现。
听起来有点激进?但结合AI的能力后,这套方法论展现出了令人惊喜的效率提升。
重新定义开发流程的六步工作法
SpecKit的精髓在于将整个开发过程拆解为六个渐进式阶段,每个阶段都有明确的产出物和斜杠命令支持:
1. Constitution(立宪阶段)
命令: /constitution
这一步是确立项目的基本原则和不可妥协的底线。以一个照片管理应用为例,你可以这样设定Constitution:
/constitution Create principles focused on code quality,
testing standards, user experience consistency,
and performance requirements
系统会自动生成constitution.md
文档,包含:
-
代码质量标准:清晰易读优先,避免过度优化
-
测试规范:单元测试覆盖率要求
-
用户体验原则:响应时间、交互流畅度等指标
-
性能要求:启动时间、内存占用等硬性指标
这些原则会贯穿整个项目生命周期,成为所有AI生成代码的判断标准。
2. Specify(需求明确阶段)
命令: /specify
这个阶段专注于描述要做什么和为什么做,而不涉及技术选型。比如:
/specify Build an application that can help me organize
my photos in separate photo albums. Albums are grouped
by date and can be re-organized by dragging and dropping
on the main page. Albums are never in other nested albums.
Within each album, photos are previewed in a tile-like interface.
系统会自动生成结构化的spec.md
文档,包含:
-
用户故事和使用场景
-
核心功能需求清单
-
交互设计要点
-
数据模型概览
重点是,这份规范文档不是一次性产物,而是可执行的规范——后续所有实现都会基于它生成。
3. Clarify(需求澄清阶段)
命令: /clarify
这是SpecKit的一个独特设计。在正式制定技术方案前,系统会主动识别需求中的模糊点并提出问题。比如:
-
照片导入方式是拖拽还是选择文件?
-
是否需要支持批量操作?
-
删除相册时照片如何处理?
通过这个阶段的交互,可以显著降低后期返工概率。如果你确认需求已经足够清晰,也可以明确跳过这一步。
4. Plan(方案设计阶段)
命令: /plan
有了明确的需求后,在这个阶段提供你的技术偏好:
/plan The application uses Vite with minimal number
of libraries. Use vanilla HTML, CSS, and JavaScript
as much as possible. Images are not uploaded anywhere
and metadata is stored in a local SQLite database.
系统会生成plan.md
,包含:
-
技术栈选择:框架、库、工具链
-
架构设计:模块划分、数据流设计
-
存储方案:数据库选型、文件组织结构
-
部署策略:构建流程、环境配置
5. Tasks(任务拆解阶段)
命令: /tasks
这是最令我惊喜的功能。基于前面的spec和plan,系统自动生成详细的任务列表:
/tasks
实测中,一个中等规模的项目会拆解出40-50个具体任务,包括:
-
基础建设:项目结构搭建、依赖配置、环境设置
-
核心开发:数据模型、服务层、视图组件
-
进阶功能:交互优化、性能调优
-
质量保证:测试覆盖、错误处理
每个任务都有清晰的描述和验收标准,开发过程就像RPG游戏打怪升级一样有成就感。
6. Analyze(一致性分析)
命令: /analyze
在正式编码前,SpecKit会进行跨文档的一致性检查:
-
Spec与Plan是否匹配?
-
Tasks是否覆盖所有需求?
-
是否存在相互矛盾的设计决策?
这个阶段相当于自动化的技术评审,能在早期发现潜在问题。
7. Implement(执行实现阶段):多AI协作编码
命令: /implement
最后一步是实际编写代码:
/implement
SpecKit会按照任务清单逐一实现,最终交付完整可运行的应用。
核心亮点
支持10+主流AI编程助手
SpecKit最大的亮点是AI Agent无关性。你可以在这些工具间无缝切换:
AI Agent支持状态特点
Claude Code✅ 完全支持擅长架构设计和复杂逻辑
GitHub Copilot✅ 完全支持微软官方,集成度最高
Cursor✅ 完全支持交互便捷,适合快速迭代
Windsurf✅ 完全支持新兴工具,性能优秀
Qwen Code✅ 完全支持国产AI,中文理解能力强
Gemini CLI✅ 完全支持Google出品,多模态能力强
opencode✅ 完全支持开源友好
Kilo Code✅ 完全支持轻量级方案
Auggie CLI✅ 完全支持企业级支持
Roo Code✅ 完全支持协作开发优化
Codex CLI⚠️ 部分支持不支持自定义斜杠命令参数
实测中我发现,如果对某个AI生成的代码不满意,可以基于相同的spec切换到另一个AI重新实现。比如我用Claude Code生成初版架构后,切换到Cursor优化界面交互,最终应用的稳定性和用户体验都显著提升。
技术栈无关性
SpecKit的另一个哲学是技术中立。同一份spec可以生成:
-
前端:React/Vue/Svelte/原生JS
-
后端:Node.js/Python/Go/Rust
-
移动端:React Native/Flutter/SwiftUI
-
桌面端:Electron/Tauri/原生开发
这验证了一个重要假设:好的规范是技术无关的,应该专注于"要解决什么问题"而非"用什么技术解决"。
快速上手
方式一:持久化安装(推荐)
使用uv
工具一次性安装:
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
安装后直接使用:
specify init my-project --ai claude
specify check # 检查系统环境
优势:
-
工具持久化,无需重复安装
-
自动添加到PATH环境变量
-
支持
uv tool list
/upgrade
/uninstall
统一管理
方式二:一次性使用
如果只是临时尝试:
uvx --from git+https://github.com/github/spec-kit.git specify init my-project
初始化项目的常见场景
# 基础初始化
specify init my-project
# 指定AI助手
specify init my-project --ai cursor
# 在当前目录初始化
specify init . --ai copilot
# 或使用 --here 标志
specify init --here --ai copilot
# 强制合并到非空目录(跳过确认)
specify init . --force --ai copilot
# 使用PowerShell脚本(Windows/跨平台)
specify init my-project --ai copilot --script ps
# 跳过Git初始化
specify init my-project --ai gemini --no-git
# 启用调试输出
specify init my-project --ai claude --debug
# 使用GitHub Token(适合企业环境)
specify init my-project --ai claude --github-token ghp_your_token_here
实战效果
让我用一个真实案例展示完整流程——开发一个照片管理应用:
# 1. 初始化项目
specify init photo-manager --ai cursor
# 2. 建立项目原则
/constitution Focus on fast performance, intuitive UX,
and maintainable code
# 3. 定义需求
/specify Build a photo album manager with drag-drop
organization, date-based grouping, and tile preview
# 4. 澄清细节(可选)
/clarify # 系统会提出关键问题
# 5. 制定技术方案
/plan Use Vite + vanilla JS, SQLite for metadata,
local storage for images
# 6. 生成任务列表
/tasks
# 7. 质量检查
/analyze
# 8. 执行实现
/implement
整个过程中,我只需要提供初始想法和关键决策,剩下的结构化工作都由SpecKit完成。
更关键的是,这些文档不是一次性产物,而是可以持续迭代的"项目知识库"。
适用场景分析
根据我的使用体验,SpecKit在以下场景特别有价值:
强烈推荐:
-
0-to-1新项目(Greenfield):从零开始需要完整规划
-
大型功能开发:涉及多模块协作,需要明确接口
-
团队协作项目:多人参与,需要统一认知和可传承的文档
-
并行技术探索:同一需求尝试多种技术栈实现
-
遗留系统改造(Brownfield):为老项目添加新功能或现代化升级
不太适合:
-
快速原型验证:完整的spec流程会增加前期时间成本
-
小型bug修复:过于正式,杀鸡用牛刀
-
简单脚本编写:一次性工具类代码,直接用AI生成更快
实验性支持:
-
企业级约束场景:支持特定云服务商、技术栈、合规要求
-
创意探索:并行实现多种UX方案,快速对比效果
-
用户分层开发:从vibe-coding到AI-native,适配不同开发风格
类似项目对比
如果你对规范驱动开发感兴趣,也可以关注这些项目:
项目定位与SpecKit的区别
Aider代码级AI协作专注于代码编辑,与SpecKit形成互补
SweepIssue→PR自动化GitHub原生集成,侧重CI/CD流程
Copilot Workspace官方AI开发环境理念类似但更封闭,仅支持GitHub Copilot
Cursor Composer多文件编辑强于代码生成,弱于规范管理
SpecKit的独特价值在于:它是一个开放的流程框架,而非绑定特定AI或技术栈的工具。
核心理念
SpecKit背后的哲学非常值得玩味:
几十年来,代码一直是王者——规范只是搭建后就丢弃的脚手架。Spec-Driven Development改变了这一点:规范变得可执行,直接生成可工作的实现,而非仅仅指导实现。
这种转变带来三个关键价值:
意图驱动开发:先定义"做什么"再考虑"怎么做",避免过早陷入技术细节
多步骤精炼:不再是"一次prompt生成全部代码",而是逐步细化的结构化流程
充分利用AI能力:让AI在最擅长的领域(理解需求、生成规范)发挥价值
使用建议
经过两周的深度体验,我总结了几个实用技巧:
最佳实践:
-
Constitution要具体:不要写"代码要好",而要写"函数不超过50行,注释覆盖率>30%"
-
Spec要讲故事:用用户视角描述场景,而非直接列功能点
-
Plan要留白:给AI一定发挥空间,过度细节化反而限制创造力
-
多尝试AI切换:不同AI的strengths不同,Claude擅长架构,Cursor擅长交互
避坑指南:
-
非Git项目需设置环境变量:
SPECIFY_FEATURE=001-photo-albums
指定工作目录 -
Codex CLI限制:不支持自定义命令参数,功能受限
-
首次使用建议:从小项目开始,熟悉流程后再上大项目
系统要求与环境配置
在使用前,请确保满足以下条件:
-
操作系统:Linux/macOS或Windows WSL2
-
包管理器:
uv
(Python包管理工具) -
Python版本:3.11或更高
-
版本控制:Git
-
AI Agent:至少安装一个支持的AI编程助手
检查环境是否就绪:
specify check
系统会自动检测已安装的AI工具和必要依赖。
写在最后
作为一个看过太多"AI开发工具"来了又走的产品经理,我对SpecKit的印象是:它没有试图取代开发者,而是给开发者提供了一套更科学的思考方法。
在AI编程工具越来越"智能"的今天,SpecKit反而回归本质——先想清楚要做什么,再高效地去实现。这种"慢即是快"的哲学,配合多AI协作和技术中立的设计,让它成为了一个真正适合企业级开发的工具。
如果你正在寻找更结构化的开发方式,或者团队协作中经常出现"需求理解不一致"的问题,不妨试试这个刚在GitHub开源的SpecKit。它可能不会让你的开发速度提升10倍,但一定能让你的开发过程更清晰、更可控、更可传承。
项目地址: