Impeccable 动画指南：为 AI 设计工作流编写有目的、克制且可无障碍访问的 motion

Impeccable 动画指南：为 AI 设计工作流编写有目的、克制且可无障碍访问的 motion

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

本篇文章是 Impeccable 设计技能中animate命令对应的完整操作指南。它以 skill/reference/animate.md 为骨架，结合仓库内的 craft-floor.md、delight.md、polish.md 等关联参考文档，以及 foundation/src/css/scan.rs 等检测器源码，讲解如何在 Web 与原生界面中为 motion 找到"工作"、确立动效论点（motion thesis）、选择有意义的材质、校准时序与缓动、按运行时实现，并最终通过无障碍与性能验证。读完你会获得一套可直接执行的动效决策框架与验收清单，并在最后交给impeccable polish完成终审。

animate 命令在 Impeccable 工作流中的位置

Impeccable 是仓库根目录skill/SKILL.src.md定义的一套设计技能，通过impeccable <verb>命令（如craft、shape、critique、polish、animate）驱动。在命令表中，animate的定位是：

Enhance — Add purposeful animations and motion — 参考文档 reference/animate.md

配套的命令元数据位于 skill/scripts/command-metadata.json，其中animate的描述为："Review a feature and enhance it with purposeful animations, micro-interactions, and motion effects that improve usability and delight. Use when the user mentions adding animation, transitions, micro-interactions, motion design, hover effects, or making the UI feel more alive."（使用场景：用户提到添加动画、过渡、微交互、动效设计、悬停效果，或希望界面更有生命力）。

也就是说，animate不是"给页面加动画"的通用指令，而是先审查、后增强：先判定当前界面里哪些地方配得上 motion，再只在这些地方注入有目的的运动。这个基调贯穿整篇参考文档——动效的默认态度是克制，而不是堆砌。

与它相邻的两个命令需要分清边界：delight（reference/delight.md）负责品牌个性与情感时刻，其中"对于需要创作的 motion，加载 animate.md"，即动效是 delight 的实现手段之一；polish（reference/polish.md）是终审流程，animate文档的收尾明确写着"当 motion 赢得了自己的位置，交给{{command_prefix}}impeccable polish做最后一遍检查"。

开场原则：motion 解释关系，而非装饰

参考文档的第一句就划定了边界：

Additional context needed: performance constraints.（需要补充的上下文：性能约束。）

这句话是运行该参考文档时的输入条件：动效决策高度依赖目标设备的性能预算，因此在开始之前要尽可能确认运行环境与性能上限，无法从现有信息推断时再向用户提问。

紧接着是整份文档的题眼：

Use motion to explain state, relationship, and hierarchy, or to create one authored moment the surface has earned. Decoration without purpose is animation debt.

motion 只被允许做两件事：

1. 解释状态、关系与层级——用户需要看懂"发生了什么、它和别的元素什么关系、谁更重要"；
2. 创造一个页面配得上的、经过作者刻意编排的时刻——这是"focal moment（焦点时刻）"的雏形。

反之，"没有目的的装饰"被直接定性为animation debt（动画债）。这个债务观与 craft-floor.md 的 Motion 检查项一脉相承："one authored moment, not scattered effects and not one identical entrance on every section"（一个作者时刻，而不是零散效果、也不是每个区块都套同一个入场动画）。

按访客模式决定 motion 的分量

Impeccable 用四种"访客模式"（Visitor mode）命名一个界面面向的访客成功形态（见 SKILL.src.md）。animate文档按模式给出了 motion 的不同权重：

在 Persuade/Experience 界面上，motion 是"voice（声音）"的一部分，可以做文章；在 Operate/Read 界面上，motion 是"feedback（反馈）"，必须让位给任务速度。而原生平台（iOS/Android）则完全交给平台规范——例如 ios.md 的 Motion 章节要求：系统转场（push 滑动、sheet 升起、dismiss 反向）优先，自定义转场不得对抗导航模型，且必须遵循 iOS 的 Reduce Motion（用 crossfade 代替视差与大幅滑动）；android.md 也要求 Material 化之外，在 iPhone 硬件上仍然兑现 iOS 的系统保证（safe-area、Reduce Motion、edge-swipe back）。Web 端的那套 CSS/JS 工具在原生路径上不适用。

Find the job：先找出 motion 的工作

"找活干"是执行animate的第一步：检查现有的 motion 语言、交互状态、目标设备与性能预算，然后只找那些 motion 能发挥作用的点：

• acknowledge an action（确认一个动作被响应）；
• make a state change or spatial relationship legible（让状态变化或空间关系变得可读）；
• preserve continuity through navigation or layout change（在导航或布局变化中保持连续性）；
• direct attention at a meaningful moment（在重要时刻引导注意力）；
• embody the selected visual world（体现所选视觉世界）。

只有当某个"材料性约束"无法推断时才提问；不要因为页面某个静态区域存在就去动画它。这句"do not animate a static area merely because it exists"是反堆砌的核心指令——先审查、再增强的顺序在这里落地。

Set the motion thesis：先写计划再动手

在实现之前，写下一份简短计划，包含四个要素：

• Focal moment（焦点时刻）：唯一值得作者刻意编排的序列或交互（如果有的话）；
• Continuity（连续性）：需要被解释的状态、布局或导航变化；
• Feedback（反馈）：需要被确认的控件与结果；
• Budget（预算）：哪些效果可能昂贵、它们多久运行一次。

文档特别强调："The focal moment must come from this product and surface concept"——焦点时刻必须来自这个产品与这个界面的概念。一个通用的 fade-and-rise、hover lift、视差层或滚动 reveal不是论点。这呼应了 delight.md 中"Derive the treatment from product mechanism and visual world, not a stock catalog"的要求：素材必须源自产品机制与视觉世界，而不是现成目录。

Choose material by meaning：让属性承载语义

transform与opacity是可靠的基础，但不是全部调色板。参考文档按"过渡要传达什么"来选属性：

两个纪律：

1. 不要为了奇观而叠加技巧——"One strong material idea, carried through the focal sequence and quiet supporting states, is usually enough"（一个强大的材质想法贯穿焦点序列与安静的支持状态通常就足够了）。craft-floor.md 也把 blur、backdrop-filter、clip-path、mask 和 shadow 明确纳入调色板，前提是"保持流畅"。
2. 兄弟元素错峰（sibling stagger）只在列表以列表身份出现时适用——需要给总延迟设上限，并且永远不要把每个滚动区块都重新解释成错峰列表。

这条"不要给每个滚动区块都做 stagger"与 craft-floor.md 的"not one identical entrance on every section"是同一原则的两面：重复的入场动画恰恰是 AI 生成界面最典型的 slop 信号。

Timing and easing：用时长表达距离与后果

参考文档给出的时长对照表需要完整继承：

三条配套规则：

• 出场比入场更快（Exit faster than entrance）；
• 使用自然的减速曲线，例如cubic-bezier(0.16, 1, 0.3, 1)传达自信的到达——这正是 craft-floor.md 提到的"exponential ease-out"曲线的具体形态，也是 Impeccable 的测试夹具 motion.html 中正面示例animation: fade-in-keyframe 0.4s cubic-bezier(0.16, 1, 0.3, 1)使用的曲线；
• 不要习惯性使用 bounce 或 elastic 曲线——负面示例 motion.html 中的animation: bounce-keyframe 1s infinite正是要拦截的弹跳动画。

最后一句值得反复强调："Long feedback feels like latency"——过长的反馈在用户感知中就是卡顿。这也是为什么 Operate/Read 模式要求例行过渡必须快。

Implement to the runtime：按运行时选择实现手段

参考文档把 Web 实现手段按用途分层：

• CSS transitions 与 keyframes：用于声明式的状态与有界的序列；
• Web Animations API 或项目现有的动效库：用于中断（interruption）、编排与动态值；
• View Transitions 或共享元素技术：当跨状态的连续性是核心诉求；
• 滚动驱动动效（scroll-driven motion）：只有当滚动关系本身承载意义时才使用，且必须有稳健的降级方案；
• 不要为一个现有技术栈能干净表达的效果引入依赖。

实现纪律同样明确：

1. 默认状态保持内容可见——即使脚本失败，页面也不能因此被隐藏；
2. 避免随手动画布局驱动属性（width、height、top、left、margin）——改用 FLIP、transform 或 grid 技术。这条与 optimize.md 中"Avoid casual animation of layout-driving properties"以及"avoid animations that cause layout shifts"的规则完全一致；
3. 把 blur、filter、shadow、canvas、shader 工作限定在隔离区域（bounded regions）；
4. 只在已知动画期间使用will-change，不要全局声明；
5. 在目标视口与设备上实测，而不是假设 transform 就一定快——"Measure on target viewports and devices rather than assuming transform means fast"。

Accessibility and control：尊重用户的运动偏好

无障碍部分是 motion 的硬性验收项：

• 尊重自动播放与声音偏好：任何非必要的循环动画在离开屏幕或隐藏时必须停止；
• 每个 Web 动画都需要一条prefers-reduced-motion路径，且必须提供有意的替代方案：
  • 移除或减少空间位移（spatial movement），同时保留承载意义的 opacity、color 与状态过渡；
  • 关键认知是："Reduced motion means fewer and gentler animations, not disabling all motion"——减少动效不等于禁用全部动效，确认动作的反馈必须仍然可读。

这条原则在检测器源码层面有直接对应：crates/foundation/src/css/scan.rs中的strip_reduced_motion_blocks函数会定位@media (prefers-reduced-motion: reduce)块并剥离其内容（源码注释标明它对应 JS 的checks.mjs#stripReducedMotionBlocks），说明 Impeccable 的质量检测机制本身就把 reduced-motion 区块当作一个需要专门解析、单独看待的 CSS 结构。原生路径上同样要求遵循平台行为：iOS 的 Reduce Motion（crossfade 代替视差与大幅滑动，见 ios.md）、Android 的系统 Reduce Motion 设置（见 android.md）。

Verify：七项验收清单

实现完成后，参考文档要求逐项核对：

1. 焦点动效特定于所选的视觉世界与界面（不是换一个产品也能原样套用）；
2. 每个辅助动画都在解释反馈、状态或关系；
3. 中断与重复使用行为正确（动画被再次触发、被打断时应正常）；
4. 桌面、移动与键盘路径仍然可用；
5. prefers-reduced-motion路径减少了位移但没有抹掉有意义的反馈或状态变化；
6. 昂贵效果在目标设备上保持流畅；
7. 移除某个动画会损失意义或作者性格，而不仅仅是损失装饰。

最后一条是"克制"的最终裁决：如果一个动画可以被删掉且什么都不损失，那它从一开始就不该存在。这也与 delight.md 的验证项"去掉装饰后界面仍然快速且不言自明"相互印证。

与质量底线（Craft floor）的呼应

skill/reference/craft-floor.md 在"Verify"部分对 Motion 给出了同一套底线的压缩表达，可以作为动效完成的快速自查：

• Motion: 一个作者时刻，而不是零散效果，也不是每个区块同一个入场；从已可见的默认状态做指数级 ease-out；材质调色板要突破 transform 与 opacity——blur、backdrop-filter、clip-path、mask、shadow 在保持流畅时都属于调色板。

此外，craft-floor.md 的<gemini>段落有一条专门针对动效的反模式："Never animate an image on hover, directly or through its parent——图片不是动作目标，给容器做反馈。"这可以看作对"找活干"的补充：hover 动画的目标应该是可交互的控件，而不是图片本身。

完整流程一瞥

把上面各节串起来，一次animate的执行路径是：

1. 确认性能约束与运行环境（必要时提问）；
2. 按访客模式（Persuade/Experience 还是 Operate/Read，或原生平台路径）确定 motion 的分量；
3. 检查现有动效语言、交互状态与目标设备，找出 motion 真正的工作（Find the job）；
4. 写下 motion thesis：焦点时刻、连续性、反馈、预算；
5. 按语义选择材质：连续性/深度/揭示/能量/反馈，不叠加技巧；
6. 按时长表与缓动曲线校准时序，出场快于入场；
7. 按运行时实现：CSS 优先，WAAPI 处理中断，View Transitions 处理跨状态连续性，避免布局属性动画与不必要的依赖；
8. 落实prefers-reduced-motion替代路径，并保持默认状态内容可见；
9. 逐项跑完七项验收清单；
10. 确认 motion 配得上自己的位置后，交给impeccable polish做最终质量收尾。

如果处理的是原生界面（ios/android/adaptive），步骤 3 之后直接进入对应平台参考文档的 Motion 章节，遵循平台转场与 Reduce Motion 行为，Web 工具链不参与。

结论：animation debt 与"赢得"动画

回到文档开头的题眼：motion 要么解释状态、关系与层级，要么创造一个页面配得上的作者时刻——其余都是动画债。Impeccable 对动效的全部约束（按模式定位、先写论点、材质承载语义、时长表达后果、reduced-motion 有意的替代、移除即损失的验收）都在为同一件事服务：让 AI 生产界面里的每一个动画都"赢得"自己的位置。当你确认动效已经赢得位置，就把它交给 polish.md 定义的最后一遍检查；而在整个过程中，craft-floor.md 的质量底线会兜住"一个作者时刻、指数级 ease-out、材质超越 transform/opacity"这些机械性红线，让你把精力留给方向而非重复踩坑。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable