Design Brief Builder

[文件结构] design-brief-builder/ ├── SKILL.md # 主 Skill 定义（本文件） └── templates/ └── design-brief-template.md # Design Brief 输出模板

[采访维度清单] 在对话过程中，需要探明以下维度的信息（不必按顺序，根据对话自然推进）：

**必须探明**（没有这些，设计工具只能猜）：

- 情绪方向：产品给人什么感觉？用同类产品做锚点逼出答案。追到有 3 个关键词 + 至少 1 个参考产品为止。
  - "你的产品更接近 [参考A] 的 XX 路线，还是 [参考B] 的 YY 路线？"
  - "如果你的产品是一个人，用三个词形容他/她？"

- 色彩方向：冷色 / 暖色 / 中性？深色 / 浅色？有没有品牌色？基于情绪方向给 2-3 个配色方案让用户选。
  - "你选了 [XX方向]，常见的配色有 A（像 [参考]）和 B（像 [参考]），你偏哪个？"
  - "有没有已经定好的品牌色或 logo？"

- 信息密度：一屏信息多还是少？从 Product Spec 的功能数量和 UI 布局出发判断。
  - "你的产品有 N 个核心功能，信息量偏大。你是要像 [紧凑参考] 一屏尽量多？还是像 [宽松参考] 每次聚焦一件事？"

- 核心功能视觉：Product Spec 中每个有视觉设计决策空间的核心功能/页面，都要确认其视觉表现方向。逐功能追问，用同类产品做锚点。纯后端功能跳过。
  - Spec 有聊天界面 → "消息气泡是圆角卡片还是纯文本？AI 回复要不要打字机效果？"
  - Spec 有数据表格 → "表格走 Airtable 那种彩色标签风格？还是 Excel 那种紧凑数据风格？"
  - Spec 有侧边栏导航 → "侧边栏可折叠吗？折叠后只留图标还是完全隐藏？"
  - Spec 有画布功能 → "画布背景是白底还是网格？元素选中后像 Figma 还是 Miro？"
  - 涉及不确定的设计模式时，先 WebSearch 搜索该功能的主流设计方案

**尽量探明**（有这些，设计更精准）：

- 反面参考：用户讨厌的风格或产品，加具体讨厌什么。通过排除缩小范围。
  - "有没有哪种风格你一看就讨厌？给我个例子。"

- 品牌资产：有没有现成的 logo、品牌色、字体？影响设计是否需要从零构建视觉体系。
  - "有没有现成的 logo 或品牌色？还是从零开始？"

- 交互风格：动画多不多？过渡效果偏什么感觉？整体节奏快还是慢？
  - "要不要动画效果？多一点 vs 尽量少 vs 适中就好"

- 状态设计：空状态、加载状态、错误状态的视觉方向。
  - "空白页面（没数据的时候）你希望怎么处理？插画引导？还是极简文案？"

- 目标用户审美：用户群体习惯什么视觉语言？不同群体有不同预期。
  - 开发者 → 偏爱深色、极简、信息密集
  - 消费者 → 偏爱亲切、活泼、视觉引导强
  - 企业用户 → 偏爱专业、稳重、品牌一致

**不需要问用户**（交给设计工具决定）：
- 具体圆角值、阴影参数、间距数值
- 具体字号、行高
- 具体 hex 色值（只定方向，不定数值）
- 组件的具体实现方式

[采访策略] 二选一引导法（This-or-That） 展示两个对立的方向，让用户选。比"你喜欢什么"有效十倍。 常用对比对（每对附真实产品参考）： - 信息密度：Linear（紧凑高效）vs Notion（宽松灵活） - 色彩温度：Stripe（冷色专业）vs Airbnb（暖色亲切） - 正式程度：Bloomberg Terminal（严肃专业）vs Figma（活泼创意） - 视觉层次：Apple（极简大留白）vs Vercel Dashboard（密但干净） - 导航风格：Slack（侧边栏导航）vs Spotify（底部 Tab 导航） - 主题偏好：GitHub（默认深色）vs Google Docs（默认浅色） - 圆角风格：iOS（大圆角柔和）vs Windows（直角锐利） - 插画风格：Dropbox（抽象插画）vs 无插画（纯 UI）

**品牌人格化**
"如果你的产品是一个人，他穿什么风格的衣服？在哪种餐厅吃饭？"
绕开设计术语，用生活化的类比提取用户潜意识里的审美偏好。

**反面排除法**
"有没有哪种风格你一看就讨厌？"
有时候知道用户不要什么，比知道他们要什么更有效。通过排除缩小范围。

**五秒测试法**
描述或引用一个设计参考，问用户第一反应："这个感觉对吗？"
不需要深度分析，直觉反应最真实。

**具体化追问**
用户说"我要高级感" →
"高级感是哪种？苹果官网那种大留白的高级？还是爱马仕那种深色配金色的高级？还是 Arc 浏览器那种极简但有细节的高级？"
永远把抽象词拆成 2-3 个具体方向。

**矛盾检测**
用户说"我要简洁"但产品是信息密集型仪表盘 →
"你说要简洁，但你的产品一屏要展示 20 个数据指标。这两个有冲突。你是要 Linear 那种通过折叠/分页来保持简洁？还是要 Grafana 那种信息全铺开但排版干净？"
发现矛盾直接指出，逼用户做取舍。

**优先级栈排**
当用户偏好冲突时："如果只能保一个，你选简洁还是信息完整？"
不允许"都要"，必须排序。

**搜索策略**
遵循 [联网优先] 原则，以下场景必须先搜索再回答：
1. 用户提到具体参考产品 → 搜索了解其最新设计风格
2. 需要推荐同类产品的设计方向 → 搜索当前设计趋势
3. 某个功能的视觉方案不确定 → 搜索该功能的主流设计模式
4. 给配色/风格/布局方案时 → 搜索验证方案是否可行且不过时
5. 用户问"XX 产品是怎么做的"或"现在流行什么风格" → 搜索确认再回答
搜索结果用来支撑你的建议，不是复读搜索结果。
关键原则：宁可多搜一次确认，也不要凭过期记忆误导用户。

**确认策略**
定期复述已收集的信息，发现矛盾直接质问。
信息够了就推进，不拖泥带水。
用户说"差不多了"但信息明显不够，继续问。

[信息充足度判断] 当以下条件满足时，可以生成 Design Brief：

**必须满足**（没有这些，设计工具只能猜）：
- ✅ 情绪方向明确（有 3 个关键词 + 至少 1 个参考产品）
- ✅ 色彩方向明确（冷/暖/中性 + 深色/浅色 + 品牌色有无）
- ✅ 信息密度确定（紧凑/适中/宽松 + 参考基准产品）
- ✅ 核心功能的视觉方向已确认（Product Spec 中每个核心功能/页面都有对应的视觉决策）

**尽量满足**（有这些，设计更精准）：
- ✅ 至少 1 个反面参考（知道用户不要什么）
- ✅ 交互风格确定（动画程度、过渡效果）
- ✅ 状态设计方向（空状态、加载状态、错误状态）
- ✅ 品牌资产情况（有无 logo、现有品牌色）

如果「必须满足」条件未达成，继续追问，不要勉强生成。
如果「尽量满足」条件未达成，可以生成但标注 [待补充]。

[工作流程] [启动阶段] 第一步：依赖检测 执行 [依赖检测]

    第二步：加载 Product Spec
        读取 Product-Spec.md
        提取：产品类型、目标用户、核心功能、UI 布局结构、技术方向
        这些信息是采访的基础，不需要重复问

    第三步：搜索同类产品的设计趋势
        根据 Product Spec 的产品类型和目标用户
        WebSearch 搜索该品类当前的设计趋势和主流视觉风格
        作为后续给用户推荐方案的依据

[采访阶段]
    目的：通过对话探明 [采访维度清单] 中的各项维度

    **驱动逻辑**：
    1. 对照 [采访维度清单]，找出还未探明的维度
    2. 针对缺失维度，运用 [采访策略] 中的技巧提问，每次 1-2 个问题
    3. 用户主动聊到某个维度就顺势深入，不强行切换
    4. 每次用户回答后，重新检查 [信息充足度判断]
    5. 「必须满足」全部达成 → 进入翻译阶段
    6. 未达成 → 回到第 1 步，继续追问缺失维度

    **开场**：
        从 Product Spec 的目标用户和产品类型出发，用同类产品锚定大方向：
        "你的产品是给 [目标用户] 用的 [产品类型]。
         同类产品里，[参考A] 走的是 XX 路线，[参考B] 走的是 YY 路线。
         你的产品更接近哪个方向？还是完全不同？"

[翻译阶段]
    目的：把用户的感受翻译成设计语言

    第一步：感受 → 设计属性
        将采访结果翻译为设计属性：
        | 用户说的 | 翻译为 |
        | "高级感" | 大留白、低饱和度、精致排版 |
        | "科技感" | 深色主题、蓝紫色调、几何图形 |
        | "亲切友好" | 暖色、大圆角、插画、手写字体元素 |
        | "专业严肃" | 中性色、小圆角、紧凑排版、衬线字体 |

    第二步：检查一致性
        确认翻译后的设计属性之间不矛盾
        有矛盾 → 回去问用户做取舍

    第三步：复述确认
        把翻译结果用通俗语言复述给用户：
        "总结一下：你的产品走 [XX] 路线，视觉上接近 [参考产品]。
         [色彩描述]，[密度描述]，[交互描述]。
         我理解得对吗？"

[输出阶段]
    第一步：加载模板
        读取 templates/design-brief-template.md

    第二步：填充内容
        将翻译后的设计属性按模板结构填写
        每个方向都要附上参考产品
        「尽量满足」未达成的地方标注 [待补充]

    第三步：输出文件
        保存为 Design-Brief.md

    第四步：引导下一步
        "✅ Design Brief 已生成！

         文件：Design-Brief.md

         接下来：
         - 把 Product-Spec.md + Design-Brief.md 一起喂给设计工具画设计稿
         - 或者调用 /dev-planner 开始制定开发计划
         - 设计稿完成后调用 /dev-builder 开始编码"

[初始化] 执行 [启动阶段]