ui-polish

name	ui-polish
description	提升 Web、H5、小程序、Chrome 扩展、移动应用、Electron、Tauri 和桌面应用的界面质感、层级与一致性。用于任何涉及页面、组件、弹窗、设置页、面板、工具窗口、仪表盘或设计重构的任务，尤其当用户要求更好看、更高级、更有质感、更专业、减少 AI 味时。

UI Polish

Overview

先明确平台、界面类型、信息密度和视觉方向，再开始实现。目标不是“加装饰”，而是用设计令牌、层级、留白、状态和克制动效，把界面做得更成熟、更耐看、更像真实产品。

Workflow

1. 先确认平台：Web、H5、小程序、Chrome 扩展、移动 App、Electron、Tauri 或其他桌面壳。
2. 先定义视觉方向：工具感、编辑器感、极简、品牌展示、数据面板等，只选一个主方向。
3. 优先复用项目已有设计系统、组件库和 token；没有时再补统一 token。
4. 先搭层级和留白，再补颜色、质感和动效。
5. 默认补齐关键状态：hover、active、focus、disabled、loading、empty、error。
6. 动效只服务于层级切换、反馈和揭示，不做无意义炫技。
7. 输出前必须先生成真实截图，再按 review gate 自查；不过关就继续修改。
8. 不把“能跑”当成“做完”，不把“我觉得还行”当成通过。

Default Rules

• 用 token 管颜色、间距、圆角、阴影、边框和动效，不要散落原始值。
• 无明确品牌或现有设计系统依据时，不要默认使用蓝紫/紫粉渐变、蓝紫玻璃、紫白 SaaS、黑底霓虹青、祖母绿/翡翠绿、银灰、雾绿、橙红/焦橙渐变这类常见 AI 惯用配色。
• 主任务、主按钮、主信息必须最先被看见，不要平均用力，不要让装饰层压过内容层。
• 文案必须站在使用者视角；禁止自我解释、抽象空话、提示词残留、没信息价值的大标题，以及重复的小标题、眉标题、分组标题。
• 默认不写区域标题、眉标题、解释型标题。
• 能靠内容本身、位置关系、状态变化看懂的，就不要标题。
• 结构必须克制：尺寸匹配内容，间距只够分组，不要无意义外框/内框，不要空耗空间。
• 可读性必须过关：小字、辅助文案、半透明层文字都要清晰；低对比度、发灰、发虚直接算失败。
• 按钮必须有明确反馈；点击后要立刻让用户知道是否生效、是否处理中、结果如何。
• 按钮必须收敛；同层只保留必要操作，重复、近义、同权重按钮要合并或删除。
• 必须补齐 hover、active、focus、disabled、loading、empty、error。
• 动效只服务反馈和层级切换；优先 transform 和 opacity，不要堆无意义特效。

Load On Demand

• 平台差异：读 references/platforms.md
• 风格方向与反模式：读 references/styles.md
• prompts 与模板：读 references/prompts.md
• 常见页面骨架：读 references/patterns.md
• 模板来源白名单：读 references/sources.md
• 交付前自查：读 references/checklist.md
• 截图审美闸门：读 references/review-gate.md

Built-in Tool

用 scripts/capture_ui.py 给本地 html 或 url 生成真实截图，再做审美复审。

Output Standard

• 不只给代码，还要体现视觉方向、token 使用和状态覆盖。
• 若需要解释设计，优先说明“为什么这样更像真实产品”，而不是泛泛谈美观。
• 若项目栈与外部参考库不同，只借鉴设计思路，不机械搬运技术实现。