design-exploration

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

核心原则

不猜，多问 — 没确认范围不出图，没设计规范就问，拿不准就让用户选
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 步：确认设计风格

问用户以下问题：

有没有已有的设计规范？（如 design-system.html）
- 有 → 读取并严格遵循 design tokens（颜色、字号、圆角、间距）
- 没有 → 问风格偏好，或直接出图让用户挑感觉
有没有要参考的已有页面？（外框、导航结构）
- 有 → 读取参考页面，对齐外框样式（如 mac-window、sidebar 布局）
- 没有 → 按独立页面处理
载体形式？
- 已有应用的新页面/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 方案
只做正常态不管异常态
跳过技术调研直接画图（如果涉及外部数据）
把决策留在对话里不写进需求总结
自己编版本号和模块名
没问就默认使用某个设计规范