design-explorationlisted

用户有一个模糊的想法，想做一个新功能或新模块，但还没想清楚具体要什么。通过结构化的探索流程，帮助用户���模糊想法收敛到明确的设计方案，并产出完整的设计参考文档。 ## 核心原则 - **不猜，多问** — 没确认范围不出图，没设计规范就问，拿不准就让用户选 - **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