UI 组件总差一口气？38 万人装的 Skill，先改这 7 处

一个按钮点下去慢半拍，一个弹层从屏幕正中间凭空长出来，一段列表动画又拖了 400ms。单看都不算 Bug，合在一起，用户会觉得这个产品有点钝。

这正是 emil-design-eng 想管的事。它来自 emilkowalski/skills，不是又一个“帮我做个好看页面”的提示词包，而是一份把 UI 手感翻译成代码检查项的 Skill。写稿时，skills.sh 记录它已有 382,788 次安装，仓库有 49,172 个 GitHub Star；最近一周单周安装也在 2 万量级。这个热度至少说明：很多人都在补同一课——页面能跑，离“用起来顺”还差一层。

先把预期摆在桌面上：本文没有拿某个真实团队项目做性能或转化实测，下面的图和例子来自该 Skill 的开源规则整理。它不会替你找出错误的信息架构，更不会凭空长出产品判断；它擅长的是在功能已经做完之后，把那些用户说不清、却会默默影响信任感的细节，一条条挑出来。

图：源站仓库截图。Skill 本身是面向设计师与工程师的开源规则集。

如果你使用支持 Agent Skills 的编码工具，安装命令就是：

npx skills add emilkowalski/skills --skill emil-design-eng

真正有用的用法，不是把它扔给 Agent 后说一句“帮我美化”。把一个已完成的组件、它的使用频率和运行环境一起交给它，让它以 Before / After / Why 三列来审。这会强迫输出从“建议加点动效”变成可落到 diff 的修改。

先把“有点廉价”翻成具体问题

这份 Skill 最值钱的地方，是它先规定了评审格式。你会得到的不是一串审美形容词，而是这样的替换关系：

改前	改后	为什么
transition: all 300ms	只过渡 transform 160ms ease-out	不让颜色、尺寸等无关属性被顺手拖进动画
transform: scale(0)	scale(0.95) 配合 opacity: 0	弹层应像从触发点展开，而不是凭空出现
所有下拉都用 ease-in	进入时用 ease-out 或明确的自定义曲线	用户先看到反馈，动作才显得利落
只有 hover	增加轻微 :active 按下态	鼠标和手指都需要即时回应

图：本文根据开源 Skill 规则整理的评审卡；不是实际产品的改造前后截图。

拿按钮举例，scale(0.97) 这种很小的按压反馈，肉眼几乎不会把它当动画，却会让手指知道“系统收到了”。反过来，如果一个按钮要播一段 300ms 的华丽缩放，用户每天点几十次，最后只会觉得它在拦路。

Skill 给出的判断顺序也很实用：先问这个动作一天会被看到几次；再问它是为了说明空间关系、反馈操作，还是只是为了热闹；最后才挑曲线和时长。键盘快捷键、命令面板这类高频动作，答案往往是：别动。模态框、抽屉、toast 这类偶发界面，才值得用 150–250ms 的过渡帮用户看清状态变化。

三处最容易被忽略的“手感债”

第一处在弹层。很多组件默认从中心缩放，实际触发它的是右上角按钮或列表里的一行。视觉上就像你按了门把手，门却从房间中心长出来。对 tooltip、菜单、popover，让 transform-origin 指向触发点；居中的模态框则保持中心。这个区别小到设计稿里常被忽略，却会影响界面是不是讲得通。

第二处在连续操作。toast、折叠面板、筛选条件是会被用户快速重复触发的。这里更适合 CSS transition，而不是每次从零播放的 keyframes：前者能从当前状态转向下一个状态，后者容易让界面被自己的动画绊一下。需要根据手势实时变化的拖拽再交给 JavaScript 或 WAAPI；预先定义的入场和退场，尽量留给 CSS。

第三处在性能。Skill 反复强调，只动画 transform 和 opacity，少去碰 width、height、margin、padding。这些属性会让浏览器重新布局或绘制，页面一忙就容易掉帧。还有一个很实在的提醒：在负载高的页面里，别因为写起来方便就默认用 Framer Motion 的 x、y 简写；完整的 transform: translateX(...) 更容易走硬件加速。它不是“永远不要用库”，而是提醒你把最卡的那一拍放到真正需要的地方。

图：根据源规则整理的七项检查顺序；先判断是否需要动画，再谈视觉效果。

你可以直接带进下一次 Code Review 的提示词

下面这段比“优化一下 UI”具体得多。它要求 Agent 先理解交互频率，再给出能验证的改动；也留出了“不需要改”的空间。

请用 Before / After / Why 三列表评审这个组件的交互与动效。

场景：{组件用途与用户触发频率}
设备：{桌面 / 触摸设备 / 两者}
重点检查：
1. 高动作频率时，是否应该取消或缩短动画；
2. 按钮是否有克制的按下反馈；
3. popover、tooltip 是否从正确触发点出现；
4. 是否误用了 transition: all、scale(0)、ease-in 或高频 keyframes；
5. 动画是否只改 transform / opacity，触摸端 hover 是否被正确限制；
6. prefers-reduced-motion 下保留了哪些必要反馈。

只报告有证据的问题；给出可直接替换的代码，不要为了“更生动”硬加动画。

最后一条尤其重要。减少动态效果不是把所有过渡砍光：颜色和透明度有时仍能帮人理解状态；该收掉的是会造成位移、眩晕或拖慢高频操作的运动。同理，hover 效果要放在 @media (hover: hover) and (pointer: fine) 里，不然触摸屏点一下，状态可能黏着不走。

这类 Skill 适合谁？已经有组件库、页面也过了功能验收，但总觉得成品比设计稿少点东西的前端和产品工程师。它不适合谁？需求还没想清、信息层级混乱、键盘可达性和语义标签都没补齐的项目。后者先把基本功补好，别用一层动效当遮羞布。

界面好不好，不只看第一眼的截图。更常见的分水岭，是用户第十次打开菜单、第十五次拖动抽屉时，系统有没有继续安静、准确地回应。你现在项目里，最想先抓哪一个组件来做这张“手感体检表”？

小岛AI｜记录一线实战、踩坑与成长