mcpField
D
design-style-picker

design-style-picker

github.com/daymade设计与 UI1.5k348 次安装今天更新
代码仓库

关于 design-style-picker

design-style-picker 是帮助设计人员把模糊的审美偏好转化为可比较视觉方案的技能。它先检查现有界面与设计资产,再生成有明确差异的选项供选择,并指导后续实现与视觉验收。

主要功能

  1. 01梳理设计目标与变更范围
  2. 02检查现有界面和设计资产
  3. 03生成差异化视觉方案矩阵
  4. 04按颜色角色组织配色
  5. 05审查候选图并指导实现

适用场景

  1. 01探索产品界面的视觉方向
  2. 02比较设计系统的风格选择
  3. 03依据选定参考改进现有 UI

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/daymade/claude-code-skills --skill design-style-picker

安装后在 Claude Code 中输入/design-style-picker确认已加载。

附带文件agents/openai.yamlreferences/selection-playbook.md

详细介绍

设计风格选择器

用途

使用此技能将模糊的审美偏好转化为具体的视觉选择。目标不是猜出一个最终设计,而是生成一组结构化选项,快速明确用户的审美边界。

核心规则

如果用户已经表示自己无法描述抽象风格,就不要要求他们描述。生成可供对比的视觉示例,让他们选择,然后根据选定的参考进行实现。

工作流

  1. 重述真正的目标

    • 说明用户实际要选择的内容:设计系统风格、业务应用界面、着陆页、演示文稿、组件库等。
    • 区分选择一个方向、保留多个方向,以及为不同视觉角色分配不同方向。多个选项并不意味着必须互斥;保留两种方向也不代表已经决定如何将它们共存。在探索已获授权的方向时,暂时保留尚未决定的采用或融合选择。
    • 将主要交付物与验证样例区分开。如果任务是设计系统,业务界面只是可选的验证样例,而不是主要交付物。
    • 除非用户明确要求舍弃,否则保留现有 UI、资源、设计令牌、布局、品牌线索和领域背景。
    • 在本轮授权的维度之外,固定现有的空间结构、导航、缩放/细节层级和阅读方式。演进产品前,先明确这些维度;不要仅仅为了方便比较风格,就将产品重新编排成另一个页面。
  2. 先收集现有资源

    • 检查当前渲染的 UI 或截图。
    • 选择结构性截图前,先确认其实际界面和交互层级与用户的目标相符。局部详情页可以作为局部界面任务的参考,但不能替代整个工作区,也不能代替从概览到详情的完整流程。获取缺失的视图,或使用已验证的规格,并标明任何未经视觉检查的部分。
    • 查看设计令牌、CSS 变量、组件名称、关键图像、品牌/领域参考和现有截图。
    • 将当前资源视为起始词汇。不要在此基础上生成无关的“全新”概念。
  3. 生成矩阵,而非细微变体

    • 如果审美偏好不明确,至少使用两个已获授权的维度:
      • 纵向梯度:某一维度按较大幅度变化,例如色彩强度 20/35/50/65/80。
      • 横向方向:采用不同的组织策略,例如数据驱动的色彩、品牌主轴、温暖的产品图像、场景模块或治理主导的布局。
    • 让选项在视觉上明显不同。如果两张图看起来像同一系列的变体,就重新生成其中一张,增强对比。
    • 优先批量生成。用户在等待选择,而不是观看一张张缓慢生成的图片。
  4. 将色彩作为系统来使用

    • “色彩少一些”并不等于黑白配色。通常意味着减少相互竞争的视觉焦点。
    • 保持产品调色板的活力,同时为色彩分配角色:
      • 用大面积区域和分区色带表达架构。
      • 用数据可视化和证据系统承载多色语义。
      • 将品牌色/风险色用于少量但醒目的强调。
      • 日常 UI 使用中性色组件。
    • 用户调整色彩时,明确提供上限样例:稳妥、中等、高强度和过载边界。
  5. 展示前先审核

    • 亲自打开生成的图像。
    • 在评判审美前,先检查目标覆盖情况:用户能否检查所要求的界面、比例、状态和交互层级,候选方案是否保留了所述关系?先补齐缺失内容,再判断色彩或视觉特征。静态图像可以展示交互层级,但不能证明交互行为。
    • 标注哪些方案可能过于沉闷、色彩过多、过于普通、太像业务系统,或最接近目标。
    • 为每个有用的候选方案提供文件路径和简短的决策说明。
  6. 根据选定的图像实现

    • 提取原则,而不是像素:颜色角色、布局密度、视觉焦点层级、组件处理方式、图像使用方式,以及治理/数据的放置位置。
    • 经批准后,明确融合选定的参考方案。例如:“颜色布局采用 H02,调色板强度采用 V04。”如果保留多个方向仅用于探索,应继续将其纳入备选,但不要将保留视为已批准融合或分配角色。
    • 除非用户要求创建新作品,否则将实现范围限定在现有 UI 内。
    • 实现后,对渲染结果进行视觉质量检查。

提示词模式

生成图像时,请包含:

This is an evolution of the existing UI/design system, not a replacement.
Preserve these assets: <tokens, imagery, sections, components, brand cues>.
Target surface and levels: <requested view, scale, states, overview/detail coverage>.
Reference coverage: <what each screenshot proves; missing views or specification-only parts>.
Frozen behavior: <spatial structure, navigation, zoom, reading>.
Direction relationship: <choose one / retain several / approved role assignment; unresolved choices>.
Axis: <vertical ladder or horizontal direction>.
Variant name: <clear label>.
Color/visual rule: <specific budget or organization method>.
Primary focal point: <one thing>.
Avoid: <known rejected styles from the user>.

需要保留的经验

  • 用户说“不要太花哨”,可能是指“不要出现几十个权重相同的小色块”,而不是“去掉所有颜色”。
  • 用户说“更有分量”,可能是指视觉权威感和层级,而不是暗色模式控制室。
  • 对于设计系统工作,不要用业务仪表板取代设计系统。业务界面可以用于验证风格,但不应成为最终答案。
  • 始终创建有意设置的边界样例。它们能直观呈现“过多”的程度,并加快选择过程。
  • 批准组合后,融合选定的参考方案,并说明各自的贡献。

参考资料

  • 进行完整的风格选择流程,或用户在图像探索期间提出审美调整意见时,请阅读 references/selection-playbook.md。

评论

支持 Markdown