规格驱动开发（Spec-Driven Development）
概览
使用该方法进行系统化的软件功能开发，以减少歧义、提升质量与可维护性，并通过结构化规划提高交付成功率。
元信息
- 名称: spec-driven-development
- 描述: 使用需求、设计、任务三阶段的系统化方法，把模糊功能想法转为清晰、可实现的解决方案，以减少歧义、提升质量并促进 AI 协作。
- 许可证: MIT
- 兼容性: Claude Code、Cursor、VS Code、Windsurf
- 元数据:
- 类别: methodology
- 复杂度: intermediate
- 作者: Kiro Team
- 版本: 1.0.0
三阶段工作流
阶段 1：需求收集
目的: 将模糊的功能想法转化为清晰、可测试的需求。
流程:
- 编写能够表达价值与目的的用户故事
- 使用 EARS 格式定义验收标准
- 识别边界情况与约束
- 验证完整性与可行性
EARS 格式模式:
WHEN [event] THEN [system] SHALL [response]
IF [precondition] THEN [system] SHALL [response]
WHEN [event] AND [condition] THEN [system] SHALL [response]
示例:
**用户故事:** 作为一名新用户，我希望创建账户，以便访问个性化功能。
**验收标准:**
1. WHEN 用户提供有效邮箱和密码 THEN 系统 SHALL 创建新账户
2. WHEN 用户提供已存在的邮箱 THEN 系统 SHALL 显示“邮箱已注册”错误
3. WHEN 用户提供短于 8 位的密码 THEN 系统 SHALL 显示“密码过短”错误
4. WHEN 账户创建成功 THEN 系统 SHALL 发送确认邮件
阶段 2：设计文档
目的: 形成全面的技术实现计划。
流程:
- 调研技术方案与约束
- 定义系统架构与组件交互
- 明确数据模型与接口
- 规划错误处理与测试策略
设计文档结构:
## 概览
[高层方案摘要]
## 架构
[系统组件与关系]
## 组件与接口
[组件的详细说明]
## 数据模型
[数据结构与校验规则]
## 错误处理
[错误场景与响应策略]
## 测试策略
[不同层级的测试方式]
决策记录:
### 决策: [标题]
**背景:** [需要决策的情境]
**候选方案:**
1. [方案 1] - 优点: [收益] / 缺点: [不足]
2. [方案 2] - 优点: [收益] / 缺点: [不足]
**决策:** [选择的方案]
**理由:** [选择原因]
阶段 3：任务规划
目的: 将设计拆解为可执行、可顺序推进的实现步骤。
流程:
- 把设计元素转化为具体编码任务
- 按依赖关系排序以支持增量交付
- 为每个任务定义清晰目标与完成标准
- 关联需求以便追溯
任务结构:
- [ ] 1. [史诗/主要组件]
- [ ] 1.1 [具体实现任务]
- [实现细节]
- [要创建的文件/组件]
- _需求: [需求引用]_
任务排序策略:
- 基础优先: 先做核心接口与基础设施，再做依赖组件
- 功能切片: 以端到端纵向切片验证主流程
- 风险优先: 优先处理不确定或高风险部分
- 混合: 根据项目特点组合使用
质量检查清单
需求清单
设计清单
任务清单
与 AI 工作流集成
面向 Claude Code / AI 助手:
- 先提供背景、约束与目标
- 依次完成需求、设计、任务三个阶段
- 通过对话迭代完善输出
- 使用清单进行自检与复核
- 维持需求、设计与任务之间的可追溯性
用于启动规格的示例提示:
我正在做 [项目背景]，需要新增 [功能描述]。
上下文:
- 技术栈: [stack]
- 用户: [目标人群]
- 约束: [关键限制]
请帮助我使用 EARS 格式编写需求，从用户故事与验收标准开始。
常见陷阱
- 跳过阶段：每个阶段都依赖前一步，跳过会导致返工
- 需求含糊：比如“系统要快”而非可衡量指标
- 把实现细节写进需求：需求关注“做什么”，不是“怎么做”
- 过度设计：只解决当前需求，避免为假设场景过度建设
- 任务过大：拆分到 2-4 小时的实现粒度
- 忽略错误场景：始终考虑失败与异常路径
后续步骤
- 按任务顺序开始实现
- 随进度勾选已完成任务
- 实现过程中发现缺口就更新规格
- 完成后对照需求进行验收
- 记录经验以便后续规格复用
