过去半年，我参与了不少新媒体技术选型的讨论。一个反复被问及的问题是：既然 AI 已经能写 Remotion 代码了，是不是意味着 MG 动画的工业化生产可以全面转向“提示词工程”？品牌方只需输入文案，几分钟后就能拿到一支参数化生成的产品宣传片？

在最近一档播客中，我依然认为 Remotion 的理想过于丰满，没有考虑到 MG 动画非标且多样的创作路径。而现在，如果你实际跑通过这些 AI 生成的 Remotion 项目，会发现一个尴尬的事实：对专业动画师或者交互设计师来说，它们几乎都在及格线以下徘徊，产出一个类似中等水平 PPT 的设计。不仅不够精美，且仍然不具备 MG 动画最基本的叙事骨架和时间逻辑。很多人把这种失败归结为“AI 还还不懂动画导演”，认为这只是暂时的——大模型再迭代几个版本，自然会学会缓动曲线和动画十二原则。

这种判断低估了问题的复杂性。困境不在AI的理解层，而在于 Remotion 这套方法论本身，与 MG 动画的生产逻辑之间存在难以调和的错配。

一、Remotion是什么被误解的“代码转视频”

先做一点概念厘清。Remotion 是一个由 Jonny Burger 创建的 React 框架，核心机制简单说就是：你用 React 组件写动画逻辑，它通过无头浏览器逐帧截图，最终合成 MP4。这意味着，它本质上是网页动画的离线渲染器，而不是一套独立的动画引擎。

理解这一点至关重要。Remotion 的一切能力边界，都被划定在浏览器渲染管线的范畴之内。你能驱动的，是 CSS 的transform和opacity，是 Canvas 2D 的绘图上下文，是通过 WebGL 运行的着色器。它没有自己的合成器、没有粒子解算器、没有物理模拟引擎，只能做有限的图层的混合模式与特效堆栈。它所做的，只是忠实地将 Web 动画转存为视频文件。

这就引出了第一个方法论困境：当 AI 试图用 Remotion 生成 MG 动画时，它选择的这条技术路线，从一开始就和MG动画的主流生产范式不在同一条轨道上。

二、方法论的错配MG动画不是“图形在动”

要理解这种错配，我们需要先看清 MG 动画的真实生产图谱。

AE 当然是绕不开的名字，但远非全部。Apple Motion 用节点式合成搭配行为驱动，让动画师可以用“重力行为+碰撞边缘”这样的逻辑而非关键帧来创作；Cavalry 把程序化生成做到极致，一个复杂的数据可视化模板可以在不手动K帧的情况下适配数百个数据点；Fusion 和 Nuke 把合成逻辑推向电影级，三维空间、深度通道、粒子解算是常态；更不用提 TouchDesigner 这类实时创作工具，它根本上就没有“时间轴”的概念，一切都在节点流的实时计算中生成和消亡。

这些工具的共性是什么？它们都提供了一套基于时间的、可预测的视觉合成模型。动画师在其中操作的核心，是时间轴上的事件编排：什么时刻出现什么元素，这个元素以怎样的节奏运动，它和前后元素的动态关系是什么，整个序列的情绪曲线如何起伏：

而 Remotion 的方法论完全不同。它提供给AI的，是一套基于代码状态的声明式渲染模型。你定义的是每一帧中各个属性的值，而不是一段运动。用 React 的范式来描述，就是“当时间t到达某个值时，opacity 从 0 变为 1”——这本质上是在定义离散的采样点，而非连续的运动意图。

三、被丢失的“时间轴”声明式代码的结构性局限

这正是 Remotion AI 动画困局的根源。

在 AE 或 Cavalry 中，动画师面对的是一个连续的时间轴。他可以直接拖拽图层的时间范围，直观地感受两个关键帧之间 0.3 秒和 0.4 秒带来的节奏差异。时间，是画布本身的维度，是创作的第一性元素。 

而在 Remotion 的代码世界里，时间被抽象成了 useCurrentFrame() 返回的一个数字。AI 要编排动画，就必须在代码中计算每一个元素在每一帧的位置和状态。这带来了三个致命的结构性问题：

其一，时间关系被强行转码为数学关系。 一个“元素 A 出现 0.3 秒后，元素 B 开始从下方弹入”的简单调度，在 AE 中是拖拽图层块的长度和起始位置，一眼可知。在Remotion中，AI 必须将它翻译成 frame > startFrame + 18 ? spring(...) : 0这样的条件逻辑。当动画序列复杂到包含数十个元素的交错出场时，这些时间判断会像藤蔓一样缠绕在整个组件树的各处，牵一发而动全身，极难被正确生成和调试。

其二，运动的本质被离散化了。 在合成软件中，一个“弹性弹跳”的运动是一个连续函数被应用在时间区间上。动画师不需要知道它在第几帧位移了多少像素——他只需要设置缓动类型和参数，并结合自己的设计风格做感性研判。而在 Remotion 代码中， AI 不得不在每一帧去调用 spring() 函数并传入当前帧号来计算值。这个根本差异意味着， AI 在 Remotion 中做不到“设计一段运动”，它只能做到“为一千帧分别计算出一个位置”。

其三，AI 对生成结果的反馈链路被截断了。 一个动画师在 AE 中调整一段动画，预览是即时的。他可以看到效果、感受节奏、做出调整。而 AI 生成 Remotion 代码后，想要“看”到自己做出来的效果，必须先渲染整个视频。这个渲染-反馈循环实在太慢了，导致AI无法像人类动画师那样，通过大量快速的迭代来逼近理想的运动质感。这恰恰解释了为什么 AI 生成的 Remotion 动画总是充斥着“差不多能跑就行”的妥协感——它根本没有机会去精修。

四、不可能三角灵活、可控、可生成

如果我们把视角拉得更高，会发现Remotion AI动画面临的是一个结构性的不可能三角。

一个动画生产系统，很难同时做到：高度的生成灵活性（能处理任意的、开放的动画需求）、精确的时间轴控制力（能产出符合专业叙事节奏的动画）、以及对大语言模型的代码生成友好性（模型的输出能稳定地落在高品质动画的区间内）。

Remotion 选择了第一条和第三条——它是代码，所以灵活；代码能由大模型生成，所以对模型友好。但它代价就是放弃了对时间轴的精确控制。因为如前所述，声明式代码缺乏将“动画意图”和“帧计算过程”解耦的中间层。

AE 这样的合成软件则拥有极高的可控性，但它对 AI 生成是极不友好的——让大模型直接输出一个.aep 工程文件，其中包含无数二进制的关键帧数据和效果参数，在可预见的未来都不现实。

Lottie（由 AE 的 Bodymovin 插件导出的 Web 动画格式）曾试图站上这个三角的中心。它有 JSON 的开放结构，对代码生成相对友好；它保留了AE时间轴的关键帧和缓动数据，有一定可控性；它可以被程序化操作，有一定灵活性。但 Lottie 的能力边界极其有限——它不支持AE的绝大部分合成特效，一旦动画复杂度超过矢量形状变换的范畴，它就无能为力了。

这套不可能三角是技术结构的内生局限，不是给 AI 喂更多数据就能突破的。它决定了：只要你选 Remotion 这条技术路线，你就必须接受它在时间轴控制力上的天生短板。

五、困境的终点Remotion AI 动画到底能做什么？

经过这一系列的分析，我们或许可以更清醒地定义 Remotion AI 动画的合理疆域。

它是一个出色的“视频脚手架生成器”。对于结构高度模板化的视频内容——比如数据大屏的自动化生成、视频模板的参数化批量渲染、或是一些简单而重复的信息动画——Remotion AI 能发挥极大的效率优势。因为在这些场景下，时间节奏是固定的，内容的复杂度是可控的，AI只需要在既有的框架内填入变量。

但它不是一个合格的“MG 动画导演”。任何需要叙事节奏设计、需要元素间精密的动态呼应、需要借助合成特效来呈现视觉张力的动画创作，Remotion AI 目前的表现会是系统性的失效。这不是因为GPT-5还没学会贝塞尔曲线，而是因为用声明式代码去描述一段连续的、有情绪的运动，这条路从根本上就比基于时间轴的直接操作要迂回得多。

AI 终有一天会学会动画的审美。但到那时，它更可能选择的目标，是直接去操作一套真正为动画而生的合成引擎，而不是继续在网页动画的语法糖里挣扎。

Remotion AI 的困境，从本质上说，是试图用网页开发的方法论，去解决视频动画生产的问题——这中间的范式鸿沟，远非模型能力的提升可以填平。