企业官网建设流程全解析

1. 当模型说"我能生成视频"时，它到底在生成什么

先把一个容易混淆的概念掰开：Claude Opus 5.5 这类大语言模型本身并不输出.mp4文件。它没有内置的渲染管线，也没有显卡驱动的编码器。它做的事情是生成代码——具体来说，是生成一段能驱动浏览器 Canvas 或 Node.js 端 FFmpeg 的 JavaScript 程序，再由这段程序去逐帧绘制、合成、编码，最终产出一个视频文件。

这个区别非常关键。很多人第一次听说"AI 做视频"，脑子里浮现的是模型直接吐出一段视频流。实际链路是这样的：

用户描述需求 → 模型理解意图并规划分镜 → 模型输出 JavaScript/Canvas 绘图代码 → 代码在运行时逐帧渲染 → FFmpeg 把帧序列编码成视频 → 得到可播放文件

所以真正决定成片质量的，不是模型"画"得好不好，而是它写的代码在帧率控制、坐标系变换、时间轴同步、编码参数这几个环节上有没有踩坑。我前后用这套思路做过十几个小项目，从简单的几何动画到带文字特效的片头，踩的坑基本都集中在这几块。下面把我摸索出来的完整链路拆开讲，包括为什么这么选、每一步容易在哪里翻车。

这篇文章适合两类人：一是想用大模型辅助做视频、但不知道从哪下手的前端或脚本开发者；二是已经能让模型吐出代码、但跑出来的视频要么卡顿要么糊成一片、想搞清楚问题出在哪的人。不需要你有视频编码背景，但至少要能看懂 JavaScript 和命令行。

2. 为什么是 Canvas 加 FFmpeg 这套组合

2.1 浏览器 Canvas 负责"画"，FFmpeg 负责"压"

视频的本质是一连串静止画面按时间顺序快速播放。要做视频，就得解决两件事：怎么把每一帧画出来，以及怎么把一堆帧打包成一个文件。

画帧这件事，Canvas 是目前门槛最低、生态最成熟的选择。它提供了 2D 绘图上下文，矩形、圆形、路径、渐变、文字、图片合成全都能干，而且浏览器原生支持，不需要装任何东西。模型生成 Canvas 代码的准确率也明显高于其他方案，因为 Canvas API 稳定、文档丰富、训练语料里到处都是。

打包这件事，FFmpeg 是事实标准。它能把 PNG/JPG 序列、原始像素流、甚至另一段视频重新编码成目标格式，控制码率、帧率、分辨率、编码器全都不在话下。模型对 FFmpeg 命令行的掌握程度也相当高，常见的-framerate、-crf、-pix_fmt这些参数基本不会写错。

两者结合的方式有两种，我分别说说适用场景：

我个人的选择是中间那条路：浏览器里用 Canvas 逐帧画好，导出成图片序列，再用 FFmpeg 编码。原因是它把"画"和"压"彻底解耦了——画错了可以单独调绘图代码，压糊了可以单独调编码参数，互不干扰。MediaRecorder 那条路看起来省事，但它本质是实时录制，一旦某一帧渲染慢了，录出来的视频就会掉帧或者时间轴错位，做精确动画基本没法用。

2.2 模型在这条链路里扮演的角色

理解了链路，就能明白模型的价值点在哪。它不是替你"想创意"那么简单，而是承担了三件具体的活：

第一，把自然语言需求翻译成绘图逻辑。你说"一个红色圆从左上角滚到右下角，带一点弹性"，模型要把它拆成：圆的初始坐标、运动方程、缓动函数、每帧的clearRect和arc调用。这一步它做得相当好。

第二，生成时间轴和帧循环的骨架。视频必须有稳定的帧率，模型通常会写出for (let frame = 0; frame < totalFrames; frame++)这样的循环，并在循环里根据frame / fps计算当前时间，再据此决定每个元素的状态。这个"用帧号反推时间"的模式是正确做法，比用setInterval靠谱得多。

第三，补全 FFmpeg 命令。你把导出的图片序列交给它，它能给出带-framerate 30 -i frame_%04d.png -c:v libx264 -pix_fmt yuv420p out.mp4的完整命令，还会提醒你yuv420p是为了兼容性。

但模型也有明显的盲区，这些盲区就是你必须自己把关的地方：它经常忘记处理坐标原点（Canvas 原点在左上角，做旋转和缩放时容易翻车）、容易忽略文字基线（导致文字位置偏移）、对编码参数的含义理解停留在表面（比如不知道-crf调小是变清晰而不是变大）。这些我在后面会逐个展开。

3. 从需求到可运行代码：模型生成 Canvas 动画的完整拆解

3.1 让模型先输出"分镜表"而不是直接写代码

这是我踩过坑之后改掉的习惯。早期我直接让模型"写一个视频生成代码"，它经常一上来就堆几百行，逻辑混在一起，改都没法改。后来我改成两步走：先让它输出一份分镜表，确认无误后再让它按分镜写代码。

分镜表要包含每个镜头的：起止时间、画面元素、运动方式、文字内容、转场效果。比如做一个小金鱼游动的动画，分镜表大概长这样：

镜头1 (0-2s)：背景渐变蓝，一条金鱼从左游到右，尾巴摆动 镜头2 (2-4s)：金鱼停下，气泡从下方升起 镜头3 (4-6s)：文字"小金鱼捏捏"淡入，金鱼轻微缩放

这份表看起来简单，但它逼着模型把"时间"这个维度显式表达出来。视频和静态图的根本区别就在时间轴上，先把时间轴定死，后面写代码就是填空题。我实测下来，有分镜表的项目返工率比没有的低一大截，因为大部分错误在分镜阶段就能发现——比如两个镜头时间重叠了、总时长和帧数对不上。

3.2 帧循环的正确写法与常见错误

分镜确认后，进入核心的帧循环。正确的骨架长这样：

const fps = 30; const duration = 6; // 秒 const totalFrames = fps * duration; for (let frame = 0; frame < totalFrames; frame++) { const t = frame / fps; // 当前时间，单位秒 ctx.clearRect(0, 0, width, height); drawBackground(ctx, t); drawFish(ctx, t); drawText(ctx, t); exportFrame(canvas, frame); // 导出当前帧 }

这里有几个关键点，模型不一定每次都写对：

第一，时间必须由帧号推导，不能用真实时钟。有些模型会写const t = Date.now() / 1000，这在实时动画里没问题，但在逐帧导出时是灾难——因为导出每一帧都要花时间，真实时钟会一直往前走，导致动画速度完全乱掉。正确做法永远是t = frame / fps，这样无论导出多慢，每一帧对应的时间都是确定的。

第二，clearRect不能忘。Canvas 是叠加绘制的，不清空的话上一帧的内容会残留，做出来的视频全是拖影。模型偶尔会漏掉这一句，尤其是当它把背景画成不透明矩形时，会误以为不需要清空。稳妥起见，每帧开头都清一次。

第三，导出帧的命名要能排序。FFmpeg 读取图片序列时依赖文件名顺序，必须用零填充的编号，比如frame_0001.png、frame_0002.png。如果写成frame_1.png、frame_2.png，到frame_10.png时排序就会乱，视频顺序全错。这个坑我踩过一次，排查了半天才发现是文件名的问题。

3.3 缓动函数：让运动不像机器人

模型默认生成的运动会是线性的——匀速从 A 到 B。这种运动看起来非常机械，因为现实世界里几乎没有东西是严格匀速的。解决办法是引入缓动函数（easing function）。

最简单的缓动是二次缓入缓出：

function easeInOutQuad(t) { return t < 0.5 ? 2 * t * t : 1 - Math.pow(-2 * t + 2, 2) / 2; }

用法是把归一化的进度p（0 到 1）传进去，得到缓动后的进度，再插值坐标：

const p = (t - startTime) / (endTime - startTime); const eased = easeInOutQuad(Math.min(Math.max(p, 0), 1)); const x = startX + (endX - startX) * eased;

注意那个Math.min(Math.max(p, 0), 1)，它把进度钳制在 0 到 1 之间。如果不钳制，当t超出镜头时间范围时，p会变成负数或大于 1，元素就会飞到画面外或者反向运动。模型经常忘记这个钳制，导致元素在镜头切换时"闪一下"。

我一般会让模型把常用的缓动函数都写进一个工具对象里，包括linear、easeInQuad、easeOutQuad、easeInOutQuad、easeOutBack（带一点回弹，适合"捏捏"这种俏皮效果）。这样调动画的时候直接换函数名就行，不用改运动逻辑。

3.4 文字渲染的基线陷阱

文字是视频里最容易出问题的地方。Canvas 的fillText默认基线是alphabetic，也就是文字底部对齐给定坐标。如果你想让文字在某个矩形里垂直居中，直接传矩形中心 y 坐标是不对的，文字会偏上。

正确做法是设置textBaseline = 'middle'，或者手动加上字号的一半。我通常两个都做：

ctx.font = 'bold 48px sans-serif'; ctx.textAlign = 'center'; ctx.textBaseline = 'middle'; ctx.fillText('小金鱼捏捏', width / 2, height / 2);

textAlign = 'center'让文字水平居中于给定 x 坐标，textBaseline = 'middle'让文字垂直居中于给定 y 坐标。这两句配上，文字才会真正落在你期望的位置。模型生成的代码里，这两句经常只写一句，或者都不写，结果文字位置总是差那么一点。

还有一个坑是字体加载时机。如果用了自定义字体，必须等document.fonts.ready之后再开始渲染，否则前几帧会用默认字体画，后面才切换，视频里就会出现字体突变。这个在导出图片序列时尤其明显，因为每一帧都是独立渲染的。

4. 把帧序列变成视频：FFmpeg 编码参数逐个说清

4.1 图片序列导入与帧率设定

帧导出完成后，目录里应该是一堆frame_0001.png到frame_0180.png（6 秒 30 帧就是 180 帧）。编码命令的核心是告诉 FFmpeg 按什么帧率读这些图片：

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

-framerate 30是输入帧率，意思是每秒读 30 张图。-i frame_%04d.png是输入模式，%04d表示四位零填充的数字。这里有个容易搞混的点：-framerate和输出端的-r不是一回事。-framerate控制读图速度，-r控制输出帧率。如果两者不一致，FFmpeg 会做帧复制或丢帧。做逐帧动画时，两者设成一样最省心。

如果你的图片编号不是从 1 开始，或者位数不同，可以用-start_number指定起始编号。比如从 0 开始就是-start_number 0。

4.2 编码器与画质参数的选择逻辑

-c:v libx264指定用 H.264 编码器，这是兼容性最好的选择，几乎所有播放器和浏览器都能放。如果你追求更小的体积，可以用libx265，但兼容性会差一些，某些老设备放不了。

画质由-crf控制，全称是 Constant Rate Factor，范围 0 到 51。数值越小画质越好、文件越大，这个方向和很多人的直觉相反。经验取值：

我一般用 18 到 20 之间。做动画类内容时，因为画面里大片纯色区域多，压缩效率本来就高，CRF 18 出来的文件也不会太大。

-pix_fmt yuv420p这个参数必须加。Canvas 导出的 PNG 是 RGBA 格式，带透明通道，而 H.264 的标准像素格式是 yuv420p。如果不指定，FFmpeg 可能输出 yuv444p 之类的格式，在部分播放器上会显示成绿屏或者无法播放。这个坑非常经典，我第一次做的时候视频在本地能放，发给别人就绿了，就是这个问题。

4.3 用管道替代中间文件：省磁盘也省时间

导出 180 张 PNG 再编码，中间会产生一堆临时文件。如果视频长一点，比如 1 分钟 30 帧就是 1800 张图，磁盘占用很可观。更优雅的做法是让 Canvas 直接把每帧的像素数据通过管道喂给 FFmpeg，不落盘。

在 Node.js 环境下可以这样：

const { spawn } = require('child_process'); const ffmpeg = spawn('ffmpeg', [ '-f', 'rawvideo', '-pix_fmt', 'rgba', '-s', `${width}x${height}`, '-r', String(fps), '-i', '-', '-c:v', 'libx264', '-pix_fmt', 'yuv420p', '-crf', '18', 'output.mp4' ]); // 每画完一帧，把像素数据写进 ffmpeg 的标准输入 const imageData = ctx.getImageData(0, 0, width, height); ffmpeg.stdin.write(Buffer.from(imageData.data));

这里-f rawvideo告诉 FFmpeg 输入是原始像素流，-pix_fmt rgba说明每个像素 4 字节，-s指定分辨率，-i -表示从标准输入读取。这种方式省掉了 PNG 编码和解码两步，速度快很多，磁盘也干净。

不过它有个前提：分辨率必须固定，而且每帧的字节数要严格一致（宽 × 高 × 4）。如果中途改了画布尺寸，管道就会错位，输出全是花屏。所以用管道方案时，画布尺寸在初始化后就不要再动。

5. 那些让视频"看起来不对"的细节问题

5.1 坐标系变换：旋转和缩放的锚点问题

Canvas 的rotate和scale都是围绕原点进行的，而原点默认在左上角。这意味着如果你直接ctx.rotate(angle)然后画一个圆，圆会绕着画布左上角转，而不是绕自己转。这是模型生成代码时最高频的错误之一。

正确做法是先把原点平移到目标位置，旋转，画完再平移回来：

ctx.save(); ctx.translate(cx, cy); // 原点移到圆心 ctx.rotate(angle); // 绕新原点旋转 ctx.beginPath(); ctx.arc(0, 0, radius, 0, Math.PI * 2); // 在原点画圆 ctx.fill(); ctx.restore(); // 恢复坐标系

save和restore必须成对出现，它们保存和恢复整个绘图状态（包括变换矩阵、样式、裁剪区域）。漏掉restore的话，后续所有绘制都会带着这个变换，画面会越来越歪。我见过模型连续写好几个save却一个restore都不写的代码，跑出来的效果就是所有元素挤在角落。

5.2 帧率与运动速度的耦合

有个反直觉的现象：同样的运动代码，帧率从 30 改成 60，动画速度会变成两倍。原因是很多代码把"每帧移动多少像素"写死了，比如x += 5。帧率翻倍，每秒的帧数翻倍，位移自然翻倍。

正确做法是让位移和时间挂钩，而不是和帧数挂钩：

// 错误：速度随帧率变化 x += 5; // 正确：速度由时间决定 const speed = 150; // 像素/秒 x = startX + speed * t;

或者用增量形式x += speed * deltaTime，其中deltaTime = 1 / fps。这样无论帧率怎么变，运动速度都是恒定的。模型生成的代码里，写死每帧位移的情况很常见，尤其是做简单动画时。如果你发现改帧率后动画变快变慢，八成就是这个原因。

5.3 抗锯齿与像素对齐

Canvas 默认开启抗锯齿，画斜线和圆的时候边缘会平滑。这在大多数情况下是好事，但做像素风格或者需要锐利边缘的图形时，抗锯齿反而会让画面发虚。

另外，画 1 像素宽的直线时，如果坐标落在整数上，线会跨在两个像素之间，看起来是 2 像素宽的灰线。解决办法是把坐标偏移 0.5：

ctx.moveTo(10.5, 10.5); ctx.lineTo(100.5, 10.5);

这样线就精确落在像素中心，看起来是清晰的 1 像素。这个技巧在画网格、边框、分隔线时特别有用。模型基本不会主动加这个 0.5，需要你自己补。

5.4 导出图片的透明背景处理

Canvas 默认背景是透明的。如果你直接导出 PNG，透明区域在 FFmpeg 编码成 H.264 后会被填成黑色（因为 yuv420p 不支持透明）。如果你想要白色背景，必须在每帧开头先填充：

ctx.fillStyle = '#ffffff'; ctx.fillRect(0, 0, width, height);

这一句要放在clearRect之后、其他绘制之前。顺序错了的话，要么背景没填上，要么把之前画的内容盖掉。我一般把背景填充封装成一个drawBackground函数，每帧第一个调用，这样不会漏。

6. 性能与批量生成：当你要做的不止一个视频

6.1 渲染瓶颈通常不在 Canvas 而在导出

单帧渲染本身很快，Canvas 画几十个图形也就几毫秒。真正的瓶颈在导出环节——toDataURL或者toBlob把画布转成 PNG 是同步阻塞操作，一帧可能要几十毫秒。180 帧下来就是好几秒甚至十几秒。

优化思路有几个：

• 用toBlob替代toDataURL：toBlob是异步的，不阻塞主线程，而且直接产出二进制，省掉了 base64 编码解码的开销。
• 降低导出分辨率再放大：如果成片不需要太高分辨率，可以按 720p 渲染导出，编码时用 FFmpeg 放大到 1080p。虽然会损失一些锐度，但速度提升明显。
• 用 OffscreenCanvas：在 Worker 里渲染，不占用主线程，可以边渲染边做其他事。

我实测下来，toBlob加异步写入文件，比toDataURL快大概三到五倍。如果帧数多，这个差距非常可观。

6.2 批量生成时的参数化设计

如果你要生成一系列视频，比如不同文字、不同颜色的片头，硬编码肯定不行。正确做法是把可变部分抽成配置对象：

const config = { text: '小金鱼捏捏', primaryColor: '#ff6b6b', duration: 6, fps: 30, width: 1080, height: 1080 };

然后所有绘图函数都从config里读参数。这样换一个视频只需要改配置，代码一行不动。模型在生成这类代码时，如果你明确要求"参数化"，它通常能做得不错；但如果你不说，它默认会写死。

批量生成还有个坑是文件命名冲突。如果多个视频同时生成，输出文件名要带上唯一标识，比如时间戳或者配置的哈希值，否则会互相覆盖。我一般用output_${Date.now()}.mp4这种形式。

6.3 用 React 做参数面板的取舍

热词里出现了 React，确实有人会用 React 做一个可视化的参数调节面板，实时预览 Canvas 效果，调好了再导出。这个思路本身没问题，但要注意 React 的渲染机制和 Canvas 的命令式绘制是两套逻辑。

React 管的是 DOM 结构，Canvas 管的是像素。把两者结合时，常见做法是用useRef拿到 canvas 元素，在useEffect里做绘制，参数变化时重新绘制。关键是不要在 React 的渲染函数里直接画 Canvas，那样每次状态更新都会重画，性能很差。

const canvasRef = useRef(null); useEffect(() => { const ctx = canvasRef.current.getContext('2d'); drawScene(ctx, params); // params 变化时重画 }, [params]);

这个模式是对的。但如果你只是做一次性视频生成，其实没必要上 React——一个简单的 HTML 页面加几个 input 就够了。React 的价值在于参数多、需要复杂交互的场景，杀鸡用牛刀反而增加复杂度。

7. 我踩过的几个真实坑和排查思路

7.1 视频能播但时长不对

有一次导出的视频，画面内容是对的，但时长比预期短了一半。排查过程是这样的：先看帧数，ls frame_*.png | wc -l显示 180 张，没问题。再看 FFmpeg 的输出日志，发现它报告 "Input stream #0:0: Video: png, 90 frames"。180 张图只读了 90 帧。

问题出在文件名上。我的导出代码用了frame_${i}.png，没有零填充。文件列表排序后是frame_1, frame_10, frame_100, frame_101...，FFmpeg 按%d模式匹配时，遇到frame_10之后找不到frame_11（因为实际存在的是frame_2），就停了。改成frame_${String(i).padStart(4, '0')}.png后正常。

这个坑的教训是：任何涉及文件序列的地方，零填充都是必须的，不是可选项。

7.2 画面颜色和浏览器里看到的不一样

浏览器里预览是鲜艳的红色，导出的视频里变成了暗红。这个问题困扰了我一阵。后来查明白是色彩空间的问题：Canvas 用的是 sRGB，而 FFmpeg 编码时如果没指定色彩参数，可能按 BT.601 处理，导致颜色偏移。

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

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

bt709 是高清视频的标准色彩空间，指定之后颜色就和浏览器里一致了。这个参数模型基本不会主动加，需要你自己补。

7.3 长视频内存溢出

做 3 分钟的视频，180 帧变 5400 帧。如果一次性把所有帧的像素数据都存在内存里再统一编码，内存直接爆掉。解决办法是流式处理：画一帧、写一帧、释放一帧，内存占用始终保持在单帧级别。

用管道方案天然就是流式的，因为数据直接写进 FFmpeg 的 stdin，不累积。如果用图片序列方案，也要确保每帧导出后不保留引用，让垃圾回收能正常工作。我见过把每帧的ImageData存进数组的代码，帧数一多必崩。

7.4 排查问题的通用顺序

踩了这么多坑，我总结出一套排查顺序，遇到视频不对时按这个顺序查，基本能定位到问题：

1. 先看帧数：导出的图片数量和预期是否一致
2. 再看单帧：随便打开一张中间帧，看画面内容对不对
3. 然后看编码日志：FFmpeg 的输出会告诉你读了多少帧、用了什么参数
4. 最后看播放：换个播放器试试，排除播放器兼容性问题

这个顺序的逻辑是从源头往末端查。帧数不对是导出问题，单帧不对是绘图问题，日志异常是编码问题，只有播放器有问题才是兼容性问题。按这个顺序走，不会在错误的方向上浪费时间。

8. 关于"模型做视频"这件事的一点个人看法

用 Claude Opus 5.5 这类模型做视频，本质上是你和一个很懂代码但不懂你具体想要什么的助手合作。它的强项是把你的描述翻译成可运行的绘图和编码逻辑，弱项是对"最终看起来对不对"没有判断力——它看不到自己生成的视频。

所以真正的工作量不在写代码，而在定义清楚你要什么和验证产出对不对。分镜表、参数配置、逐帧检查，这些看起来繁琐的步骤，恰恰是保证成片质量的关键。我现在的习惯是每做完一个视频，先抽几帧出来单独看，确认构图、颜色、文字位置都没问题，再去编码。这样比编码完发现不对再回头改要省事得多。

另外，别指望一次生成就完美。模型给的代码是起点，不是终点。缓动函数要调、颜色要试、文字大小要改，这些微调是必须的。把模型当成一个能快速产出可用草稿的助手，而不是一个一键出片的黑盒，心态就对了。