design-exploration
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese用户有一个模糊的想法，想做一个新功能或新模块，但还没想清楚具体要什么。通过结构化的探索流程，帮助用户从模糊想法收敛到明确的设计方案，并产出完整的设计参考文档。
When a user has a vague idea to create a new feature or module but hasn't clarified the specifics yet, this structured exploration process helps the user converge from the vague idea to a clear design solution and produce a complete design reference document.
核心原则
Core Principles
- 不猜，多问 — 没确认范围不出图，没设计规范就问，拿不准就让用户选
- ASCII 先行 — 先对齐信息结构和布局逻辑，逻辑对了再投入 HTML
- 一次多方案 — 批量出 5-8 个方案让用户选方向，不要一个个试
- 全状态是必须的 — 正常态只是起点，异常态、边界情况、交互反馈必须穷举
- 决策要落纸 — 对话中确认的每个决策都写进需求总结，不能只存在对话上下文里
- No Guessing, Ask More Questions — Do not create drafts without confirming the scope; ask about design specifications if unclear; let users make choices when uncertain
- ASCII First — Align information structure and layout logic first, then invest in HTML only when the logic is correct
- Multiple Solutions at Once — Produce 5-8 schemes in batches for users to choose a direction, instead of testing one by one
- Full State Coverage is Mandatory — Normal state is just the starting point; exception states, boundary cases, and interactive feedback must be fully enumerated
- Document All Decisions — Every decision confirmed in conversations must be written into the requirements summary, not just kept in conversation context
输出物
Deliverables
每次探索产出 3 个文件，归档到 目录下：
设计/v{版本号}-{模块名}/| 文件 | 内容 | 用途 |
|---|---|---|
| 背景、目标、功能范围、关键决策、技术约束 | PRD 阶段的输入，讲清楚"为什么做、做什么" |
| 主界面 HTML mockup | PRD + 前端开发的视觉参考 |
| 所有页面状态、Toast、边界情况、交互规则表 | 前端开发直接对照实现 |
版本号和模块名由用户决定，必须问用户确认。
Each exploration produces 3 files, archived in the directory:
设计/v{version}-{module-name}/| File | Content | Purpose |
|---|---|---|
| Background, objectives, feature scope, key decisions, technical constraints | Input for the PRD phase, clarifying "why build it and what to build" |
| Main interface HTML mockup | Visual reference for PRD and front-end development |
| All page states, Toast, boundary cases, interactive rule table | Directly referenced by front-end developers for implementation |
The version number and module name are determined by the user and must be confirmed with them.
工作流程
Workflow
第 1 步：需求发散与收敛
Step 1: Requirements Divergence and Convergence
用户说了模糊想法后，主动追问：
- 痛点是什么 — 现在遇到了什么问题？为什么想做这个？
- 核心场景 — 最典型的使用场景是什么？
- 边界在哪 — 这个版本要做什么？不做什么？
整理成结构化的需求共识：
做什么：
- xxx
- xxx
不做什么：
- xxx
载体：独立应用 / 已有应用的新 Tab / 插件 / ...禁止：用户说了一句话就开始出图。必须先对齐需求边界。
After the user shares a vague idea, proactively ask:
- What are the pain points? — What problems are encountered now? Why do you want to build this?
- Core Scenarios — What is the most typical usage scenario?
- What are the boundaries? — What will be included in this version? What will be excluded?
Organize into a structured requirements consensus:
What to build:
- xxx
- xxx
What not to build:
- xxx
Carrier: Standalone App / New Tab in Existing App / Plugin / ...Prohibition: Start creating drafts right after the user says one sentence. Must align on requirements boundaries first.
第 2 步：技术调研（按需）
Step 2: Technical Research (As Needed)
判断是否需要调研：如果功能涉及外部数据（配置文件、API、第三方系统、文件格式），必须先调研技术约束。如果是纯 UI 功能不涉及外部依赖，跳过。
调研内容：
- 数据存储位置和格式
- 现有系统的接口和限制
- 技术可行性验证
调研结果会直接影响设计方案（比如发现两个工具配置格式不同，决定了界面需要展示"类型"列）。
禁止：跳过调研直接画图，画出来发现技术上实现不了。
Determine if research is required: If the function involves external data (configuration files, APIs, third-party systems, file formats), technical constraints must be researched first. Skip if it's a pure UI function without external dependencies.
Research content:
- Data storage location and format
- Interfaces and limitations of existing systems
- Technical feasibility verification
Research results will directly affect the design solution (e.g., discovering different configuration formats between two tools may require adding a "Type" column to the interface).
Prohibition: Skip research and start drafting directly, only to find it's technically unimplementable.
第 3 步：ASCII 批量探索
Step 3: ASCII Batch Exploration
一次出 5-8 个不同思路的 ASCII 布局方案，每个方案包含：
- ASCII 布局图
- 一句话说明核心思路
方案 A：卡片列表 + 工具勾选
┌──────────────────────────────────┐
│ ┌────────────────────────────┐ │
│ │ pencil [✓] CC [✓] CX│ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘
方案 B：表格视图，一行一个
┌──────────────────────────────────┐
│ 名称 类型 CC CX │
│ pencil stdio [✓] [✓] │
│ github http [✓] [✓] │
└──────────────────────────────────┘用户可以：
- 直接选一个方案
- 组合多个方案的元素（"B 的结构 + E 的开关风格"）
- 全部否掉，补充新的方向
禁止：
- 只出 1-2 个方案（用户没有选择空间）
- 超过 10 个方案（选择困难）
- 方案之间差异太小（换汤不换药）
Produce 5-8 ASCII layout schemes with different ideas at once, each including:
- ASCII layout diagram
- One-sentence explanation of the core idea
Scheme A: Card List + Tool Checkboxes
┌──────────────────────────────────┐
│ ┌────────────────────────────┐ │
│ │ pencil [✓] CC [✓] CX│ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘
Scheme B: Table View, One per Row
┌──────────────────────────────────┐
│ Name Type CC CX │
│ pencil stdio [✓] [✓] │
│ github http [✓] [✓] │
└──────────────────────────────────┘Users can:
- Directly select one scheme
- Combine elements from multiple schemes ("Structure of B + Switch style of E")
- Reject all schemes and provide new directions
Prohibitions:
- Produce only 1-2 schemes (no choice space for users)
- Produce more than 10 schemes (choice overload)
- Schemes with minimal differences (cosmetic changes only)
第 4 步：确认设计风格
Step 4: Confirm Design Style
问用户以下问题：
-
有没有已有的设计规范？（如 design-system.html）
- 有 → 读取并严格遵循 design tokens（颜色、字号、圆角、间距）
- 没有 → 问风格偏好，或直接出图让用户挑感觉
-
有没有要参考的已有页面？（外框、导航结构）
- 有 → 读取参考页面，对齐外框样式（如 mac-window、sidebar 布局）
- 没有 → 按独立页面处理
-
载体形式？
- 已有应用的新页面/Tab → 必须对齐已有页面的外框和导航
- 独立应用 → 自定义外框
- 其他 → 问清楚
禁止：没问就默认使用某个设计规范。
Ask the user the following questions:
-
Is there an existing design system? (e.g., design-system.html)
- Yes → Read and strictly follow design tokens (colors, font sizes, rounded corners, spacing)
- No → Ask about style preferences, or directly produce drafts for users to choose a style
-
Are there existing pages to reference? (Outer frame, navigation structure)
- Yes → Read the reference page and align the outer frame style (e.g., mac-window, sidebar layout)
- No → Treat as an independent page
-
Carrier form?
- New page/Tab in existing app → Must align with the outer frame and navigation of the existing page
- Standalone app → Custom outer frame
- Other → Clarify details
Prohibition: Default to a certain design system without asking.
第 5 步：HTML 设计稿
Step 5: HTML Design Draft
基于选定方案 + 确认的设计风格，输出 HTML mockup：
- 使用真实数据填充（不用 lorem ipsum）
- 如有设计规范，严格使用 CSS 变量 / design tokens
- 如有参考页面，外框结构保持一致
输出后让用户浏览器打开查看，根据反馈微调。微调是具体的小修改（间距、配色、文案），直接执行，不需要重新走方案选择。
Based on the selected scheme + confirmed design style, output an HTML mockup:
- Fill with real data (do not use lorem ipsum)
- Strictly use CSS variables / design tokens if a design system is available
- Keep the outer frame structure consistent if a reference page is available
After output, ask the user to open it in a browser for review and make minor adjustments based on feedback. Minor adjustments refer to specific small changes (spacing, color matching, copy), which can be executed directly without re-selecting schemes.
第 6 步：全状态覆盖
Step 6: Full State Coverage
产出一个完整的全状态设计参考 HTML，固定包含以下内容：
Produce a complete full-state design reference HTML, which must include the following content:
必须覆盖的页面状态
Mandatory Page States to Cover
| 状态 | 说明 |
|---|---|
| 正常态 | 有数据的标准展示 |
| 加载态 | 数据加载中（spinner + 禁用交互） |
| 空态 | 没有数据，引导文案 |
| 搜索/筛选无结果 | 有数据但当前条件无匹配 |
| 错误态 | 数据加载失败、文件不存在、格式错误等（按场景拆多个） |
| 部分可用 | 部分数据源可用、部分失败 |
| State | Description |
|---|---|
| Normal State | Standard display with data |
| Loading State | Data loading in progress (spinner + disabled interactions) |
| Empty State | No data, with guidance copy |
| No Results from Search/Filter | Data exists but no matches for current conditions |
| Error State | Data loading failure, file not found, format error, etc. (split into multiple by scenario) |
| Partially Available | Some data sources available, some failed |
必须覆盖的交互反馈
Mandatory Interactive Feedback to Cover
- Toast 汇总：所有操作的成功/失败/警告 Toast，包含具体文案
- Toast 规则：位置、时长（成功短、错误长）、同时最多显示几条
- Toast Summary: All success/failure/warning Toasts for operations, including specific copy
- Toast Rules: Position, duration (short for success, long for error), maximum number displayed at the same time
必须覆盖的边界情况
Mandatory Boundary Cases to Cover
- 长文本截断（名称、路径、URL）
- 大量数据滚动
- 其他根据具体场景补充
- Long text truncation (names, paths, URLs)
- Scrolling with large amounts of data
- Others added based on specific scenarios
必须包含的交互行为规则表
Mandatory Interactive Behavior Rule Table
表格格式，列定义：
| 触发 | 用户操作 | 系统行为 | 反馈 |
|---|---|---|---|
| 用户/系统/异常 | 具体操作 | 详细的系统处理步骤 | Toast/状态变化/界面更新 |
覆盖所有用户操作和系统行为的完整映射，前端开发直接对照实现。
Table format with column definitions:
| Trigger | User Action | System Behavior | Feedback |
|---|---|---|---|
| User/System/Exception | Specific action | Detailed system processing steps | Toast/state change/interface update |
Covers the complete mapping of all user operations and system behaviors, directly referenced by front-end developers for implementation.
文档结构
Document Structure
- 顶部：标题、版本、日期
- 目录：锚点跳转
- 每个状态一个 section：标签 + 标题 + 说明 + 预览截面 + 标注
- 底部：交互行为规则表
禁止：只做正常态就结束。全状态覆盖是本流程的核心交付物。
- Top: Title, version, date
- Directory: Anchor jump
- Each state as a section: Tag + Title + Description + Preview Section + Annotations
- Bottom: Interactive Behavior Rule Table
Prohibition: Stop after only completing the normal state. Full state coverage is the core deliverable of this process.
第 7 步：需求总结 + 归档
Step 7: Requirements Summary + Archiving
按模板（）生成需求总结文档。
templates/需求总结-模板.md将对话中确认的所有决策提取出来，写入"关键决策"部分。这些决策往往散落在对话各处，必须主动收集整理，不能遗漏。
三个文件归档到 目录下。版本号和模块名问用户确认。
设计/v{版本号}-{模块名}/设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.htmlGenerate a requirements summary document using the template ().
templates/需求总结-模板.mdExtract all decisions confirmed in conversations and write them into the "Key Decisions" section. These decisions are often scattered in conversations and must be actively collected and organized without omission.
Archive the three files in the directory. Confirm the version number and module name with the user.
设计/v{version}-{module-name}/设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html过程中的沟通规范
Communication Specifications During the Process
必须问用户的
Must Ask the User
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 痛点、场景、边界（做什么/不做什么） |
| 第 3 步 | 选哪个方案 |
| 第 4 步 | 有无设计规范、参考页面、载体形式 |
| 第 5 步 | mockup 效果是否满意，有无微调 |
| 第 6 步 | 全状态覆盖有无遗漏的场景 |
| 第 7 步 | 版本号和模块名 |
| Timing | Questions |
|---|---|
| Step 1 | Pain points, scenarios, boundaries (what to build/what not to build) |
| Step 3 | Which scheme to select |
| Step 4 | Whether there is a design system, reference pages, carrier form |
| Step 5 | Whether the mockup effect is satisfactory, any minor adjustments needed |
| Step 6 | Whether any scenarios are missing in full state coverage |
| Step 7 | Version number and module name |
不需要问用户的
No Need to Ask the User
| 事项 | 直接做 |
|---|---|
| 全状态要不要覆盖 | 必须覆盖，不用问 |
| 交互规则表要不要写 | 必须写，不用问 |
| 需求总结要不要输出 | 必须输出，不用问 |
| Toast 文案 | 先给出建议，用户不满意再调 |
| Item | Directly Execute |
|---|---|
| Whether to cover full states | Mandatory, no need to ask |
| Whether to write interactive rule table | Mandatory, no need to ask |
| Whether to output requirements summary | Mandatory, no need to ask |
| Toast copy | Provide suggestions first, adjust if user is unsatisfied |
AI 绝不应该做的
What AI Should Never Do
- 用户说了一句模糊想法就开始出 HTML
- 只出一个 ASCII 方案
- 只做正常态不管异常态
- 跳过技术调研直接画图（如果涉及外部数据）
- 把决策留在对话里不写进需求总结
- 自己编版本号和模块名
- 没问就默认使用某个设计规范
- Start creating HTML right after the user shares a vague idea
- Produce only one ASCII scheme
- Only handle normal state and ignore exception states
- Skip technical research and start drafting directly (if external data is involved)
- Keep decisions only in conversations instead of writing them into the requirements summary
- Make up version numbers and module names on its own
- Default to a certain design system without asking