1. 从"写代码"到"做视频"：这条路线到底在解决什么问题

先说结论：用 Claude Opus 5.5 这类强推理模型写代码来做视频，本质上是把"视频制作"这件事从"剪辑软件里拖时间轴"迁移到"用代码描述画面与运动"。你不再需要逐帧拖拽，而是写一段可复现、可参数化、可版本管理的程序，让浏览器或渲染器把画面算出来。这条路线的核心关键词就是Canvas、WebGL、Three.js、提示词工程，而 Claude Opus 5.5 在其中扮演的角色，是一个能听懂自然语言、又能吐出可运行代码的"技术合伙人"。

我做这套东西的起点其实很朴素：早期用传统剪辑软件做数据可视化短片，改一个数字就要重新导出一次，一条 30 秒的片子改十几版是常态。后来换成代码驱动，同样的片子改参数只要刷新浏览器，导出交给录制或离屏渲染就行。再后来接入 Claude Opus 5.5，连"写代码"这一步都能用自然语言描述需求来推进，效率提升是数量级的。

这篇文章适合三类人看：一是会一点前端、想用代码做视频但不知道从哪下手的开发者；二是做数据可视化、产品演示、教学动画的内容创作者；三是已经在用 AI 写代码、但发现"提示词写不好就出一堆废代码"的实践者。我会把 7 类技术路线讲清楚，用 5 个案例拆开揉碎，最后给一套我自己反复打磨、可以直接抄的提示词框架。全程不聊虚的，只讲能跑起来的东西。

需要提前说明的是，下面涉及的具体 API、参数、库版本，都是基于当前主流实践的合理方案，不同环境可能有差异，你落地时以自己项目的实际依赖为准。我尽量把"为什么这么选"讲透，这样即使工具迭代了，思路也不会过时。

2. 七类技术路线全景拆解：先选对赛道再动手

很多人一上来就问"用 Three.js 还是 Canvas"，这其实是个伪问题。选路线的前提是搞清楚你的画面到底要什么。我把代码做视频拆成 7 类路线，从轻到重排一遍，你对号入座。

2.1 路线一：纯 Canvas 2D 绘图，适合图表与扁平动画

Canvas 2D 是最容易上手的一类。它的心智模型就是"一块画布 + 一支笔"，你调用fillRect、arc、bezierCurveTo这些方法把图形画上去，再用requestAnimationFrame逐帧更新。适合做柱状图动画、进度条、文字逐字出现、粒子飘散这类扁平风格的内容。

它的优势是零依赖、调试直观、性能对简单场景完全够用。劣势也明显：没有真正的三维空间，做不了光照和透视，复杂场景下每帧重绘全部内容会掉帧。我的经验是，只要画面元素在几百个以内、没有 3D 需求，Canvas 2D 就是性价比最高的选择，别为了炫技上 WebGL。

2.2 路线二：Canvas + 离屏渲染，适合批量导出与高分辨率输出

普通 Canvas 是画在屏幕上的，但你可以用OffscreenCanvas或者创建一个不挂载到 DOM 的 canvas 元素，在内存里逐帧绘制，再用toBlob或convertToBlob把每一帧存成图片，最后用 FFmpeg 合成视频。这条路线的价值在于：你可以渲染 4K 甚至更高分辨率，不受屏幕尺寸限制，还能在后台批量跑。

关键点是帧率与时间戳的对应关系。假设你要 30fps、时长 10 秒，那就是 300 帧，第 n 帧对应的时间是n / 30秒。所有动画逻辑都必须基于这个"虚拟时间"来算，而不是依赖requestAnimationFrame的真实时间，否则导出会抖动。这一点后面案例里会再展开。

2.3 路线三：WebGL 原生着色器，适合流体、光效与像素级控制

WebGL 让你直接操作 GPU。你写顶点着色器和片元着色器，片元着色器里每个像素的最终颜色由你决定。做流体、噪声、光晕、扭曲、故障风这些效果，WebGL 是天花板最高的路线。

代价是学习曲线陡。你得理解 GLSL 语法、uniform 传参、纹理采样、坐标系转换。但一旦跨过这道坎，你会发现很多"看起来很贵"的视觉效果，其实就是一个片元着色器加一个时间变量。比如经典的"云间列车"那种流动云雾，本质就是多层噪声函数叠加时间偏移。

2.4 路线四：Three.js 场景化，适合三维空间与镜头运动

Three.js 把 WebGL 的复杂度封装成了场景图：Scene、Camera、Mesh、Light、Material。你描述"有一个立方体、一盏平行光、相机从 A 点移动到 B 点"，它帮你翻译成 GPU 指令。做产品 3D 展示、空间穿梭、粒子星系、镜头推拉，Three.js 是首选。

它的核心价值在于"镜头语言"。代码做视频最缺的就是运镜，而 Three.js 的 Camera 可以精确控制位置、朝向、视场角，配合缓动函数就能做出电影感的推拉摇移。这也是为什么热词里"three.js 快速创建项目"一直很火——大家都想快速搭一个能运镜的三维舞台。

2.5 路线五：Three.js + 后期处理，适合电影感调色与辉光

Three.js 自带 EffectComposer 后期处理管线，可以叠加 Bloom（辉光）、景深、色彩校正、胶片颗粒等 Pass。这一步是把"能看"变成"好看"的关键。很多新手做出来的三维画面灰扑扑的，就是因为少了后期。

我的习惯是：基础场景搭完后，先加一层 Bloom 让高光溢出，再加一层轻微的色彩查找表调色，最后叠一点噪点模拟胶片质感。这三步下来，画面质感立刻上一个台阶。注意 Bloom 参数别开太大，否则整个画面糊成一团。

2.6 路线六：代码生成 + 视频合成流水线，适合规模化生产

当你需要批量产出几十上百条视频时，单条手写就不划算了。这时候要把流程拆成"模板 + 数据 + 渲染 + 合成"四段：模板是参数化的代码，数据是 JSON 或表格，渲染是离屏逐帧，合成交给 FFmpeg。Claude Opus 5.5 在这里的价值是帮你快速生成模板代码和 FFmpeg 命令，省去查文档的时间。

2.7 路线七：AI 生成素材 + 代码编排，适合混合工作流

最后一类是把 AI 生成的图片、视频片段作为素材，用代码来编排它们的出现时机、转场和叠加效果。比如用文生图模型生成背景，用代码控制它随音乐节奏缩放。这条路线的难点在于素材的尺寸、帧率、色彩空间要统一，否则合成时会出各种诡异问题。

下面这张表帮你快速定位：

3. 五个案例拆解：从需求到可运行代码的完整链路

光讲路线太抽象，我拿 5 个真实做过的案例，把"需求描述 → 提示词 → 代码 → 调优"整条链路走一遍。每个案例我都会说清楚踩过的坑。

3.1 案例一：Canvas 绘制动态数据看板

需求是做一个 15 秒的销售数据看板动画，柱状图从 0 长到目标值，数字同步滚动，背景有轻微网格呼吸效果。

提示词我这样写："用原生 JavaScript 和 Canvas 2D，创建一个 1920x1080 的画布。绘制 6 根柱状图，高度从 0 缓动到目标值，缓动函数用 easeOutCubic，时长 1.5 秒。每根柱子上方显示对应数字，数字从 0 滚动到目标值，与柱子同步。背景绘制淡灰色网格，网格透明度随时间做正弦波动。所有动画基于传入的时间参数 t 计算，不要用 Date.now()。"

这里最关键的一句是"基于传入的时间参数 t 计算"。为什么？因为导出时要逐帧渲染，如果动画依赖真实时间，导出就会乱。把时间作为参数传进去，渲染函数就变成了纯函数：给定 t，输出确定的画面。这是代码做视频的第一原则。

代码骨架大概是这样：

function renderFrame(ctx, t) { const duration = 1.5; const progress = Math.min(t / duration, 1); const eased = 1 - Math.pow(1 - progress, 3); // easeOutCubic ctx.clearRect(0, 0, 1920, 1080); drawGrid(ctx, t); data.forEach((item, i) => { const h = item.value * eased; drawBar(ctx, i, h); drawNumber(ctx, i, item.value * eased); }); }

导出时循环for (let f = 0; f < 450; f++) renderFrame(ctx, f / 30)，每帧存图。450 帧就是 15 秒 30fps。

坑点：数字滚动如果直接用Math.round，会出现跳变不自然。我后来改成对数字也做缓动，并且用toFixed(0)保证是整数显示。另外网格呼吸的透明度别超过 0.15，否则抢主体。

3.2 案例二：WebGL 片元着色器做流体背景

需求是一段 20 秒的抽象流体背景，颜色在蓝紫之间流动，有类似墨水滴入水中的扩散感。

这类效果用 Canvas 2D 做会很吃力，直接上 WebGL。提示词："写一个全屏 WebGL 片元着色器，用 simplex noise 生成流动纹理。使用三层不同频率和速度的噪声叠加，通过时间变量驱动偏移。颜色在深蓝 #0a1a3a 和紫色 #6a3a9a 之间根据噪声值混合。输出带轻微暗角。"

片元着色器核心逻辑：

float n1 = snoise(vec3(uv * 2.0, time * 0.15)); float n2 = snoise(vec3(uv * 4.0 + n1, time * 0.25)); float n3 = snoise(vec3(uv * 8.0 + n2, time * 0.4)); float v = (n1 + n2 * 0.5 + n3 * 0.25) * 0.5 + 0.5; vec3 col = mix(vec3(0.04, 0.10, 0.23), vec3(0.42, 0.23, 0.60), v);

坑点：simplex noise 函数很长，直接让模型写容易出错。我的做法是让模型用现成的噪声库，或者先让它生成一个经过验证的 noise 实现，再在此基础上改。另外time的推进速度要慢，0.15 这种量级比较合适，太快就像沸腾的水而不是流体。

3.3 案例三：Three.js 云间列车运镜

这个对应热词里的"webgl 云间列车"。需求是一列低多边形列车在云层中穿行，相机跟随列车侧后方，云层用粒子或半透明平面模拟。

提示词："用 Three.js 创建一个场景。一列由多个 BoxGeometry 组成的低多边形列车，沿 Z 轴负方向匀速前进。相机位于列车侧后方，位置随列车移动，朝向略微偏向列车前方。云层用 200 个半透明 PlaneGeometry 随机分布在列车路径两侧，材质用 MeshBasicMaterial 带透明度贴图。添加平行光和环境光。背景色用渐变天空。"

这里有个关键决策：云层用粒子还是平面？粒子性能好但缺乏体积感，平面有体积感但容易穿帮。我最后选了平面 + 随机旋转 + 透明度贴图，因为列车速度不快，平面穿帮不明显，而体积感对"云间"这个氛围很重要。

相机跟随的代码：

const camOffset = new THREE.Vector3(8, 4, 12); function updateCamera() { const target = train.position.clone().add(camOffset); camera.position.lerp(target, 0.1); camera.lookAt(train.position.x, train.position.y + 1, train.position.z - 5); }

坑点：lerp的系数 0.1 决定了跟随的"软硬"。太大相机会抖，太小会滞后。我试了 0.05 到 0.2，最后 0.1 最稳。另外lookAt的目标点要比列车位置稍微靠前，否则相机像在盯着车尾看，没有"向前"的感觉。

3.4 案例四：Three.js 后期处理做电影感

接上个案例，画面能看但不够"高级"。加后期：Bloom 让云层边缘发光，色彩校正压暗部提亮部，加轻微噪点。

提示词："在 Three.js 场景中加入 EffectComposer，依次添加 RenderPass、UnrealBloomPass、自定义 ShaderPass 做色彩校正、FilmPass 做胶片颗粒。Bloom 强度 0.8，半径 0.4，阈值 0.85。色彩校正用 lift-gamma-gain 模型。"

后期管线的顺序很重要：先渲染，再 Bloom，再调色，最后颗粒。如果颗粒加在 Bloom 前面，颗粒也会被发光放大，画面会脏。阈值 0.85 意味着只有亮度超过 0.85 的部分才发光，这样云层的高光会溢出，暗部保持干净。

坑点：加了后期之后帧率会掉，导出时如果逐帧渲染，一帧可能要几百毫秒。20 秒 30fps 就是 600 帧，可能要跑好几分钟。建议导出时把分辨率降到 1280x720 先预览，确认没问题再上 1080p 或 4K。

3.5 案例五：代码流水线批量生成短视频

最后一个案例是规模化的。需求是根据一份 CSV 数据，批量生成 50 条结构相同、数据不同的短视频。

流程拆成四步：第一步，把 CSV 读成 JSON 数组；第二步，每条数据套进模板生成一个 HTML 页面或直接调用渲染函数；第三步，用 Puppeteer 或 Playwright 打开页面，逐帧截图；第四步，用 FFmpeg 把图片序列合成 MP4。

FFmpeg 命令：

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

-framerate 30要和渲染帧率一致，-crf 18是质量参数，数字越小质量越高体积越大，18 到 23 是常用区间。-pix_fmt yuv420p保证兼容性，不加的话某些播放器打不开。

坑点：Puppeteer 截图默认是异步的，如果不等上一帧渲染完就截下一帧，会出现重复帧或跳帧。我的做法是在页面里暴露一个window.renderFrame(t)函数，Puppeteer 调用它并等待返回，再截图。这样时序完全可控。

4. 可复用提示词框架：让 Claude Opus 5.5 一次吐对代码

前面案例里我反复提到提示词怎么写。这一节把方法沉淀成框架。核心思路是：把模型当成一个需要明确约束的工程师，而不是一个会读心的魔法师。

4.1 提示词的四段式结构

我总结的框架是四段：环境约束 + 目标描述 + 技术选型 + 输出规范。

环境约束告诉模型运行环境，比如"原生 JavaScript，不引入任何外部库"或"使用 Three.js r160，通过 CDN 引入"。这一步能避免模型给你一堆需要构建工具的代码。

目标描述说清楚画面要什么，越具体越好。别说"做一个好看的动画"，要说"1920x1080，深色背景，6 根蓝色柱状图从底部生长，时长 1.5 秒，缓动为 easeOutCubic"。

技术选型明确指定用 Canvas 还是 WebGL 还是 Three.js，以及关键 API。这一步是防止模型自作主张。

输出规范规定代码结构，比如"所有动画逻辑封装在 renderFrame(ctx, t) 函数中，t 为秒数，不要使用 Date.now() 或 requestAnimationFrame"。

4.2 时间参数化：代码做视频的第一原则

这一条我要单独拎出来讲，因为它太重要了。凡是涉及导出的项目，动画必须由外部传入的时间参数驱动，而不是自己读系统时间。原因有三：一是导出时逐帧渲染，系统时间不可控；二是参数化后可以任意跳帧、倒放、变速；三是便于测试，给定 t 就能复现画面。

提示词里我会明确写："所有动画状态必须是时间 t 的纯函数，禁止在渲染函数内部调用 Date.now()、performance.now() 或依赖 requestAnimationFrame 的时间戳。"

4.3 分步生成：先骨架后细节

一次性让模型生成几百行代码，出错概率很高。我的做法是分步：第一步让它生成骨架和主循环，确认结构对了；第二步让它填充具体绘制逻辑；第三步让它加缓动和细节。每一步都要求它输出完整可运行代码，而不是片段。

这样做的另一个好处是，如果某一步出错，你能快速定位是哪一层的问题，而不是面对一坨代码无从下手。

4.4 提示词模板（可直接抄）

下面是我常用的模板，你替换方括号内容即可：

环境：原生 JavaScript，[是否使用库]，运行在浏览器。 目标：创建一个 [宽]x[高] 的画布，实现 [具体画面描述]。 时间：动画总时长 [X] 秒，帧率 [Y] fps。 技术：使用 [Canvas 2D / WebGL / Three.js]，关键 API 为 [列出]。 约束： 1. 所有动画逻辑封装在 renderFrame(ctx, t) 中，t 为秒数。 2. 禁止使用 Date.now()、performance.now()、requestAnimationFrame 的时间戳。 3. 缓动函数使用 [easeOutCubic 等]。 4. 代码需完整可运行，包含必要的初始化。 输出：完整 HTML 文件，包含 canvas 和 script。

4.5 迭代与纠错：模型出错时怎么救

模型出错是常态，关键是怎么救。我的经验是：不要笼统地说"不对"，要指出具体现象和期望。比如"柱子生长到一半就停了"比"动画有问题"有用得多。如果模型连续两次改不对，就换思路，把问题拆得更小，或者自己写关键部分让它补全。

还有一个技巧：让模型解释它的代码。问它"你这行progress = t / duration在 t 大于 duration 时会怎样"，它往往会自己发现没做 clamp，然后修正。这比直接指出错误更能让它理解意图。

5. 常见问题与排查技巧实录

做这类项目，问题集中在几个地方。我整理成速查表，再补充几个独家避坑经验。

5.1 画布模糊的根因与修复

新手最常遇到的就是画布模糊。根因是 canvas 有两个尺寸：一个是 CSS 显示尺寸，一个是实际像素尺寸。如果只设 CSS 不设像素尺寸，浏览器会拉伸，就糊了。正确做法：

const dpr = window.devicePixelRatio || 1; canvas.width = 1920 * dpr; canvas.height = 1080 * dpr; canvas.style.width = '1920px'; canvas.style.height = '1080px'; ctx.scale(dpr, dpr);

但导出时要注意，如果你要 1920x1080 的输出，就别乘 dpr，直接用 1920x1080，否则导出尺寸会翻倍。

5.2 导出速度优化的三个手段

导出慢是常态，三个手段能明显提速。第一，降低预览分辨率，确认无误再上高分辨率。第二，关闭不必要的后期处理，导出时用简化管线。第三，用离屏渲染避免屏幕刷新开销。我实测下来，同样的场景，离屏渲染比屏幕渲染快 30% 到 50%。

5.3 提示词失效时的降级策略

有时候模型就是理解不了你的意图，反复出错。这时候降级：把复杂需求拆成多个简单需求，逐个生成再拼装。或者干脆自己写核心逻辑，让模型只做辅助。别跟模型死磕，时间成本不划算。

5.4 素材统一：混合工作流的隐形杀手

如果你用 AI 生成的图片做素材，务必统一尺寸、帧率、色彩空间。我踩过的坑是：生成的图片是 sRGB，渲染管线是线性空间，合成后颜色偏暗。解决办法是在加载纹理时设置texture.colorSpace = THREE.SRGBColorSpace，让 Three.js 帮你转换。

6. 工具链与项目搭建：从零到能跑

这一节讲具体怎么把环境搭起来，让代码真的能跑。

6.1 Three.js 项目的两种引入方式

第一种是 CDN，适合快速验证：

<script type="importmap"> { "imports": { "three": "https://unpkg.com/three@0.160.0/build/three.module.js", "three/addons/": "https://unpkg.com/three@0.160.0/examples/jsm/" } } </script> <script type="module"> import * as THREE from 'three'; import { EffectComposer } from 'three/addons/postprocessing/EffectComposer.js'; </script>

第二种是 npm 安装，适合正式项目。npm install three之后用打包工具引入。CDN 的好处是零配置，坏处是依赖网络。正式项目我建议 npm，版本可控。

6.2 导出流水线的目录结构

我习惯的目录结构：

project/ src/ render.js // 渲染函数 scene.js // 场景搭建 data/ input.csv // 数据源 output/ frames/ // 帧图片 videos/ // 成品视频 export.js // 导出脚本

export.js负责读数据、循环渲染、存帧、调 FFmpeg。这样数据和逻辑分离，换数据不用改代码。

6.3 帧率与时长的心算

导出前先算清楚：时长 X 秒，帧率 Y fps，总帧数就是 X 乘 Y。30 秒 30fps 是 900 帧，60fps 是 1800 帧。帧数直接决定导出时间，一帧如果 200 毫秒，900 帧就是 3 分钟。心里有数，就不会被导出时间吓到。

6.4 版本管理：代码做视频的隐藏优势

这是代码路线相比剪辑软件最大的优势之一：你的"视频工程"是一个代码仓库，可以 git 管理。改了什么、什么时候改的、为什么改，全都有记录。我现在的习惯是每条视频一个分支，改版就提交，回滚就是 checkout。这在传统剪辑里是不可想象的。

7. 提示词工程的底层逻辑：为什么有的提示词好用

最后聊聊提示词这件事的底层逻辑，因为热词里"提示词工程""ai 编程提示词"一直很热，但很多人只是抄模板，不理解为什么。

7.1 提示词的本质是约束搜索空间

模型生成代码时，理论上可能的输出是无限的。提示词的作用是缩小这个空间，让模型往你要的方向走。所以提示词越具体，输出越可控。"做一个动画"和"1920x1080、6 根柱子、easeOutCubic、1.5 秒"，后者把搜索空间压缩了几个数量级。

7.2 为什么"鹈鹕骑自行车"这类测试提示词有效

你可能见过"鹈鹕骑自行车"这种看似无厘头的测试提示词。它的价值在于：这是一个模型训练数据里罕见的具体场景，能快速暴露模型在空间关系、物体组合、细节一致性上的能力边界。做代码视频时，你也可以用类似的"压力测试"提示词来评估模型，比如"画一个正在融化的钟表挂在树枝上"，看它能不能处理好形变和空间关系。

7.3 从"描述结果"到"描述过程"

新手提示词往往只描述结果："画一个好看的星空"。老手会描述过程："用 500 个随机分布的点，每个点大小随机，亮度随时间正弦闪烁，颜色在白色和淡蓝之间插值"。描述过程的好处是，模型不需要猜你的审美，只需要执行你的算法。这也是代码做视频和纯 AI 生成视频的根本区别：前者你控制过程，后者你只能祈祷结果。

7.4 提示词的复用与参数化

好的提示词是可以复用的。把变化的部分抽成变量，固定的部分做成模板。比如"画一个 [形状]，颜色 [色值]，位置 [坐标]"，这样一个模板能生成无数变体。这也是批量生产的基础。

8. 我踩过的坑与实操心得

写到这里，把几个印象最深的坑分享一下，都是文档里不会写的。

第一个坑：别在渲染函数里做异步操作。我早期在渲染函数里加载图片，结果导出时图片还没加载完就截图了，出来一堆空白帧。正确做法是先把所有资源加载完，再开始渲染循环。

第二个坑：缓动函数别乱用。easeInOut 看起来优雅，但用在数据展示上会让人看不清中间值。数据类动画用 easeOut 更合适，快速到达再缓慢稳定。

第三个坑：颜色别凭感觉调。我一开始手动调 RGB，调了半天不满意。后来改用 HSL，只调色相和明度，效率高很多。深色背景配高饱和主体，浅色背景配低饱和主体，这个规律基本不会错。

第四个坑：导出前先做 3 秒预览。完整导出可能要几分钟，如果方向错了就是浪费。先导 3 秒看看效果，确认了再全量导出。

第五个坑：模型生成的代码一定要读。不是不信任模型，而是它有时会用一些你环境里没有的 API，或者写出性能很差的循环。读一遍，改一改，比出了 bug 再查快得多。

这套东西我做了大半年，从最初的手忙脚乱到现在能比较顺畅地批量产出，最大的体会是：代码做视频的门槛不在代码，而在"把画面翻译成算法"的思维。一旦你习惯了用参数、时间、缓动、噪声这些概念去描述画面，剩下的就是熟练度问题。Claude Opus 5.5 这类模型能帮你跨过语法和 API 的门槛，但画面的设计思路，还是得你自己想。这也是为什么我一直强调提示词要描述过程而不是结果——过程是你的，结果才是模型的。