idea-to-ui-design-brief

从创意到 UI 设计简报

概述

将此技能作为创意工作流中 Full 模式的可选阶段。它会将产品／设计方向转化为实用的 UI 设计简报，用于指导图像生成概念、HTML 原型或后续的 Superpowers 实施工作。

除非用户明确要求 UI 设计，否则不要在 Lite 模式下运行此技能。Lite 模式应保留之前简单记录创意的行为。

UI 简报是产品构思与实施之间的桥梁。它应明确界面应呈现什么视觉效果、带来什么感受以及如何响应，而不应过早强加代码架构。

适用场景

用户提出以下需求时使用：

• 探索某个创意的可能 UI 设计；
• 在创意工作流中添加专门的 UI／设计阶段；
• 为应用截图、仪表板、落地页或产品界面生成图像提示词；
• 在将创意交给编码 Agent 之前创建 UI 简报；
• 已有截图时，评审或重新设计已构建的应用；
• 将设计文档转化为逐屏 UI 需求。

以下情况不要使用：

• 用户只想快速记录一条 Lite 模式的创意；
• 创意尚不够明确，无法确定目标用户和核心行为；
• 用户希望立即获得生产级前端代码——选定 UI 方向后再使用实施技能；
• 用户只想要正式的 token 规范——如果有 design-md，请使用它。

产物位置

对于 Full 模式的创意方案包，在设计文档之后、实施规划之前添加此产物：

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

回退规则：如果用户跳过此阶段，请保留旧工作流的编号和行为，或在实施规范中将 UI 决策标记为假设。不要仅因为缺少 UI 简报而阻止工作流。

必需输入

撰写 UI 简报之前，收集或推断以下信息：

• 产品用途和目标用户；
• 核心用户流程；
• 主要屏幕或界面；
• 目标平台：Web、桌面端、移动 Web、原生移动端或多种界面；
• 期望的感受：平和、指挥中心风格、活泼、专业、信息密集、极简等；
• 视觉限制：品牌、现有代码仓库／设计系统、无障碍需求、深色／浅色模式；
• 重要状态：空状态、加载中、错误、成功、首次使用、重复使用。

如果缺少这些信息，且用户没有要求继续推进，则一次只问一个简短问题。

UI 简报结构

创建 02-ui-design-brief.md，内容包括：

# <Idea Title> — UI Design Brief

## Purpose

## Product Feel

## Design Principles

## Primary Surfaces / Screens

## Screen-by-Screen Notes

## Layout / Information Architecture

## Component Inventory

## Key User Flows

## States to Design

## Visual Direction

## Accessibility and Responsiveness

## Content / Copy Notes

## Optional Image-Generation Concepts

## Selected Direction

## Open Questions

## Handoff Notes for Implementation

可选图像生成环节

图像生成是可选的，应视为概念探索，而非实施的事实依据。

以下情况使用图像生成：

• 用户想探索可能的视觉方向；
• 设计偏好尚不明确；
• 应用／仪表板／落地页需要先进行视觉探索，再编写代码；
• 工作流适合对比 2-3 种方向。

默认生成三个概念提示词：

1. 保守型 — 熟悉、风险低、易于实现。
2. 高度契合型 — 对产品简报的最佳诠释。
3. 差异化型 — 更具特色，有助于探索偏好边界。

每条提示词都应说明：

• 产品类别和目标用户；
• 屏幕类型和平台；
• 信息层级；
• 信息密度和交互方式；
• 视觉风格和主题；
• 不应出现的内容；
• 结果应为 UI 概念截图，而非营销图片。

图像提示词模板

Create a high-fidelity UI concept screenshot for <product>. Platform: <desktop web/mobile/etc>. Screen: <main dashboard/onboarding/settings/etc>. Target user: <user>. Product feel: <feel>. Layout: <key layout>. Must show: <components/data/actions>. Avoid: generic SaaS filler, fake irrelevant metrics, stock photos, excessive gradients, unreadable tiny text. Style: <visual direction>. The image should be a realistic product UI mockup suitable for turning into a design brief.

生成图像后

如果生成了图像产物：

1. 在 UI 简报中保存或引用每张图像的路径／URL。
2. 使用视觉分析或人工评审，提取有效之处和不足之处。
3. 更新 Selected Direction，写明选定的布局、组件和视觉规则。
4. 不要让构建 Agent 盲目照搬图像。应将图像转化为文本需求、组件、tokens 和验收标准。

构建后的重新设计循环

Superpowers 或其他编码 Agent 构建应用后，可以再次运行此技能，进行 UI 润色：

1. 截取已构建应用的屏幕截图。
2. 将截图与 UI 简介和产品设计文档进行比较。
3. 找出 UI 差距：层级、间距、导航、文案、状态处理、响应式设计。
4. 可选择生成其他 UI 概念。
5. 编写有针对性的重新设计简介和实施任务清单。
6. 将任务清单交给 Superpowers，并提出以下限制：仅改进 UI，除非明确获批，否则不要更改后端行为。

集成规则

• 默认情况下，此阶段仅适用于 Full 模式。
• 不得将其变成强制步骤或脆弱的环节。
• 如果跳过此阶段，则继续沿用旧的“设计文档 → 实施规范 → 交接”流程。
• 如果用户希望加快速度，则仅在设计文档中加入简短的 UI / UX Notes 部分。
• 如果无法生成图像，则编写图像提示词，并继续创建纯文本 UI 简介。
• 如果已有代码仓库，则在提出新的设计方向前，先检查现有 UI/组件。

常见问题

1. 让图像成为规范。 图像仅供参考。书面的 UI 简介和实施交接文档才是事实依据。
2. 让 Lite 模式过于复杂。 除非用户要求，否则不要在快速创意记录中加入此阶段。
3. 使用千篇一律的仪表盘设计。 避免使用虚构指标、无关图表和装饰性卡片，除非产品确实需要。
4. 遗漏状态。 空状态、加载状态、错误状态、成功状态、首次运行状态和移动端状态都会影响构建质量。
5. 破坏产物编号。 如果将此阶段加入软件包，请更新 README 中的产物映射，并一致地调整后续阶段编号。
6. 照搬专有参考设计。 转化风格原则，不要克隆第三方具有鲜明特色的 UI。

验证清单

• 工作流处于 Full 模式，或用户明确要求进行 UI 设计。
• 产品/设计方向足够清晰，可以据此做出屏幕级 UI 决策。
• 如果运行了此阶段，则存在 02-ui-design-brief.md。
• 即使跳过图像生成，也要将可选的图像提示词存放在简介中。
• 如果生成了图像，应将其视为参考，并转化为文本要求。
• 实施交接文档引用了选定的 UI 方向，或明确说明 UI 仅为假设。
• 如果跳过此阶段，旧工作流仍可不受阻碍地继续执行。