让 Claude 写动画代码，再逐帧合成视频

用 Claude 做产品视频，关键不在于让模型直接生成画面，而在于让它写出一段可以按时间精确播放的程序。作者的流水线是：Opus 5.5 写 HTML，Playwright 逐帧截图，ffmpeg 合成视频。修改镜头时，改代码和参数，再渲染即可。

这套方法值得程序员关注，因为它把动效制作变成了熟悉的工程问题：真实素材、确定性执行、参数管理、逐帧验收。但作者也走过弯路：第一版功能齐全的 2D 视频并不好看，最终效果来自重做和多轮审片。

视频能不能精确修改，取决于时间怎么进入程序

作者反复强调，Opus 5.5 在这条流程里输出的是文本代码，像素由浏览器生成。核心接口是 window.renderAt(t)：输入秒数 t，直接画出对应画面。

每一帧都应该由时间直接计算出来，而不是依赖前面播放过什么。

例如，要修改第 84 帧，就直接渲染那个时间点，不必先跑完前 83 帧。作者在自己的设备上重复渲染同一帧，得到相同文件哈希；这是他的实测，不能据此保证不同浏览器和设备也完全一致。

实现这个约束，需要禁用 Date.now、setTimeout、setInterval、CSS transitions，以及渲染模式下的 requestAnimationFrame。随机噪声使用带种子的 mulberry32，不能调用 Math.random，帧之间也不能携带状态。

下面是作者逐帧截图脚本的核心，它把指定时刻的页面保存为 PNG：

// node render.mjs anim.html 6 30   (file, seconds, fps)
import { chromium } from 'playwright';
import { pathToFileURL } from 'node:url';
import { mkdirSync } from 'node:fs';

const [file = 'anim.html', secs = '6', fps = '30'] = process.argv.slice(2);
const FPS = Number(fps), N = Math.round(Number(secs) * FPS); // frames 0..N-1
mkdirSync('out/frames', { recursive: true });

const browser = await chromium.launch();
const page = await browser.newPage({ viewport: { width: 1920, height: 1080 } });
await page.goto(pathToFileURL(file).href, { waitUntil: 'networkidle' });
await page.evaluate(() => document.fonts.ready);

for (let i = 0; i < N; i++) {
  await page.evaluate((t) => {
    if (window.renderAt) window.renderAt(t);
    document.getAnimations().forEach((a) => { a.pause(); a.currentTime = t * 1000; });
  }, i / FPS);
  await page.screenshot({ path: `out/frames/${String(i).padStart(4, '0')}.png` });
}
await browser.close();

重点看 i < N 和 document.fonts.ready：循环视频只取第 0 到 N-1 帧，避免首帧重复；字体加载完成后再截图，避免开头闪出替代字体。

随后使用 ffmpeg 编码：

ffmpeg -framerate 30 -i out/frames/%04d.png -c:v libx264 -profile:v high \
  -pix_fmt yuv420p -crf 18 -movflags +faststart out/anim.mp4

注意输入仍是 PNG。作者要求中间帧不要经过 JPEG 压缩，以免编码成视频之前先损失一次文字边缘。

环境需要 Node、ffmpeg 和 Playwright Chromium。安装入口是 npm i -D playwright、npx playwright install chromium；运行 claude 后通过 /model 选择 Opus 5.5。库版本必须锁定，网络请求只允许字体和指定的库。

把「高级感」拆成参数，模型才有东西可执行

原文引用的一次对比中，只有「酷、精致、现代」的提示词，生成了深蓝背景、光环、粒子、旋转产品和未经要求的标语。问题不是形容词绝对无效，而是它们给默认套路留下了太多空间。

作者现在先确定目标、输出引擎、尺寸、时长和帧率，再指定配色、字体、缓动、镜头区间及验收帧。每个镜头只安排一个主要动作，转场默认直接切镜。

数字让修改有了落点：

• 入场使用 ease-out，退场使用 ease-in；退场比入场短 40% 到 50%，例如 400 ms 入、200 ms 出。在 30 fps 下，400 ms 就是 12 帧。
• 弹簧阻尼比为 damping / (2 * Math.sqrt(stiffness * mass))。原文建议 0.7 到 0.85 偏克制，0.4 到 0.6 偏活泼，低于 0.3 偏卡通；这些是风格经验。
• UI 反馈用 100 到 200 ms，普通位移用 200 到 500 ms，主角揭示用 600 到 900 ms。位置和尺寸可以回弹，透明度和颜色不要回弹。
• 文字至少停留「每词 0.3 秒，再加 0.5 秒」，两个词需要 1.1 秒；中文不能机械照搬英文词数，仍要实际检查阅读时间。

节奏也可以计算：每拍帧数为 fps × 60 / BPM。120 BPM、30 fps 对应每拍 15 帧。每一拍都应从时间独立计算再取整，持续累加取整后的间隔会产生偏移。

素材则必须真实。Slabwatch 的界面直接来自实际页面的 HTML 和 CSS，通过 iframe 放进影片。作者要求先用 Playwright 抓取产品素材，缺失时询问，不能补画一个看起来可信的假界面，也不能编造指标。

禁用项同样需要具体：居中渐变标题、全员淡入、反复上滑、紫蓝渐变、发光、粒子和无意义旋转，都被逐项写进规则。作者把这些要求集中到 CLAUDE.md，动效参数集中到 motion.js，让每次修正能够留给下一次使用。

3D 的成本不只在渲染，还在把字保住

Slabwatch 第一版长 60 秒，1920×1080、30 fps，全部使用平面 2D。它展示了电表越过 200 units、Rs 32,000 账单，以及使用第 19 天和第 30 天账单之间的关系。作者的评价却是：内容正确，但不够吸引人。

第二版换成 three.js 0.186，加入电表模型、7 段 LCD、镜面地板、预测图、灯光和景深。完整渲染前，先检查了 4 轮静帧。

作者报告，RTX 2050 笔记本在 1080p、带景深和阴影时约需 0.3 秒一帧。他通过 --use-angle=vulkan、--enable-gpu、--ignore-gpu-blocklist 启用 GPU，避免自己的环境落到 SwiftShader 软件渲染。这组参数的效果仍依赖设备和驱动。

版本也会影响代码能否运行：原文指出 three.js 0.186 已移除 PCFSoftShadowMap，并提到 r160 中 TextGeometry 使用 height、忽略 depth 的参数陷阱。ES modules 则需要本地 HTTP 服务，例如 npx http-server，不能沿用前面基础示例的 file:// 加载方式。

更容易被忽略的是清晰度。作者要求文字和 UI 放在独立图层，在景深及模糊处理后绘制；最近镜头至少保证每个输出像素对应 1 texel，素材通常按 2x 抓取，特写按 3x。颗粒不超过 .02，最终 crf <= 18，默认 16，细节丰富的 3D 用 14。

快速运动的模糊通过每帧 4 个子帧混合实现，采样覆盖半帧，对应 180° 快门思路，渲染耗时约增至 4 倍。作者因此只建议在最终输出时开启。

先验收静帧，再花时间渲染整片。

具体流程是每轮找出最差的 3 个问题，标明帧号，修改后再看，通常做 2 到 4 轮。除了 360 px 宽的手机预览，还要查看原尺寸近景和片尾，把文字放大到 200%。缩略图能看构图，却看不出小字是否已经发糊。

我的判断

这篇最有价值的是一套能执行的验收办法：真实素材、确定性时间、明确帧号和清晰度检查。它很适合产品演示、UI 动效、数据叙事和文字动画，尤其适合已经熟悉 HTML、CSS、JavaScript 的开发者。

但「换成 3D 就更好看」只是作者对自己项目的判断。原文没有给观看完成率、转化率，也没有提供受控对照，不能把个人审美结论当成传播效果证据。复杂角色、自然运动和写实场景，也不是这条代码路线最擅长的任务。

声音部分同样需要保留判断距离：第一版混到 -14 LUFS，第二版为 -14.6 LUFS；earshot 给第二版打出 19/21，并评价为「launch-grade」。工具自评不能代替真人试听。文字清晰度的 0.50 合格、较大文字 0.60+，也属于作者自建检查方法，原文没有提供通用有效性的验证。

此外，所给正文在第 10 节截断。目录虽列出声音制作、长片规划、平台导出，以及 Blender、Remotion、Manim 等路线比较，但这里没有完整内容，不能据此补出它们的优劣表。

能拿来做什么

• 给产品演示建立一个最小 Node 工程，用 window.renderAt(t) 控制时间，先完成一段可逐帧定位的 UI 动效，再决定是否增加 3D。
• 把真实页面截图、Logo 和业务数字整理成素材目录，要求 AI 编程助手先列出素材来源，再编排镜头；缺少素材时停止补画。
• 把缓动、时长、错峰间隔写进 motion.js，把渲染和验收规则写进 CLAUDE.md，让修改从「再高级一点」变成调整具体参数。
• 每次先提交指定帧、手机尺寸预览和文字特写，审核通过后再渲染整片；反馈写清对象、帧号和修改方向，例如「第 84 帧的冲击峰值提前 2 帧」。