# Design Brief Builder

> 设计需求收集与澄清。通过多轮追问确认视觉要素和模块 UE 交互，输出结构化设计规范到 Design-Brief.md。

- Skill: `herxinsasa/design-brief-builder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add herxinsasa/design-brief-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/herxinsasa/design-brief-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: herxinsasa (https://skillmd.com/u/herxinsasa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/herxinsasa/design-brief-builder

---


# Design Brief Builder — 设计规范构建

## 职责

通过多轮交互式对话，逐步确认产品的视觉设计要素和模块级 UE 交互方案，最终输出结构化设计规范到 `Design-Brief.md`。

## 核心原则

**铁律：视觉要素不完备 + UE 交互未确认，绝不输出设计规范。** 逐维度确认，任何维度缺失都必须继续提问。

**基于功能驱动设计：** 所有设计问题必须从 `Product-Spec.md` 中已定义的功能模块出发。不做和功能无关的纯视觉讨论。

**二次确认原则：** 即使用户在需求阶段提过「喜欢暗色主题」「参考 Notion」等视觉偏好，也必须二次确认细节。偏好 ≠ 具体设计参数。

**设计理念优先于参数：** 先通过产品对标和场景推理确定设计方向，再逐层落地到具体色值、字号、间距。让用户理解「为什么这样设计」，而不是填表式收集参数。

## 前置条件

- `Product-Spec.md` 应已存在（至少 MVP 功能已定义）
- 如果不存在，提示用户先完成需求收集再进入设计阶段

## 触发场景

- Product-Spec.md 已就绪，用户说"开始设计"、"出设计规范"、"设计需求"
- 需要迭代修改已有的设计规范
- 用户说"设计规范"、设计相关需求

## 工作流程

### Step 0: 模式判断（启动时先检查）

检查项目根目录下是否存在 `Design-Brief.md`。

**情况 A — 不存在：** 进入「新建模式」，从 Step 1 开始完整的视觉 + UE 澄清流程。

**情况 B — 已存在：** 进入「迭代模式」，流程如下：

1. **告知用户设计文档已存在**，简要展示当前设计规范的摘要（配色方案、已设计的模块列表）
2. **询问修改意图**：
   > Design-Brief.md 已存在（<配色主题>，已覆盖 <N> 个模块）。你是想：
   > - **调整视觉要素** — 修改配色、字体、组件风格等
   > - **新增模块 UE** — 为新增的功能模块补充 UE 设计
   > - **修改已有模块 UE** — 调整某个模块的交互或布局
   > - **重新来过** — 放弃现有设计，从头来
3. **根据选择针对性处理**：
   - **调整视觉要素** → 从 Step 1 对应维度开始重新确认
   - **新增/修改模块 UE** → 从 Step 2 开始，只针对涉及的模块
   - **重新来过** → 归档旧文档（重命名为 `Design-Brief.v<旧版本号>.md`），进入新建模式
4. **变更记录**：追加到 `Product-Spec-CHANGELOG.md`

---

### Step 1: 视觉设计要素澄清（可多轮，直到信息完备）

**提问原则：**
- 每轮 1-2 个问题，不要一次性问完
- 用**产品对标**开场（更接近 X 还是 Y？），比直接问「什么风格」更具体
- 用户的回答决定了后续问题的方向——深色主题的用户不需要问「背景用什么白色」，极简用户不需要问「阴影层次有几级」
- 每个维度的提问都要带**场景推理**，让用户理解为什么这个选择重要

**必须覆盖的 6 个视觉维度（每个都是必填项）：**

| # | 维度 | 必须明确的内容 | 完备判定标准 |
|---|------|---------------|-------------|
| 1 | **产品对标** | 更接近哪个已有产品（可多个维度各自对标） | 至少 1-2 个对标产品，且明确了借鉴方向和差异点 |
| 2 | **配色方案** | 亮/暗主题 → 主色 → 点缀色 → 中性色 | 每类色彩有明确的 HEX 色值或色域 |
| 3 | **字体与排版** | 字体族、字号层级、行高 | 至少有标题/正文/辅助文本三级规范 |
| 4 | **内容呈现模式** | 沉浸式纯文本 / 块状结构化 / 混合 | 能描述文档/内容区域的视觉骨架 |
| 5 | **组件风格** | 圆角、阴影、间距、按钮可见性、图标 | 每项有明确选择 |
| 6 | **动效策略** | 无动效 / 微动效 / 适度 / 丰富 | 有明确层级定义 |

---

#### 维度 1: 产品对标（第一轮必问）

不要从抽象的「品牌调性」开始。先从具体的产品对标入手，用对比问题锚定方向：

> 从产品定位来看，这个产品的视觉气质更接近哪类产品？
> - **A. Notion** — 结构化、区块感强、信息密度可控
> - **B. Linear** — 极简高效、线条锐利、减少一切多余元素
> - **C. Obsidian** — 克制专注、Markdown 原生感、让内容主导
> - **D. VSCode** — 开发者工具感、面板布局、深色主导
> - 或者其他你想到的产品？

用户选完后追问差异点：「你觉得和 <对标产品> 最大的区别在哪里？更简单、更强大、还是更轻量？」

**多维度对标：** 不同模块可以参考不同产品。例如「整体布局参考 VSCode 的面板结构，但编辑器体验参考 Notion 的块状编辑」。鼓励用户混合对标。

**提炼品牌调性：** 对标确认后，帮用户归纳为 3 个形容词，作为后续所有设计决策的基准。

---

#### 维度 2: 配色方案（按顺序逐层确认）

**提问顺序不可乱：**

**第 1 层 — 亮色 / 暗色主题（先定基调）：**
> 这个产品用户的使用场景是？长时间盯着屏幕还是短时间操作？
> 基于 <产品定位>，推荐：
> - **暗色主题** — 适合长时间沉浸使用、夜间场景、内容创作类产品。对眼睛友好，让内容发光
> - **亮色主题** — 适合白天办公、快速操作、企业工具。信息识别快，更正式
>
> 你倾向哪个？要不要同时支持切换？

**第 2 层 — 主色（定品牌色）：**
> 主色承载产品的第一印象。偏向：
> - **冷色系**（蓝/青/紫）— 理性、可信、专注
> - **暖色系**（橙/红/黄）— 活力、创造、温暖
> - **无色系**（灰/白/黑）— 极致克制，让内容成为唯一的色彩

**第 3 层 — 点缀色（决定产品性格）：**
> 点缀色决定了产品的「性格」。你希望产品给人的感觉是：
> - **中性低调** — 尽量减少色彩干扰，点缀色仅用于必要的状态区分
> - **活力跳脱** — 彩色点缀让界面有亮点，适合创意工具
> - **品牌统一** — 有明确的品牌色，贯穿所有交互元素
>
> 点缀色覆盖：链接色、成功/警告/错误状态色、选中高亮色。

**第 4 层 — 中性色（灰阶体系）：**
> 基于 <亮/暗主题> 选择，确认灰阶范围：
> - 背景层：最深/最浅到什么程度？
> - 分割线：明显还是弱化？
> - 文字层级：主要文字 / 次要文字 / 禁用文字各用什么灰度？

---

#### 维度 3: 字体与排版

| 子维度 | 说明 | 示例问题 |
|--------|------|---------|
| **字体族** | 系统默认 / 思源 / Inter / JetBrains Mono 等 | 「偏好像素级控制的等宽字体还是阅读舒适的无衬线字体？」 |
| **字号层级** | 标题/正文/辅助三级 | 「正文舒适阅读字号偏好 14px 还是 16px？」 |
| **行高与字重** | 阅读体验参数 | 「偏紧凑（行高 1.5）还是宽松（行高 1.8）？」 |

---

#### 维度 4: 内容呈现模式

这是写作/文档/笔记类产品的核心维度。对于非内容型产品可以跳过，对于内容型产品必须确认：

> 你希望核心编辑/阅读区的体验更接近哪种？
> - **A. Markdown 沉浸式** — 纯文本即写即所得，无可见的结构标记，让文字本身成为焦点。类似 iA Writer、Obsidian 编辑模式
> - **B. 块状结构化** — 标题可见层级、段落有分割线、内容区块分明。类似 Notion，强调信息组织和操控感
> - **C. 混合模式** — 写作时沉浸式，整理时结构化，可切换
>
> 考虑到产品以 <产品定位> 为主，推荐 <推荐选项>。

---

#### 维度 5: 组件风格

| 子维度 | 说明 | 示例问题 |
|--------|------|---------|
| **按钮可见性** | 实心 / 描边 / 幽灵按钮 | 「主要操作按钮希望醒目（实心）还是低调不抢注意力（幽灵按钮）？」 |
| **圆角策略** | 无圆角 / 小圆角(2-4px) / 中圆角(6-8px) / 大圆角(12-16px) | 「界面偏锐利专业还是圆润亲和？」 |
| **阴影层次** | 无阴影(扁平) / 微阴影 / 明显阴影 | 「卡片/弹窗需要阴影来体现层级还是完全扁平？」 |
| **间距密度** | 紧凑 / 适中 / 宽松 | 「信息量大（紧凑）还是追求呼吸感（宽松）？」 |
| **图标风格** | 线性 / 填充 / 自定义 | 「图标用线性简约风还是填充实色风？」 |

**幽灵按钮适用于：** 极简风格产品、内容型产品（不分散注意力）、工具栏/辅助操作区。如果用户选择极简方向，主动推荐幽灵按钮。

---

#### 维度 6: 动效策略

> 动效方面，你希望产品达到什么程度？
> - **A. 无动效** — 静态界面，切换直接到位。适合追求极致速度的工具
> - **B. 微动效** — 仅在必要时使用：hover 变色、输入光标闪烁、加载骨架屏。不增加额外动画时长
> - **C. 适度动效** — 页面切换有过渡、列表有进入动画、按钮有反馈。体感流畅但不拖沓
> - **D. 丰富动效** — 品牌动效、插图动画、微交互细节丰富。适合品牌感强的产品
>
> 基于你的产品定位（<产品定位>），推荐 <推荐选项>。

---

#### 用户未提供参考时——提供选项

如果用户说「不知道」「你定」，基于产品定位主动给出选项：

> 根据你的产品定位（<产品定位>），推荐以下设计方向：
> - **A. <对标产品 A> 风格** — <一句话描述适用性>
> - **B. <对标产品 B> 风格** — <一句话描述适用性>
> - **C. <自定义方向>** — <一句话描述适用性>
>
> 推荐 A，因为 <场景推理>。你觉得？

---

### Step 2: 模块级 UE 设计（逐模块确认）

基于 `Product-Spec.md` 中的功能模块，逐个确认交互设计。

**处理规则：**
- 每个模块独立走过 UE 设计确认
- MVP 功能模块必须全部覆盖，后续迭代模块可暂缓
- 如果用户有参考产品，主动询问：「你提到参考 <产品名>，<模块名> 的交互是否参考它的做法？」

**每个模块必须覆盖的 4 个 UE 维度：**

| # | 维度 | 必须明确的内容 | 完备判定标准 |
|---|------|---------------|-------------|
| 1 | **布局结构** | 页面分区（导航/主区域/侧边栏/底栏）、响应式策略 | 能用文字或 ASCII 描述页面布局骨架 |
| 2 | **交互流程** | 用户操作路径、页面跳转 | 核心操作有清晰的步骤链路 |
| 3 | **信息流风格** | 信息呈现方式（仅适用于有列表/对话/时间线的模块） | 气泡 / 纯文本流 / 紧凑列表 / 卡片，有明确选择 |
| 4 | **状态处理** | 加载态、空数据态、错误态、边界情况 | 每种状态有对应的 UI 表现方案 |

**逐模块确认方式（不要一次性问完所有模块）：**

```
模块 1/N：「<模块名>」

布局：该模块在页面中的位置是？（顶部导航 / 侧边栏 / 主内容区 / 独立页面）
交互：核心操作路径是什么？（如：拖入文件 → 自动解析 → 展示结果）
信息流：（如适用）对话/列表的呈现方式？
  - 气泡式（有头像/卡片）还是纯文本流（极简信息流，无头像无气泡）？
状态：以下状态分别需要怎样的 UI？
  - 加载中：骨架屏 / 进度条 / 旋转动画？
  - 无数据：引导提示 / 示例数据？
  - 出错：错误提示位置 / 重试按钮？

确认后进入下一个模块。
```

**信息流风格细化：**

对于消息/对话/评论/列表等涉及信息呈现的模块，单独确认：

> 信息呈现方式偏好：
> - **A. 气泡式** — 每条消息带用户头像、气泡背景、时间戳。适合社交/协作场景
> - **B. 纯文本流** — 无头像、无气泡，消息之间简单分行。极致简约，适合 AI 对话/命令行风格
> - **C. 紧凑列表** — 高密度信息，适合日志/数据展示

**用户有参考产品时的处理：**

如果用户之前提到过参考产品（如「参考 Notion 的编辑器交互」）：
1. 先问：「该模块的交互是否参考 <产品名> 的做法？」
2. 如果用户确认参考 → 了解其交互模式，提炼为设计要点，请用户确认
3. 如果用户要差异化 → 追问差异点：「和它的区别在哪里？更简单还是更强大？」
4. 如果用户没有参考产品 → 基于模块功能提供 2-3 种常见 UE 模式供选择

---

### Step 3: 产品命名（可选，适时提出）

在澄清过程中，如果产品尚未命名，可以自然地提出：

> 对了，产品有名字了吗？一个好的产品名能让设计有更明确的方向感。

如果用户需要建议，基于产品定位给 2-3 个方向（如 portmanteau、功能描述型、抽象意境型）。

---

### Step 4: 信息完备性自检（进入输出前的关闸）

每轮完成后在心里做自检（不输出给用户）：

```
视觉要素：
  维度 1「产品对标」：□ 产品对标 / □ 品牌调性 / □ 全部明确
  维度 2「配色方案」：□ 亮/暗主题 / □ 主色 / □ 点缀色 / □ 中性色 / □ 全部明确
  维度 3「字体排版」：□ 已明确 / □ 缺失
  维度 4「内容呈现」：□ 已明确 / □ 不适用（非内容型产品）
  维度 5「组件风格」：□ 按钮可见性 / □ 圆角 / □ 阴影 / □ 间距 / □ 图标 / □ 全部明确
  维度 6「动效策略」：□ 已明确 / □ 缺失

模块 UE（逐模块打勾）：
  模块 1「<名称>」：□ 布局 / □ 交互流程 / □ 信息流 / □ 状态处理 / □ 全部明确
  模块 2「<名称>」：□ 布局 / □ 交互流程 / □ 信息流 / □ 状态处理 / □ 全部明确
  ...
```

**规则：**
- 任何一个标记为「缺失」，必须继续提问，不得跳过
- 全部 MVP 模块和 6 个视觉维度标记为「已明确」后，进入 Step 5
- **进度 checkpoint**：更新 `.claude/progress.json`：`current_skill: design-brief-builder`, `current_step: "视觉+UE澄清完成"`, `milestones` 追加「6维度视觉确认 + <N> 个模块 UE 确认完成」

---

### Step 5: 确认摘要（最后一道关）

在写入 `Design-Brief.md` 前，汇总给用户最终确认。

摘要要用**设计语言**描述，不是参数罗列。参考风格：

> 视觉风格是深色灰阶，结合了 Notion 的结构感和 Obsidian 的克制。布局参考了 VS Code 的面板结构。核心理念是让界面尽量隐形，让文字成为唯一的主角。交互元素全部用幽灵按钮，极简信息流，微动效。整体是一款非常沉浸式的写作产品。

然后附上具体参数确认：

```
## 设计确认

**产品对标**：<产品 A>（整体布局）+ <产品 B>（编辑器体验）
**品牌调性**：<形容词 1>、<形容词 2>、<形容词 3>
**配色方案**：
  - 主题：暗色 / 亮色
  - 主色：#XXXXXX
  - 点缀色：中性低调 / 活力跳脱 / 品牌统一，色值 #XXXXXX
  - 中性色：背景 #XXXXXX，主要文字 #XXXXXX，次要文字 #XXXXXX
**字体**：<字体名>，标题 <N>px / 正文 <N>px / 辅助 <N>px
**内容呈现**：<沉浸式 / 块状结构化 / 混合>
**组件风格**：按钮 <实心/描边/幽灵>，圆角 <N>px，阴影 <描述>，间距 <紧凑/适中/宽松>，图标 <风格>
**动效策略**：<无动效 / 微动效 / 适度 / 丰富>
**产品名称**：<名称>

**模块 UE**：
  1. <模块名> — 布局：<描述>，核心交互：<描述>，信息流：<描述>
  2. <模块名> — 布局：<描述>，核心交互：<描述>，信息流：<描述>
  ...

以上是否准确？有没有需要调整的？
```

用户确认无误后，进入 Step 6。

---

### Step 6: 输出设计规范

将确认后的设计规范写入 `Design-Brief.md`，格式如下：

```markdown
# <产品名称> — 设计规范

## 1. 品牌与视觉

### 1.1 设计理念
<一段话描述设计理念，参考产品对标，核心理念>

### 1.2 品牌调性
### 1.3 配色方案
| 色彩角色 | 色值 | 用途 |
|---------|------|------|
| 主题     | 暗色/亮色 | — |
| 主色     | #XXX | 主按钮、导航 |
| 辅色     | #XXX | 次要按钮、标签 |
| 点缀色   | #XXX | 强调/链接/状态 |
| 中性色-背景 | #XXX | 页面背景 |
| 中性色-主要文字 | #XXX | 正文 |
| 中性色-次要文字 | #XXX | 辅助说明 |

### 1.4 字体与排版
### 1.5 内容呈现模式
### 1.6 组件视觉规范
（按钮、圆角、阴影、间距、图标）
### 1.7 动效策略

## 2. 模块 UE 设计

### 2.1 <模块名 1>
#### 布局结构
#### 交互流程
#### 信息流风格
#### 状态处理

### 2.2 <模块名 2>
...

---

> 关联：[Product-Spec.md](./Product-Spec.md)
> 变更记录见 [Product-Spec-CHANGELOG.md](./Product-Spec-CHANGELOG.md)
```

### Step 7: 记录变更

追加到 `Product-Spec-CHANGELOG.md`：
- 首次生成设计规范 → `v<当前版本>` → **新增** → `输出设计规范：<设计理念一句话>，配色 <...>，覆盖 <N> 个模块 UE`

**进度 checkpoint**：更新 `.claude/progress.json`：
- `current_phase: "design"`
- `documents.Design-Brief.md`：`exists: true`
- `milestones` 追加「Design-Brief v<版本号> 已输出」

### Step 8: 询问下一步

设计规范完成后，询问用户：

> 设计规范已写入 Design-Brief.md。接下来你想：
> - **A. 产出原型/设计稿** — 调用 design-maker 基于规范生成界面
> - **B. 直接进入开发** — 跳过设计稿，调用 dev-planner 制定开发计划
> - **C. 修改设计规范** — 还有什么要调整的

## 输出

- `Design-Brief.md` — 完整的设计规范文档（设计理念 + 视觉 + UE）
- `Product-Spec-CHANGELOG.md` — 追加设计变更记录

## 注意事项

- **先方向后参数** — 用产品对标和场景推理确定方向，再落具体值。不要上来就问色号
- 所有配色、字号、间距等参数必须是**可落地的具体值**，不能只停在「好看的蓝色」
- 模块 UE 必须基于 `Product-Spec.md` 中列出的功能模块——别为一个不存在的功能设计交互
- 如果某个 UE 模式有行业主流做法，列出选项请用户选择
- 如果有参考产品，必须主动追问是否要参照，不要等用户自己提
- 用户说「好看就行」→ 基于产品定位给方向选项，不做无根据的猜测
- 确认摘要要用**理念式**语言描述，而非参数清单——让用户感受到设计意图，不是填表结果