1. 从标题说起一个视频生成项目的技术轮廓“Claude Opus 5.5 是怎么做出视频的”——这个标题第一次看到的时候我脑子里冒出来的第一个念头不是“AI 生成视频”而是“它到底是用什么方式把一帧一帧画面拼出来的”。因为如果你真的动手做过视频相关的项目就会知道“做出视频”这四个字背后藏着完全不同的技术路径有的是用现成的视频生成模型直接输出 mp4有的是用代码一帧一帧渲染再编码还有的是在浏览器里用 Canvas 实时绘制再录制。结合热搜词里反复出现的Claude Opus、视频、程序、JS、Canvas这几个关键词我基本可以判断这个项目讨论的核心不是“模型内部怎么生成视频”而是围绕 Claude Opus 这个模型能力用程序化的方式把内容变成可视化的视频。换句话说重点在“程序”和“Canvas”而不是在“模型权重”。这也是我写这篇博文的出发点。我会把这套东西拆成几个层面来讲整体设计思路、核心细节、实操过程、常见问题排查。适合谁看如果你是会一点 JavaScript、想用代码做视频的开发者或者你正在研究“AI 输出内容如何变成视频”这个方向那这篇内容应该能给你不少可以直接抄作业的东西。如果你是完全的新手也没关系我会尽量用生活化的类比把原理讲清楚。先说结论性的判断这类项目通常不会真的让模型去“渲染视频”而是让模型负责生成结构化的内容或绘图指令然后由 JavaScript 和 Canvas 负责把这些指令变成画面最后再通过录制或编码合成视频。这个分工非常关键理解了它后面所有的技术选择就都顺了。2. 整体设计与思路拆解2.1 为什么是 Canvas 而不是直接调视频生成接口很多人第一反应是既然要“做出视频”为什么不直接调用一个视频生成的能力输入一段文字输出一个 mp4这个思路听起来最省事但实际做项目的时候问题一大堆。首先是可控性。直接生成的视频你很难精确控制每一帧里某个元素的位置、颜色、出现时机。而用 Canvas 绘制每一帧画什么、画在哪、什么时候画全在你手里。这就像做饭一个是点外卖一个是自己掌勺外卖快但你不知道里面放了什么自己炒虽然麻烦但每一步都可控。其次是成本与延迟。视频生成类的能力通常计算量大、响应慢做交互式或者批量化的场景会很吃力。而 Canvas 是浏览器原生能力绘制一帧的开销极小配合requestAnimationFrame可以轻松跑到 60fps。第三是与 JS 生态的契合。热搜词里出现了大量 JS 相关的内容比如js函数、js判断字符串是否包含、canvas绘图、canvas 2d vue这说明整个项目的技术栈是围绕 JavaScript 展开的。Canvas 天然就是 JS 的好搭档不需要额外的重型依赖。所以这里的核心思路可以概括成一句话让 Claude Opus 负责“想”让 Canvas 负责“画”让 JS 负责“串”。模型输出的是结构化的绘图描述或者代码片段程序解析后驱动 Canvas 渲染最终合成视频。2.2 内容生成与画面渲染的分层设计一个清晰的视频生成项目通常会分成三层我在实际做的时候也是这么分的内容层由 Claude Opus 这类模型生成。它负责产出脚本、分镜描述、每帧的绘图指令甚至直接生成可执行的 Canvas 代码。渲染层由 JavaScript Canvas 承担。它接收内容层的输出解析成具体的绘制操作比如画矩形、画文字、画路径。合成层把渲染出来的帧序列编码成视频文件。浏览器里常用的是MediaRecorder配合canvas.captureStream()服务端则可能用 ffmpeg。这样分层的好处是每一层都可以独立替换和调试。比如你觉得模型生成的画面不好看只需要改内容层的提示词觉得渲染太慢只需要优化渲染层觉得视频格式不对只需要调整合成层。如果全揉在一起改一个地方就牵一发动全身。我特别想强调一点不要一上来就追求“全自动”。很多新手想的是“我输入一句话它自动出一个完整视频”。实际做的时候这种全自动链路非常脆弱任何一环出问题都很难定位。更稳的做法是先手动把某一层跑通比如先手动写死一段绘图指令确认 Canvas 能画出东西再逐步接入模型生成。2.3 技术选型背后的取舍逻辑在具体技术选型上有几个关键决策点值得展开说。第一Canvas 2D 还是 WebGL热搜词里出现了canvas 2d vue和canvas绘图引擎。如果你的视频内容是 2D 图形、文字动画、图表这类Canvas 2D 完全够用API 简单上手快。如果要做 3D 场景或者大量粒子效果那才需要考虑 WebGL。对于大多数“用代码做视频”的场景2D 是性价比最高的选择。第二前端渲染还是服务端渲染前端渲染的好处是所见即所得调试方便用户能实时看到画面。服务端渲染的好处是可以批量、可以跑在无头浏览器里、不依赖用户设备性能。我的建议是开发阶段用前端生产环境看需求。如果只是生成少量视频前端录制完全够如果要批量生成成百上千条那就上服务端。第三帧率怎么定这是个容易被忽略但很重要的参数。常见的视频帧率是 24fps、30fps、60fps。帧率越高越流畅但渲染和编码的压力也越大。对于文字动画、图表这类内容30fps 已经很顺滑了对于快速运动的画面才需要 60fps。我一般默认用 30fps兼顾流畅度和性能。3. 核心细节解析与实操要点3.1 让模型输出“可执行”的绘图指令这是整个项目里最考验设计的一环。模型再聪明如果输出的东西程序解析不了那也是白搭。所以关键在于约定好输出格式。我试过几种方案最后觉得最稳的是让模型输出JSON 格式的绘图指令数组。比如{ width: 1280, height: 720, fps: 30, frames: [ { duration: 1.0, elements: [ { type: rect, x: 100, y: 100, w: 200, h: 100, fill: #3498db }, { type: text, x: 150, y: 160, content: Hello, size: 32, color: #fff } ] } ] }这种结构的好处是程序解析起来毫无歧义每个元素类型对应一个绘制函数duration控制这一帧持续多久。模型只需要按这个 schema 填内容就行。为什么不直接让模型输出 Canvas 代码因为代码的自由度太高模型可能写出各种奇怪的写法甚至写出有 bug 的代码调试成本很高。而 JSON 是受限的、可校验的程序端可以做好防御。提示在提示词里一定要给出完整的 schema 示例并且明确告诉模型“只输出 JSON不要输出任何解释文字”。否则模型很容易在 JSON 前后加一堆废话导致解析失败。3.2 Canvas 绘制的性能优化要点Canvas 绘制本身不难难的是画得快、画得稳。我在实际项目里踩过不少性能的坑这里挑几个最关键的讲。第一避免每帧都重新创建对象。比如渐变对象、路径对象如果每帧都new一次垃圾回收压力会很大。正确的做法是能复用就复用把不变的东西缓存起来。第二文字渲染是性能大户。尤其是大段文字或者频繁变化的文字fillText的开销比画矩形大得多。如果文字内容不变可以考虑先画到离屏 Canvas 上再drawImage贴过来。第三合理使用离屏 Canvas。热搜词里有图片转canvas这其实就是离屏 Canvas 的典型用法。把复杂的、静态的部分预先渲染到离屏 Canvas主循环里只做合成能大幅提升帧率。第四注意clearRect的时机。每一帧开始前要清空画布但清空整个画布也有开销。如果画面只有局部变化可以考虑只清空变化区域。不过这个优化要谨慎容易出残影问题。3.3 帧序列到视频的合成细节渲染出来的是一帧帧画面怎么变成视频浏览器里最常用的方案是MediaRecorderconst stream canvas.captureStream(30); const recorder new MediaRecorder(stream, { mimeType: video/webm }); const chunks []; recorder.ondataavailable (e) chunks.push(e.data); recorder.onstop () { const blob new Blob(chunks, { type: video/webm }); // 下载或上传 blob }; recorder.start(); // 开始逐帧渲染...这里有几个坑要注意。第一captureStream的参数是帧率要和你的渲染帧率一致否则会出现丢帧或重复帧。第二MediaRecorder的编码是实时的也就是说你渲染多久录制就多久。如果渲染一帧要 100ms那录制出来的视频时间轴就会和预期不符。解决办法是用固定时间步长驱动渲染而不是依赖真实时间。第三格式兼容性。video/webm在 Chrome 上没问题但有些场景需要 mp4。这时候要么在服务端用 ffmpeg 转码要么用支持 mp4 编码的方案。热搜词里出现了hevc 视频扩展说明编码格式确实是个绕不开的话题。注意如果你要做的是“精确控制每一帧时长”的视频建议不要用实时录制而是先把每一帧导出成图片再用 ffmpeg 合成。这样时间轴完全可控画质也更稳定。4. 实操过程与核心环节实现4.1 环境准备与项目骨架搭建先把项目骨架搭起来。我用的是最朴素的方案不引入重型框架方便你理解每一部分在干什么。mkdir canvas-video-demo cd canvas-video-demo npm init -y npm install express目录结构大概是这样canvas-video-demo/ ├── public/ │ ├── index.html │ ├── renderer.js │ └── recorder.js ├── server.js └── package.jsonindex.html里放一个 Canvas 元素和一个控制按钮canvas idstage width1280 height720/canvas button idstart开始生成/buttonrenderer.js负责解析绘图指令并渲染recorder.js负责录制。这个结构简单到不能再简单但足够跑通整个链路。4.2 绘图指令解析器的实现解析器的核心就是一个switch根据元素类型调用对应的绘制函数。我把它写成一个类方便管理状态class Renderer { constructor(canvas) { this.ctx canvas.getContext(2d); this.width canvas.width; this.height canvas.height; } clear() { this.ctx.clearRect(0, 0, this.width, this.height); } drawElement(el) { const ctx this.ctx; switch (el.type) { case rect: ctx.fillStyle el.fill; ctx.fillRect(el.x, el.y, el.w, el.h); break; case text: ctx.fillStyle el.color; ctx.font ${el.size}px sans-serif; ctx.fillText(el.content, el.x, el.y); break; case circle: ctx.beginPath(); ctx.arc(el.x, el.y, el.r, 0, Math.PI * 2); ctx.fillStyle el.fill; ctx.fill(); break; default: console.warn(未知元素类型:, el.type); } } drawFrame(frame) { this.clear(); frame.elements.forEach((el) this.drawElement(el)); } }这段代码看起来平平无奇但它是整个渲染层的地基。关键设计点是drawElement用switch分发这样以后要加新元素类型只需要加一个case不用改其他逻辑。4.3 用固定时间步长驱动帧渲染前面提到实时录制的时间轴问题解决办法是用固定时间步长驱动。具体做法是不管真实时间过了多久每一帧都按1/fps秒的节奏推进。async function renderSequence(renderer, frames, fps) { const frameDuration 1000 / fps; for (const frame of frames) { const repeat Math.round((frame.duration * 1000) / frameDuration); for (let i 0; i repeat; i) { renderer.drawFrame(frame); await new Promise((r) setTimeout(r, frameDuration)); } } }这里的逻辑是一帧画面如果持续 1 秒而 fps 是 30那这一帧就要重复画 30 次。这样录制出来的视频时间轴就和预期完全一致。提示setTimeout的精度其实不高实际间隔可能比frameDuration略长。如果对时间精度要求高可以用requestAnimationFrame配合时间戳累加的方式但逻辑会复杂一些。对于大多数场景setTimeout够用了。4.4 录制与导出完整流程把渲染和录制串起来async function generateVideo() { const canvas document.getElementById(stage); const renderer new Renderer(canvas); const frames await fetchFramesFromModel(); // 从模型获取绘图指令 const stream canvas.captureStream(30); const recorder new MediaRecorder(stream, { mimeType: video/webm }); const chunks []; recorder.ondataavailable (e) chunks.push(e.data); recorder.start(); await renderSequence(renderer, frames, 30); recorder.stop(); recorder.onstop () { const blob new Blob(chunks, { type: video/webm }); const url URL.createObjectURL(blob); const a document.createElement(a); a.href url; a.download output.webm; a.click(); }; }整个流程跑下来你会得到一个 webm 文件。如果浏览器支持也可以直接播放预览。这套流程我实测下来很稳只要绘图指令没问题出来的视频基本符合预期。4.5 从模型获取绘图指令的提示词设计这一步是内容层的核心。我用的提示词大概长这样你是一个视频分镜生成器。请根据以下主题生成一段视频的绘图指令。 主题{用户输入} 输出要求 1. 只输出 JSON不要输出任何解释文字。 2. JSON 结构必须符合以下 schema{schema} 3. 画面尺寸 1280x720帧率 30。 4. 每个 frame 的 duration 单位为秒建议在 0.5 到 2 之间。 5. 元素类型只允许使用 rect、text、circle。 现在开始生成。这里的关键是把约束写死。模型很聪明但也很“自由”你不约束它它就会给你加各种花里胡哨的东西。约束越明确输出越稳定。5. 常见问题与排查技巧实录5.1 模型输出解析失败怎么办这是最常见的问题。模型有时候会在 JSON 前后加json这样的代码块标记有时候会加一句“好的以下是生成的指令”。解决办法有两个第一在提示词里反复强调“只输出 JSON”并且给出反例。第二在程序端做容错用正则把 JSON 部分抠出来function extractJSON(text) { const match text.match(/\{[\s\S]*\}/); if (!match) throw new Error(未找到 JSON); return JSON.parse(match[0]); }这个正则的意思是从第一个{开始一直匹配到最后一个}。对于大多数情况都能work。如果模型输出的 JSON 本身就有语法错误那就只能重试或者让模型修复。5.2 视频时间轴和预期不符前面讲过这个问题多半是实时录制导致的。排查思路是检查captureStream的帧率是否和渲染帧率一致。检查渲染循环是否用了固定时间步长。检查MediaRecorder是否在渲染开始前就start了。如果这些都对了还是不对那可能是浏览器性能问题导致丢帧。这时候可以考虑降低分辨率或者帧率或者改用“导出图片序列 ffmpeg 合成”的方案。5.3 Canvas 画面模糊或锯齿严重这个问题通常和设备像素比有关。在高分屏上Canvas 的物理像素和 CSS 像素不一致导致画面模糊。解决办法是const dpr window.devicePixelRatio || 1; canvas.width 1280 * dpr; canvas.height 720 * dpr; canvas.style.width 1280px; canvas.style.height 720px; ctx.scale(dpr, dpr);这样绘制出来的画面在高分屏上就清晰了。不过要注意录制的时候captureStream抓的是物理像素所以导出视频的分辨率会变成1280 * dpr如果不需要这么高可以适当调整。5.4 常见问题速查表问题现象可能原因排查方向模型输出解析失败输出含多余文字或代码块标记检查提示词约束加正则容错视频时间轴不对实时录制导致时间漂移改用固定时间步长或图片序列方案画面模糊未处理设备像素比设置 canvas 物理尺寸和 scale录制无数据MediaRecorder 未正确启动检查 start 时机和 mimeType 支持帧率低卡顿每帧绘制开销过大用离屏 Canvas 缓存静态内容文字显示异常字体未加载完成用document.fonts.ready等待字体提示这张表是我在实际项目里一点点攒出来的建议你遇到问题时先对照排查能省不少时间。5.5 几个容易被忽略的实操心得第一先跑通最小闭环。不要一上来就接模型先用写死的 JSON 跑通“渲染 录制 导出”这条链路。确认没问题了再把模型接进来。这样出问题时你能快速定位是哪一层的锅。第二给渲染加日志。每一帧渲染的时候打印一下当前帧索引和元素数量出问题时一眼就能看出是渲染卡住了还是数据有问题。第三视频导出后一定要人工看一遍。自动化测试能验证流程跑通但画面好不好看、时间轴顺不顺还是得人眼判断。我踩过好几次“程序说成功但视频是黑屏”的坑。第四注意内存占用。如果视频很长帧数据全存在内存里可能会爆。可以考虑边渲染边录制或者分批处理。6. 这套方案还能怎么扩展跑通基础链路之后能扩展的方向其实很多。比如把 Canvas 2D 换成 WebGL就能做 3D 场景把静态绘图指令换成带缓动函数的动画指令画面会更生动把前端录制换成服务端无头浏览器渲染就能批量生成。热搜词里出现的canvas绘图引擎、canvas 2d vue这些其实都指向同一个方向把渲染层做得更工程化。你可以封装一个绘图引擎把常用的动画、转场、文字特效都做成可复用的模块这样以后做新视频就只需要组合模块不用每次从头写。另外图片转canvas这个点也很实用。你可以把用户上传的图片先画到 Canvas 上再在上面叠加文字和图形做出类似“图片视频”的效果。这个在营销物料生成场景里很常见。我个人在实际操作中的体会是这套方案的价值不在于“做出视频”本身而在于它把视频生成拆成了可控的、可调试的、可复用的模块。你不需要依赖某个黑盒能力每一帧画面怎么来的你都清清楚楚。这种掌控感是直接调接口生成视频给不了的。最后再分享一个小技巧如果你觉得逐帧写绘图指令太麻烦可以让模型先生成一个“场景描述”再由程序把场景描述转成绘图指令。这样模型只需要关注内容程序负责把内容翻译成画面分工更清晰输出也更稳定。