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

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 — 已存在： 进入「迭代模式」，流程如下：

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

先问：「该模块的交互是否参考 <产品名> 的做法？」
如果用户确认参考 → 了解其交互模式，提炼为设计要点，请用户确认
如果用户要差异化 → 追问差异点：「和它的区别在哪里？更简单还是更强大？」
如果用户没有参考产品 → 基于模块功能提供 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维度视觉确认 + 个模块 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，格式如下：

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

## 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 模式有行业主流做法，列出选项请用户选择
如果有参考产品，必须主动追问是否要参照，不要等用户自己提
用户说「好看就行」→ 基于产品定位给方向选项，不做无根据的猜测
确认摘要要用理念式语言描述，而非参数清单——让用户感受到设计意图，不是填表结果