requirement-intake — 需求输入与理解

定位：需求收集、分析与确认的完整流程。可被 dev-flow 阶段 0 按需调用，也可独立使用。 独立触发："帮我分析这个需求" / "走需求理解流程" / "帮我理解下这个 任务平台 单"

在 dev-flow 完整模式下作为阶段 0 自动加载（用户说"启动开发流程"/"新需求"/"走开发流程"等）。

需求输入方式

方式 A：交互式提问（默认）

当用户说"启动开发流程"/"新需求"但未提供需求信息时，使用 ask_followup_question 工具分步提问。

第 1 轮：了解需求本身

[
  {
    "id": "req_type",
    "question": "这次的需求属于哪种类型？",
    "options": ["Bug 修复", "新功能开发", "UI/样式调整", "性能优化", "重构/代码优化", "其他"],
    "multiSelect": false
  },
  {
    "id": "req_desc",
    "question": "请简要描述需求内容（也可以直接粘贴 任务平台 链接、Figma 链接、或截图）",
    "options": ["我直接在这里描述", "我贴 任务平台 链接", "我贴 Figma 设计稿", "我发截图"],
    "multiSelect": false
  }
]

第 2 轮（按需）：补充上下文

[
  {
    "id": "module",
    "question": "涉及哪个模块/页面？",
    "options": ["（根据项目实际模块动态生成）", "不确定"],
    "multiSelect": true
  },
  {
    "id": "env",
    "question": "有测试环境 URL 或其他补充信息吗？",
    "options": ["有，我来提供", "暂时没有", "不需要"],
    "multiSelect": false
  }
]

注意：module 选项应根据当前项目的实际模块结构动态生成。AI 应在首次使用时扫描项目结构，生成贴合实际的选项列表。

提问原则：

• 像自然对话一样提问，不要像填表
• 每轮最多 2-3 个问题，不要一次问太多
• 用户选择"其他"或给出自由文本回答时，自然追问细节
• 信息足够时立即进入需求理解，不要为了"走完流程"继续问已经明确的问题

方式 B：用户直接带信息启动

如果用户在说"启动开发流程"时已附带了需求描述、链接、截图等信息，跳过提问，直接进入需求理解。

方式 C：用户口头描述

用户以任何自然语言形式描述需求（如"播放器更多按钮点击没反应"），AI 直接进入需求理解分析。

需求来源适配

⚠️ 上下文持久化

需求信息（链接/类型/标题）在首次获取后应记录到工作上下文，避免后续重复索要。

需求理解

步骤 1：需求分析

收到需求信息后，AI 必须输出以下分析（不是直接动手）：

### 需求理解确认

**我的理解**：
（用自己的话复述需求，确保理解正确）

**涉及范围**：
- 模块/页面：
- 架构版本：（如 V2 架构 / 旧 TT 架构）
- 运行环境：（PC端 / 移动端 / SSR / CSR）

**技术初判**：
- 可能涉及的文件/组件：
- 预估改动量级：（小 / 中 / 大）
- 是否涉及第三方库：

**我的疑问**（如果有）：
1. ...
2. ...

请确认以上理解是否正确，以及回答我的疑问。

步骤 2：疑问确认

• 如有疑问，汇总后一次性提问，不要一个一个问
• 用户回答后，如果仍有不清楚的，继续追问
• 所有疑问都是阻塞性的，必须确认后才能继续

步骤 3：理解确认

所有疑问解决后，输出最终确认：

### 最终确认

需求理解已达到 99% 把握，准备进入开发阶段。

**将要做的事**：
1. ...
2. ...

**不会做的事**（明确边界）：
- ...

**开发顺序**：
1. ...
2. ...

确认无误后，我将进入步骤 1 开始开发。

步骤 4：需求确认交互（交互式）

最终确认输出后，必须使用 ask_followup_question 弹出交互式选项让用户确认：

需求分析已输出，请确认：

• 用户选「✏️ 补充/纠正」→ 接收补充信息 → 更新需求分析 → 重新弹出确认选项
• 用户选「❓ 我有疑问」→ 讨论解决 → 更新需求分析 → 重新弹出确认选项
• 用户选「✅ 理解正确」→ 需求理解完成，流程结束（或进入 dev-flow 下一阶段）