SpecKit 入手指南-概念篇
在 SDD(规范驱动开发)正在让 Vibe Coding 走在正确的方向上 中我们提到了 SDD 的诞生背景和核心理念， 强调了规范驱动开发的核心是使用规范来生成代码从而实现需求。
在这篇文章中我们将介绍如何使用 Cursor + SpecKit 进行规范驱动开发。
SpecKit 专注于对新项目的规范驱动开发， 如果你现在正在维护一些存量项目， 你可以参考 xxx, xxx。
简介
spec-kit 是由 GitHub 官方团队开发并维护的开源项目，全称为“💫 Toolkit to help you get started with Spec-Driven Development”（帮助你开始规范驱动开发的工具包）。它采用 MIT 开源协议，主要语言为 Python。 旨在帮助开发者和团队更高效地进行产品和技术开发。它通过“规范”来驱动需求、设计、开发和协作流程，将“需求文档”、“产品规范”与“代码实现”紧密结合起来。
解决的问题
- 需求与实现割裂：解决了需求文档与代码实现脱节的问题，让所有流程围绕“规范”展开。
- 协作低效：解决跨角色沟通（产品、开发、测试）低效、易混乱的问题。
- 工程落地难：通过标准化工具和流程，降低规范落地的门槛，提高开发速度。
- 智能化不足：引入 AI 助力，提升自动化程度，减少重复劳动。
核心概念
- 意图驱动开发，其中规范在“如何”之前定义“什么”
- 在组织原则指导下，利用保障措施创建详尽的规范说明
- 多步骤细化，而非从提示中一次性生成代码
- 对规范解释严重依赖高级 AI 模型能力
工作流
Spec Kit 的工作流旨在将模糊的需求通过一系列结构化的步骤，转化为高质量、可执行的代码，其核心在于“规范先行”。整个流程环环相扣，确保了开发过程的可控性与成果的可预测性。
结合 SDD 规范先行的本质， SpecKit 提供了一套完整的工作流， 包括：
1. 立宪法（项目原则） (Constitution)
这是工作流的基石。你需要在这里定义项目的“根本大法”，为后续所有工作设定护栏和方向。 注意这里还没有到需求层面， 只是一些项目原则和不可协商的规则。
- 目的：确立项目在代码质量、安全、性能、架构等方面的核心原则和不可协商的规则
- 命令：
/speckit.constitution - 关键产出：
.specify/memory/constitution.md文件。例如，你可以规定：“所有代码必须用TypeScript编写，禁用any类型；必须编写单元测试；UI组件使用React函数式组件。”在后续所有阶段，AI都会严格遵守这些原则。
2. 编写规范（Specify）
在此阶段，你只关注“做什么”（What）和“为什么”（Why），而不是“怎么做”（How）。
- 目的：将模糊的想法或需求转化为结构化的、无歧义的功能规格说明书，重点关注用户价值和验收标准。
- 命令：
/speckit.specify - 关键产出：
specs/<功能名称>/spec.md文件并触发内置脚本创建一个新的仓库分支，例如001-create-taskify。这份文档通常包含用户故事、功能需求列表和验收标准。例如，描述“用户可以将商品加入购物车”，而不是“需要创建一个addToCart的API接口”。
3. 做计划（Plan）
要将规格转化为具体的技术方案。这一阶段是连接需求与实现的桥梁。
- 目的：基于规格说明书，制定具体的技术架构、数据模型、技术选型和实施策略。
- 命令：
/speckit.plan - 关键产出：
specs/<功能名称>/plan.md，通常还会伴随产生data-model.md（数据模型）、api.md（API合约）等文档。例如，决定使用Vite构建前端，数据存储在IndexedDB中，并设计出核心的数据表和组件结构。
4. 分解任务（Tasks）
将宏大的技术方案分解为具体、可执行、有优先级和依赖关系的开发任务清单。
- 目的：创建一份清晰、原子化的开发路线图，使实现过程可控、可追踪。
- 命令：
/speckit.tasks - 关键产出：
specs/<功能名称>/tasks.md文件。这个文件会将工作分解为多个阶段（如设置、基础、功能实现、优化），每个任务都有唯一的标识符（如T001）、描述、预估时间和依赖关系。
5. 实现代码（Implement）
这里才到AI大显身手的阶段，它像一名严格的开发员，依据前序所有规划自动生成代码。
- 目的：让AI代理按照任务清单自动执行编码任务，确保代码符合宪法和规格。
- 命令：
/speckit.implement - 过程：AI会逐个读取
tasks.md中的任务，并开始编写代码、创建文件、运行命令。它会在终端实时报告进度，并在完成后标记任务为完成。最佳实践是分阶段实现，每完成一个阶段就进行验证，确保项目始终处于可运行状态。
✨ 增强步骤（可选但强烈推荐）
为了进一步提升成功率，可以在关键节点插入以下增强步骤：
- 澄清 (Clarify)：在“写规格”之后运行
/speckit.clarify，AI会主动识别规格中的模糊点，并以选择题或简答题形式向你提问（例如，“任务的优先级有几种？具体是哪几种？”）。这将需求歧义和返工风险前置解决。 - 一致性分析 (Analyze)：在“拆任务”之后、正式“实现”之前运行
/speckit.analyze。AI会全面检查宪法、规格、计划和任务文档之间是否存在逻辑矛盾或违反原则的地方，充当一个自动化的质量闸门。 - 质量检查清单 (Checklist)：它通常在生成技术方案（/speckit.plan）之后、开始实现之前进行，扮演着“质量闸门”的角色
和 OpenSpec 的区别
Spec Kit 和 OpenSpec 虽然都致力于通过规范驱动开发来解决 AI 编程中的不确定性，但它们在设计哲学、工作流程和适用场景上有着显著的不同。
- 核心定位：
- Spec Kit：企业级治理工具，强调流程标准化，
- OpenSpec：轻量级敏捷框架，强调变更隔离与快速迭代。
- 设计哲学：
- Spec Kit：规格即代码工件”：提供结构化、线性的工作流，
- OpenSpec “变更隔离”：将当前事实规格与变更提案分离管理。
- 工作流程：
- Spec Kit：严格的多阶段线性流程（如：宪法→规格→计划→任务→实现），
- OpenSpec 灵活的三步敏捷循环（提案→应用→归档）。
- 流程特点：
- Spec Kit：类似瀑布模型，每一步都有明确的产出和质量门禁，严谨但稍显繁重，
- OpenSpec 类似敏捷冲刺，迭代速度快，侧重快速对齐和实现
- 理想场景
- Spec Kit：大型团队、全新项目（绿地开发）、有严格合规和审计要求的场景
- OpenSpec 小型敏捷团队、现有项目（棕地开发）、需要快速原型验证和迭代的场景
- 学习曲线
- Spec Kit：相对陡峭，需要理解多阶段流程和规范文档结构，
- OpenSpec 相对平缓，适合敏捷团队快速上手。
- 适用阶段
- Spec Kit：适合项目初期（宪法制定）和需求明确后的规范制定
- OpenSpec 适合项目迭代中（变更提案与应用）和快速原型验证阶段
Spec Kit 像是一位经验丰富的资深架构师，为你规划好每一步的蓝图并确保万无一失；而 OpenSpec 则更像一位高效的敏捷开发者，能与你快速对齐意图并立即投入实战。
关注我， 下一篇我们将介绍 SpecKit 的实战案例， 敬请期待。
公众号会持续输出，欢迎关注。 如果对你有帮助，欢迎点赞、收藏、关注。 