用大模型做代码视频：从提示词到渲染编码的完整工程实践-平芜编程栈

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

很多人第一次看到"用大模型做视频"这个说法，脑子里浮现的画面是：敲一行提示词，屏幕上直接吐出一段 mp4。我一开始也这么以为，直到真正动手跑了一遍才发现，这条路根本走不通，而且走不通的原因不是模型能力不够，而是方向从一开始就错了。

大语言模型本质上是一个文本到文本的映射器。它擅长的是理解结构、生成逻辑、组织符号，而不是直接输出像素流。你让它"生成一段视频"，它给你的永远是一堆字符——可能是代码，可能是配置，可能是分镜脚本。真正把字符变成动态画面的，是后面那一整套渲染管线。

所以"代码视频"这个玩法的核心思路是：让模型生成一段能描述动画的代码，再由渲染引擎把这段代码逐帧画出来，最后用编码器把帧序列压成视频文件。模型负责"写剧本"，渲染器负责"演戏"，编码器负责"录像"。三者分工明确，缺一不可。

这套流水线听起来简单，但真正落地时会遇到一堆细节问题：代码用什么语言写？渲染器选哪个？帧率怎么定？编码参数怎么配？每一步都有坑。下面我就按自己实际跑通的顺序，把这五步拆开讲清楚，包括每一步为什么这么选、参数怎么算、以及我踩过的那些坑。

提示：本文讨论的是"代码驱动动画"这一类技术路线，不涉及任何视频生成模型的直接推理。所有内容都是围绕"文本→代码→帧→视频"这条链路展开的。

2. 第一步：把"想要什么画面"翻译成模型能接住的提示结构

2.1 为什么不能直接说"给我做个视频"

我试过最偷懒的写法，直接跟模型说"帮我生成一段展示粒子效果的视频"。结果它回了我一段伪代码，变量名全是particle1、particle2，循环逻辑也是错的，根本跑不起来。问题出在哪？模型不知道你要用什么渲染框架，也不知道你的运行环境。

大语言模型在生成代码时，会默认往它训练数据里最常见的模式靠。如果你不说清楚，它可能给你 Python 的 matplotlib、可能给你 JavaScript 的 canvas、也可能给你一段 Processing 的草图。这三种东西的语法、坐标系、渲染方式完全不同，拿到手根本没法直接用。

所以第一步的关键不是"描述画面"，而是描述技术约束。你得告诉模型：用什么语言、什么库、什么坐标系、输出什么格式。这些约束越明确，生成的代码越接近可运行状态。

2.2 我实际用的提示结构模板

经过几次失败后，我固定下来一个提示结构，分四块写：

运行环境：Python 3.10 + Pillow + imageio，或者 Node.js + canvas，明确版本
画面描述：用自然语言说清楚要什么效果，比如"200 个粒子从中心向外扩散，带拖尾"
技术约束：坐标系原点在哪、画布尺寸、帧率、总帧数
输出要求：每帧存成 PNG，命名格式frame_0001.png，或者直接返回帧数组

举个例子，我实际用的一段提示是这样的：

环境：Python 3.10，只用标准库 + Pillow，不要用 numpy 画布：800x600，背景纯黑 效果：150 个粒子从画面中心随机方向飞出，速度递减，带半透明拖尾 帧率：30fps，总时长 4 秒，即 120 帧 输出：写一个函数 render_frames()，返回 120 个 PIL.Image 对象

这样写之后，模型生成的代码基本能直接跑，最多改几个变量名。关键是把"模糊的艺术描述"转成"可执行的工程约束"，这是第一步最核心的动作。

2.3 一个容易被忽略的细节：帧的独立性

这里有个坑我踩了两次才明白。如果你让模型生成"逐帧绘制"的代码，它很容易写成"每一帧都重新随机初始化粒子位置"。结果就是画面疯狂闪烁，因为每帧的粒子位置都是独立的随机数，根本没有连续性。

正确的做法是：粒子的初始状态只初始化一次，后续每帧只更新位置和速度。这个逻辑必须在提示里说清楚，否则模型默认会给你写一个"每帧重置"的版本。我后来在提示里加了一句"粒子状态需要在帧之间保持连续，用类或字典保存状态"，生成的代码才正常。

这个细节看起来小，但它决定了你的视频是"流畅动画"还是"随机噪点"。很多人第一次跑出来发现画面在抖，以为是渲染器的问题，其实是状态管理没做对。

3. 第二步：渲染器的选型——为什么我最后放弃了 matplotlib

3.1 三种常见渲染方案的对比

模型把代码给你之后，下一步就是选一个真正能"画帧"的渲染器。我前后试过三种方案，各有优劣，这里直接上对比表：

方案	优点	缺点	适用场景
matplotlib	上手快，API 熟悉	逐帧渲染慢，动画支持弱	数据可视化类短视频
Pillow 手绘	完全可控，速度快	所有图形要自己算	粒子、几何、自定义效果
canvas (Node)	浏览器级渲染质量	需要额外环境，跨语言	网页风格动画

我最初用的是 matplotlib，因为它画图方便。但跑起来才发现，matplotlib 的FuncAnimation在保存视频时会把每一帧重新走一遍完整的绘图流程，120 帧跑了将近 3 分钟，而且中间还报了几次内存警告。对于"代码视频"这种需要频繁迭代的场景，这个速度完全不能接受。

后来换成 Pillow 手绘，速度直接降到 8 秒左右。代价是所有图形都要自己用ImageDraw画，圆、线、多边形都得手动算坐标。但对于粒子效果、几何动画这类需求，Pillow 反而更灵活，因为你可以精确控制每一个像素的绘制顺序。

3.2 Pillow 渲染的核心代码结构

我实际用的 Pillow 渲染骨架大概是这样：

from PIL import Image, ImageDraw def render_frames(): frames = [] particles = init_particles(150) # 只初始化一次 for i in range(120): img = Image.new('RGB', (800, 600), (0, 0, 0)) draw = ImageDraw.Draw(img, 'RGBA') update_particles(particles) # 更新状态 for p in particles: draw.ellipse([p.x-2, p.y-2, p.x+2, p.y+2], fill=(255,255,255,180)) frames.append(img) return frames

注意ImageDraw.Draw(img, 'RGBA')这个参数，它让绘制支持透明度。如果不加这个，拖尾效果就出不来，所有粒子都是实心白点，看起来像一堆静止的星星。

3.3 渲染速度的优化经验

Pillow 渲染虽然快，但如果你每帧都创建新的Image对象，内存会涨得很快。120 帧 800x600 的 RGB 图，大概占 120 × 800 × 600 × 3 字节 ≈ 172MB。如果帧数更多，比如 600 帧，直接上 1GB，很容易把内存吃满。

我的做法是：渲染完一帧就立刻写盘，不要全部存在内存里。改成边渲染边保存：

for i in range(total_frames): img = render_one_frame(i) img.save(f'frames/frame_{i:04d}.png')

这样内存占用始终只有一帧的大小，跑几千帧也不会爆。代价是多了磁盘 IO，但相比内存爆掉的风险，这点 IO 完全值得。

注意：写盘时文件名一定要用零填充的格式（frame_0001.png），否则后面用 ffmpeg 拼接时，frame_10.png会排在frame_2.png前面，顺序全乱。

4. 第三步：帧序列到视频——编码参数里藏着的坑

4.1 为什么不能直接存 GIF

很多人图省事，直接把帧序列存成 GIF。我一开始也这么干，结果发现两个致命问题：一是 GIF 只支持 256 色，粒子渐变的半透明效果全丢了，画面变成一块一块的色带；二是 GIF 的帧延迟精度只有 10ms，30fps 需要 33.3ms 的延迟，GIF 根本表达不了，实际播放速度会偏。

所以只要你对画质有要求，就必须走"帧序列 → 视频编码"这条路。GIF 只适合做预览，不适合做最终输出。

4.2 ffmpeg 编码命令的完整拆解

我用的是 ffmpeg 做编码，核心命令就一行，但每个参数都有讲究：

ffmpeg -framerate 30 -i frames/frame_%04d.png \ -c:v libx264 -pix_fmt yuv420p -crf 18 \ -preset slow -movflags +faststart \ output.mp4

逐个解释：

-framerate 30：输入帧率，必须和渲染时的帧率一致，否则视频会变速
-i frames/frame_%04d.png：输入模式，%04d对应四位零填充的文件名
-c:v libx264：用 H.264 编码，兼容性最好
-pix_fmt yuv420p：像素格式，这个必须加，否则很多播放器打不开
-crf 18：质量参数，18 是视觉无损，数字越小质量越高、文件越大
-preset slow：编码速度预设，slow 比 medium 慢但压缩率更高
-movflags +faststart：把元数据移到文件头，方便在线播放

这里面最容易漏的是-pix_fmt yuv420p。我第一次编码出来的视频，在本地播放器能放，但传到某些平台就黑屏，查了半天才发现是像素格式的问题。yuv420p 是兼容性最好的格式，加上它基本不会出错。

4.3 CRF 参数怎么选

CRF 是"恒定速率因子"，控制画质和文件大小的平衡。我实测下来的经验值：

CRF	画质	文件大小（120帧 800x600）	适用场景
15	极高	约 8MB	存档、二次编辑
18	高	约 4MB	常规输出
23	中	约 2MB	快速预览
28	低	约 1MB	草稿

对于代码视频这种以几何图形为主的画面，CRF 18 基本就是视觉无损了，再低意义不大。如果你只是快速看效果，CRF 23 足够。

5. 第四步：让模型自己迭代——把报错信息喂回去

5.1 第一次生成的代码几乎不可能直接跑通

我跑了十几次，第一次生成的代码能直接跑通的概率大概只有三成。剩下的七成会报各种错：变量名拼错、库没导入、坐标系搞反、循环边界写错。这时候很多人会手动改，但更高效的做法是把报错信息原样喂回给模型，让它自己修。

比如模型生成的代码报NameError: name 'ImageDraw' is not defined，你直接把这段报错贴回去，加一句"运行报了这个错，帮我修一下"，模型基本能立刻定位到是from PIL import ImageDraw没写。

5.2 迭代提示的写法

我总结的迭代提示模板：

上面的代码运行时报错： [粘贴完整报错信息] 我的环境是 [Python版本 / 库版本]。 请只修改出错的部分，不要重写整个文件。

关键是要求它只改出错部分。如果不加这句，模型很容易把整个代码重写一遍，结果引入新的错误。我吃过好几次这个亏，改一个变量名结果把整个渲染逻辑都换了。

5.3 视觉问题的迭代

比语法错误更难处理的是"代码能跑但画面不对"。比如粒子颜色全是白的、拖尾没出来、画面偏到一边。这类问题没法靠报错信息定位，得用自然语言描述现象。

我一般这么写：

代码能正常运行，但画面有问题： 1. 粒子没有拖尾效果，每帧都是独立的白点 2. 画面整体偏左上角，右边和下边有大片空白 请分析原因并给出修改方案。

模型看到这种描述，通常能推断出是"没有做帧间混合"和"坐标系原点没居中"这两个问题。实测下来，两三轮迭代基本能把画面调到可用状态。

6. 第五步：整条流水线的串联与自动化

6.1 把五步写成一个脚本

手动跑五步太累，我最后把它串成了一个 Python 脚本，大致流程：

调用模型 API 生成渲染代码（或者直接用本地缓存的代码）
执行渲染代码，输出帧序列到frames/目录
调用 ffmpeg 编码成 mp4
清理临时帧文件

核心就是用subprocess调 ffmpeg：

import subprocess subprocess.run([ 'ffmpeg', '-y', '-framerate', '30', '-i', 'frames/frame_%04d.png', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', '-crf', '18', '-preset', 'slow', 'output.mp4' ], check=True)

-y参数是覆盖已有文件，不加的话 ffmpeg 会卡在交互确认上，脚本就挂住了。

6.2 参数化的设计

为了让脚本能复用，我把关键参数都提到了配置区：

CONFIG = { 'width': 800, 'height': 600, 'fps': 30, 'duration': 4, 'crf': 18, 'output': 'output.mp4' }

这样改分辨率、改时长、改画质都不用动核心逻辑，只改配置就行。我后来做不同效果的视频，基本就是改配置 + 换提示词，五分钟能出一条。

6.3 我踩过的一个自动化坑

有一次我把渲染和编码串在一起跑，结果渲染到一半报错，但编码步骤还是执行了，ffmpeg 拿着不完整的帧序列编出了一个只有 2 秒的视频，还没报错。我看了半天才发现是帧数不对。

后来我在编码前加了一个检查：统计frames/目录下的文件数量，和预期帧数对比，不一致就直接退出。这个检查救了我好几次，尤其是渲染代码有随机性的时候，偶尔会少渲染几帧。

import os expected = CONFIG['fps'] * CONFIG['duration'] actual = len([f for f in os.listdir('frames') if f.endswith('.png')]) if actual != expected: raise RuntimeError(f'帧数不对：预期 {expected}，实际 {actual}')