Web Motion Ultra
通过创意开发者和动效设计师的技艺，将静态页面转化为鲜活的体验。每一次移动都应引导注意力、传达状态、建立层次或表达品牌。围绕内容编排动效，而非在所有地方应用相同的特效。
上下文与范围
从项目和请求中推断模式、目标、受众、受影响的页面、动效特性、强度和所用技术栈。若此类信息已可用，则不要提出问题清单。简要陈述有用的假设；仅在阻碍进展时才提问。
- 增强（现有站点的默认模式）： 保留文案、区块顺序、视觉标识、功能性和信息架构。仅添加动效所需的包装器、属性和局部修改。不要将请求转变为重新设计。
- 创建： 当请求一个新页面时，将布局与动效共同设计，使用图层、比例对比和层次结构，使其在静止状态下也清晰可辨。
- 如果没有可用的页面、URL或代码，先定义初步概念，然后请求应用概念所需的材料。不要虚构用户的站点，也不要声称做出了从未发生的更改。
- 对于URL，使用可用的读取或浏览器工具。仅凭截图无法验证交互和滚动。
尊重现有的技术栈和依赖关系。对于没有约束的新页面，从 HTML、CSS 和 vanilla JavaScript 开始。简单效果使用 CSS 和 IntersectionObserver；复杂的序列、固定和拖拽擦洗使用 GSAP 搭配 ScrollTrigger；当 React 中已使用或被请求时，使用 Motion/Framer Motion。Lenis 是可选的，必须为项目服务，而非作为前提条件。在添加库之前，先在官方文档中验证 API 和版本。使用现有的包管理器或固定版本的 CDN，永远不要使用 latest。
超高质量标准
将“Ultra”理解为精确的编排、持续的交互，以及经过验证的桌面和移动端质量。它不会自动增加强度、效果数量或依赖关系。
在做出更改前，观察页面并识别具体问题：静态的层次结构、缺失的反馈、不一致的时序、跳跃、沉重的滚动，或与触控不兼容的效果。如果动效已存在，记录基线并改进现有系统。保持分析和文档与局部更改成比例。
对于每次实现，请阅读 references/smooth-responsive-motion.md：它定义了编排、中断、输入模型、性能以及验收标准。查阅效果目录以选择视觉语言；质量也取决于状态之间的过渡。
1. 概念
检查结构、内容、主要操作和现有交互。定义：
- 动效概念：用一句话描述行为，而不仅仅是审美形容词。
- 标志性时刻：页面或旅程中最令人难忘的效果，具有叙事或实用目的。在操作界面中，这可能是一个微妙的微交互。
- 支持性效果：为每个区块定义，解释它们帮助用户理解或完成什么。
- 特性与强度：操作界面和阅读场景采用克制；促销落地页的默认假设为中等；仅在请求一致时使用大胆。强度改变的是幅度、密度和复杂度，而不仅仅是速度。
一次只突出一个视觉主导。对标题、图片、列表和控件采用不同的处理方式，但共享相同的令牌。使用序列、重叠和暂停；大元素可能比小元素花费更长时间。不要延迟 CTA 的可用性，也不要为了模拟质量而强制使用预加载器。
要选择效果，请阅读 references/effect-selection.md。这是一个精选的曲目库，而非需要完成的检查清单。一个站点可以通过响应式交互而显得生动，无需持续的动画。
2. 系统与动效地图
将持续时间、缓动、距离和交错集中到 CSS 令牌和 JavaScript 配置中。可参考以下起始值进行调整：
| 令牌 | 起始值 | 用途 |
|---|---|---|
| micro | 150–250 毫秒 | 控件和链接反馈 |
| standard | 400–700 毫秒 | 展示和局部过渡 |
| hero | 800–1200 毫秒 | 非阻塞主序列 |
| ease-out | cubic-bezier(0.16, 1, 0.3, 1) | 柔和进入 |
| ease-in-out | cubic-bezier(0.65, 0, 0.35, 1) | 状态转换 |
| stagger | 60–120 毫秒 | 相关元素之间的节奏 |
| distance | 16–48 像素 | 有约束的位移，移动端减少 |
当库期望不同格式时，使用等效的缓动函数：不要将 CSS 字符串传递给不接受它的 API。linear 适用于持续循环、与滚动相关的进度和匀速运动。避免普遍使用弹跳和弹性缓动。限制长交错序列以及单个动画的总持续时间。
根据工作规模准备动效地图：
| 区块/元素 | 目的 | 触发条件 | 效果/属性 | 持续时间或滚动范围 | 缓动 | 延迟/交错 | 移动端/触控 | 减少动效 |
|---|
对于交互式效果，还需指定中断、反转、重复输入行为以及最终静止状态。使用相同的视觉意图定义单独的桌面和触控配置文件；仅凭屏幕宽度无法决定输入或设备性能。
对于擦洗（scrubbing），描述滚动范围和任何平滑处理，而不是发明一个固定的时间持续时间。为每个效果提供一个缩减版本或完全静态状态。
3. 实现
当请求代码更改时，在同一任务中从概念推进到实现。各个阶段用于组织工作，不需要中间批准。仅在用户明确请求检查点时，才在阶段之间停止；在询问继续之前，先呈现该阶段的具体结果。如果只请求概念或动效地图，则尊重该范围。
阅读 references/implementation-and-qa.md 以了解初始化、无障碍性、清理和实用检查。应用以下约束：
- 即使没有 JavaScript、缺少依赖项或在初始化错误后，基本内容和操作必须保持可见和可用。仅靠早期的
.js类并不能保证这一点。 - 优先使用
transform和opacity；仔细评估 clip-path、滤镜、渐变和大面积内容。在没有测量的情况下不要承诺 60 fps。避免交替进行布局读取和写入。 - 对于手风琴和其他必要的尺寸变化，选择语义化、可测量的解决方案。不要仅仅为了遵守完全禁止
height的规则而使用scaleY扭曲文本。 - 为媒体内容预留空间，并通过包装或合成保留现有的变换。不要引入布局偏移或意外的水平溢出。
- 保留原生滚动、锚点、历史记录、键盘访问、焦点和缩放。没有滚动劫持；平滑滚动和固定必须保留用户控制。
- 在触控/移动端上减少或禁用视差、倾斜、自定义光标和高代价图形。操作不能依赖悬停。
- 对于
prefers-reduced-motion: reduce，移除大位移、视差、空间擦洗、叙事性固定和非必要的循环。在适当之处使用即时状态或短淡入淡出。同时要尊重会话期间偏好的变化。 - 无故意闪烁。对于与其他内容一起自动移动超过五秒的内容，提供暂停/停止/隐藏功能或使其保持静态。仅靠减少动效的支持不能替代该控制。
- 将文本拆分为单词或行时，保留语义。不要对屏幕阅读器隐藏交互式元素或可聚焦控件的祖先。
对于 vanilla 项目，在需要时使用 motion.css 和 motion.js。在框架中，遵循现有的模块、组件和生命周期约定。公开用于强度、时间、距离、交错和可选功能的集中配置；不要为尚未实现的效果添加开关。
使用声明式属性以简化复用，例如 data-reveal="mask"、data-stagger="80"（毫秒）和 data-parallax="0.15"（因子）。定义所支持属性的单位和含义。当局部 CSS 过渡足够时，不要构建通用引擎。
仅为实际存在的效果分离初始化器，例如 initHero、initReveals 和 initParallax。每个初始化都必须是可丢弃的；在导航或重新挂载后，避免重复的观察器、监听器、计时器和触发器。在 React 中，使用生命周期和清理，而不要直接修改 React 管理的 DOM 来拆分文本。
当你有访问权限时，交付集成到项目文件中的完整代码。不要仅仅粘贴片段并使实现未完成。除非被请求，否则不要发布或部署站点。
4. 验证与交付
当浏览器可用时，验证初始和最终动画状态、移动端、触控/键盘、窗口缩放、减少动效、禁用 JavaScript 以及依赖项失败。运行相关的项目检查。对代表性的交互进行性能分析，识别高开销效果。
在交付之前，应用平滑动效参考中的验收标准。如果某个效果难以达成，首先降低渲染成本、并发性，然后降低幅度或复杂度；减速并不能修复掉帧问题。纠正观察到的实际问题并执行有针对性的重新检查。
报告实际验证了哪些内容，以及哪些内容尚未验证。不要将代码审查与浏览器测试混淆。在得出结论前先纠正观察到的实际问题。
根据请求的规模进行交付，并包括：
- 概念、标志性时刻和简明的动效地图。
- 已实现的更改和文件链接；仅在无法直接编辑文件时提供每个文件的完整代码。
- QA 结果、权衡以及相关的剩余假设。
- 用于使结果更克制或更大胆的具体参数。
不要为每个阶段重复空白的章节或审批问题。