用途
polish 用于改善产品界面的视觉与交互质量，同时保留既有的视觉语言。它解决的不是“审美”问题，而是“决策”问题：默认样式、缺乏层级、装饰取代意图。它通过理解产品、有意识地审计、并做出少量强决策来改进界面，而不是堆叠渐变与特效。
主要能力
- 在保持视觉语言的前提下优化信息层级、排版、间距、密度、交互状态、响应式与键盘可用性。
- 提供多种工作模式，每种模式限定改动范围：subtle polish（间距/字体/一致性，不做结构改动）、full redesign（自结构向上：布局、层级、表面）、dashboard（密度优先、可扫读、状态完整）、landing page（层级与唯一主行动）、mobile-first（先设计 390px 流程再向上增强）、design-system cleanup（将漂移收敛到现有令牌，不新增内容）。
- 提供审计清单与工作流程：先检查仓库与渲染产品，识别现有原语（间距尺度、字体尺度、语义色角色、圆角、阴影、断点、焦点处理、动效令牌），记录漂移；在支持的桌面与窄宽度渲染目标路由，捕获初始、加载、填充、空、错误、禁用、校验、长内容等状态；进行纯键盘导航、可见焦点、Esc 行为、对话框、菜单与表单错误检查；测试真实压力场景（长翻译字符串、窄宽度、多行、缺图、慢网络、缩放、暗色主题、减少动效偏好）。
- 设计决策框架要求先写方向段落（受众、主要任务、层级意图、密度、视觉性格、需保留的约束、预期最有效的最小改动集），再按结构 → 节奏 → 可读性 → 表面 → 反馈的顺序决定改动。
- 交互与状态模型：对每个改动的交互组件，明确用户动作、启用条件、反馈、成功、可恢复失败、不可逆失败与键盘行为，并覆盖默认、悬停/激活、焦点可见、禁用、加载、空、错误、成功等状态。
- 可访问性与性能验证协议：语义、键盘、视觉可达性、动效、运行时质量、回归范围。要求文本对比度达到 AA，焦点处处可见；对 Web 检查当前 Core Web Vitals（LCP ≤ 2.5s、INP ≤ 200ms，均在第 75 百分位分移动/桌面分段），并说明工具、条件与局限。
- 提供禁用清单：默认紫色渐变、随机玻璃拟态、卡片网格成瘾、因“现代 SaaS”而巨大的 hero、任意渐变/光晕、图标泛滥、为新颖而重写令牌。
使用方式
使用前需明确：产品是什么、谁在用、页面唯一主行动是什么、现有设计系统（仓库中已有的令牌、组件、字体）以及可复用的已有成果。需确定支持的视口范围、颜色主题、区域设置、数据极端情况、输入方式与实现边界。若请求仅为“让它更好”，应先检查真实界面并返回简明方向，再做广泛视觉改动。工作流程：1）对照清单审计；2）决定方向；3）在系统内实现；4）像工程师一样验证；5）审查实现差异。
适用场景
适用于已有产品定义、设计系统与可渲染界面的项目，用于系统化精修界面。
限制
用户无法完成任务时属于可用性问题，应先用 friction 处理；从截屏/URL 重建已有设计不适用；项目尚无产品定义时，应先使用 hotseat/distill。不得仅凭截屏、自动扫描或对比度就声称符合 WCAG。不得在截屏或报告中使用真实客户数据。涉及法律、定价、安全、本地化或转化含义的文案修改需先询问。设计文件、截屏与运行中的应用是不同证据，需说明检查的是哪一种及其不能证明什么。若无运行界面，只能做静态检查，所有视觉或行为结果须标注为未验证，不得把代码阅读伪装成渲染审查。