---
name: design-exploration
description: 新功能设计探索流程。当用户有模糊想法要做新功能/新模块时使用。通过"需求收敛 → 技术调研 → ASCII 批量探索 → HTML 设计稿 → 全状态覆盖 → 需求总结"的结构化流程，从模糊想法产出可交付的设计参考文档，作为 PRD 阶段的输入。
---

用户有一个模糊的想法，想做一个新功能或新模块，但还没想清楚具体要什么。通过结构化的探索流程，帮助用户从模糊想法收敛到明确的设计方案，并产出完整的设计参考文档。

## 核心原则

- **不猜，多问** — 没确认范围不出图，没设计规范就问，拿不准就让用户选
- **ASCII 先行** — 先对齐信息结构和布局逻辑，逻辑对了再投入 HTML
- **一次多方案** — 批量出 5-8 个方案让用户选方向，不要一个个试
- **全状态是必须的** — 正常态只是起点，异常态、边界情况、交互反馈必须穷举
- **决策要落纸** — 对话中确认的每个决策都写进需求总结，不能只存在对话上下文里

## 输出物

每次探索产出 **3 个文件**，归档到 `设计/v{版本号}-{模块名}/` 目录下：

| 文件 | 内容 | 用途 |
|------|------|------|
| `需求总结.md` | 背景、目标、功能范围、关键决策、技术约束 | PRD 阶段的输入，讲清楚"为什么做、做什么" |
| `{模块名}-设计稿.html` | 主界面 HTML mockup | PRD + 前端开发的视觉参考 |
| `{模块名}-全状态设计参考.html` | 所有页面状态、Toast、边界情况、交互规则表 | 前端开发直接对照实现 |

版本号和模块名由用户决定，必须问用户确认。

## 工作流程

### 第 1 步：需求发散与收敛

用户说了模糊想法后，主动追问：

- **痛点是什么** — 现在遇到了什么问题？为什么想做这个？
- **核心场景** — 最典型的使用场景是什么？
- **边界在哪** — 这个版本要做什么？不做什么？

整理成结构化的需求共识：

```
做什么：
- xxx
- xxx

不做什么：
- xxx

载体：独立应用 / 已有应用的新 Tab / 插件 / ...
```

**禁止**：用户说了一句话就开始出图。必须先对齐需求边界。

### 第 2 步：技术调研（按需）

**判断是否需要调研**：如果功能涉及外部数据（配置文件、API、第三方系统、文件格式），必须先调研技术约束。如果是纯 UI 功能不涉及外部依赖，跳过。

调研内容：
- 数据存储位置和格式
- 现有系统的接口和限制
- 技术可行性验证

调研结果会直接影响设计方案（比如发现两个工具配置格式不同，决定了界面需要展示"类型"列）。

**禁止**：跳过调研直接画图，画出来发现技术上实现不了。

### 第 3 步：ASCII 批量探索

一次出 **5-8 个**不同思路的 ASCII 布局方案，每个方案包含：
- ASCII 布局图
- 一句话说明核心思路

```
方案 A：卡片列表 + 工具勾选
┌──────────────────────────────────┐
│ ┌────────────────────────────┐   │
│ │ pencil       [✓] CC [✓] CX│   │
│ └────────────────────────────┘   │
└──────────────────────────────────┘

方案 B：表格视图，一行一个
┌──────────────────────────────────┐
│ 名称       类型   CC    CX      │
│ pencil     stdio  [✓]   [✓]    │
│ github     http   [✓]   [✓]    │
└──────────────────────────────────┘
```

用户可以：
- 直接选一个方案
- 组合多个方案的元素（"B 的结构 + E 的开关风格"）
- 全部否掉，补充新的方向

**禁止**：
- 只出 1-2 个方案（用户没有选择空间）
- 超过 10 个方案（选择困难）
- 方案之间差异太小（换汤不换药）

### 第 4 步：确认设计风格

问用户以下问题：

1. **有没有已有的设计规范？**（如 design-system.html）
   - 有 → 读取并严格遵循 design tokens（颜色、字号、圆角、间距）
   - 没有 → 问风格偏好，或直接出图让用户挑感觉

2. **有没有要参考的已有页面？**（外框、导航结构）
   - 有 → 读取参考页面，对齐外框样式（如 mac-window、sidebar 布局）
   - 没有 → 按独立页面处理

3. **载体形式？**
   - 已有应用的新页面/Tab → 必须对齐已有页面的外框和导航
   - 独立应用 → 自定义外框
   - 其他 → 问清楚

**禁止**：没问就默认使用某个设计规范。

### 第 5 步：HTML 设计稿

基于选定方案 + 确认的设计风格，输出 HTML mockup：

- 使用真实数据填充（不用 lorem ipsum）
- 如有设计规范，严格使用 CSS 变量 / design tokens
- 如有参考页面，外框结构保持一致

输出后让用户浏览器打开查看，根据反馈微调。微调是具体的小修改（间距、配色、文案），直接执行，不需要重新走方案选择。

### 第 6 步：全状态覆盖

产出一个完整的全状态设计参考 HTML，固定包含以下内容：

#### 必须覆盖的页面状态

| 状态 | 说明 |
|------|------|
| 正常态 | 有数据的标准展示 |
| 加载态 | 数据加载中（spinner + 禁用交互） |
| 空态 | 没有数据，引导文案 |
| 搜索/筛选无结果 | 有数据但当前条件无匹配 |
| 错误态 | 数据加载失败、文件不存在、格式错误等（按场景拆多个） |
| 部分可用 | 部分数据源可用、部分失败 |

#### 必须覆盖的交互反馈

- **Toast 汇总**：所有操作的成功/失败/警告 Toast，包含具体文案
- Toast 规则：位置、时长（成功短、错误长）、同时最多显示几条

#### 必须覆盖的边界情况

- 长文本截断（名称、路径、URL）
- 大量数据滚动
- 其他根据具体场景补充

#### 必须包含的交互行为规则表

表格格式，列定义：

| 触发 | 用户操作 | 系统行为 | 反馈 |
|------|---------|---------|------|
| 用户/系统/异常 | 具体操作 | 详细的系统处理步骤 | Toast/状态变化/界面更新 |

覆盖所有用户操作和系统行为的完整映射，前端开发直接对照实现。

#### 文档结构

- 顶部：标题、版本、日期
- 目录：锚点跳转
- 每个状态一个 section：标签 + 标题 + 说明 + 预览截面 + 标注
- 底部：交互行为规则表

**禁止**：只做正常态就结束。全状态覆盖是本流程的核心交付物。

### 第 7 步：需求总结 + 归档

按模板（`templates/需求总结-模板.md`）生成需求总结文档。

将对话中确认的所有决策提取出来，写入"关键决策"部分。这些决策往往散落在对话各处，必须主动收集整理，不能遗漏。

三个文件归档到 `设计/v{版本号}-{模块名}/` 目录下。版本号和模块名问用户确认。

```
设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html
```

## 过程中的沟通规范

### 必须问用户的

| 时机 | 问什么 |
|------|--------|
| 第 1 步 | 痛点、场景、边界（做什么/不做什么） |
| 第 3 步 | 选哪个方案 |
| 第 4 步 | 有无设计规范、参考页面、载体形式 |
| 第 5 步 | mockup 效果是否满意，有无微调 |
| 第 6 步 | 全状态覆盖有无遗漏的场景 |
| 第 7 步 | 版本号和模块名 |

### 不需要问用户的

| 事项 | 直接做 |
|------|--------|
| 全状态要不要覆盖 | 必须覆盖，不用问 |
| 交互规则表要不要写 | 必须写，不用问 |
| 需求总结要不要输出 | 必须输出，不用问 |
| Toast 文案 | 先给出建议，用户不满意再调 |

### AI 绝不应该做的

- 用户说了一句模糊想法就开始出 HTML
- 只出一个 ASCII 方案
- 只做正常态不管异常态
- 跳过技术调研直接画图（如果涉及外部数据）
- 把决策留在对话里不写进需求总结
- 自己编版本号和模块名
- 没问就默认使用某个设计规范