规格驱动开发工作流

技能文档

---
name: spec-workflow-guide
title: 规格驱动开发工作流
category: 开发工具
description: 在实现前先产出明确的需求规格、技术设计与任务拆解文档，适用于中大型功能开发、跨模块改造、验收标准模糊或架构级任务的分阶段确认式开发。当用户需要需求文档、技术设计文档、任务拆解、EARS 验收标准或规格驱动开发等场景时触发。
---

# 规格驱动开发工作流

## 何时使用

适合使用本工作流的场景：

- 定义或打磨新功能
- 设计复杂架构
- 协调跨模块改动
- 规划数据库或重 UI 的工作
- 提升需求质量与验收边界清晰度

不适合的场景：

- 范围明确的小 bug 修复
- 单文件文档更新
- 简单配置变更
- 用户已给出精确实现指令的微小重构

## 技能工作流

### 步骤1：判断是否走完整流程

- 任务中大型、影响跨模块、验收边界模糊、用户希望先规划后实现 → 走完整流程
- 任务小、低风险、目标与验收已足够清晰、用户明确要求直接改代码 → 允许直接执行，不强制产出规格文档

常见错误：验收标准未明确就开写代码；需求、设计、任务之间跳过用户确认；任务写得太虚、无法对应到用户可见结果；把 UI 工作当成纯技术实现而不澄清设计意图。

### 步骤2：编写需求文档

创建 `specs/<spec_name>/requirements.md`：

- 复述问题与范围
- 编写用户故事
- 用 EARS 风格编写验收标准
- 澄清业务规则、约束与非目标

EARS 模式：

```text
当<可选前置条件>时，若<可选触发条件>，则<系统名称>应当<系统响应>
```

示例：

```text
当用户提交表单时，预订系统应当在创建记录前校验必填字段。
```

### 步骤3：编写设计文档

创建 `specs/<spec_name>/design.md`：

- 描述架构与模块边界
- 说明技术选型与权衡
- 按需定义数据模型、API、安全与测试策略
- 仅当图表能实质提升清晰度时使用 Mermaid

### 步骤4：拆解任务

创建 `specs/<spec_name>/tasks.md`：

- 把设计拆解为可执行任务
- 保持任务具体、可评审
- 每个任务回链到对应需求
- 随工作推进更新任务状态

任务格式：

```markdown
# 实施计划

- [ ] 1. 任务标题
  - 具体工作项
  - 另一个具体步骤
  - _需求: 1
```

### 步骤5：确认后执行

仅在用户确认任务计划后开始实现。执行期间：

- 保持任务状态最新
- 一次完成一个有意义的工作单元
- 保持「改动 → 任务 → 需求」的可追溯链路

## 工作规则

1. 请求欠明确时主动追问，不猜测核心产品行为。
2. 需求、设计、任务拆解之间必须获得用户确认后再进入下一阶段。
3. 改动包含面向用户的页面或视觉决策时，尽早引入 UI 设计参考。
4. 文档保持简洁但可测试。
5. 任务命名优先面向用户可见结果，而非实现细节。

## 产出物

- `requirements.md`：问题、范围、用户故事、EARS 验收标准
- `design.md`：架构、技术方案、数据/API/安全/测试要点
- `tasks.md`：与需求挂钩的可执行实施清单

使用说明

# 规格驱动开发工作流

一句话：中大型改动先写需求、设计、任务三份规格文档，分阶段确认后再动手实现。

## 使用

直接对话，例如：

- 「我要加一个积分商城功能，先帮我出需求和设计文档」
- 「这次重构涉及三个模块，按规格流程拆解任务再实现」

## 工作原理

技能按「需求 → 设计 → 任务 → 执行」四阶段推进：需求阶段用 EARS 风格写验收标准，设计阶段明确架构与模块边界，任务阶段拆解出与需求挂钩的实施清单，每阶段需用户确认后才进入下一步，保证改动可追溯。

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。