Dev requirements

需求结构化

把模糊的想法变成可以直接进入架构设计的结构化需求文档。这一阶段不写任何代码、不做技术选型——只回答"做什么、为谁做、做到什么程度算完成"。

开工前对齐（必须）

动手前先向用户简述本阶段计划：准备围绕哪些维度提问、最终产出什么文件（docs/dev/01-requirements.md）。用户明确同意后才开始；用户有调整意见先吸收进计划再动手。

商量必须自带默认推荐：每个待定项都给出你建议的选项并标注「推荐」+一句理由，用户确认或改选即可，不许只抛开放式问题。

工作流程

1. 收集原始需求

先完整听用户说完。如果用户只给了一句话（如"我想做一个报销系统"），不要立刻开问，先根据常识列出你对这个需求的理解框架，再针对性提问。

2. 澄清关键问题（用 AskUserQuestion）

只问真正影响设计的问题，一次最多 3-4 个，分批进行。必须搞清楚的维度：

• 目标用户：谁用？多少人用？内部工具还是对外产品？
• 核心场景：用户最高频的 1-3 个操作路径是什么？
• 范围边界：第一版必须有什么？什么可以砍？（防止范围蔓延）
• 约束条件：截止时间、必须兼容的现有系统、部署环境（云/内网/信创）、预算
• 成功标准：怎么判断这个东西做成了？

已经能从上下文推断的不要问；用户明显不关心的细节（如具体交互样式）留到后面阶段。能给出合理默认答案的问题，把你的猜测作为推荐选项放第一位（标注"推荐"），用户点一下确认即可。

3. 输出结构化需求文档

写入项目根目录 docs/dev/01-requirements.md（目录不存在则创建）：

# 需求文档：<项目/功能名>

> 版本：v1.0 | 日期：<今天> | 状态：草稿/已确认

## 1. 背景与目标
一段话说清楚：现状是什么、痛点是什么、这个东西解决什么问题。

## 2. 用户与场景
| 角色 | 描述 | 核心诉求 |
|------|------|----------|

## 3. 功能需求
按优先级分组（MoSCoW）：

### P0 - 必须有（第一版没有就不能上线）
- **[REQ-001]** 作为<角色>，我要<做什么>，以便<获得什么价值>
  - 验收标准：
    - [ ] <具体的、可测试的判断条件>
    - [ ] <边界情况：为空/超长/并发/权限不足时的行为>

### P1 - 应该有（第一版尽量做）
### P2 - 可以有（明确排到后续版本）

## 4. 非功能需求
- 性能：预期用户量 / 并发 / 数据量级
- 安全：登录方式 / 权限模型 / 数据敏感级别
- 兼容：浏览器 / 移动端 / 操作系统 / 数据库要求

## 5. 明确不做（Non-goals）
写清楚哪些容易被误以为要做、但本期明确不做的事。

## 6. 开放问题
尚未确定、需要后续决策的点，标注决策人和期限。

4. 确认与交接

1. 把文档摘要（P0 列表 + Non-goals）念给用户确认，根据反馈修订。
2. 用户确认后，把文档状态改为"已确认"。
3. 提示用户：下一步运行 /dev-architecture 进入架构设计。

原则

• 每条需求必须有可测试的验收标准，"体验好""速度快"这种写法要落成具体数字或行为。
• 宁可 Non-goals 写多，不要范围默认膨胀。
• 用户说"都要"时，追问"如果只能先上一个功能，是哪个"来逼出真实优先级。
• 需求文档是后续所有阶段的锚点，改需求就改这个文件，不要口头改。