1. 先厘清一个被标题带偏的认知模型不产视频产的是可渲染的代码很多人第一次看到用大模型做视频这个说法脑子里浮现的画面是敲一句话模型吐出一个 mp4 文件。我一开始也这么以为直到真正动手做了一条完整的代码视频流水线才发现完全不是这么回事。模型从头到尾没有生成过任何一帧画面它做的事情只有一件——把一段自然语言描述翻译成一段可被程序执行的绘图代码。真正把画面渲染出来、编码成视频的是后面那套图形库和编码工具。这个认知差非常关键因为它直接决定了你整条流水线的架构。如果你以为模型能直接出视频你会把全部精力押在提示词怎么写才能让它吐视频上然后撞得头破血流一旦你明白模型只是个代码翻译器你就会自然地把整件事拆成五个环节脚本拆解、代码生成、环境渲染、帧序列合成、音画对齐。这五步里模型只负责第二步其余四步全是工程活。我把它叫做代码视频五步流水线。这套流水线的好处是极其可控每一帧都是代码算出来的参数可调、可复现、可版本管理。你想改一个颜色、改一个运动曲线改的是代码里的一行数字而不是重新抽一次卡。对于做数据可视化动画、数学讲解视频、算法演示、产品概念短片这类需求这套方法比传统剪辑软件快得多也比纯 AI 视频生成可控得多。这篇文章适合三类人看一是想用代码批量生产讲解类视频的内容创作者二是需要做算法/数据可视化演示的工程师三是对AI 到底能做什么、不能做什么有好奇心的技术爱好者。下面我把这五步拆开每一步讲清楚为什么这么做、具体怎么落地、以及我踩过的坑。2. 第一步把一句需求拆成分镜脚本而不是直接喂给模型2.1 为什么不能一句话丢给模型新手最容易犯的错是直接把帮我做一个讲快速排序的视频丢给模型。结果它要么给你一段毫无结构的代码要么给你一段根本跑不起来的伪代码。原因很简单视频是有时间维度的而模型默认输出的是无时间维度的静态结果。你不告诉它第几秒画面里有什么、元素怎么动、持续多久它就只能瞎猜。所以第一步必须由人来完成或者至少由人主导把需求拆成一份分镜脚本storyboard。这份脚本不需要多精美但必须包含四个字段时间区间、画面元素、运动/变化描述、旁白或字幕文案。我习惯用一张表格来管理因为它天然带时间轴改起来也直观。时间段画面元素运动/变化旁白/字幕0-3s标题文字 背景网格文字淡入网格缓慢右移什么是快速排序3-8s一排乱序柱子柱子从随机高度归位先看一组待排序的数据8-15s基准柱高亮高亮柱左右扫描其余柱变色选一个基准比它小的放左边15-22s左右分区分区之间出现分隔线递归处理两个子区间22-28s全部有序柱子依次变绿排序完成2.2 分镜脚本的颗粒度怎么把握颗粒度太粗模型生成的代码会缺细节太细你自己写脚本的时间比写代码还长。我的经验是每个分镜片段控制在 3 到 8 秒一个片段里只描述一个核心动作。上面那张表就是比较合适的颗粒度。如果一个片段里同时有柱子移动和颜色渐变和文字出现模型很容易顾此失彼渲染出来就是一团乱。还有一个技巧在脚本里显式标注这一帧的坐标系和画布尺寸。比如统一用 1920x1080、原点在左上角、y 轴向下。这个信息如果你不写模型可能一会儿用数学坐标系y 向上一会儿用屏幕坐标系y 向下最后动画方向全是反的。我吃过这个亏一条物体下落的动画被渲染成了物体上升排查了半天才发现是坐标系约定不一致。2.3 把脚本转成结构化提示再交给模型分镜脚本写好后不要直接整段贴给模型。我习惯把它转成一段结构化的提示包含三部分全局约定 逐帧描述 输出格式要求。全局约定里写清楚画布尺寸、坐标系、帧率、总时长、配色方案逐帧描述就是把表格里的每一行翻译成一句话输出格式要求则明确告诉模型输出一段 Python 代码使用某个绘图库按帧号计算每个元素的位置。这样做的原因是模型对结构化输入的遵循度远高于自然语言长文。你把约定单独拎出来它就不会在每一帧里重复纠结坐标系你把输出格式钉死它就不会一会儿给你伪代码一会儿给你真代码。这一步多花十分钟后面能省两小时。3. 第二步让模型生成逐帧可计算的绘图代码3.1 为什么是逐帧可计算而不是一段动画这是整条流水线里最核心的技术点。模型生成的代码不能是播放一段动画这种高层调用而必须是一个函数输入帧号 t输出这一帧的画面。为什么因为只有这样渲染器才能一帧一帧地调用它把每一帧存成图片最后再合成视频。这种模式叫程序化动画它的本质是画面 f(时间)。用生活化的类比传统动画像翻页书每一页都是人画好的程序化动画像一台机器你给它一个时间刻度它当场算出那一页长什么样。前者的每一帧都是死的后者的每一帧都是算出来的。算出来的好处是你想改帧率不用重画你想改时长不用重画你想改某个元素的运动曲线改一个公式就行。我给模型的核心提示大概长这样# 要求模型输出的代码结构 def render_frame(frame_index, total_frames): # 根据 frame_index 计算当前进度 progress frame_index / total_frames # 根据 progress 计算每个元素的位置、颜色、透明度 # 返回这一帧的绘制指令 ...3.2 用进度归一化统一所有动画节奏模型生成动画代码时最容易乱的地方是时间单位。有的地方用秒有的地方用帧号有的地方用百分比。我的做法是强制统一所有动画都基于一个 0 到 1 的 progress 变量。第 0 帧 progress0最后一帧 progress1中间线性插值。这样无论总时长是 10 秒还是 60 秒动画节奏都不会变。如果某个元素只在中间一段时间出现就用区间映射比如它只在整体的 30% 到 60% 之间活动那就先算出局部进度local (progress - 0.3) / 0.3再 clamp 到 0 到 1。这个技巧我在提示里会明确写出来否则模型经常让元素提前出场或者超时停留。3.3 缓动函数让动画不机械的关键线性插值的动画看起来非常生硬像机器人。真实世界里物体运动是有加速减速的所以需要缓动函数easing function。最常用的是 ease-in-out公式是t*t*(3-2*t)输入 0 到 1输出也是 0 到 1但中间快两头慢。我在提示里会直接把这个公式给模型让它套用。这里有个坑不是所有动画都适合 ease-in-out。比如文字淡入适合但进度条匀速前进就不适合匀速反而更自然。所以我在分镜脚本里会标注每个动作的缓动类型模型照着套就行。如果你不标注模型默认全用线性出来的效果就是全程匀速、毫无生气。3.4 代码生成后的第一道检查能不能跑模型给的代码不要直接进渲染流程先单独跑一遍。我通常只渲染第 0 帧、中间帧、最后一帧这三帧看看画面元素在不在、位置对不对、有没有报错。这一步叫抽帧验证能在几秒内发现 80% 的问题。常见问题包括引用了不存在的变量、坐标系搞反、颜色值超出范围、字体路径写死导致找不到字体。抽帧验证通过后再跑全量渲染。全量渲染是整条流水线里最耗时的环节所以前面能省的检查一定要省在前面。4. 第三步环境渲染——把代码变成一帧帧图片4.1 绘图库怎么选三个维度的权衡模型生成的代码要落地得有个绘图库来执行。常见的几个选择我按自己的使用体验列一下绘图库上手难度渲染速度适合场景主要短板某二维绘图库低快图表、几何动画、文字排版3D 能力弱某三维绘图库中中3D 场景、粒子、光照配置复杂某浏览器渲染方案中慢网页风格、复杂排版依赖浏览器环境某数学动画库中中数学公式、精确几何生态相对小我的建议是讲解类、数据类视频优先用二维绘图库因为它渲染快、依赖少、出图稳定。3D 场景才考虑三维库。浏览器渲染方案虽然排版强但每帧都要启动一次浏览器上下文速度慢得让人抓狂除非你特别需要网页级的排版效果否则不推荐。4.2 渲染参数帧率、分辨率、格式的取舍帧率方面24 帧够用30 帧流畅60 帧只在有快速运动时才必要。代码视频大多是慢节奏的讲解24 帧完全够而且渲染量少 60%。分辨率方面1080p 是甜点4K 渲染时间是 1080p 的四倍左右除非要投大屏否则没必要。输出格式我强烈建议先存成 PNG 序列再合成视频而不是直接写视频文件。原因有三一是 PNG 无损合成时不会二次压缩二是如果中间某帧渲染失败可以单独重渲那一帧不用全部重来三是 PNG 序列方便你随时抽查任意一帧。代价是占磁盘一条 30 秒 1080p 24 帧的视频大概有 720 张图占几个 G记得提前清盘。4.3 并行渲染把等待时间压下来单进程渲染 720 帧如果每帧 0.5 秒就是 6 分钟。听起来还行但一旦你调参数反复重渲时间就上去了。我的做法是按帧号分片多进程并行。比如开 8 个进程每个进程负责 1/8 的帧。因为每一帧的计算是独立的这正是逐帧可计算架构的好处并行几乎线性加速。这里有个细节并行时要注意随机数种子。如果你的动画里有随机元素比如粒子位置每个进程必须用不同的种子否则所有分片的随机图案会一模一样拼起来就穿帮了。我一般用seed base_seed frame_index这种方式保证每帧随机但可复现。提示渲染前先确认磁盘剩余空间。PNG 序列很占地方磁盘写满会导致渲染中途失败而且失败信息往往很隐晦容易误判成代码问题。5. 第四步帧序列合成视频以及音画对齐的坑5.1 合成命令的关键参数帧序列合成视频最稳的工具是命令行编码器。核心命令大概是这样ffmpeg -framerate 24 -i frame_%05d.png -c:v libx264 -pix_fmt yuv420p -crf 18 output.mp4几个参数解释一下-framerate 24是输入帧率必须和渲染时一致否则会变速-pix_fmt yuv420p是像素格式这个一定要加否则很多播放器打不开-crf 18是质量参数数字越小质量越高体积越大18 到 23 是常用区间。frame_%05d.png里的%05d表示帧号补零到 5 位这样文件排序才不会乱否则 frame_10 会排在 frame_2 前面。5.2 音画对齐最容易被忽视的环节代码视频通常要配旁白或背景音乐。音画对齐的难点在于你的分镜脚本是按秒写的但渲染出来的视频时长可能因为帧率取整而有零点几秒的偏差。比如你计划 28 秒24 帧渲染出来是 672 帧正好 28 秒但如果计划 28.3 秒就会变成 679 帧28.29 秒差一点点。我的做法是先渲染视频量出实际时长再根据实际时长调整音频。如果旁白是提前录好的就用音频编辑工具微调语速如果是机器合成的旁白直接改语速参数。千万不要反过来去改视频时长因为视频时长是被帧率钉死的改起来很麻烦。还有一个坑旁白和画面的对应关系要在分镜脚本阶段就定死。我见过有人先做画面再配旁白结果旁白讲到第三个知识点时画面还在第二个全程错位。正确做法是分镜脚本里每一行都标好这句话对应哪个画面配音时严格按这个来。5.3 字幕烧录还是外挂字幕有两种做法烧录进画面硬字幕和外挂字幕文件软字幕。硬字幕的好处是任何平台都能显示坏处是改起来要重渲软字幕的好处是可编辑坏处是有些平台不显示。我的建议是讲解类视频用硬字幕因为观众大概率在静音环境下刷到字幕是刚需而且硬字幕的排版你可以用绘图库直接画进每一帧和画面风格统一。用绘图库画字幕时注意文字换行和字号自适应。模型生成的代码经常把长句画成一行超出画布。我在提示里会要求它每行不超过 20 个汉字超过则自动换行并且字号根据行数动态调整。这个细节不写出来的字幕要么溢出要么小得看不清。6. 第五步整条流水线的复盘与可复用经验6.1 哪些环节可以自动化哪些必须人工跑通一遍之后你会发现有些环节特别适合自动化有些则必须人来把关。可以自动化的抽帧验证、并行渲染、帧序列合成、字幕烧录。必须人工的分镜脚本撰写、缓动类型选择、音画对齐的最终确认。原因很简单前者的判断标准是客观的跑不跑得起来、帧数对不对后者的判断标准是主观的节奏好不好、观感顺不顺。我后来把可自动化的部分串成了一个脚本输入分镜脚本输出成片中间只在抽帧验证失败时停下来让人看。这样一条 30 秒的视频从脚本到成片大概 15 分钟其中 12 分钟是渲染等待人真正干活的时间只有 3 分钟。6.2 模型生成代码的常见翻车点跑多了之后我总结出模型生成绘图代码的几个高频翻车点列出来供你提前防范坐标系不一致前面提过一定要在提示里钉死。颜色值越界模型有时会给出 0 到 255 之外的值渲染时报错或显示异常。字体路径写死模型喜欢写一个具体的字体文件路径换台机器就找不到。要求它用系统默认字体或字体族名。循环边界错误比如画 10 个柱子写成 range(11)多画一个。透明度叠加错误多个半透明元素叠加时模型经常忘记考虑叠加顺序导致颜色不对。针对这些我的做法是在提示末尾加一段输出前自检清单让模型自己过一遍。虽然不能 100% 避免但能挡掉一大半。6.3 这套流水线适合什么、不适合什么最后说清楚边界。这套代码视频流水线适合数据可视化、算法讲解、数学动画、产品概念演示、流程说明、教学短片。它的优势是精确、可复现、可批量。它不适合真人出镜、实拍素材、复杂 3D 写实场景、需要大量手绘质感的艺术短片。这些场景要么用传统拍摄要么用专门的生成工具硬套代码流水线只会事倍功半。我个人在实际操作中的体会是代码视频的价值不在于像不像真的而在于讲得清不清楚。它天生适合把抽象的东西具象化——一个排序算法、一条数据趋势、一个物理过程用代码画出来比用嘴说清楚一百倍。想明白这一点你就不会纠结为什么模型不直接给我视频而是会享受每一帧都在我掌控之中的那种踏实感。