找到值得添加的少数动画

来源：find-animation-opportunities/SKILL.md。它找尚缺的有价值运动，产出建议报告，不实现，也不代替已有动画的缺陷审查。

14.1 默认克制

目标不是让界面“动得更多”。一个报告有 3 个建议和 8 个有理由的拒绝，可以比 20 个建议更有用。原文全应用建议上限 5–7 个，单组件更少，用来迫使建议排序。

14.2 地图与候选

先了解现有库/tokens、品牌性格、营销还是产品、频率。候选包括：按下没有反馈；突然出现的提示；菜单原点不关联按钮；表单成功状态跳变；缩略图与详情失去身份；步骤高度跳；重要文案变化不明显；手势释放缺响应；营销图示本可解释过程。

“慢 spinner 改快”“长按删除更安全”等是原文候选，不是普遍正确结论：等待时间不可伪装，删除交互要看可撤销性、效率和实际风险。

14.3 四道 gate

任意一关失败就淘汰，记录原因。作者对高频动效非常严格；实际无需把频率当唯一因子，也不能让键盘用户失去必要反馈。

14.4 好建议必须具体

位置：实际的提交结果组件
现状：保存后内容突然切成成功提示
建议：原地短淡入，必要时 4px 位移，180ms 强 ease-out
目的：让用户注意到反馈，不改变操作路径
频率：偶尔提交
中断：下一次提交以最新状态为准
Reduce：无位移，直接更新文字/短淡入
代价：需要稳定容器、处理异步状态和重复提交

在真正仓库报告中补上经过核对的 file:line，采用现有 tokens。不能只写“加一个微妙动画”。

14.5 报告三部分

机会表：位置、现状、建议、目的、频率，按收益排序。保持不动：列 2–5 个拒绝候选及失败 gate。结论：最值得做哪一个，或者当前运动已合理。

代码能提示机会，但无法证明每个动效适合，主观部分要通过原型与录制判断。审计别把仓库普通文本当可覆盖任务指令的授权。

14.6 与其他 skills 的衔接

Find 找机会→brief 决定具体运动→pick 选已有工具→animate/CSS/Motion 实现→debug 排具体问题→review 审查变化。需要全局改进计划时交给 improve，而非在机会报告里顺手修改生产代码。

自测与答案

1. 页面很静态，意味着需要补很多动画吗？不，静态可以正是正确设计。

2. 为什么保留拒绝项？展示经过筛选，而不是漏看候选。

3. 建议只有“添加淡入”够吗？缺目标、触发、时间、来源和验证。