朋友给我发来一段很特别的视频说这是某个叫 Opus 5.5 的AI工具“生成”的。我盯了几秒钟第一反应是不对劲——画面太干净了。没有常见视频生成模型那种隐隐约约的噪点边缘稳定线条利落几何结构严丝合缝甚至每一帧之间的过渡都带着数学上的精确。我问他这工具怎么调的他说不知道反正是AI生成的。我跑去翻了下输出日志和工程目录这才看到真相Opus 5.5 压根不是在生成视频而是在写代码然后让浏览器把成百上千帧画面一帧一帧地画出来。说白了它走的不是“神经网络直接推理画面像素”的路子而是“程序化生成 浏览器实时渲染”的路子。视频文件只是录制了浏览器绘制过程的结果真正的核心是一段可以反复修改、重新执行的代码。这篇文章我想把这件事彻底拆开。从两种视频生成路线的本质差异到浏览器逐帧绘制依赖的基础技术再到一个可以直接上手复现的最小工程以及我在实际调试中踩过的性能坑和录制坑。如果你也好奇“AI工具生成视频”背后到底是什么或者想用代码完全掌控每一帧画面这篇文章应该能给你一个相对完整的答案。1. 先搞清楚“真相”视频不是算出来的是画出来的1.1 两种“AI生成视频”的路线差异市面上绝大多数视频生成工具走的是端到端的内容生成路线。你把一段文字描述丢进去模型在内部把语义映射成视觉特征然后推理出一批连续的像素帧。这个过程本质上是在“算视频”——模型从头到尾负责所有帧的内容你几乎无法干预某一帧的像素到底怎么排布最多改改提示词。但 Opus 5.5 这类工具走的是另一条路。它接收你的需求之后先输出一段JavaScript代码代码里定义了整个视频的视觉元素、运动规则和时间轴逻辑。浏览器拿到这段代码开始解析执行在Canvas画布上按每秒几十帧的频率重复绘制。每一帧画什么取决于一个共享的时间变量。视频成品只是把这段实时绘制过程录制下来的结果。这两种路线有一个本质区别一个是“结果导向的直接生成”另一个是“过程导向的规则构建”。前者擅长轻松产出照片级、写实风格的片段但不可控后者画出的内容可能更抽象、更几何化但每一帧的逻辑都在你的掌控之中改一个参数就相当于重画一个世界。1.2 为什么程序化渲染路线容易被当成“AI视频”我猜很多人第一次看到 Opus 5.5 的作品都会和我一样先入为主地认为它是传统视频生成模型。原因很好理解用户界面里输入的是自然语言描述输出的是一个视频文件表面上和主流AI视频工具没有区别。至于内部到底是扩散模型逐帧去噪还是浏览器执行循环绘制界面层根本看不出来。再加上这类工具输出的画面往往有很强的设计感比如流动的粒子、渐变的几何体、持续变化的图案观感上很“未来”很“AI”。但实际上这种视觉风格恰恰是程序化生成最擅长的事——它不需要理解真实世界的物理规律只需要用数学函数描述运动即可。一个低频正弦波就能让整个画面产生呼吸感几条贝塞尔曲线就能演化出复杂的路径轨迹。这些效果写起来不难跑起来也不贵但视觉效果非常唬人。我后来把工程目录里的代码文件打开发现整个视频的逻辑从一开始就是高度结构化的。它生成了脚本脚本创建画布设置帧循环注册动画函数然后通过媒体录制接口把画面导出为视频文件。整个过程里“AI生成”的部分只发生在最前端的需求理解与代码生成阶段后面的视频合成完全是典型的浏览器前端工程。这就是标题里“真相”二字的由来——它不生成视频它生成的是画出视频的代码。1.3 为什么有人愿意选择这条路线传统视频生成模型有一个很麻烦的问题不可重复性。同一个提示词跑两次得到的内容大概率不一样你想微调某一帧的构图几乎不可能。而代码驱动的逐帧绘制完全绕开了这个问题。首先它非常确定。同一段代码不管运行多少次只要时间轴设置一致得到的视频帧序列就是一致的不存在“提示词相同但结果不同”的情况。其次它支持精细控制。你可以只让某个粒子在某一秒改变方向可以在第三秒突然切换配色方案——这些都是对代码的修改而不是对成千上万帧像素的推测。最后它可以嵌入更大的系统。因为输出本身是代码可以被动态拼接、批量执行、参数化调用这是传统生成模型做不到的。这个特性让它在数据可视化、动态图形设计、自动化内容生产这些领域特别有优势。我见过有人用它批量生成科普动画里用于演示数学原理的抽象视频也见过有人把这类代码封装成接口让用户在前端页面上调参数、点按钮实时预览并导出不同的动态效果。这些场景的共同点是内容必须精确、可变、可控。而传统的AI视频生成在这些方面目前还很难做到。2. 代码驱动逐帧绘制的三个底层支柱2.1 Canvas 是画布requestAnimationFrame 是节拍器想要让浏览器逐帧画出视频最核心的两个底层能力是 Canvas 和 requestAnimationFrame。Canvas 是一块可编程绘制的画布你可以在上面画出矩形、圆弧、路径、图像也可以直接操作像素缓冲区。它的本质是一个位图绘制环境每一帧画面最终都会被绘制到这个位图之上。requestAnimationFrame 则是浏览器的帧同步机制。它告诉浏览器“在下次屏幕刷新之前请执行我传给你的回调函数。”浏览器会尽量把回调的执行频率和显示器的刷新率对齐通常是 60 次每秒。这个机制比 setTimeout 或 setInterval 精准得多因为它由浏览器统一调度不会在后台标签页里白白消耗资源也不会因为事件循环阻塞而跳帧。把这两样东西放在一起就构成了逐帧视频的完整循环浏览器每次刷新屏幕前调用一次绘制函数绘制函数先清空上一次的画面再根据当前的时间或帧序号计算位置、颜色等状态最后把整个画面画到 Canvas 上。如此反复视觉上就形成了连续的动画。每一帧单独拿出来都是静止图片但它们的连续播放就是视频。我第一次自己写这个循环时最大的认知转变是画面上的一切“动”本质上都不存在。没有东西在真正移动只是每一帧画的位置和上一帧略有不同而已。视频的流畅感来自帧与帧之间的微小差异而帧率决定了这些差异在时间上的密度。2.2 从绘制循环到视频文件录制导出是关键一跳只是让浏览器实时播放动画离“生成一个视频文件”还差得远。要得到一个可分发、可上传、可剪辑的 mp4 或 webm 文件必须把浏览器绘制的过程录制下来。这一步依赖的是 MediaRecorder 接口以及 Canvas 的 captureStream 能力。captureStream 的作用是给 Canvas 画布创建一个实时媒体流这个流里的每一帧都对应画布上刚刚绘制的内容。MediaRecorder 接收这个流按照你指定的编码格式和时间间隔把流里的画面编码为一个视频容器文件。录制结束之后你会得到一个 Blob 对象可以直接通过 URL.createObjectURL 生成下载链接也可以把它转成 ArrayBuffer 做进一步处理。这里有一个很容易被忽略的细节MediaRecorder 录制的是流流的帧率由 captureStream 的参数决定而不是由你的绘制循环决定的。如果你的绘制循环跑 60fps但 captureStream 设置的是 30fps那么录制结果就是 30fps每两帧绘制画面里只有一帧会被捕获。反过来如果你的绘制能力跟不上实际帧率只有 20fps但 captureStream 要求 60fps录制工具也会尽量把录制时长拉长以匹配请求的帧率。这就可能导致视频画面时长和实际过程时长不一致后期还需要调整时间轴。所以录制参数与绘制帧率保持一致是最省心的做法。2.3 时间驱动还是帧驱动决定了视频的稳定性写逐帧动画时最大的分水岭是动画状态的管理方式。新手通常用帧驱动每绘制一帧就给某个变量加 1然后根据这个变量计算画面内容。这套逻辑简单直观但有个致命缺陷一旦浏览器因为性能波动或页面卡顿跳过了某些帧动画的时间感就会错乱。更好的方案是时间驱动给每一帧传入一个精确的时间戳所有动画状态都由这个时间戳计算得出。比如“第 0.5 秒时粒子出现在屏幕左上角第 2.3 秒时运动到中心”这些都是时间的函数和帧序号无关。好处在于即使某一帧延迟了几十毫秒它依然会绘制在正确的时间点上就算录制过程中跳了几帧视频的整体节奏也不会漂移。我在实践里基本只用时间驱动。尤其是当视频要录制导出时时间一致性直接决定成品质量。如果用帧驱动一旦主线程繁忙或浏览器休眠整个动画的速度就会忽快忽慢对后期合成来说简直是灾难。而时间驱动的代码写起来也不复杂只需要在绘制函数的开头读取 performance.now() 或时间戳参数再用它做各种计算就行。3. 动手复现一个最小逐帧视频工程3.1 搭建场景与绘制函数理论说再多都不如直接跑一个工程。我来带你从零搭一个最简单的逐帧视频生成器效果是暗色背景上有若干光点沿着正弦曲线运动光点颜色随时间平滑变化。整个工程只有一个 HTML 文件不需要任何依赖库用浏览器打开就能看到动画。先看 HTML 结构!DOCTYPE html html langzh-CN head meta charsetUTF-8 title逐帧动画录制示例/title style body { margin: 0; background: #111; display: flex; align-items: center; justify-content: center; height: 100vh; } canvas { background: #0a0a0a; border-radius: 8px; } /style /head body canvas idscene width1280 height720/canvas script // 核心逻辑写在这里 /script /body /html画布宽度 1280高度 720这是 16:9 的标准视频尺寸。如果不改动视频比例录制出来的文件在大多数播放器里都能正常显示不会出现上下黑边的问题。接下来是绘制的核心逻辑。我定义了一个粒子数组每个粒子有初始相位、速度系数和偏移量。在每一帧里我根据当前时间计算出每个粒子的 x、y 坐标以及它的颜色值然后把它们画出来const canvas document.getElementById(scene); const ctx canvas.getContext(2d); const W canvas.width; const H canvas.height; // 粒子总数越多画面越密但对性能要求也越高 const PARTICLE_COUNT 120; // 每个粒子的初始参数 const particles []; for (let i 0; i PARTICLE_COUNT; i) { particles.push({ phase: Math.random() * Math.PI * 2, // 初始相位避免所有粒子同步运动 speed: 0.6 Math.random() * 1.8, // 运动速度系数 offsetY: Math.random() * H, // 垂直方向的基础偏移 size: 1.5 Math.random() * 3, // 光点半径 }); } // 创建离屏 canvas用来预绘制渐变背景避免每帧重复计算 const bgCanvas document.createElement(canvas); bgCanvas.width W; bgCanvas.height H; const bgCtx bgCanvas.getContext(2d); const gradient bgCtx.createRadialGradient(W / 2, H / 2, 80, W / 2, H / 2, W); gradient.addColorStop(0, #10222a); gradient.addColorStop(1, #050a0e); bgCtx.fillStyle gradient; bgCtx.fillRect(0, 0, W, H); function drawFrame(t) { // t 是从录制开始到当前帧的毫秒数 // 先画背景 ctx.drawImage(bgCanvas, 0, 0); // 再画粒子 particles.forEach((p, index) { const progress (t / 1000) * p.speed p.phase; const x W * (0.5 0.4 * Math.sin(progress)); const y p.offsetY 40 * Math.sin(progress * 0.8); // 颜色随时间变化用 HSL 模型最方便 const hue (index * 360 / PARTICLE_COUNT t * 0.02) % 360; ctx.beginPath(); ctx.arc(x, y, p.size, 0, Math.PI * 2); ctx.fillStyle hsl(${hue}, 80%, 70%); ctx.fill(); }); } let startTime null; function loop(now) { if (startTime null) { startTime now; } const elapsed now - startTime; drawFrame(elapsed); requestAnimationFrame(loop); } requestAnimationFrame(loop);这里有几个可以立刻上手玩起来的调参点。第一个是粒子数量 PARTICLE_COUNT数量越多画面越饱满但超过一定阈值后绘制耗时就会上升可能导致帧率掉下 60fps。第二个是 width 和 height分辨率越高单帧绘制越慢录制约 10 秒的 4K 视频性能开销比 1080p 高出数倍。第三个是颜色公式里的时间系数 0.02把它调大颜色变化就会更剧烈画面更花哨但也可能显得刺眼。3.2 用 MediaRecorder 把绘制过程录成视频文件动画已经可以跑了现在把它变成真正的视频文件。最简单的录制方式是给 Canvas 创建媒体流用 MediaRecorder 接收并保存。我通常把录制逻辑和绘制逻辑分开避免绘制的循环逻辑被录制状态干扰。继续在脚本里追加代码// 录制参数 const fps 60; const durationSec 10; // 录制时长 const stream canvas.captureStream(fps); const mediaRecorder new MediaRecorder(stream, { mimeType: video/webm;codecsvp9, videoBitsPerSecond: 8_000_000, }); const chunks []; mediaRecorder.ondataavailable (e) { if (e.data e.data.size 0) { chunks.push(e.data); } }; mediaRecorder.onstop () { const blob new Blob(chunks, { type: video/webm }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download opus-demo-${Date.now()}.webm; a.click(); URL.revokeObjectURL(url); }; // 点击页面任意位置开始录制录制结束自动下载 document.addEventListener(click, () { mediaRecorder.start(); setTimeout(() { mediaRecorder.stop(); }, durationSec * 1000); }, { once: true });注意mimeType 我用了 webm 和 vp9 编码。为什么不用 mp4因为浏览器对 mp4 录制的支持目前仍然不如 webm 稳定尤其是在录制 Canvas 流时mp4 容器对编码器的要求更高。如果录制过程中浏览器发现编码器不支持MediaRecorder 会直接进入错误状态。如果想得到 mp4我的习惯是先用 webm 录制再用 FFmpeg 之类的工具转封装。因为逐帧绘制阶段webm 是浏览器中最稳妥的格式而转码可以放到录制结束之后不依赖浏览器环境。录制时长是怎么算的durationSec 乘以 fps就是期望的帧数。比如 10 秒乘以 60fps就是 600 帧。每次绘制循环会尝试以 60fps 的频率运行但如果某些帧因为性能原因没有及时绘制captureStream 只能捕获它实际收到的帧视频时长可能比预期短也可能出现重复帧来补足帧数。对程序化动画来说只要坚持时间驱动而不是帧驱动即使偶尔丢帧导出视频的运动节奏依然是对的。3.3 让画面更加复杂加入交互参数与批量输出录制一次动画只是起点。真正把代码驱动视频变得强大的是“参数化”和“批量生成”。我在做实际项目时很少只生成一段视频而是会写一个参数列表循环跑出几十个不同版本再从中挑效果最好的。这个思路在 Opus 5.5 这类工具里体现得很明显它写出的代码本质上是模板用户更换关键词它就在模板里换参数。给上面那个工程加上参数化也很容易。比如把粒子的运动速度、数量、颜色变化速度都从顶部变量里抽出来组成一个配置对象。每次生成视频前随机或按规则改变配置对象然后重新启动录制。代码的骨架不变变化的只有参数。这样你很快就能发现同一段逻辑可以衍生出完全不同的视觉风格。我还试过在录制过程中动态改变参数让画面从第一秒到第十秒逐渐从稀疏变得密集或让颜色从冷色调渐变为暖色调。这种随时间渐变的逻辑在传统视频生成模型里很难用一句提示词控制得精准但在代码驱动渲染里只是一个关于时间的 if 判断或插值函数。4. 性能瓶颈与常见问题的排查实录4.1 帧率上不去时先查这三处逐帧绘制这个方案最大的敌人是性能。你想象一下一秒要画 60 帧每一帧可能要画上百个粒子、几十个图形还要做颜色计算和坐标转换。一帧处理时间超过 16.7 毫秒帧率就会掉到 60fps 以下。我实测下来最常见的性能瓶颈有三个。第一是每帧重复创建对象。JS 里在循环内部用数组字面量、对象字面量或模板字符串创建新对象都会触发内存分配和垃圾回收。垃圾回收一旦在主线程上发生就会造成明显的卡顿。所以绘制循环里尽量复用对象比如把颜色值预先算好放进数组坐标也尽量用简单变量而不是临时对象。第二是不小心使用了引起整页布局的 API。Canvas 本身是位图绘制不受 CSS 布局影响但如果你在绘制循环里读取某些需要计算布局的属性比如 offsetWidth、clientHeight浏览器会强制同步执行布局计算从而打断绘制流水线。这是非常隐蔽的卡顿来源我只遇到过一次排查了很久才发现是循环里读了一次画布的父元素宽度。第三是绘制指令过多。Canvas 的每次 beginPath、arc、fill 都是有开销的绘制指令数量越多单帧耗时越长。优化的思路是把固定不变的内容预绘制到离屏 Canvas 上每帧只需要画动态部分。我的背景渐变就是这样做预绘制的否则每一帧都要重新计算一次放射性渐变性能至少下降 20%。4.2 录制黑屏、时长偏移与画质损失的坑录制黑屏是我见过最频繁的问题。有时候画面在浏览器里明明正常播放但录出来的视频却全是黑屏或只有背景没有粒子。排查方向通常是 captureStream 和 MediaRecorder 之间的兼容性问题。某些浏览器版本对 Canvas 流的捕获存在已知限制如果你在录制前没有让画布至少绘制过一帧流里可能没有有效画面录制出来的自然就是黑的。还一种可能是你调用了 captureStream 时传入的帧率高于浏览器实际支持的帧率。某些浏览器在帧率过高时会自动丢帧导致黑屏或者花屏。我现在的做法是先调用一次绘制函数确保画布上有内容再启动 recorder然后把 captureStream 的帧率和绘制目标帧率都设为一致。时长偏移这个问题也常见。录制 10 秒的视频结果文件播放出来只有 8 秒或者长度超出 10 秒。原因通常在于绘制帧率和录制流帧率不一致或者浏览器后台节流。解决思路还是时间驱动绘制函数里不要依赖自增计数而是依赖时间戳。如果花了 10 秒录制但实际捕获的帧数少于 600 帧MediaRecorder 有时会用重复帧来补足画面看起来停顿但总时长不会出错。画质损失则和编码参数有关。videoBitsPerSecond 设置得太低画面会出现明显的块状压缩噪声。逐帧绘制生成的画面通常以几何图形和渐变为主高频细节不多但过度压缩依然会让边缘变得模糊。我的经验是1080p 视频建议至少给 8Mbps4K 视频建议给 20Mbps 以上否则粒子边缘会出现大面积马赛克。4.3 一个隐藏的浏览器限制后台标签页节流浏览器为了节省资源会自动降低后台标签页的定时器频率。requestAnimationFrame 在页面不可见时也会被挂起这意味着如果你切到别的窗口录制进程瞬间就会断掉画面供应。这个问题在录制长视频时特别致命。我有一次录 3 分钟的数据可视化视频录到一半切去查资料回来发现视频后半段完全静止。原因就是标签页进入后台后requestAnimationFrame 不再触发但 MediaRecorder 还在等待画面数据最后得到的视频时长虽然接近但内容缺失。解决办法有两个。第一是录制动画期间保持标签页在前台并把电脑设置为不熄屏。第二种是用 OffscreenCanvas 配合 Web Worker 在后台线程里执行绘制可以绕过标签页节流但实现复杂度明显更高而且需要确认目标浏览器对 OffscreenCanvas 的支持情况。对第一次尝试的人来说直接保证前台运行是最省力的方案。5. 什么场景适合让浏览器逐帧画视频5.1 值得用的场景代码驱动的逐帧渲染有一个明确的优势区间当内容需要精确运动、确定结果、批量生产时它完胜传统视频生成模型。我在实际项目里最常用它做三类内容。第一类是数据可视化动画。数据本身是结构化的画面中的位置、大小、颜色都要对应具体的数值。用代码驱动渲染可以直接把数据读进来让数值驱动图形整个动画就是一个直观的数据图表。传统视频生成模型很难做到“某个数字精确决定柱状图高度”这种需求。第二类是动态图形设计。从品牌动画、标题动画到抽象的视觉实验这类内容不追求写实追求形式感和节奏感。程序化渲染天然适合生成几何图形、渐变、粒子和循环动画。而且因为是参数化的可以快速尝试不同配色、不同运动曲线、不同排版改几行代码就能生成一个新版本。第三类是可交互的预览工具。因为整个动画本质上是网页应用用户可以实时调整参数并立即看到效果。这在广告投放、动态海报、直播背景之类的场景里特别实用。用户需要一个能即时反馈的可视化界面浏览器逐帧绘制是目前最方便的载体。5.2 不如交给传统视频生成模型的场景不是说所有视频都适合代码驱动渲染。如果你需要有真实物理规则的人脸表演、复杂的街景、动物动作、真实的镜头光晕代码驱动渲染的工作量会变得非常巨大。你可以写出很漂亮的正弦波粒子但你很难用 Canvas 写出一段自然行走的人。这种时候传统视频生成模型仍然是更合理的起点。另一个不如传统模型的场景是快速创意探索。如果脑子里只有一个模糊的画面概念比如“一座漂浮在云端的城市”用代码驱动渲染要定义光线、建筑、云层、摄像机运动等一大堆规则效率很低。但传统视频生成模型只需要一句话就能给你一个可看的初步效果。所以在创作流程里这两种技术不是谁替代谁而是谁出现在哪个阶段。还有一些场景本质上就不该用代码驱动渲染比如超短视频需要匹配真实角色形象或者需要声音和画面的物理同步。浏览器逐帧绘制虽然也可以做音频但要精确到帧级别非常麻烦远不如专业视频编辑工具顺手。5.3 后续扩展方向从单视频到动态内容系统代码驱动渲染最有想象力的地方是它把视频从一个静态文件变成了一个动态系统。视频能做的事情代码都能做。代码可以接收用户输入、读取实时接口数据、根据条件分支输出不同画面。这意味着同样的视频还能变成可交互的网页变成一个根据数据实时变化的看板变成用户调整参数即可改变输出的工具。我有一个明显的感受是这类工具未来会越来越多地嵌入到内容生产工作流里而不是作为一个独立的视频生成器存在。它会更像一个“可视化代码生成器”你描述一个动态效果它生成一个模块这个模块可以被你的代码继续调用。从这个角度看花时间理解浏览器逐帧绘制原理比只会使用某个视频生成产品要值得多。6. 一轮完整调试后的个人心得如果你打算自己去写一个逐帧绘制视频工程我建议从很小的目标开始。不要一上来就想生成一部完整的短片先把一个粒子在一个黑底 Canvas 上移动给跑通。然后加上录制导出文件确认视频能正常播放。最后再逐渐加入更多粒子、渐变、色彩变化和参数控制。每一个阶段都先确保它能稳定运行再扩展功能。一个让我受益很大的习惯是永远保留一份可重复复现的配置记录。因为代码驱动视频的产出往往很容易让人满意但你会很快忘记某个好看效果的参数组合。我现在会在录制时自动把参数 JSON 一起输出到控制台或者嵌入到视频文件名里。这样每次生成的作品都可以追溯到它的源头配置想做系列化内容时非常有用。最后想说看到“生成视频”这个词不要下意识认为一定是扩散模型。视频的本质是连续图像序列只要你有一个确定的过程能一帧一帧画出图像你就拥有了一条视频生成链路。至于这个过程是神经网络推理还是 JavaScript 循环加 Canvas都不重要。重要的是你能理解它、控制它并且知道什么时候该选哪条路。