企业官网建设流程全解析

1. 从"一句话生成动画"说起：这个赛道到底在解决什么问题

第一次接触"文本驱动动画"这个概念，是在一个做短视频批量生产的朋友那里。他当时的需求特别朴素：每天要出几十条产品展示动画，每条动画的结构几乎一样——产品图淡入、卖点文字逐条弹出、结尾Logo收束。人工在AE里做一条要二十分钟，一天下来人直接废掉。他问我：能不能用大模型把"给我做一个15秒的产品展示动画，蓝色科技风，三个卖点依次出现"这句话直接变成可播放的动画文件？

这个问题背后，其实藏着一条完整的产业链条。文本LLM负责理解意图、拆解任务、生成结构化的动画描述；中间件负责把这份描述翻译成具体动画引擎能吃的格式；动画引擎负责渲染输出。三者缺一不可，而目前市场上真正把这条链路跑通的方案并不多。大部分产品要么停留在"LLM生成一段代码让你自己跑"的阶段，要么就是封闭的SaaS工具，你没法控制中间过程。

我花了大概两个月时间，把市面上能试的方案基本都摸了一遍，从开源的Lottie生成工具到商业化的动画中间件，踩了不少坑。这篇文章就把我对这个赛道的理解、技术选型的逻辑、以及实际落地时会遇到的那些"文档里不会写"的问题，完整地梳理一遍。不管你是想自己搭一套工具链的开发者，还是想评估这个方向值不值得投入的产品经理，应该都能从中找到有用的东西。

先明确一下讨论范围。这里说的"文本LLM驱动动画创作"，指的是用户用自然语言描述动画需求，系统自动生成可播放、可编辑的动画内容。它和"AI生成视频"是两回事——后者生成的是像素级的视频帧，前者生成的是结构化的动画描述（关键帧、缓动曲线、图层关系），本质上更接近"用自然语言写代码"。这个区别很关键，因为它决定了整个技术栈的选型方向。

2. Animation-IR：为什么中间表示层是整个赛道的胜负手

2.1 没有中间层会怎样：两种失败路径

在聊Animation-IR之前，先说说没有它会怎样。我见过两种典型的失败方案。

第一种是"LLM直接生成引擎代码"。比如让模型直接输出一段Lottie的JSON，或者一段CSS动画代码。这种做法在简单场景下能跑通，但一旦动画复杂度上来，模型生成的JSON结构就会开始出错——图层引用错乱、关键帧时间轴对不齐、缓动函数参数越界。更麻烦的是，你没法对生成结果做校验，因为JSON本身就是最终产物，错了只能重新生成。

第二种是"LLM直接控制渲染管线"。让模型输出一系列绘图指令，逐帧渲染。这种做法灵活性最高，但计算成本极高，而且模型对空间关系的理解很容易出偏差，生成出来的动画经常"看起来对但就是别扭"。

两种路径的共同问题是：LLM的输出和动画引擎的输入之间，缺少一个稳定的、可校验的、语义清晰的中间层。

2.2 Animation-IR应该长什么样

Animation-IR（Animation Intermediate Representation）的核心思路，是把动画拆解成一组语义明确的结构化描述，而不是直接生成最终格式。它需要包含几个关键维度：

• 时间轴结构：每个动画元素的起止时间、持续时间、延迟，以及元素之间的时序关系（并行、串行、依赖触发）
• 空间属性：位置、尺寸、旋转、缩放、锚点，以及这些属性随时间变化的曲线
• 视觉属性：颜色、透明度、描边、填充、阴影等
• 层级关系：父子图层、遮罩、混合模式
• 缓动描述：用语义化的方式描述运动曲线，比如"先快后慢""弹性回弹""匀速"

我实测下来，一个设计良好的Animation-IR应该满足三个条件：第一，它的表达能力要覆盖目标引擎90%以上的常用特性；第二，它的结构要足够简单，让LLM能稳定生成；第三，它要能被程序化校验，在进入渲染引擎之前就发现错误。

提示：Animation-IR的设计不要追求"大而全"。我见过一个团队试图把After Effects的所有特性都抽象进去，结果IR的schema复杂到LLM根本生成不对。正确的做法是先覆盖高频场景，低频特性用扩展字段预留。

2.3 Lottie作为目标格式的取舍

为什么大家普遍选择Lottie作为输出格式？因为它是目前跨平台支持最好的矢量动画格式，iOS、Android、Web、Flutter都有成熟的渲染库，而且文件体积小、可编程控制。但Lottie也有它的局限：不支持3D变换、不支持复杂的粒子效果、表达式支持有限。

这就引出一个关键决策：Animation-IR是直接映射到Lottie的JSON结构，还是保持独立、再写一个转换层？

我的建议是保持独立。原因很简单：Lottie的JSON结构是为渲染优化的，不是为生成优化的。它的字段命名、嵌套方式、坐标系定义，对LLM来说都不够友好。如果让LLM直接生成Lottie JSON，出错率会显著高于生成一个专门设计的IR。转换层虽然多写一点代码，但换来的是生成稳定性的巨大提升。

3. LLM在动画生成链路里到底该干哪几件事

3.1 意图理解与任务拆解

很多人以为LLM在这个链路里的角色就是"把自然语言翻译成IR"，其实远不止。一个完整的文本到动画流程，LLM至少要参与三个环节。

第一个环节是意图理解。用户说"做一个炫酷的科技感开场"，这句话里"炫酷"和"科技感"都是模糊的。LLM需要把它拆解成具体的视觉决策：配色偏冷色调、运动节奏偏快、使用几何图形而非有机形状、缓动曲线偏锐利。这一步的输出不是IR，而是一份"设计决策清单"。

第二个环节是任务拆解。一个15秒的动画可能包含十几个元素、几十个关键帧。LLM需要把整体需求拆成可管理的子任务：先确定场景结构，再确定每个场景的元素，再确定每个元素的动画。这种分层的生成方式，比让模型一次性输出完整IR要稳定得多。

第三个环节才是IR生成。而且我建议把IR生成再拆成两步：先生成"动画大纲"（哪些元素、什么顺序、大致时长），再生成"详细IR"（具体的关键帧和属性值）。这种两阶段生成的方式，实测下来错误率能降低一半以上。

3.2 用LLM做校验而不是做生成

这是一个反直觉的经验：LLM在动画生成链路里，做校验比做生成更靠谱。

具体做法是，IR生成之后，让另一个LLM实例（或者同一个模型的不同prompt）来审查这份IR：时间轴有没有重叠冲突、图层引用是否存在、缓动参数是否在合理范围、整体节奏是否符合原始需求。这种"生成-校验"的双模型架构，比单纯依赖一个模型生成要可靠得多。

我试过用同一个模型做生成和校验，效果不如用两个不同模型。因为同一个模型对自己的输出有"偏见"，校验时容易放过自己的错误。用不同模型（比如一个偏创意、一个偏严谨）交叉校验，能发现更多问题。

3.3 什么时候不该用LLM

LLM不是万能的。在动画生成链路里，有几件事不该交给LLM做：

• 精确的数值计算：比如根据画布尺寸计算元素的对齐位置，这种用代码算比让LLM猜要准得多
• 格式转换：IR到Lottie JSON的转换，用确定性代码实现，不要用LLM
• 资源加载：图片、字体、图标的引用和加载，走常规工程逻辑

把LLM用在它擅长的地方——理解模糊意图、做创意决策、生成结构化描述——把确定性任务交给代码，这个边界划清楚了，整个系统的稳定性会好很多。

4. 中间件层的工程实现：从IR到可播放动画

4.1 转换层的核心逻辑

中间件层最核心的工作，是把Animation-IR转换成目标引擎能吃的格式。以Lottie为例，转换过程大致分几步：

第一步是坐标系转换。IR里我建议用左上角为原点的归一化坐标系（0到1），这样和画布尺寸解耦。转换到Lottie时再乘以实际像素尺寸。这个设计的好处是，同一份IR可以适配不同分辨率的输出。

第二步是时间轴映射。IR里的时间用毫秒表示，Lottie的帧率通常是30或60。转换时需要做帧对齐，并且处理关键帧的插值。这里有个坑：Lottie的关键帧时间必须是帧的整数倍，如果IR里的时间不是帧的整数倍，需要做舍入，而舍入会导致动画节奏的微小偏移。我的做法是在IR生成阶段就约束时间值为帧间隔的整数倍。

第三步是缓动曲线转换。IR里用语义化描述缓动（如"ease-in-out"），Lottie需要具体的贝塞尔控制点。这需要一个映射表，把常见缓动语义映射到标准贝塞尔曲线。对于自定义缓动，可以让LLM生成贝塞尔控制点，但要加范围校验。

4.2 资源管理与依赖注入

动画里经常需要引用外部资源：图片、字体、图标。中间件需要处理这些资源的加载和注入。我的做法是在IR里用占位符引用资源，中间件在转换时根据资源配置表替换成实际路径或base64数据。

这里有个实际踩过的坑：Lottie对字体资源的处理比较特殊，需要同时提供字体文件和字符映射表。如果动画里有文字元素，中间件需要额外生成这份映射。我一开始没注意这个，生成的动画在Web端文字显示正常，到了移动端就变成方块了。后来查了半天才发现是字体映射没生成。

4.3 预览与迭代闭环

中间件还有一个容易被忽视的功能：预览。用户拿到生成的动画后，大概率需要调整。如果每次调整都要重新走一遍LLM生成，效率太低。好的做法是，中间件支持"局部重生成"——用户指定要改哪个元素、改成什么样，只重新生成那部分IR，然后合并。

这个功能实现起来不难，但对用户体验的提升是巨大的。我实测下来，有了局部重生成之后，用户从"生成到满意"的平均迭代次数从5次以上降到了2次左右。

5. 市场格局：三类玩家和各自的打法

5.1 通用LLM厂商的降维打击

第一类玩家是通用大模型厂商。他们的优势是模型能力强、生态完善，劣势是不懂动画领域的特殊需求。目前我看到的情况是，他们主要通过API提供"文本生成Lottie JSON"的能力，但生成质量和稳定性都还有很大提升空间。

这类玩家的打法通常是"通用能力+领域微调"。他们会收集大量动画相关的数据做微调，但动画数据的获取成本很高，而且格式不统一。我判断这个方向短期内很难做到生产可用，更适合做demo和轻量场景。

5.2 垂直工具厂商的深耕

第二类玩家是垂直的动画工具厂商。他们懂动画、懂用户需求，但模型能力是短板。这类玩家的典型做法是：自研或微调一个小模型专门做动画IR生成，配合自己积累的模板库和素材库。

这类玩家的优势在于对场景的理解深度。比如他们知道"产品展示动画"和"节日祝福动画"在结构上有什么不同，能针对性地优化生成效果。劣势是模型能力受限，遇到复杂需求时容易力不从心。

5.3 中间件与基础设施玩家

第三类玩家是做中间件和基础设施的。他们不直接面向终端用户，而是提供IR标准、转换工具、渲染引擎适配层。这类玩家的价值在于降低整个行业的重复建设成本。

目前这个方向还比较早期，没有形成事实标准。但我判断未来一定会出现一个类似"动画领域的Markdown"的中间表示标准，让不同工具之间可以互通。谁先把这个标准做出来并被广泛采用，谁就能占据生态位。

6. 实际落地时那些文档不会写的问题

6.1 生成稳定性比生成质量更重要

刚开始做的时候，我特别在意生成出来的动画"好不好看"。后来发现，对于生产环境来说，稳定性比质量重要得多。一个80分但每次都能稳定生成的方案，比一个偶尔能出95分但经常崩掉的方案有价值得多。

提升稳定性的几个实操手段：约束IR的schema，用JSON Schema做严格校验；限制LLM的输出空间，用结构化生成而非自由文本；建立错误恢复机制，生成失败时自动降级到模板方案。

6.2 时间轴对齐是个隐形杀手

前面提过时间轴对齐的问题，这里再展开说一下。动画里多个元素的时序关系非常敏感，差个几十毫秒，观感就完全不一样。而LLM生成的时间值往往不够精确，容易出现"这个元素还没消失那个元素就出现了"的情况。

我的解决方案是在IR里引入"时序约束"的概念。用户或LLM可以声明"元素B在元素A结束后开始"，中间件在转换时自动计算具体时间值，而不是依赖LLM直接给出数值。这样既保证了时序正确，又减轻了LLM的负担。

6.3 缓存与增量生成

生产环境下，同一个动画模板可能会被反复生成。如果每次都走完整的LLM链路，成本和时间都受不了。我的做法是建立"IR缓存"：把生成过的IR按语义哈希存起来，下次遇到相似需求时直接复用或微调。

更进一步的是增量生成。用户修改了动画里的一个元素，只需要重新生成那个元素相关的IR片段，其他部分保持不变。这个功能对交互式编辑场景特别重要。

6.4 多端渲染的一致性

同一个Lottie文件，在Web、iOS、Android上的渲染效果可能有细微差异。这些差异在简单动画里看不出来，但在复杂动画里会累积成明显的问题。我踩过的坑包括：某些缓动曲线在不同平台上的实现不一致、图层混合模式的支持程度不同、字体渲染的基线偏移。

解决这个问题的办法是建立"渲染一致性测试"：准备一组标准动画，在各端渲染后做像素级对比，发现差异就针对性处理。这个测试应该纳入CI流程，每次中间件更新都跑一遍。

7. 我对这个方向的一些判断

做了两个多月的调研和实测，有几个判断可以分享。

第一，Animation-IR这个中间层一定会成为标配。现在各家各做各的，重复造轮子，效率很低。未来一两年内应该会出现一个被广泛接受的IR标准，就像Web领域的HTML/CSS一样。

第二，LLM在这个链路里的角色会逐渐清晰。它擅长的是意图理解和创意决策，不擅长的是精确计算和格式转换。把边界划清楚，整个系统的可靠性会有质的提升。

第三，这个赛道的商业化路径还在探索中。纯工具很难收费，因为开源方案会不断涌现。可能的路径是"工具免费+素材/模板收费"，或者"基础功能免费+企业级服务收费"。

第四，技术门槛没有想象中那么高。核心难点不在模型，而在工程细节——IR设计、转换逻辑、错误处理、多端适配。这些工作琐碎但关键，做好了就是护城河。

最后分享一个我在实操中总结的小技巧：在IR生成阶段，让LLM同时输出一份"设计说明"，解释它为什么这样设计。这份说明不参与渲染，但可以帮助用户理解生成结果，也方便后续调整。实测下来，有了这份说明，用户对生成结果的满意度明显提升，因为他们能看懂"为什么是这样"。

这个方向还在快速演进，我上面说的这些可能过几个月就过时了。但底层的逻辑——把模糊意图转成结构化描述、把结构化描述转成可执行内容——这个范式应该会长期成立。抓住这个范式，具体的技术选型反而没那么重要。