大模型做视频的真相：五步流水线从代码到成片

1. 先厘清一个被标题带偏的认知：模型不产视频，产的是"可渲染的中间态"

很多人第一次看到"用大模型做视频"这个说法，脑子里浮现的画面是：敲一句话，模型吐出一个 mp4 文件。我一开始也这么以为，直到自己动手跑了一遍完整链路才发现，事情根本不是这样。所谓"代码视频"，本质上是用代码去描述画面，再由渲染引擎把代码翻译成像素，大模型在这条链路里扮演的是"写代码的人"，而不是"拍视频的人"。

这个区别非常关键，因为它直接决定了你后面所有的技术选型。如果模型真的能直接生成视频，那你需要的是算力和显存；但既然它生成的是代码，那你需要的是一套从自然语言到可执行动画代码再到成片的流水线。这条流水线我把它拆成五步：需求结构化、场景脚本生成、动画代码生成、渲染执行、后期合成。每一步都有它自己的坑，而且坑和坑之间是会互相放大的。

我写这篇东西的目的很直接：把这条五步流水线完整拆开，告诉你每一步在干什么、为什么这么设计、参数怎么定、哪里最容易翻车。适合两类人看——一类是想把大模型接进内容生产流程的开发者，另一类是好奇"AI 做视频"到底怎么回事、想自己动手试一遍的技术爱好者。不需要你有视频剪辑经验，但需要你能看懂基本的代码逻辑，因为整条链路的核心产物就是代码。

先给一个整体判断：这条流水线里，模型能力大概只占三成，剩下七成是工程问题。很多人把精力全花在"怎么让模型写出更好的代码"上，结果卡在渲染环境、字体缺失、时间轴对不齐这些琐事上。我踩过的坑里，至少一半跟模型无关。所以下面我会把工程细节讲得比模型技巧更细，这才是真正能让你跑通的东西。

2. 五步流水线的整体设计与选型逻辑

2.1 为什么是"五步"而不是"三步"或"一步到位"

先说清楚为什么要把流程切得这么细。理论上你确实可以让模型一步到位：给个主题，直接输出一段完整的动画代码，跑一下就出片。我试过，能跑，但不可控、不可改、不可复用。一旦画面里某个元素位置不对，你没法局部调整，只能整段重生成，而重生成的结果又是随机的，可能把原本对的地方也改坏了。

切成五步的核心目的是把不确定性收敛到可控的边界内。每一步的输入输出都是明确的、可检查的中间产物：第一步产出结构化的需求描述，第二步产出分镜脚本，第三步产出每个分镜对应的代码，第四步产出渲染好的帧序列或片段，第五步产出最终成片。任何一步出问题，你只需要回退到上一步重做，而不是从头再来。

这里有个经验：中间产物一定要落盘成文件，不要全在内存里传。我早期图省事，把脚本和代码都放在一个 Python 字典里流转，结果调试的时候根本没法单独看某一步的输出，排查问题极其痛苦。后来改成每一步都写一个 json 或文本文件，调试效率直接翻倍。

2.2 渲染引擎的选型：为什么我最终选了浏览器内核方案

代码视频的渲染引擎选择，主流就三条路：一是纯 Python 的图形库（比如基于 matplotlib 或 manim 这类数学动画框架），二是浏览器内核方案（用 HTML/CSS/JS 或 Canvas/SVG 描述画面，再用无头浏览器截图或录屏），三是专业合成软件的命令行接口。

我三条路都走过，最后稳定在浏览器内核方案上，理由有三个。第一，大模型对 HTML/CSS/JS 的掌握程度远高于对任何专用动画框架的掌握，你让它写一段 CSS 动画，它几乎不会出错，但你让它写 manim 的特定 API，它经常记错参数名。第二，浏览器内核的渲染结果所见即所得，你在本地浏览器里看到什么样，无头渲染出来就是什么样，调试成本极低。第三，生态成熟，字体、渐变、阴影、变换这些视觉效果开箱即用，不用自己造轮子。

代价也有：无头浏览器的启动有开销，批量渲染时如果不做进程复用，光启动就能吃掉大量时间。这个后面在实操部分会讲怎么优化。

2.3 模型选型的考量：不是越强越好，而是越"听话"越好

标题里提到的那个模型，能力确实强，但在代码视频这个场景里，强不等于合适。我实测下来的体会是：这个场景需要的不是模型的通用推理能力，而是三样东西——对结构化输出的遵循度、对长上下文中前文风格的一致性保持、以及生成代码的可执行率。

结构化输出遵循度决定了第二步和第三步能不能稳定拿到可解析的结果。如果模型老是给你输出一段带解释文字的代码，你还得额外写正则去提取，非常烦。一致性保持决定了多个分镜之间的视觉风格是否统一，否则第一个分镜是扁平风、第二个分镜突然变成拟物风，成片会很割裂。可执行率就更直接了，生成的代码跑不起来，后面全白搭。

我的做法是分步用不同策略：需求结构化和脚本生成用强模型，因为这两步吃理解能力；代码生成用中等模型加严格的模板约束，因为这一步吃的是格式遵循，模板能兜底。这样既保证了质量，又把成本压下来了。

3. 核心细节拆解：每一步到底在做什么

3.1 第一步：需求结构化——把一句人话变成机器能吃的字段

这一步最容易被忽视，但它是整条流水线的地基。用户给的输入往往是一句话，比如"做一个介绍光合作用的短视频"。这句话里缺了太多信息：时长多少、画面比例、风格、有没有旁白、要不要字幕、重点讲哪几个环节。

我的处理方式是用固定的 schema 去逼模型补全。schema 大概长这样：主题、目标时长、画面比例、视觉风格、节奏、核心信息点列表、是否需要旁白文案、是否需要字幕。模型的任务不是创作，而是把模糊输入映射到这个 schema 上，缺的字段按合理默认值填。

这里有个关键技巧：核心信息点列表必须让模型显式列出来，而且限制在 3 到 5 个。为什么？因为视频时长有限，信息点太多会导致每个点都讲不透，画面切换过快，观众根本记不住。我试过让模型自由发挥，它一口气列了 9 个点，结果生成的脚本每个点只有两秒，成片像走马灯。限制数量之后，节奏立刻舒服了。

注意：这一步的默认值不要写死在提示词里，而是放在代码的配置字典里。这样你调整默认风格时不用改提示词，改配置就行，维护成本低很多。

3.2 第二步：场景脚本生成——分镜是视频的骨架

拿到结构化的需求后，第二步是把它展开成分镜脚本。一个分镜脚本至少包含：分镜序号、时间区间、画面描述、屏幕上的文字内容、动画类型（入场、强调、退场）、以及和旁白的对应关系。

这一步的难点在于时间分配。模型天然不擅长算时间，你让它分配 60 秒给 4 个信息点，它可能给你每个 15 秒，看起来很均匀，但实际做视频的人都知道，开场和结尾需要额外时间，中间的重点信息点应该更长。我的做法是给模型一个时间分配的公式：总时长减去开场 3 秒和结尾 3 秒，剩下的按信息点权重分配，权重由模型根据重要性给出，但总和必须归一化到 1。

举个具体的例子。假设总时长 60 秒，开场 3 秒、结尾 3 秒，剩 54 秒。模型给 4 个信息点的权重是 0.4、0.3、0.2、0.1，那么对应时长就是 21.6、16.2、10.8、5.4 秒。这个分配明显比平均分合理，因为重点内容拿到了更多时间。

脚本生成还有一个隐藏要求：每个分镜的画面描述必须足够具体，具体到能直接翻译成代码。如果描述是"展示光合作用的过程"，那第三步的模型就懵了，它不知道该画什么。但如果描述是"画面中央一个绿色叶片图标，左侧射入三条黄色箭头代表阳光，箭头进入叶片后变成蓝色气泡向上飘出"，那代码生成就非常顺畅。所以我在提示词里会强制要求：画面描述必须包含元素、位置、颜色、运动方向四个要素。

3.3 第三步：动画代码生成——模板约束下的自由创作

这是整条流水线里技术含量最高的一步，也是最容易翻车的一步。核心矛盾在于：你既希望模型自由发挥做出好看的动画，又希望它输出的代码严格符合你的渲染框架要求。

我的解法是给一个骨架模板，让模型只填内容不搭结构。模板里已经写好了 HTML 结构、CSS 的通用动画类、时间轴控制逻辑，模型只需要在指定的位置填入元素和对应的动画类名。这样既保证了代码一定能跑，又给了模型在视觉表现上的发挥空间。

模板大概长这样（简化版）：

<div class="scene"># 无头浏览器运行时（以 Node 生态为例） npm install puppeteer # 视频编码（系统级工具） # ffmpeg 需要单独安装，各平台包管理器都有 # Python 侧的音频和流程控制 pip install pydub requests

这里要提醒一句：无头浏览器在服务器上跑，字体是个大坑。默认环境里往往只有最基础的无衬线字体，你代码里写了某个特定字体，渲染出来会 fallback 成默认字体，视觉效果全变。我的做法是把需要的字体文件打包进项目，用@font-face显式加载，不依赖系统字体。这样无论在哪台机器上渲染，结果都一致。

4.2 第一步实操：结构化需求的代码实现

import json SCHEMA = { "topic": "", "duration": 60, "aspect_ratio": "16:9", "style": "扁平插画", "pace": "中等", "key_points": [], # 限制 3-5 个 "need_voiceover": True, "need_subtitle": True } def structure_requirement(user_input): prompt = f""" 把下面的需求映射到给定 schema，缺失字段用合理默认值填充。 核心信息点必须列出 3 到 5 个，每个不超过 15 字。 需求：{user_input} schema：{json.dumps(SCHEMA, ensure_ascii=False)} 只输出 json，不要任何解释。 """ # 调用模型，拿到返回后解析 result = call_model(prompt) return json.loads(result)

这段代码的关键在于**"只输出 json，不要任何解释"**这句话。不加这句，模型十有八九会在 json 前后加一段"好的，这是为您生成的结果"。加了之后，解析成功率能到 95% 以上。剩下 5% 的情况，我会加一层容错：用正则把第一个{到最后一个}之间的内容抠出来再解析。

4.3 第二步实操：时间分配的归一化计算

时间分配这块我单独写了个函数，因为它是纯数学，不该交给模型算：

def allocate_time(total, weights, intro=3, outro=3): body = total - intro - outro s = sum(weights) normalized = [w / s for w in weights] durations = [round(body * n, 1) for n in normalized] # 修正舍入误差，把差值补到最后一个 diff = round(body - sum(durations), 1) durations[-1] = round(durations[-1] + diff, 1) return intro, durations, outro

实测下来，weights让模型给，durations用代码算，这个分工最稳。模型负责判断"哪个信息点更重要"，代码负责"把重要性翻译成秒数"。舍入误差那一步别省，否则总时长会差个零点几秒，拼接的时候音画会错位。

4.4 第三步实操：代码生成的模板与约束

模板文件我单独存成一个.html骨架，里面用占位符标记模型要填的位置：

<!DOCTYPE html> <html> <head> <style> /* 预定义的动画类，模型不能改这里 */ .fade-in { animation: fadeIn var(--duration) ease var(--delay) forwards; } .slide-in-left { animation: slideInLeft var(--duration) ease var(--delay) forwards; } /* ... 其余动画类 ... */ </style> </head> <body> <div id="stage"> <!-- MODEL_FILL_START --> <!-- MODEL_FILL_END --> </div> </body> </html>

模型的任务就是把MODEL_FILL_START和MODEL_FILL_END之间的内容填上。这样即使模型抽风，也不会破坏动画类的定义和整体结构。我试过让模型自由生成整个 HTML，结果它经常把动画类定义改掉或者删掉，导致整个页面崩掉。用占位符约束之后，这类问题基本消失了。

4.5 第四步实操：确定性渲染的核心代码

渲染的核心是控制虚拟时间轴。以 Puppeteer 为例：

async function renderFrame(page, timeInSeconds) { await page.evaluate((t) => { // 把所有动画暂停，并设置到指定时间点 document.getAnimations().forEach(anim => { anim.pause(); anim.currentTime = t * 1000; }); }, timeInSeconds); await page.screenshot({ path: `frame_${timeInSeconds}.png` }); }

document.getAnimations()这个 API 是关键，它能拿到页面上所有正在运行的动画，然后统一控制。anim.currentTime设置成毫秒值，就能让动画跳到任意时刻。这样每一帧都是精确可控的，不受渲染速度影响。

批量渲染时，我会复用同一个页面实例，只切换内容不重启浏览器。重启浏览器的开销大概在 1 到 2 秒，一个 60 秒 30 帧的视频有 1800 帧，如果每帧都重启，光启动就要一小时。复用之后，整个渲染时间能压到几分钟。

4.6 第五步实操：合成命令与参数

帧序列到视频，一条 ffmpeg 命令搞定：

ffmpeg -framerate 30 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p -crf 18 output.mp4

参数解释一下：-framerate 30是输入帧率，-crf 18是质量参数，数值越小质量越高、文件越大，18 是视觉无损的常用值，再低就浪费空间了。-pix_fmt yuv420p是兼容性参数，不加的话某些播放器打不开。

拼接多个片段用 concat：

ffmpeg -f concat -safe 0 -i filelist.txt -c copy final.mp4

filelist.txt里每行写file '片段路径'。-c copy表示不重新编码，直接拼接，速度快且无损。但前提是所有片段的编码参数一致，所以前面渲染时参数要统一。

5. 常见问题与排查技巧实录

5.1 渲染结果和浏览器预览不一致

这是最高频的问题。原因通常有三个：字体缺失、CSS 特性支持差异、以及动画时序问题。

字体缺失最常见，排查方法是在渲染前先截图一张纯文字页面，看看字体对不对。如果不对，检查@font-face的路径是不是绝对路径，相对路径在无头环境里经常找不到。

CSS 特性支持差异主要出现在一些较新的属性上。无头浏览器的版本如果比你的本地浏览器旧，某些属性可能不支持。解决办法是锁定浏览器版本，让本地和无头用同一个版本。

动画时序问题表现为某些元素位置偏移。这通常是虚拟时间轴设置和动画定义不匹配导致的。检查一下动画的delay和duration是不是都用了 CSS 变量，如果有的地方写死了数值，虚拟时间轴就控制不到它。

5.2 生成代码跑不起来

模型生成的代码跑不起来，九成是这几个原因：标签没闭合、CSS 变量名写错、引用了不存在的动画类。

我的排查流程是：先把生成的代码单独存成 html 文件，用本地浏览器打开，看控制台报什么错。控制台会直接告诉你哪一行有问题。如果错误是"未知的动画类"，那就是模型编了一个不在列表里的类名，这时候要么改代码，要么在提示词里再强调一遍"只能使用给定的动画类"。

提示：可以在渲染前加一道校验，用正则扫描生成代码里用到的所有动画类名，和允许列表比对，有不在列表里的直接打回重生成。这道校验能挡掉大部分低级错误。

5.3 音画不同步

音画不同步的根源是旁白实际时长和分镜时长不匹配。前面说过，正确顺序是先生成旁白、测时长、再定分镜。如果你已经反着做了，补救办法是在合成阶段用-itsoffset参数微调音频偏移，但这只是权宜之计，根治还是要调整流程顺序。

还有一种情况是帧率不一致导致的累积误差。比如视频轨是 30 帧，音频轨是 44.1kHz，两者时间基准不同，长视频里会慢慢错开。解决办法是统一时间基准，在合成时显式指定-r 30强制视频帧率，音频用-ar 44100强制采样率。

5.4 常见问题速查表

5.5 几个只有踩过才知道的坑

第一个坑：不要用中文文件名。无头浏览器加载本地文件时，中文路径在某些环境下会乱码，导致资源加载失败。我一开始用"第一幕.html"这种命名，排查了半天才发现是文件名的问题。后来全改成英文加数字，再没出过事。

第二个坑：截图格式选 png 不选 jpg。jpg 有压缩损失，连续帧之间的压缩噪声会导致视频出现闪烁感。png 无损，虽然文件大，但渲染质量稳定。磁盘空间不够的话，渲染完及时清理帧序列。

第三个坑：模型生成的文字内容要过一遍敏感词和错别字检查。模型偶尔会生成一些奇怪的表述，直接上屏很尴尬。我加了一道简单的检查，把生成的所有屏幕文字收集起来，人工过一眼再渲染。这一步花不了几分钟，但能避免很多尴尬。

第四个坑：分镜之间的过渡不要交给模型。模型生成的过渡效果往往很突兀，我后来改成统一用 0.3 秒的淡入淡出，所有分镜之间都用这个，成片反而更专业。过渡这种东西，统一比花哨重要。

6. 关于成本和效率的一些实测数据

跑通之后我做了几轮压测，把数据分享出来，方便你估算自己的场景。

一个 60 秒、30 帧、1080p 的代码视频，从输入需求到成片，全流程大概耗时 8 到 12 分钟。其中模型调用占 2 到 3 分钟（分步调用，有网络延迟），渲染占 4 到 6 分钟（1800 帧，复用浏览器实例），合成占 1 分钟左右。如果分镜里有 60 帧的片段，渲染时间会相应增加。

成本方面，模型调用是大头，但因为分步用了不同规格的模型，整体可控。渲染和合成是纯本地算力，没有额外费用。如果你的机器性能一般，渲染时间会拉长，但不会影响成片质量，因为虚拟时间轴保证了确定性。

效率优化的关键点有两个：一是并行渲染，不同分镜之间没有依赖，可以开多个浏览器实例同时渲染，我试过开 4 个实例，渲染时间直接砍到四分之一；二是缓存中间产物，脚本和代码生成一次就存下来，改画面时只重渲染不改脚本，省掉模型调用的时间。

我个人在实际操作中的体会是，这条流水线最大的价值不是"快"，而是"可复现"。传统视频制作里，改一个细节可能要重新剪辑半天，而在这条流水线里，改一个参数重新跑一遍就行，而且每次结果都一样。这种确定性，才是它真正区别于"抽卡式生成"的地方。