AE 到可运行代码:大淘宝 AI 动画全链路方案(实践篇)¶
📊 Level ⭐⭐⭐ | 10.9KB
核心概述¶
淘天集团营销&交易技术团队落地的全链路方案:将传统动画交付流程从「AE → Lottie/视频 → 前端手写代码」简化为「AE 插件直出代码」,通过 AE 插件 + 工程代码生成 + Cursor Skill AI 集成,打通从视觉表达到可执行代码的完整链路。单次开发耗时从 2-4 小时压缩至 15-30 分钟,还原度从 70-80% 提升至 95%+。
→ 原文存档
问题:设计与工程的结构性鸿沟¶
传统动画交付的核心矛盾是设计侧视觉表达与工程侧代码实现之间的结构性鸿沟。现有两条路线都走不通:
| 路线 | 缺陷 |
|---|---|
| 纯手写 DOM 动画 | 还原度差、2-4h/个、动画与业务耦合 |
| Lottie 播放 | 体积大(复杂动画破百 KB)、交互受限(静态播放) |
问题不在实现方式,而在交付形式本身——需要让设计师交付可运行代码而非动画文件。
方案:三段式全链路¶
设计师侧(AE 插件)¶
- AE 动画制作 + 规范检查(遮罩图层一致性、图层遮挡检查)
- 一键转码:AE 工程 → 代码生成 → byte 预览 → 动画代码链接
- 实时预览闭环:在 AE 中直接看到代码渲染效果,问题前置发现
开发侧(Cursor Skill)¶
- 打开动画链接,可视化筛选导出(多段拆分、剔除干扰元素)
- CSS / Anime.js 双格式代码输出
- Cursor Animation Integration Skill 智能集成
AI 集成策略¶
- DOM 优先:以现有业务 DOM 为基础,映射动画节点(业务 DOM 已存在时)
- 动画优先:以动画代码为基础,扩展业务逻辑(设计稿与业务 UI 差异大时)
AI 的核心价值在于集成环节——需同时理解动画结构和业务 DOM 现状,判断节点映射关系,决定合并策略。这个过程无法规则化,是整条链路中最适合交给大模型的部分。建议使用 opus 4.6 模型。
效率数据¶
| 指标 | 传统 | 新方案 |
|---|---|---|
| 单次开发耗时 | 2-4 小时 | 15-30 分钟 |
| 还原度 | 70-80% | 95%+ |
已验证场景:淘宝秒杀砸金蛋、一元购动画等。
缺口与演进:Clip 分层产物¶
当前缺口:多模块串联动画(如红包飞入→抖动→用户点击→砍价→价格变化),串联关系只存在于设计稿和开发认知里。
Clip 分层方案:将"完整组件"改为同时产出"完整组件 + clips/",每个 clip 只负责"动"不感知业务,串联编排逻辑收敛在胶水层。AI 辅助长段动画智能分段 + 自动生成 Cursor Prompt。
深度分析¶
三段式链路的信息流:每一段产出什么,信息又在哪里丢失¶
链路被切成三段:设计师侧(AE 插件)→ 中间表示与 Clip 拆分 → 开发侧代码生成与集成。第一段的产出不是文件而是结构化数据:AE 工程经规范检查后一键转码,落成「代码生成 → byte 预览 → 动画代码链接」三件套——这是唯一还握有完整信息的时刻,缓动曲线、路径坐标、图层父子关系都还在手边。第二段做减法:筛选导出、多段拆分、剔除干扰元素。第三段是代码生成与集成:CSS / Anime.js 双格式输出,再由 Cursor Skill 解析动画节点 → 找业务 DOM 对应关系 → 判断集成策略 → 识别边界问题。信息丢失最严重处恰恰在第三段:动画节点与业务 DOM 的映射关系不存在于任何交付物中,只存在于开发者认知里,必须由模型在集成时重新推断。前两段是压缩,第三段是重建,而重建所需的上下文从未写进产物——这就是串联动画至今没有闭环的根因。
真正的产品是中间表示,代码只是它的一个投影¶
把交付形式从「动画文件」改成「可运行代码」,实质是把交付物抬升为程序可读写的结构化表示。反面证据很清楚:视频 / GIF 不可解析,时间轴、缓动曲线、路径坐标都无法精确提取;Lottie 虽可播放,但本质是静态播放格式,交互受限、复杂动画体积破百 KB。两者都是「终态渲染物」,不给下游留加工接口,前端只能人肉反推;而中间表示有接口:同一份数据可投影成 CSS、Anime.js,也可投影成模型的输入上下文。这条链路沉淀的可复用资产不是生成出的那份代码,而是那层能双向读写的中间表示——代码只是它的第一个下游消费者。
效率数字的适用域:单模块已验证场景,而非串联场景¶
2-4 小时 → 15-30 分钟、70-80% → 95%+ 这两组数字有明确适用范围:已验证场景是淘宝秒杀砸金蛋、一元购这类单模块营销动效,特征是元素可控、边界清晰、耦合点少。多模块按顺序协同播放的场景(红包飞入 → 抖动 → 用户点击 → 砍价动画 → 接口返回 → 价格变化)尚未覆盖,因为「串联关系只存在于设计稿和开发认知里,代码里感受不到」。所以 95%+ 应读作分布内还原度,而非对任意动画的承诺。判据也直接:一个动画如果它的「顺序」需要靠口头交代,它就不在当前已验证范围内。
Clip 分层:把业务语义从动画单元里剥离出去¶
Clip 方案要求导出目录从单一入口变成「完整组件 + clips/」:index.tsx 之外并列 clips/clip.1-red-packet.ts(0ms-800ms)、clip.2-shake.ts、clip.3-price.ts,每个 clip 只负责「动」、不感知业务,串联编排逻辑收敛在胶水层。它的价值不止于目录整理,而在于改变了 AI 生成任务的形状:一个「带业务语义的长段动画」既大又难判定——正确性依赖对业务流程的理解,而业务流程并未写进动画产物;切成 clip 之后单元变小、语义变空,判定标准退化为「这个时间区间内这个节点是否按预期变化」,于是可以独立生成、独立验证。
Harness 视角:契约、产物与验证闭环才是地基¶
把这条链路当成「AI 写动画代码」会低估它。它真正交付的是三样东西:契约(导出目录结构、clip 的时间区间与命名、双格式代码形态)、产物(可读写的中间表示、clips、链接化的代码)与验证闭环(AE 内直接看到代码渲染效果、byte 实时预览),模型只是在既定契约下填空。这也解释了为什么集成环节被单独挑出来交给大模型:它要同时理解动画结构与业务 DOM 现状、判断节点映射、决定合并策略,这个过程无法规则化。分工因此异常清晰——能规则化的部分全部固化成产物格式与校验机制,不能规则化的部分才留给模型:模型决定能力上限,契约与验证机制决定生产下限,与 Harness Engineering 的形态一致。同团队早期平台级方案见 淘宝动效解决方案分享,同类链路见 Design to Code。
实践启示¶
- 先修交付形式,再谈效率。 痛点不是「手写慢」,而是交付物不可解析;中间表示出现之前,换更聪明的模型也无从下手。评估 AI 化方案时先问:输入是可解析的数据,还是只能被人看懂的终态渲染物?
- 规范先行,把检查做成插件而不是评审意见。 遮罩图层一致性、图层遮挡检查前置到 AE 侧自动检查,比交付后返工 2-3 次便宜一个数量级;约束越靠上游,下游重建成本越低。
- 尽早闭合实时预览。 让还原度问题在设计师还坐在这张稿子前时暴露,而不是等前端集成完成之后——这正是 byte 预览与 AE 内看代码渲染效果的作用。
- 引用效率数字时必须同时声明适用域。 15-30 分钟 / 95%+ 的样本是秒杀砸金蛋、一元购这类单模块营销动效;凡顺序需要口头交代的串联场景一律另算,别把分布内指标当成分布外承诺。
- 用 clips 换取可验证性。 让每个 clip 只做「动」、不感知业务,编排留给胶水层。这既是架构清理,更是让 AI 分段与生成落在「小而可判定」单元上的前提——可判定,才可自动验证。
- 显式划出「不可规则化」的边界,只把这一段交给模型。 节点映射与合并策略无法规则化,是整条链路中唯一必须由模型承担的部分;其余全部固化为契约、产物格式与校验。这样模型退化时损失的是上限,而不是整条链路。
关联¶
- 淘宝动效解决方案分享 — 同团队早期平台级方案(Lottie → Anime.js、MCP 协议、跨端 Player),本篇是实践落地篇
关联¶
- 相关概念: Harness Engineering