Design Exploration

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

核心原则

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

输出物

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

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

工作流程

第 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，固定包含以下内容：

必须覆盖的页面状态

必须覆盖的交互反馈

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

必须覆盖的边界情况

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

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

表格格式，列定义：

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

文档结构

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

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

第 7 步：需求总结 + 归档

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

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

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

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

过程中的沟通规范

必须问用户的

不需要问用户的

AI 绝不应该做的

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

{模块名} — 需求总结

版本：v{版本号}

日期：{YYYY-MM-DD}

状态：设计探索完成，待 PRD

---

背景

{用户遇到了什么问题？为什么要做这个功能？用 2-3 句话描述核心痛点。}

目标

本版本要解决的核心问题：

1. {目标 1} 2. {目标 2} 3. ...

功能范围

做什么

• {功能点 1}
• {功能点 2}
• {功能点 3}
• ...

不做什么

• {明确排除的功能 1}（原因：{为什么不做}）
• {明确排除的功能 2}（原因：{为什么不做}）
• ...

载体

{这个功能的载体形式：已有应用的新 Tab / 独立应用 / 插件 / 其他}

{如果是已有应用的一部分，说明在哪个位置、怎么进入}

关键决策

探索过程中确认的产品和设计决策，PRD 和开发阶段必须遵守：

技术约束

{技术调研中发现的约束和限制，影响设计和实现的关键信息。如无技术调研则写"无特殊约束"。}

• {约束 1}
• {约束 2}
• ...

设计参考

本目录下的设计文件：

• {模块名}-设计稿.html — 主界面设计稿
• {模块名}-全状态设计参考.html — 全状态设计参考（含交互规则表）

{如有使用的设计规范，注明路径：如 设计/design-system.html}