UI 设计与动效工程包

要解决的问题

动画是 UI 开发里最容易「凭手感」的部分：给哪个元素加动效、用什么原料实现、曲线和时长取多少，往往全看个人经验。结果是代码库里反复出现同样的错误——给键盘触发的高频操作加动画、进入动画用 ease-in、用 scale(0) 起手、toast 用 keyframes 写。更麻烦的是，团队没有统一的审查标准，动效代码写完了没人知道它是否达标。

这个技能包针对的就是这些反复出现的决策点。它源自 Emil Kowalski 的设计工程实践（Vercel、Linear 背景），把判断标准固化成了可执行的流程。

核心能力与工作流程

技能包包含 10 个子技能，入口文件按用户意图路由：

• 构建动效：animate 负责写实现，采用严格的七步序列——先过频率门禁（每天 100+ 次的动作永不动画，键盘发起的动作一票否决），再用一个词命名目的（命名不出就不做），然后依次选工具（CSS transition / WAAPI / Motion）、选属性（只用 transform 和 opacity）、定缓动与时长、处理中断与退出、最后随动画一起交付 prefers-reduced-motion 与 @media (hover: hover) 门控。
• 反向术语表：animation-vocabulary 把「那个弹一下的」这类模糊描述映射到准确术语，只命名不设计。
• 设计原理：apple-design 提炼 WWDC 的流体界面原则，核心是弹簧天然可中断、动画必须从当前屏幕值开始。
• 咨询与审查：find-animation-opportunities 扫界面找动效机会（只读，预期拒绝多数候选）；improve-animations 审计全库并产出自包含的改进计划；review-animations 用 Never Ship 清单严格审查 diff。
• 组件实践：ask-sonner 提供 React toast 库的接入、样式与故障排除指南。

适用边界

• pick-ui-library、prototype、review-animations 三个子技能默认不自动触发，需显式调用。
• 顾问型技能（找机会、审计、审查）只读源码、不直接修改，产出的是计划而非代码变更。
• 技能包内置的是规则与速查表，不提供视觉资产或组件库；RECIPES.md 中的配方需要按你的技术栈适配。
• 参数建议（时长、曲线、stagger）是经过实践的默认值，最终仍需慢放与真机手势验证——技能不会替你感受「手感对不对」。