Spec - 需求规格说明技能
将模糊的需求意图转化为清晰、无歧义的需求规格文档。
核心原则
- 不猜测：遇到任何模糊点，必须向用户提问澄清，绝不自行假设
- 不模糊：每个需求边界必须是确定的，In Scope / Out of Scope 必须明确列出
- 不写代码：绝不写任何代码，包括伪代码。只用自然语言描述需求行为
- 固定产出：输出到项目既有的需求目录；若无统一约定，建议使用
spec/<spec-name>/spec.md
工作流程
第一步：理解与澄清
- 阅读用户给出的需求描述
- 阅读项目级背景文档（如 PRD、roadmap、里程碑文档；如果存在），理解整体背景
- 阅读已有的需求文档，避免重复或冲突
- 列出所有不确定的点，逐一向用户澄清
- 反复澄清直到无任何歧义
第二步：撰写 Spec
按照下方固定模板撰写，写入对应功能的 spec.md。
第三步：用户确认
将产出交给用户确认，根据反馈修订直到用户满意。
固定模板
# <功能名称> 需求规格说明
> 状态：草稿 | 已确认
> 创建日期：YYYY-MM-DD
> 所属里程碑：如项目使用里程碑则填写，否则写"无"
## 1. 概述
### 1.1 功能简述
一句话说清楚这个功能做什么。
### 1.2 所属模块
标明属于哪个系统、子模块、包、程序集、服务或运行时区域。
### 1.3 关联文档
列出关联的 PRD 章节、roadmap、设计稿、其他 spec。
## 2. 用户故事与场景
### 2.1 目标用户
明确这个功能服务于谁。
### 2.2 用户故事
使用 "作为 <角色>，我希望 <行为>，以便 <价值>" 格式。
### 2.3 使用场景
描述 2-3 个典型使用场景，包含前置条件和期望结果。
## 3. 功能需求
### 3.1 输入
明确所有输入来源、格式、必填/选填。
### 3.2 输出
明确所有输出目标、格式、成功/失败的结果。
### 3.3 核心行为描述
用自然语言逐条描述系统在每个场景下的具体行为。
**禁止使用代码或伪代码。**
### 3.4 业务规则与约束
列出所有业务逻辑规则、限制条件、异常处理要求。
## 4. 非功能需求
### 4.1 性能要求
如有明确指标则列出，无则标注"无特殊要求"。
### 4.2 安全要求
### 4.3 兼容性要求
## 5. 边界与限制
### 5.1 明确包含（In Scope）
逐条列出本次需求范围内的内容。
### 5.2 明确排除（Out of Scope）
逐条列出本次明确不做的内容。
### 5.3 已知约束
列出技术或业务上的已知限制。
## 6. 验收标准（Acceptance Criteria）
使用 "Given-When-Then" 格式逐条列出：
- **Given** <前置条件>
- **When** <用户操作>
- **Then** <期望结果>
## 7. 开放问题（Open Questions）
列出所有尚未解决的问题，标注负责人和期望解决日期。
如全部已解决则标注"无"。
## 8. 变更记录
| 日期 | 变更内容 | 变更人 |
|------|---------|--------|关键约束
- 绝不写代码：包括伪代码、代码片段、接口定义。这些属于 plan 阶段的职责
- 绝不猜测：宁可多问一轮，也不要用"可能"、"大概"、"应该"这类词
- 一个 spec 一个功能：不要在一个 spec 里塞多个不相关的功能
- spec-name 命名规则：使用小写英文 kebab-case，如
user-auth、payment-retry