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 classscene># 无头浏览器运行时以 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_asciiFalse)} 只输出 json不要任何解释。 # 调用模型拿到返回后解析 result call_model(prompt) return json.loads(result)这段代码的关键在于**只输出 json不要任何解释**这句话。不加这句模型十有八九会在 json 前后加一段好的这是为您生成的结果。加了之后解析成功率能到 95% 以上。剩下 5% 的情况我会加一层容错用正则把第一个{到最后一个}之间的内容抠出来再解析。4.3 第二步实操时间分配的归一化计算时间分配这块我单独写了个函数因为它是纯数学不该交给模型算def allocate_time(total, weights, intro3, outro3): 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 idstage !-- 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是兼容性参数不加的话某些播放器打不开。拼接多个片段用 concatffmpeg -f concat -safe 0 -i filelist.txt -c copy final.mp4filelist.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 常见问题速查表现象可能原因排查方法解决方式字体不对字体文件未加载渲染纯文字测试页用绝对路径加载字体元素位置偏移虚拟时间轴未生效检查动画是否用 CSS 变量统一用变量控制时序代码报错标签未闭合或类名错误本地浏览器看控制台加校验层打回重生成音画不同步旁白时长与分镜不匹配对比音频和视频时长调整流程顺序先音后画渲染太慢浏览器实例未复用看单帧耗时复用页面实例成片有拖影帧率不足检查运动密集分镜局部提到 60 帧5.5 几个只有踩过才知道的坑第一个坑不要用中文文件名。无头浏览器加载本地文件时中文路径在某些环境下会乱码导致资源加载失败。我一开始用第一幕.html这种命名排查了半天才发现是文件名的问题。后来全改成英文加数字再没出过事。第二个坑截图格式选 png 不选 jpg。jpg 有压缩损失连续帧之间的压缩噪声会导致视频出现闪烁感。png 无损虽然文件大但渲染质量稳定。磁盘空间不够的话渲染完及时清理帧序列。第三个坑模型生成的文字内容要过一遍敏感词和错别字检查。模型偶尔会生成一些奇怪的表述直接上屏很尴尬。我加了一道简单的检查把生成的所有屏幕文字收集起来人工过一眼再渲染。这一步花不了几分钟但能避免很多尴尬。第四个坑分镜之间的过渡不要交给模型。模型生成的过渡效果往往很突兀我后来改成统一用 0.3 秒的淡入淡出所有分镜之间都用这个成片反而更专业。过渡这种东西统一比花哨重要。6. 关于成本和效率的一些实测数据跑通之后我做了几轮压测把数据分享出来方便你估算自己的场景。一个 60 秒、30 帧、1080p 的代码视频从输入需求到成片全流程大概耗时 8 到 12 分钟。其中模型调用占 2 到 3 分钟分步调用有网络延迟渲染占 4 到 6 分钟1800 帧复用浏览器实例合成占 1 分钟左右。如果分镜里有 60 帧的片段渲染时间会相应增加。成本方面模型调用是大头但因为分步用了不同规格的模型整体可控。渲染和合成是纯本地算力没有额外费用。如果你的机器性能一般渲染时间会拉长但不会影响成片质量因为虚拟时间轴保证了确定性。效率优化的关键点有两个一是并行渲染不同分镜之间没有依赖可以开多个浏览器实例同时渲染我试过开 4 个实例渲染时间直接砍到四分之一二是缓存中间产物脚本和代码生成一次就存下来改画面时只重渲染不改脚本省掉模型调用的时间。我个人在实际操作中的体会是这条流水线最大的价值不是快而是可复现。传统视频制作里改一个细节可能要重新剪辑半天而在这条流水线里改一个参数重新跑一遍就行而且每次结果都一样。这种确定性才是它真正区别于抽卡式生成的地方。