design-exploration

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 方案
• 只做正常态不管异常态
• 跳过技术调研直接画图（如果涉及外部数据）
• 把决策留在对话里不写进需求总结
• 自己编版本号和模块名
• 没问就默认使用某个设计规范