用途
用户有一个模糊的想法，想做一个新功能或新模块，但还没想清楚具体要什么。该技能通过结构化的探索流程，帮助用户从模糊想法收敛到明确的设计方案，并产出完整的设计参考文档。触发前必须同时满足两个硬条件：①这个东西有用户能看见的界面；②界面尚不存在。
核心原则
- 不猜，多问：没确认范围不出图，没设计规范就问，拿不准就让用户选。
- ASCII 先行：先对齐信息结构和布局逻辑，逻辑对了再投入 HTML。
- 一次多方案：批量出 5-8 个方案让用户选方向，不要一个个试。
- 全状态是必须的：正常态只是起点，异常态、边界情况、交互反馈必须穷举。
- 决策要落纸：对话中确认的每个决策都写进需求总结，不能只存在对话上下文里。
输出物
每次探索产出 3 个文件，归档到 设计/v{版本号}-{模块名}/ 目录下：
- 需求总结.md：背景、目标、功能范围、关键决策、技术约束；用于 PRD 阶段的输入，讲清楚"为什么做、做什么"。
- {模块名}-设计稿.html：主界面 HTML mockup；作为 PRD + 前端开发的视觉参考。
- {模块名}-全状态设计参考.html：所有页面状态、Toast、边界情况、交互规则表；供前端开发直接对照实现。
版本号和模块名由用户决定，必须问用户确认。
使用方式（工作流程）
第 1 步：需求发散与收敛
用户说了模糊想法后，主动追问：痛点是什么（现在遇到了什么问题？为什么想做这个？）、核心场景（最典型的使用场景是什么？）、边界在哪（这个版本要做什么？不做什么？）。整理成结构化的需求共识，包括：做什么、不做什么、载体（独立应用 / 已有应用的新 Tab / 插件等）。禁止用户说了一句话就开始出图，必须先对齐需求边界。
第 2 步：技术调研（按需）
判断是否需要调研：如果功能涉及外部数据（配置文件、API、第三方系统、文件格式），必须先调研技术约束；如果是纯 UI 功能不涉及外部依赖，跳过。调研内容包括数据存储位置和格式、现有系统的接口和限制、技术可行性验证。调研结果会直接影响设计方案（比如发现两个工具配置格式不同，决定了界面需要展示"类型"列）。禁止跳过调研直接画图，画出来发现技术上实现不了。
第 3 步：ASCII 批量探索
一次出 5-8 个不同思路的 ASCII 布局方案，每个方案包含 ASCII 布局图和一句话说明核心思路。例如方案 A（卡片列表 + 工具勾选）、方案 B（表格视图，一行一个）。用户可以：直接选一个方案；组合多个方案的元素（"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 方案
- 只做正常态不管异常态
- 跳过技术调研直接画图（如果涉及外部数据）
- 把决策留在对话里不写进需求总结
- 自己编版本号和模块名
- 没问就默认使用某个设计规范