Requirements Spec

用于编写正式需求和用户故事。

When to Use

• 需要整理功能需求或非功能需求
• 需要梳理 MVP 与后续迭代
• 需要明确约束和优先级
• 从模糊想法进入正式需求文档

Input

Output Schema

Minimum Viable Output

• user-stories.md 含 ≥3 条用户故事，格式为"作为...我希望...以便..."
• 每条用户故事含优先级（高/中/低）
• 已区分 MVP 和后续迭代
• constraints.md 含 ≥2 条约束

Complete Output

• user-stories.md 全部字段饱满：触发场景、验收关注点、依赖
• constraints.md 含技术约束、时间约束、资源约束、监管约束
• 已标注每条需求依赖哪些假设（回链 assumptions.md）

Dependencies

Procedure

1. 先确认目标项目根目录，并只更新该项目目录下的需求页
2. 用用户故事或能力清单表达需求
3. 区分 MVP、后续迭代、非目标
4. 把约束写成明确条目，避免散落在正文里

用户故事字段说明

每条用户故事应含以下字段：

| 字段 | 说明 | 示例 |
|------|------|------|
| ID | 唯一标识 | US-001 |
| 角色 | 谁（As a...） | 目标用户 |
| 能力 | 能做什么（I want to...） | 创建核心业务记录 |
| 目标 | 为什么（So that...） | 后续查询和管理 |
| 优先级 | 高/中/低 | P0 |
| 所属阶段 | MVP / 后续迭代 | MVP |
| 验收条件 | 可验证的完成标准 | ≥1 条 |
| 触发场景 | 何时会使用 | 早晨起床后 |
| 依赖 | 依赖哪些假设/其他 US | assumptions: A-001 |

MVP 划分标准

验收条件格式

每条 US 必须含 ≥1 条验收条件，格式如下：

✅ 验收条件 = [条件描述] + [通过标准]

示例：
- 验收条件：资源创建后可立即查询
- 通过标准：写入成功且查询接口返回新记录

Enriched Behavior

• 不只罗列功能点，要把需求组织成用户可理解、开发可执行、验收可映射的结构
• 可以同时给出用户故事、能力清单、优先级分层，避免单一表达方式信息密度不足
• 当用户需求含糊时，优先拆成可讨论的候选需求组，而不是直接武断定稿
• 对明显依赖前置设计的问题，主动回链到概览、假设或调研页面

Target Pages

• <项目根目录>/wiki/01-requirements/user-stories.md（主）
• <项目根目录>/wiki/01-requirements/constraints.md（主）

页面归属说明

Changelog