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