Spec 工作流：从需求到实施计划
本篇整合自三篇原始文档：
什么是 Spec 工作流
Spec 工作流是一种系统化的需求到实施计划的方法。它将整个开发过程分为三个阶段：
- 需求收集 — 将你的想法转化为结构化的需求文档
- 设计文档 — 基于需求创建技术设计文档
- 实施规划 — 将设计转化为可执行的任务清单
每一步都需要你的确认才能进入下一步。这个流程只创建设计和规划文档，实际编码通过单独的工作流完成。
阶段一：需求收集
工作流程
首先，基于你的功能想法以 EARS 格式生成初始需求集，然后与你迭代完善，直到需求完整准确。
EARS 格式说明
EARS（Easy Approach to Requirements Syntax）是一种简单直观的需求编写格式：
格式："作为[角色]，我想要[功能]，以便[收益]"
需求文档结构
生成的 requirements.md 应该包含：
- 清晰的介绍部分，总结功能特性
- 层次化的编号需求列表，每个需求包含：
- 格式为"作为[角色]，我想要[功能]，以便[收益]"的用户故事
- 以 EARS 格式编写的编号验收标准列表
- 边缘情况、用户体验、技术约束和成功标准的考虑
示例格式
markdown
# [功能名称] 需求文档
## 概述
[功能的高级描述]
## 需求
### 需求 1：[标题]
**用户故事**：作为[角色]，我想要[功能]，以便[收益]
**验收标准**：
1. [标准 1]
2. [标准 2]
3. [标准 3]
### 需求 2：[标题]
...
约束条件
- 模型必须创建
.claude/specs/{feature_name}/requirements.md文件（如果尚不存在） - 模型必须基于你的粗略想法生成需求文档的初始版本，不会先问一堆问题
- 每次编辑需求文档后，必须问你"需求看起来合适吗？如果是，我们可以继续进行设计"
- 如果你请求更改或未明确批准，模型必须修改需求文档
- 模型必须在收到你的明确批准之前不得继续进行设计文档
阶段二：设计文档
工作流程
需求被批准后，模型会基于功能需求开发全面的设计文档，并在设计过程中进行必要的研究。
设计文档结构
设计文档应包含以下部分：
| 章节 | 描述 |
|---|---|
| 概述 | 功能的高层描述和目标 |
| 架构 | 系统的整体架构和组件关系 |
| 组件和接口 | 各组件的职责和它们之间的接口 |
| 数据模型 | 主要数据结构和存储方案 |
| 错误处理 | 错误场景和应对策略 |
| 测试策略 | 如何验证功能正确性 |
约束条件
- 模型必须创建
.claude/specs/{feature_name}/design.md文件 - 模型必须研究并在对话中建立上下文，不创建单独的研究文件
- 模型应该在适当时包含图表（使用 Mermaid）
- 设计文档完成后，必须问你"设计看起来合适吗？如果是，我们可以继续进行实施计划"
- 如果在设计期间发现差距，模型必须提供返回功能需求澄清的选项
阶段三：实施规划
工作流程
设计被批准后，模型会基于需求和设计创建包含编码任务清单的可操作实施计划。
任务文档结构
任务文档格式为编号复选框列表，最多两级层次结构：
markdown
## 实施计划
- [ ] **Epic 1：[名称]**（仅在需要时使用）
- [ ] 1.1 [子任务描述]
- [ ] 1.2 [子任务描述]
- [ ] **Epic 2：[名称]**
- [ ] 2.1 [子任务描述]
任务项要求
每个任务项必须包括：
- 明确的目标：涉及编写、修改或测试代码
- 附加信息：作为任务下的子项目符号
- 具体引用：对需求文档中特定需求的引用（引用细粒度的子需求，不仅仅是用户故事）
约束条件
- 模型必须创建
.claude/specs/{feature_name}/tasks.md文件 - 模型必须确保实施计划是一系列离散的、可管理的编码步骤
- 每个步骤以渐进方式建立在前面的步骤之上
- 应该优先考虑测试驱动开发
- 计划应该对步骤进行排序，以通过代码尽早验证核心功能
明确排除的非编码任务
以下类型的任务不应包含在实施计划中：
- 用户验收测试或用户反馈收集
- 部署到生产或暂存环境
- 性能指标收集或分析
- 运行应用程序测试端到端（但可以编写自动化测试）
- 用户培训或文档创建
- 业务流程变更或组织变更
- 营销或沟通活动
最终确认
任务文档完成后，必须问你"任务看起来合适吗？" 一旦任务文档获得批准，模型必须停止，并通知你可以通过打开 tasks.md 文件并点击任务项旁边的"开始任务"来开始执行任务。
开发原则（补充）
在执行任何任务时，应遵循以下核心编程原则：
| 原则 | 说明 |
|---|---|
| KISS | 追求代码和设计的极致简洁与直观，避免不必要的复杂性 |
| YAGNI | 仅实现当前明确所需的功能，抵制过度设计和不必要的未来特性预留 |
| SOLID | 单一职责、开放/封闭、里氏替换、接口隔离、依赖倒置 |
| DRY | 识别并消除代码或逻辑中的重复模式，提升复用性 |
使用示例
假设你说："我想做一个用户可以发帖、评论的社区功能。"
工作流会这样进行：
1. 需求收集 → 生成 specs/community/requirements.md：
## 需求 1：发帖功能
**用户故事**：作为注册用户，我想要发布帖子，以便分享内容
**验收标准**：
1. 用户可以在文本框中输入内容
2. 点击发布后，帖子出现在社区列表顶部
3. 未登录用户不能发帖
...
2. 设计文档 → 生成 specs/community/design.md：
## 架构
- 前端：React + Vite
- 后端：Express + SQLite
- 认证：JWT
## 数据模型
- User: id, username, email, password_hash
- Post: id, title, content, author_id, created_at
- Comment: id, content, post_id, author_id, created_at
...
3. 实施规划 → 生成 specs/community/tasks.md：
- [ ] 1.1 创建数据库 schema 和迁移脚本
- [ ] 1.2 实现用户注册和登录 API
- [ ] 1.3 实现帖子 CRUD API
- [ ] 2.1 创建帖子列表页面组件
...
每一步你都需要确认，工作流才会继续。