关于 ui-aesthetics
ui-aesthetics 是一项与框架无关的技能,用于生成、评审和改进 Web 界面。它优先关注范围、构图、层级和组件行为,并强调克制地运用色彩、纵深与动效。
主要功能
- 01生成、评审与重构任务分流
- 02构图与层级指导
- 03组件及交互状态优化
- 04色彩、纵深与动效原则
- 05基于参考资料的评审和自检
适用场景
- 01设计 Web 页面或组件
- 02诊断界面层级薄弱之处
- 03打磨控件与交互状态
- 04调整动效或视觉纵深
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ kasonye/ ui-aesthetics-skill --skill ui-aesthetics安装后在 Claude Code 中输入/ui-aesthetics确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
.gitignoreREADME.mdREADME.zh-CN.md.agent/workflows/ui-aesthetics.md.codebuddy/commands/ui-aesthetics.md.cursor/rules/ui-aesthetics.mdc.github/prompts/ui-aesthetics.prompt.md.kiro/steering/ui-aesthetics.md.opencode/commands/ui-aesthetics.md.roo/commands/ui-aesthetics.md.shared/ui-aesthetics/usage.mdcore.mdreference-map.md.windsurf/workflows/ui-aesthetics.mdagents/openai.yamlreferences/design-principles.mdcolor-system.mdanti-patterns.mdcomponent-aesthetics.mddepth-lighting-system.mdmotion-patterns.mdinteraction-states.mddistilled-examples.mdmotion-principles.mdnon-card-layouts.mdreview-rubric.mdstyle-archetypes.mdrewrite-playbook.md详细介绍
UI 美学
意图
使用此技能,让 Web UI 的输出更专业、稳定,更具产品质感。
默认目标:
- 保留用户要求的产物范围和内容规模
- 先打造平衡的构图,再添加装饰
- 让层级一目了然
- 控制色彩,呈现高级质感
- 仅在有助于明确层次时使用阴影、模糊、光晕和高光
- 让动效简短、流畅且实用
- 先让组件显得精准,再赋予其风格
- 让状态、动效和层次遵循统一的系统
此技能与框架无关。评估时不仅要看页面构图,还要关注组件精度、状态行为、动效规则和层次运用。先做出设计判断,再开始实现。
任务分类
开始前先对请求进行分类:
- 生成 用户需要创建新页面、区块或组件时使用。
- 评审 用户需要评价、发现问题,或诊断 UI 显得薄弱的原因时使用。
- 重构 用户需要直接重写现有实现时使用。
- 组件润色 结构已可接受,但控件、卡片、表格、模态框或覆盖层仍显得普通或廉价时使用。
- 状态/动效优化 悬停、焦点、按下、选中、加载、成功、错误或过渡效果显得杂乱、乏力或过于戏剧化时使用。
- 层次/光照优化 阴影、高光、光晕、模糊或暗色模式下的层次区分需要更加克制时使用。
如果请求同时包含评审和重构,先诊断,再确定重写深度,然后编辑。
不可妥协的原则
- 严格遵守要求的范围:组件就保持为组件,卡片组就保持为有限模块,区块就保持为区块;只有明确要求时,才将其扩展为整页。
- 动手实现前先确定视觉主旨。
- 先确定产物类型,再进行样式设计:不要把卡片、小组件、模态框、面板或区块的需求变成完整落地页或仪表盘。
- 让布局、间距和文字层级承担大部分品质表达。
- 只要间距足以体现元素间的关系,就优先用空间分组,而非默认添加边框或容器。
- 将“高级感”视为克制、一致和精准,而非视觉噪音。
- 减少容器、强调色和同时呈现的设计概念。
- 如果用户要求的是页面,默认采用铺满视口宽度的构图,而不是一个居中的小画布。
- 对于平台、市场、电商或门户类页面,默认采用全宽页面骨架,并有意识地限制内部内容宽度,而不是将整个体验限制在一个居中的面板里。
- 默认保留用户的信息密度和文案规模。
- 除非用户明确要求,否则不要添加主视觉文案、营销段落、导航、页脚、功能区块、徽章或 CTA 组。
- 普通卡片应简洁。优先使用有力的标签、数值和精炼的辅助文本,而不是编造介绍文案。
- 默认优先采用清晰、中性或略偏冷调的中性色表面;不要把奶油色、米色、象牙色或暖白色当作营造高级感的固定手段。
- 组件润色应服务于页面构图,而非喧宾夺主。
- 将相关控件视为同一几何与行为系统中的成员。
- 默认状态应保持视觉克制;将更强的强调留给交互状态和语义状态。
- 优先选择平衡、稳定的布局,避免刻意制造张力、不对称或视觉挑衅。
- 不要仅为避免模板感而引入不对称或夸张对比。
- 区分持续存在的选中状态与短暂的激活或按下反馈。
- 仅在能说明层叠关系、材质分隔或焦点时使用层次效果。
- 光晕应是特殊手段,而非结构性元素。
- 移动端应重新组织布局,而不是压缩桌面布局。
- 确保结果可交付、易维护。
优先顺序
除非任务明确要求采用不同顺序,否则按以下顺序进行:
- 请求范围与产物边界
- 构图与结构平衡
- 间距节奏与信息密度
- 字体排印与文案适配
- 组件打磨
- 交互状态与行为
- 色彩系统与语义克制
- 深度线索:边框、阴影、模糊、高光
- 动效、反馈与过渡
如果页面在灰度模式下仍然不理想,说明结构还没有解决。
工作流
生成
- 明确请求的产物类型和范围约束:单个组件、组件集、区块还是完整页面。
- 在该范围内推断角色、受众和信息密度,不要擅自扩大范围。
- 用一个简短短语描述期望的观感,例如
calm product clarity、enterprise polish或quiet precision。 - 编写标记之前,先确定稳定的主区块和辅助模块。
- 如果请求的是卡片或组件,只使用清晰呈现它所需的最小周边画布。
- 除非用户要求进行内容设计,否则保留文案的篇幅。必要时精简措辞,但不要臆造额外的说明文字。
- 如果请求的是页面,默认让外层布局铺满视口,而不是将页面设计成狭窄的居中内容块。
- 对于平台或电商页面,先扩展页面骨架:让导航、主视觉框架、分类栏、活动区域和商品流在视口中充分展开,再将各个模块设计成卡片。
- 明确色彩逻辑:先确定中性色,再确定强调色。
- 添加润色效果前,先让组件的尺寸、状态和行为体现出系统性。
- 静态构图奏效后,再添加深度和动效。
- 只有当请求的产物实际涵盖桌面端和移动端时,才明确说明这两种设备上的行为。
如果视觉方向仍然模糊,请阅读 references/design-principles.md。
如果配色显得喧闹、平淡或廉价,请阅读 references/color-system.md。
如果请求侧重控件、表单、卡片、表格或覆盖层,请阅读 references/component-aesthetics.md。
如果悬停、焦点、激活、选中、加载、成功或错误行为很重要,请阅读 references/interaction-states.md。
一般的动效规范请阅读 references/motion-principles.md。
如果需要更精确地控制过渡、悬停行为或显现动效,请阅读 references/motion-patterns.md。
如果需要更精确地控制阴影、高光、辉光、模糊或暗色模式下的层级逻辑,请阅读 references/depth-lighting-system.md。
如果用户要求更鲜明具体的视觉个性,请阅读 references/style-archetypes.md。
评审
- 从最严重的结构问题入手,而不是纠结 CSS 细节。
- 说明问题出在层级、密度、组件质量、状态行为、配色、深度还是动效。
- 将每项发现与可读性、信任感、注意力聚焦或操作清晰度联系起来。
- 优先给出直接的修正方案,而不是泛泛而谈审美。
使用 references/review-rubric.md 来组织评审意见。
如果界面看起来像 AI 生成或只有表面上的高级感,请参考 references/anti-patterns.md。
如果主要问题是配色规范或强调色误用,请参考 references/color-system.md。
如果主要问题是控件、卡片、表格或覆盖层的质量,请参考 references/component-aesthetics.md。
如果主要问题是悬停、焦点、激活、选中、加载或错误行为,请参考 references/interaction-states.md。
如果主要问题是动画质量、时序或反馈行为,请参考 references/motion-principles.md 和 references/motion-patterns.md。
如果主要问题是阴影朦胧、辉光误用、层级不足或暗色模式下的深度,请参考 references/depth-lighting-system.md。
重构
- 选择“轻度润色”“中度重组”或“全面重建”。
- 先调整布局和分组,再修饰组件外观。
- 如果层级不清晰,就去掉薄弱的样式,回归灰度结构。
- 添加润色效果前,先重建组件尺寸和状态逻辑。
- 只重新加入界面仍然需要的色彩、纵深和动效。
- 如果桌面结构无法适配移动端,就有针对性地重建移动端布局。
- 编辑前,说明重写级别、核心问题和预期方向。
进行大范围视觉改动前,请先阅读 references/rewrite-playbook.md。
大范围重写控件或覆盖层前,请先阅读 references/component-aesthetics.md。
更改跨状态行为前,请先阅读 references/interaction-states.md。
重写杂乱的调色板前,请先阅读 references/color-system.md。
添加或简化过渡效果前,请先阅读 references/motion-principles.md 和 references/motion-patterns.md。
添加或移除高程、辉光或高亮逻辑前,请先阅读 references/depth-lighting-system.md。
反模式规范
拒绝依赖以下做法的输出:
- 扩大范围,将组件请求变成整页、仪表盘框架或落地页布局
- 堆砌装饰性文案,添加未被要求的填充描述、徽章、统计数据或 CTA 区块
- 页面级布局被困在不必要的狭窄居中容器中,且没有内容层面的理由
- 平台或电商页面被塞进一个过大的居中卡片,而不是采用全宽页面骨架
- 套用模板式的居中堆叠主视觉加卡片网格布局
- 为营造张力而采用不稳定或刻意不对称的布局
- 权重相同的模块缺乏明确的阅读顺序
- 表面、描边、胶囊和圆角过多
- 默认使用奶油色、米色、象牙色或暖灰白等中性色来营造“高级感”
- 不稳定的中性色上搭配过于鲜艳的强调色
- 默认状态本身就使用过多视觉强调
- 悬停、按下或显现行为让交互变成一场表演
- 选中状态看起来像点击反馈
- 用辉光、阴影、模糊或渐变伪造精致感
- 动画只为吸引注意,而不是引导感知
- 深度系统让所有元素同时浮起
- 视觉效果强烈的设计先求吸睛,而非清晰
- 移动端布局只是折叠列,没有重新组织重点
如果结果看起来精致却依然廉价,请阅读 references/anti-patterns.md。
自我审查
最终输出前,请检查:
- 结果是否严格遵循用户要求的范围,没有凭空添加整页内容?
- 是否能在 3 秒内一眼看懂?
- 不使用渐变和阴影时,布局是否仍然可信且协调?
- 如果这是一个页面,默认布局是否充分利用了屏幕宽度?
- 如果这是一个平台或电商页面,外层结构是否铺满视口,同时仅限制内部内容区域的宽度?
- 文案是否尽可能简短,尤其是普通卡片上的文案?
- 中性色是否足够沉稳、一致,让强调色发挥应有的作用?
- 配色是否避免在没有内容依据时默认采用奶油色或暖白色的奢华风格?
- 相关控件的高度、内边距逻辑和圆角规范是否彼此兼容?
- 默认状态是否足够克制,为焦点、激活和错误状态留出空间?
- 选中和按下状态是否有明显区别?
- 各组件看起来是否有关联,同时又不显得权重完全相同?
- 阴影和高光是否用于呈现纵深,而非制造朦胧感?
- 在深色 UI 中,纵深是否首先通过表面层级和边缘定义来体现,而非依赖模糊和阴影?
- 发光效果是否足够少见,因而仍有意义?
- 动效时长是否可控且简短?
- 动效是否在强化交互逻辑,而非变成一场表演?
- 构图是否保持平衡,而没有刻意吸引注意力?
- 首屏移动端视口是否保留了相同的主要信息或操作?
- 改进是否减少了干扰,而非增加更多样式?
参考资料
- 核心设计规则:
references/design-principles.md - 色彩系统规则:
references/color-system.md - 组件打磨规则:
references/component-aesthetics.md - 交互状态规则:
references/interaction-states.md - 动效规则:
references/motion-principles.md - 动效模式规则:
references/motion-patterns.md - 景深与光照规则:
references/depth-lighting-system.md - 风格范式:
references/style-archetypes.md - 反模式:
references/anti-patterns.md - 评审结构:
references/review-rubric.md - 重写深度与输出规范:
references/rewrite-playbook.md - 精简判断示例:
references/distilled-examples.md