UI 美学
意图
使用此技能，让 Web UI 输出感觉更专业、更稳定、更具产品级质感。
默认目标：
- 保留用户请求的范围和内容体量
- 在添加装饰之前，先实现平衡的构图
- 让层级的可读性一目了然
- 保持色彩克制但看起来昂贵
- 仅在需要说明深度时使用阴影、模糊、发光和高光
- 动效保持简短、流畅且有用
- 让组件在感觉有样式之前先感觉精确
- 保持状态、动效和深度在同一连贯的体系内
此技能不依赖框架。不仅要评判页面构图，还要评判组件精度、状态行为、动效语法和深度纪律。先用设计判断力领导，然后实施。
任务路由
在行动前对请求进行分类：
- 生成 当用户想要一个新的页面、区块或组件时使用。
- 审查 当用户需要批评、发现或诊断 UI 为何感觉薄弱时使用。
- 重构 当用户希望直接重写现有实现时使用。
- 组件抛光 当结构可以接受，但控件、卡片、表格、模态框或覆盖层仍然感觉通用或廉价时使用。
- 状态 / 动效优化 当悬停、聚焦、按下、选中、加载、成功、错误或过渡感觉嘈杂、薄弱或戏剧化时使用。
- 深度 / 光照优化 当阴影、高光、发光、模糊或深色模式分离需要更严谨的纪律时使用。
如果请求混合了审查和重构，先诊断，然后在编辑前选择重写深度。
不可妥协的事项
- 完全尊重请求的范围：组件就保持为组件，卡片集保持为有界的模块，区块保持为区块，页面仅在要求时才成为页面。
- 在触及实现之前决定视觉主旨。
- 在样式化之前锁定工件类型：不要将卡片、小部件、模态框、面板或区块的提示变成完整的落地页或仪表盘。
- 让布局、间距和排版层次承担大部分的质量责任。
- 当间距可以承载关系时，优先使用空间分组而非默认的框架。
- 将“高级感”视为克制、一致性和精确性，而非视觉噪音。
- 使用更少的容器、更少的强调色和更少的同时想法。
- 如果请求的工件是一个页面，默认使用填满屏幕宽度的全视口构图，而不是一个居中放置的小画布。
- 对于平台、市场、电商或门户风格的页面，默认使用全宽页面骨架，并有意地约束内部内容，而不是将整个体验困在一个居中的面板内。
- 默认保留用户的信息密度和文案体量。
- 除非请求要求，否则不要添加英雄文案、营销段落、导航、页脚、功能区块、徽章或 CTA 集群。
- 让普通卡片保持简洁。倾向于使用强有力的标签、值和紧凑的支持性文本，而不是编造的简介。
- 默认偏好清晰的中性或略冷的米色表面；不要自动使用奶油色、米色、象牙色或暖色调作为“高级感”信号。
- 让组件抛光从属于页面构图。
- 将相关控件视为一个几何和行为系统的成员。
- 让默认状态在视觉上保持安静；将较强的强调留到交互和语义状态中。
- 优先选择平衡稳定的布局，而不是张力、不对称或视觉挑衅。
- 不要仅仅为了避免看起来模板化而引入不对称或夸张的对比。
- 区分持续的选中状态和瞬时的激活或按下反馈。
- 仅在能解释分层、材质分离或焦点时使用深度。
- 将发光视为例外，而非结构性元素。
- 让移动端成为重新组合的布局，而不是被挤扁的桌面版。
- 保持结果可交付和可维护。
优先级顺序
除非任务明确需要不同的顺序，否则按此顺序工作：
- 请求的范围和工件边界
- 构图与结构平衡
- 间距节奏与信息密度
- 排版与文案适配
- 组件工艺
- 交互状态与行为
- 色彩系统与语义克制
- 深度线索：边框、阴影、模糊、高光
- 动效、反馈与过渡
如果页面在灰度下看起来仍然不行，说明结构尚未解决。
工作流程
生成
- 识别请求的工件类型和硬性范围：单个组件、组件集、区块或完整页面。
- 在该范围内推断角色、受众和密度，而不是扩展它。
- 用一个简短的短语命名期望的印象，例如“平静的产品清晰度”、“企业级抛光”或“安静的精确性”。
- 在编写标记之前，选择一个稳定的主块和支持模块。
- 如果请求是针对卡片或组件，仅使用清晰展示它所需的最少周边画布。
- 除非用户要求内容设计，否则保留文案体量。如果需要，可以收紧措辞，但不要发明额外的说明性文本。
- 如果请求是针对页面，默认让外部布局跨越视口，而不是作为一个狭窄的居中板块浮动。
- 对于平台或电商页面，首先扩展页面骨架：让导航、英雄框架、分类轨道、活动区域和产品流在视口中呼吸，然后再将单个模块卡片化。
- 定义色彩逻辑：中性色优先，强调色其次。
- 在添加抛光之前，先让组件度量、状态和行为感觉系统化。
- 仅在静态构图工作后添加深度和动效。
- 当请求的工件实际跨越桌面和移动端时，明确约定两者行为。
当视觉方向仍然模糊时，阅读 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 来结构化发现。
当 UI 感觉像是 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。
自我审查
在最终输出之前，检查：
- 结果是否保持在用户请求的范围内，没有为一个组件发明一个页面？
- 三秒内能否一目了然？
- 在没有渐变和阴影的情况下，布局是否仍然感觉可信且平衡良好？
- 如果是页面，构图是否默认占据了屏幕宽度？
- 如果是平台或电商页面，外部骨架是否跨越视口，而仅内部内容区域保持受限？
- 文案是否保持任务允许的简洁，尤其是在普通卡片上？
- 中性色是否足够平静和一致，让强调色有意义？
- 调色板是否避免了在没有内容理由的情况下默认使用奶油色或暖白色的奢侈暗示？
- 相关控件是否共享兼容的高度、内边距逻辑和圆角半径纪律？
- 默认状态是否足够安静，为聚焦、激活和错误状态留出空间？
- 选中状态和按下状态是否明显不同？
- 组件看起来是否相关，但并非都具有相同的权重？
- 阴影和高光是否描述了深度，而不是制造雾气？
- 在深色 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