用 AI 写前端页面时，我们很容易提出这样的需求：
给按钮加点反馈，让卡片展开得自然一点，整体有高级感。
这句话表达了预期，却留下了很多实现细节：什么时候触发？哪个元素变化？变化持续多久？操作被打断怎么办？
与其反复让 AI“再优化一下”，不如先把动效描述拆清楚。下面以按钮、卡片和抽屉为例，整理一套比较容易复用的方法。
一、描述动效，先回答五个问题
| 要点 | 需要说清的内容 |
|---|---|
| 触发条件 | 点击、按下、悬停、拖动，还是滚动进入视口 |
| 变化对象 | 按钮本身、封面、详情层，还是整个容器 |
| 变化属性 | 位移、缩放、透明度、颜色、阴影 |
| 运动过程 | 时长、缓动、先后顺序，以及能否被打断 |
| 结束状态 | 完成后如何操作，怎样退出，焦点回到哪里 |
例如，“卡片自然展开”可以进一步描述为：
点击卡片后，展示居中的详情层。展开过程中保持封面与标题的视觉连续，关闭后回到原卡片，并恢复键盘焦点。
描述到这一步，AI 才有相对明确的实现目标。
二、按钮反馈：把不同状态分开描述
按钮的反馈不只有悬停，还包括按下、加载、成功、失败与键盘聚焦。
如果只要求“加一个弹性动画”，可能会得到一个看起来很活泼、实际却容易重复提交的按钮。
可以这样写需求：
为现有主要操作按钮添加交互反馈： 1. 按下时缩小到 0.97，松开后恢复原尺寸。 2. 恢复过渡先采用约 180ms，避免明显的大幅回弹。 3. 悬停时增加轻微阴影；键盘聚焦时显示清晰轮廓。 4. 请求进行中显示加载状态，并阻止重复提交。 5. 成功与失败状态使用文字或图标明确表达，不仅依赖颜色。 6. 用户启用减少动态效果时，取消缩放动画。 7. 保留已有点击事件和业务逻辑。 先说明需要修改的状态与样式，再给出实现。这里的0.97和180ms是便于开始调试的示例值，需要根据按钮尺寸、页面风格和实际手感调整。
验收时，可以重点检查：
- 快速连续点击是否产生重复请求。
- 加载状态是否会改变按钮宽度，导致布局跳动。
- 使用键盘能否清楚识别当前焦点。
- 请求失败后，按钮是否恢复可操作状态。
三、卡片展开：视觉连续，也要有清楚的返回路径
卡片展开的难点，往往在于两个状态之间的关系。
用户点击一张卡片，希望知道：当前详情来自哪里，关闭后又会回到哪里。如果只是突然出现一个大面板，这种对应关系就比较弱。
可以这样描述：
为列表卡片添加详情展开交互： 1. 点击后，在居中的详情层展示完整内容。 2. 展开过程中保持封面、标题与原卡片的视觉对应。 3. 过渡时长先采用约 300ms，避免文字被明显拉伸。 4. 支持关闭按钮和 Escape 键退出。 5. 打开后将焦点移入详情层，关闭后返回触发卡片。 6. 明确处理背景滚动，关闭时恢复原来的滚动状态。 7. 小屏下保证内容可滚动，关闭按钮始终容易找到。 8. 减少动态效果时，使用简单的显示与隐藏。 9. 连续点击和快速关闭时，不出现残留遮罩或状态错乱。 请结合现有项目结构选择实现方式，并说明取舍。“保持视觉连续”也不一定意味着必须让所有元素都参与变形。对于较复杂的内容，封面与容器负责过渡、正文在合适时机出现，通常更容易控制阅读体验。
验收时，除了观察一次完整播放，还应尝试在动画进行中关闭，以及连续打开不同卡片。
四、侧边抽屉：不要漏掉动画之外的行为
抽屉很容易实现一个“从右侧滑入”的效果，但完整交互还涉及背景、焦点、滚动与关闭方式。
可以这样写：
为筛选面板实现右侧抽屉： 1. 点击筛选按钮后，从右侧进入，同时显示背景遮罩。 2. 桌面端宽度先采用约 360px，小屏按视口宽度调整。 3. 进入与退出过渡先采用约 240ms。 4. 支持关闭按钮、点击遮罩和 Escape 键关闭。 5. 打开时限制背景滚动，关闭后恢复。 6. 抽屉内部内容较长时，可以独立滚动。 7. 打开后管理键盘焦点，关闭后回到筛选按钮。 8. 快速反复点击时，界面状态与实际显示保持一致。 9. 不改变现有筛选条件的保存和提交逻辑。 10. 减少动态效果时，简化滑动过渡。还需要根据业务补充一个关键决定：修改筛选项后立即生效，还是点击“应用”后生效？
这会影响关闭行为。例如，用户点遮罩退出时，刚才修改的条件应该保留还是放弃？这类规则最好由产品需求明确，而不是让动画实现顺带决定。
五、给 AI 一个明确的验收范围
生成代码后，只看动画“能不能动”通常不够。可以继续让 AI 按场景检查：
请检查刚才实现的交互： - 鼠标、触屏和键盘操作是否都能完成主要流程。 - 快速连续触发时，是否出现状态不同步。 - 打开过程中退出，是否留下遮罩或滚动锁定。 - 小屏、长标题和长内容是否出现溢出。 - 减少动态效果偏好是否得到处理。 - 动效是否影响已有业务事件。 说明已经验证的内容，以及仍需要人工确认的部分。 不要将尚未执行的检查写成测试通过。这一步可以帮助区分“代码已经生成”和“交互已经验收”。AI 给出的检查结论，也需要结合实际运行结果判断。
六、先看示例，再写需求
如果一开始很难描述，可以先找一个能操作的示例，观察它的触发、运动和结束状态，再把观察结果写成需求。
我最近也把一些交互主题整理成了一个小实验站：Motion Lab。可以在浏览器里试玩演示、查看拆解和提示词，作为描述需求时的参考。
站内演示是独立学习示意，用于理解主题和交互原理；资料摘要按标注依据整理，不代表对未核对原作的完整复现。
对自己的项目来说，更值得积累的是一套明确的表达习惯：看到一个效果后，能够说清楚它为什么触发、怎样变化，以及用户接下来可以做什么。
