企业官网建设流程全解析

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

先把结论摆在最前面：所谓"代码视频"，本质上是用代码描述画面，再由渲染引擎把代码翻译成像素。模型在整个链路里承担的是"写代码"和"改代码"的角色，它不碰帧、不碰编码、不碰封装。很多人第一次听到"用大模型做视频"，脑子里浮现的是输入一句话、直接吐出一个 mp4 文件，这个预期从根上就是错的。

我最早接触这条链路的时候也走过弯路。当时想的是"让模型直接输出视频文件"，结果发现无论怎么调提示词，拿到的都是一堆文本。后来才想明白：视频是二进制流，模型输出的是 token 序列，两者之间隔着一整个渲染管线。真正可行的路径是让模型输出结构化的绘图指令——可以是 SVG、可以是 Canvas 的 JavaScript、可以是 Processing 的 sketch、也可以是 Manim 的 Python 脚本——然后交给对应的渲染器去逐帧生成。

这个认知一旦摆正，后面所有事情都顺了。你会开始关心"模型写的代码能不能跑""渲染出来的画面稳不稳定""帧序列怎么拼成视频"，而不是纠结"模型为什么不肯直接给我 mp4"。

那这条流水线到底长什么样？我把它拆成五步：意图解析 → 代码生成 → 沙箱执行 → 逐帧渲染 → 编码封装。这五步里，模型只深度参与前两步，第三步是执行环境的事，第四步是渲染引擎的事，第五步是 ffmpeg 这类工具的事。下面我逐步拆开讲，每一步都会说清楚"为什么这么设计""实际会踩什么坑""怎么验证跑通了"。

提示：本文讨论的是"代码驱动画面"这一类视频生成方式，和基于扩散模型的像素级视频生成是两条完全不同的技术路线，不要混为一谈。

2. 意图解析：把一句人话翻译成"可编程的画面描述"

2.1 为什么不能让模型直接写代码

很多人图省事，提示词就一句"帮我做一个粒子旋转的视频"，然后指望模型直接吐出能跑的代码。实测下来，这样拿到的代码十有八九跑不起来，或者跑起来画面完全不是你想的那样。原因很简单：自然语言到可执行代码之间，缺了一层结构化的中间表示。

我的做法是强制加一个中间层。先让模型把需求拆成一份"画面规格说明书"，包含这几个字段：画布尺寸、帧率、总时长、背景、主体元素列表、每个元素的运动轨迹、配色方案、文字内容。这份规格用 JSON 或 YAML 表达，字段固定，模型填起来不容易跑偏。

举个例子，"粒子旋转"这个需求，解析出来大概是这样：

{ "canvas": {"width": 1080, "height": 1080}, "fps": 30, "duration": 6, "background": "#0d1117", "elements": [ { "type": "particle_system", "count": 240, "radius_range": [2, 5], "color_palette": ["#58a6ff", "#79c0ff", "#a5d6ff"], "motion": {"type": "orbit", "center": [540, 540], "speed": 0.8} } ] }

有了这份规格，第二步生成代码就变成了"照着规格翻译"，出错概率大幅下降。而且规格本身是可读的，你能一眼看出模型有没有理解错你的意图——如果它把"旋转"理解成了"缩放"，在规格阶段就能发现，不用等到渲染出来才发现画面不对。

2.2 规格字段里最容易含糊的几个点

我在实际项目里发现，有几个字段如果不定死，模型每次理解都不一样，导致同一句提示词跑出来的结果飘忽不定。

时间单位。是秒还是帧？如果规格里写duration: 6，模型可能理解成 6 秒，也可能理解成 6 帧。我的习惯是统一用秒，然后在代码生成阶段再乘以 fps 换算成帧数。这样规格对人友好，代码对机器友好。

坐标系原点。左上角还是左下角？Canvas 默认左上角，Processing 默认左上角，但数学绘图库往往默认左下角。这个不写清楚，画面会上下颠倒。我一般在规格里显式写"origin": "top-left"。

颜色格式。是十六进制字符串还是 RGB 数组？渲染引擎接受哪种就写哪种，别让模型自己猜。我统一用十六进制字符串，因为可读性最好，转换也简单。

运动的时间函数。是线性、缓入缓出、还是正弦往复？这个直接决定画面的"手感"。线性运动看起来机械，缓入缓出看起来自然，正弦往复适合做呼吸感。规格里我会写"easing": "ease-in-out"这种明确的值。

2.3 解析阶段的提示词怎么写才稳

我的提示词模板大致是这样组织的：先给角色设定（"你是一个画面规格生成器"），再给输出格式约束（"只输出 JSON，不要任何解释文字"），然后给字段说明，最后给一两个示例。关键是示例要给全，把每个字段都覆盖到，模型照着示例填，格式基本不会错。

还有一个技巧：让模型在生成规格后自己检查一遍，问它"这份规格是否完整覆盖了用户需求，有没有遗漏字段"。这个自检步骤能拦掉不少低级错误。我试过加和不加，加了之后规格的完整度明显提升。

3. 代码生成：让模型写出"能跑且好看"的渲染脚本

3.1 渲染目标怎么选：四种主流方案的取舍

规格有了，接下来要选一个渲染目标。这一步的选择直接决定了后面所有工作的难度。我把常见的四种方案列出来对比一下：

选哪个，取决于你的画面内容。如果只是做数据图表的动态展示，SVG 就够了，代码简单，模型也不容易写错。如果要做粒子系统、流体效果这类，Canvas 或 p5.js 更合适。如果涉及数学公式推导、几何证明，Manim 是首选，它对公式排版的支持是其他方案比不了的。

我个人的默认选择是p5.js。原因是：它的 API 设计对模型友好（函数名直观，参数少），社区示例多（模型训练时见过大量 p5 代码），而且它天然支持"每帧调用一次 draw 函数"这种模式，和逐帧渲染的思路完美契合。

3.2 为什么"逐帧可控"是硬指标

这里要强调一个关键点：渲染脚本必须支持"给定帧号，输出该帧画面"。也就是说，脚本不能依赖实时时钟，不能依赖Date.now()或performance.now()，而应该用一个显式的帧号变量来驱动所有动画。

为什么这么要求？因为后面逐帧渲染时，我们要精确控制每一帧的内容。如果脚本依赖实时时钟，那么渲染速度的快慢会影响画面内容，同一段代码跑两次结果不一样，这就没法做稳定的视频输出了。

p5.js 里有个frameCount变量，天然就是帧号，用它来驱动动画最合适。Canvas 里我会自己维护一个currentFrame变量，在渲染循环里手动递增。Manim 更简单，它本身就是按帧构造场景的。

3.3 代码生成阶段的提示词工程

生成代码的提示词，我会把规格 JSON 直接嵌进去，然后加上这些约束：

• 只输出代码，不要 markdown 代码块标记，不要解释
• 使用指定的渲染库和版本
• 所有动画必须由帧号驱动，禁止使用实时时钟
• 画布尺寸、帧率、总时长从规格读取，不要硬编码
• 代码开头定义TOTAL_FRAMES常量，等于fps * duration

最后一条特别有用。渲染器需要知道总共要渲染多少帧，如果代码里没有这个常量，渲染器就得靠猜。定义成常量，渲染器直接读就行。

还有一个经验：让模型把代码写得"防御性"一点。比如数组访问前检查长度，除法前检查分母不为零，颜色值做范围钳制。这些检查在正常运行时看不出价值，但一旦某个参数越界，有检查的代码会画出稍微不对的画面，没检查的代码直接崩溃，整个渲染中断。我吃过这个亏，一个跑了二十分钟的渲染任务因为第 1800 帧的一个除零错误全废了。

3.4 生成后的静态检查

代码拿到手，别急着跑。先做几项静态检查：

1. 语法检查。JavaScript 用node --check，Python 用python -m py_compile，能拦掉大部分低级语法错误。
2. 依赖检查。代码里import或require的库，环境里有没有装。
3. 常量检查。TOTAL_FRAMES有没有定义，值对不对。
4. 时钟检查。搜一下代码里有没有Date.now、performance.now、time.time()这类调用，有的话要改掉。

这四项检查加起来不到一分钟，但能省下大量调试时间。我现在的流程里，这步是自动化的，代码一生成就跑一遍检查，不通过直接打回让模型重写。

4. 沙箱执行：把模型写的代码关进笼子里跑

4.1 为什么必须用沙箱

模型生成的代码，本质上是不可信代码。它可能写出死循环，可能疯狂申请内存，可能试图读写文件系统，甚至可能执行一些你意想不到的操作。直接在你自己的机器上跑，风险太大。

沙箱的核心目的是三件事：限制资源、隔离环境、可控中断。限制资源是指给进程设定 CPU 时间上限、内存上限；隔离环境是指让它在一个独立的容器或虚拟机里跑，碰不到宿主机；可控中断是指你能随时杀掉它，不用等它自己结束。

我常用的方案是 Docker 容器加资源限制。启动容器时指定--memory、--cpus、--pids-limit，再配合一个超时机制，跑太久就强制终止。这样即使代码有问题，影响范围也被限制在容器内。

4.2 渲染器的接口设计

沙箱里跑的不是原始脚本，而是一个渲染器包装层。这个包装层负责：加载模型生成的代码、初始化渲染环境、按帧号调用渲染函数、把每帧画面导出成图片。

接口设计上，我要求模型生成的代码暴露两个函数：

// 初始化，只在开始时调用一次 function setup() { /* ... */ } // 渲染指定帧，frameNo 从 0 到 TOTAL_FRAMES-1 function renderFrame(frameNo) { /* ... */ }

包装层的工作就是循环调用renderFrame(0)、renderFrame(1)……直到最后一帧，每调用一次就把画布内容导出成 PNG。这样模型只需要关心"怎么画一帧"，不用关心"怎么存文件""怎么循环"，职责清晰。

4.3 逐帧导出的性能陷阱

逐帧导出 PNG 这个操作，看起来简单，实际上很容易成为性能瓶颈。我踩过的坑有这么几个：

坑一：每帧都重新创建画布。有些实现里，每次renderFrame都新建一个 canvas 对象，画完就丢。这样内存分配和回收的开销巨大，渲染速度慢好几倍。正确做法是复用同一个画布，每帧只清空重绘。

坑二：PNG 压缩级别过高。PNG 是无损格式，压缩级别越高越慢。默认级别往往偏高，导出 1080p 一帧要几百毫秒。把压缩级别调到最低，速度能快三到五倍，文件大一点无所谓，反正后面还要编码成视频。

坑三：同步写文件。每帧渲染完同步写磁盘，磁盘 IO 成为瓶颈。改成异步写，或者先攒在内存里批量写，速度提升明显。

坑四：没有进度反馈。渲染一个 6 秒 30fps 的视频是 180 帧，如果每帧要 200 毫秒，总共 36 秒。这期间如果没有任何输出，你会怀疑是不是卡死了。加个进度打印，每 10 帧输出一次，心里有底。

4.4 中断与恢复机制

长任务一定要能中断和恢复。渲染到第 120 帧发现前面某帧有问题，如果只能从头再来，那太浪费时间了。我的做法是：每渲染完一帧，就把帧号写到一个状态文件里。重新启动时先读状态文件，从上次中断的帧号继续。

这个机制还有个附带好处：可以并行渲染。把帧号范围切成几段，每段一个进程，同时跑，最后合并。8 核机器上，渲染速度能接近 8 倍。当然并行也有代价，每个进程都要独立初始化渲染环境，启动开销不能忽略，所以帧数太少的时候并行不划算。

5. 编码封装：把几万张 PNG 拼成一个能播的视频

5.1 ffmpeg 的基本调用

帧序列有了，最后一步是编码成视频。这一步用 ffmpeg 最省事。基本命令是这样：

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

几个参数解释一下。-framerate 30是输入帧率，要和渲染时的 fps 一致。-i frame_%05d.png是输入模式，%05d表示五位数字的帧号，从 00000 开始。-c:v libx264指定视频编码器，H.264 兼容性最好。-pix_fmt yuv420p是像素格式，这个必须指定，否则某些播放器打不开。-crf 18是质量参数，数值越小质量越高文件越大，18 算是视觉无损。-preset slow是编码速度预设，越慢压缩率越高。

5.2 帧号命名不一致的坑

ffmpeg 的%05d模式要求帧号连续且位数固定。如果你的渲染器输出的是frame_1.png、frame_2.png……frame_10.png，位数不固定，ffmpeg 会按字符串排序，frame_10排在frame_2前面，视频顺序就乱了。

解决办法有两个：一是渲染时就按固定位数命名，frame_00001.png；二是用-pattern_type glob配合通配符，但这样又要求文件名排序正确。我推荐第一种，从源头保证命名规范。

5.3 音画同步的预留

如果你的视频要加音频，编码时就要考虑进去。音频文件用-i audio.mp3引入，然后用-shortest让视频长度对齐较短的轨道。如果音频比视频长，会被截断；如果视频比音频长，视频末尾会静音。具体怎么处理，看你的需求。

还有一种情况是视频本身没有音频，但你想加背景音乐。这时候要注意版权问题，用自己生成的音频或者明确可商用的素材。我一般用代码合成简单的音效，比如正弦波做提示音，这样完全没有版权顾虑。

5.4 编码参数的取舍

-crf和-preset这两个参数，直接决定编码时间和文件大小。我做过一组测试，同样 180 帧 1080p 的素材：

可以看到，ultrafast到medium文件大小减半，时间增加不多，性价比最高。medium到slow时间翻三倍，文件只小一点点，不划算。所以我的默认配置是-preset medium -crf 20，兼顾速度和质量。只有对文件大小特别敏感时才用slow。

6. 整条链路的串联与自动化

6.1 一个可复用的目录结构

把五步串起来，我习惯用这样的目录结构：

project/ spec.json # 第一步产出的规格 render.js # 第二步产出的渲染脚本 frames/ # 第四步产出的帧序列 frame_00000.png frame_00001.png ... output.mp4 # 第五步产出的视频 state.json # 渲染进度状态

每一步的产物都落盘，这样任何一步出问题，都能从中间某一步重新开始，不用从头跑。比如规格写错了，改spec.json重新生成代码；代码有问题，改render.js重新渲染；渲染没问题只是编码参数不对，直接重跑 ffmpeg。

6.2 用脚本把五步串起来

手动一步步跑太累，我写了个 shell 脚本把五步串起来：

#!/bin/bash set -e # 第一步：生成规格 python gen_spec.py "$1" > spec.json # 第二步：生成代码 python gen_code.py spec.json > render.js # 第三步：静态检查 node --check render.js # 第四步：沙箱渲染 docker run --rm -v $(pwd):/work \ --memory 2g --cpus 2 \ render-env node /work/render.js # 第五步：编码 ffmpeg -y -framerate 30 -i frames/frame_%05d.png \ -c:v libx264 -pix_fmt yuv420p -crf 20 -preset medium \ output.mp4

set -e让脚本在任何一步失败时立即停止，不会带着错误继续往下跑。这个很重要，否则第一步失败了，后面几步会基于错误输入继续跑，浪费时间还容易产生误导性的结果。

6.3 失败重试的策略

自动化跑起来之后，失败是常态。模型生成的代码第一次跑不通太正常了。我的重试策略是：把错误信息喂回给模型，让它自己修。

具体做法是：捕获渲染时的报错信息（stderr），连同原始代码一起发给模型，提示词是"这段代码运行时报了以下错误，请修复后重新输出完整代码"。实测下来，大部分语法错误和简单的运行时错误，模型一次就能修好。复杂的逻辑错误可能要两三轮。

重试要有上限，我一般设 3 次。3 次还修不好，说明这个需求本身可能有问题，或者模型理解偏了，这时候应该回到第一步重新解析意图，而不是继续在代码层面打转。

7. 实测中那些文档不会写的经验

7.1 画面"抖动"的根因往往是浮点误差

有段时间我发现渲染出来的动画有轻微抖动，尤其是慢速运动的元素。排查了很久，最后定位到是浮点精度问题。当运动速度很慢时，每帧的位置变化量很小，浮点数的舍入误差就显现出来了，导致位置在相邻两帧之间来回跳。

解决办法是用帧号直接计算位置，而不是累加增量。比如旋转动画，不要写angle += speed，而要写angle = speed * frameNo。前者会累积误差，后者每帧独立计算，没有累积。这个改动很小，但效果立竿见影。

7.2 颜色在不同环节的偏差

从代码里定义的颜色，到最终视频里的颜色，中间经过好几道转换，很容易出现偏差。我遇到过定义#58a6ff结果视频里看起来偏紫的情况。排查下来是色彩空间的问题：渲染时用的是 sRGB，编码时 ffmpeg 默认可能按别的色彩空间处理。

解决办法是在 ffmpeg 命令里显式指定色彩参数：

ffmpeg -framerate 30 -i frame_%05d.png \ -c:v libx264 -pix_fmt yuv420p \ -colorspace bt709 -color_primaries bt709 -color_trc bt709 \ -crf 20 output.mp4

bt709 是高清视频的标准色彩空间，指定之后颜色就准了。这个坑很隐蔽，因为偏差往往不大，不仔细对比看不出来，但对色彩敏感的项目就是致命的。

7.3 大分辨率下的内存管理

渲染 4K 视频时，内存是个大问题。一张 4K PNG 解压后是 3840×2160×4 字节，约 33 MB。如果渲染器把 180 帧全缓存在内存里，就是 6 GB，普通机器直接爆掉。

我的做法是渲染一帧、写一帧、释放一帧，内存里始终只保留当前帧。这样内存占用是常数级的，和总帧数无关。代价是每帧都要做一次磁盘写入，但相比内存爆掉，这点开销完全值得。

如果磁盘 IO 实在太慢，可以折中：攒 10 帧批量写一次，内存占用也就 330 MB，可以接受。

7.4 模型"偷懒"的识别与应对

模型生成代码时有个常见毛病：该循环的地方它给你展开写。比如要画 100 个粒子，它可能真的写 100 行drawParticle(...)，而不是写一个循环。这样代码又长又难维护，而且容易出错。

识别方法很简单：看代码行数。如果规格里说 100 个粒子，代码却有几百行，那多半是展开写了。应对方法是在提示词里明确要求"使用循环和数组，禁止重复代码块"。如果模型还是不改，可以在后处理阶段做一次代码压缩，把重复的模式识别出来改写成循环，但这比较麻烦，不如在提示词阶段就约束好。

7.5 渲染时间的预估

跑之前先估一下时间，心里有数。估算公式很简单：总时间 = 总帧数 × 单帧渲染时间 + 编码时间。单帧渲染时间可以先渲染 10 帧测一下，取平均。编码时间大概是总帧数的 0.1 到 0.2 秒每帧，取决于分辨率和 preset。

比如 180 帧，单帧 150 毫秒，编码按 0.15 秒每帧算，总时间约 27 秒加 27 秒，一分钟以内。如果估算出来要跑半小时以上，就要考虑是不是哪里配置不对，或者该上并行了。

8. 这条流水线适合做什么，不适合做什么

8.1 适合的场景

数据可视化动画。把一组数据用动态图表展示，代码驱动的方式比手工做动画高效得多，而且数据变了重新跑一遍就行。

数学与算法讲解。公式推导、几何变换、算法流程，这类内容用 Manim 做出来清晰又专业，而且模型对这类结构化内容的代码生成质量很高。

生成艺术与创意编程。粒子系统、分形、噪声场，这些用代码描述比用鼠标画自然得多，而且参数一调就是另一个作品。

批量化的模板视频。比如给一百个产品各生成一段展示视频，模板固定，只是数据不同，这种场景代码驱动是碾压性的优势。

8.2 不适合的场景

写实风格的画面。代码画不出照片级的真实感，这是扩散模型的领域，不是代码渲染的领域。

复杂的角色动画。人物走路、表情变化这类，代码描述起来极其繁琐，用专门的动画软件效率高得多。

需要精细手工调整的画面。代码是参数化的，适合规则化的内容。如果每个细节都要单独调，代码反而不如直接操作图形界面。

8.3 和像素级视频生成的关系

这两条路线不是替代关系，而是互补关系。代码渲染擅长精确、可控、可复现的内容，像素生成擅长写实、丰富、有质感的内容。实际项目里，我见过把两者结合的：用代码渲染出精确的几何结构，再用像素生成做风格化和质感增强。这种混合方案往往能取两者之长。

不过混合方案的复杂度也高，两条链路都要调通，还要处理两者的对齐问题。如果项目对精确性要求不高，直接用像素生成更省事；如果对精确性要求极高，纯代码渲染更可靠。混合方案适合那些"既要精确又要质感"的场景。

9. 从零跑通第一条流水线的建议路径

如果你现在想动手试，我建议按这个顺序来，别一上来就搞复杂的。

第一步，先跑通一个最简单的例子。就画一个移动的圆，30 帧，每帧圆往右移一点。手动写代码，手动渲染，手动编码。目的是把五步链路走一遍，理解每一步的输入输出。

第二步，把模型接进来。还是移动的圆，但代码让模型生成。提示词就一句"生成一个 p5.js 脚本，画一个从左边移动到右边的圆，共 30 帧"。看看模型输出什么，跑一下，对比手写的版本差在哪。

第三步，加上规格层。把"移动的圆"这个需求写成 JSON 规格，让模型照着规格生成代码。体会一下加了规格层之后，输出稳定性的变化。

第四步，加上沙箱和自动化。把手动步骤写成脚本，加上资源限制和错误重试。这时候你就有了一条能用的流水线。

第五步，逐步增加复杂度。从圆到粒子系统，从单色到渐变，从线性运动到缓动曲线。每增加一个复杂度，观察流水线哪里会出问题，针对性加固。

这个路径走下来，大概两三天能跑通一条基本可用的流水线。之后就是不断打磨，把踩过的坑一个个填上。我现在用的这套，是迭代了十几版才稳定下来的，早期版本问题一大堆，但只要能跑通第一步，后面都是水到渠成的事。

最后分享一个我自己的习惯：每次跑通一个新效果，就把当时的规格、代码、参数记下来，存成一个模板。下次遇到类似需求，直接改模板比从零生成快得多，而且质量有保证。这个模板库积累到几十个之后，大部分常见需求都能在几分钟内搞定。