实测 Agent 生成视频：能渲染仍需审美验收

从空文件夹到第一个 MP4，作者实测花了约 162 秒。但这个数字证明的是工程链路能跑通：安装依赖、接入技能、完成渲染。它没有证明 AI 能在三分钟内做出一条值得发布的视频。

这篇最有价值的地方，是把「AI 视频」拆成两类：模型生成画面，以及用代码渲染画面。后者适合前端和全栈程序员上手，也适合交给 Coding Agent 执行。真正卡住交付的，是另一个问题：程序运行成功之后，谁来判断画面是否合格？

Agent 能接管的，是哪一种视频生产？

Veo、Gemini Omni、Sora 代表的是从提示词生成像素的路线。Remotion 和 HyperFrames 则把视频变成程序：前者使用 React 组件树，后者使用 HTML。

两条路线的错误类型不同。生成模型可能画错手指；代码渲染可能抛出 TypeError: undefined is not a function。Agent 可以根据类型错误、运行日志修改代码，但不能靠修复程序错误纠正一只多出来的手。

代码视频的核心，是让每一帧由时间决定。下面这段代码用当前帧计算弹簧动画进度，再把进度用于透明度：

const frame = useCurrentFrame();          // 0, 1, 2, … 149
const p = spring({ frame, fps, config: { damping: 200 } });
return <div style={{ opacity: p }}>…</div>;

要看的是第二行：动画进度由 frame、fps 和 damping: 200 等参数计算，渲染器可以直接定位到某一帧，不必等待动画从头播放。

实际流程是：Remotion 打包项目，或 HyperFrames 直接加载 index.html；无头 Chrome 逐个定位时间点并截图，最后把帧交给 FFmpeg 编码。相同输入得到相同输出，是这条路线适合自动化的基础。

于是，视频也有了代码审查入口。组件、文案、颜色和动画参数都能进入 git diff。但代码差异能解释改了什么，无法单独证明改完更好看。

162 秒跑通，究竟测到了什么？

作者在 2026-10-26 使用 Windows 11、8 核 CPU、Node 24.21.0、npm 11.19.0、Remotion 4.0.538 实测。下面四条命令完成了脚手架创建、技能安装和首次渲染，不需要编辑器或 API key：

npx create-video@latest --yes --blank demo   # scaffold
cd demo
npx skills add remotion-dev/skills -a claude-code -y   # 12 skills → .claude/skills
npx remotion render MyComp out/video.mp4      # render

这里第三条命令最容易踩坑。它把 12 个技能装进 .claude/skills/；原文所引官方安装方式 npx remotion skills add，在作者测试中写入的是 .agents/skills/，并创建 skills-lock.json。Agent 找不到技能时，先检查目录。

162 秒由约 116 秒安装、6 秒技能安装和 40 秒冷启动渲染组成。安装约占三分之二，首次渲染又包含无头 Chrome 下载。因此，162 秒是首次产出文件的耗时，不是完成视频创作的耗时。

原文还给出两组渲染数据：150 帧耗时 11.7 秒，1800 帧耗时 68.7 秒。这里有一处需要纠正：两者分别约为 12.8 fps 和 26.2 fps，不能都称为约 26 fps。固定开销可能影响短视频结果，但作者只测了一个合成项目，这些数字不足以证明渲染耗时严格线性。

技能的上下文成本也有一个容易误解的地方。最大的 remotion-best-practices 中，SKILL.md 约 4.2 KB，主要承担路由作用，引导 Agent 按任务加载另外 11 份参考资料。原文用「前期约 300 tokens，按需获取约 12k tokens 的 API 知识」解释这种设计，并非安装后就把所有文档塞进提示词。

风险是路由没有触发时，Agent 可能仍按记忆写代码。代码看起来合理，最后却只渲染出黑屏。

为什么绿色退出码不能作为交付标准？

白字放在白底上、Logo 被裁掉、动画在第 12 帧就结束，都可能得到成功退出码。编译器检查的是程序能否执行，视频交付还需要检查信息是否清楚、节奏是否合适。

作者提出的处理顺序值得保留。

先提供组件库。让 Agent 组合 <LowerThird/> 和 <StatCard/>，比让它从空白画布发明动效更容易控制质量。组件库把字号、留白、布局和运动方式固定下来，Agent 主要负责填内容和选组合。

再用静帧缩短反馈周期。作者执行 npx remotion still MyComp out/f.png --frame=45 耗时 6.7 秒；完整 5 秒视频耗时 11.7 秒，60 秒视频耗时 68.7 秒。打包有约 5 秒固定成本，视频越长，用静帧排查布局问题越划算。原文也建议用 render --frames=0-59 检查一小段，再在合并时完整渲染。

最后让具备视觉能力的 Agent 回读帧图片。没有这一步，人就是实际的验证循环；有这一步，也还需要人工判断品牌表达与观看体验。

工程上的稳定性同样不能省。字体和媒体异步加载，截图可能早于图片解码完成。作者建议媒体本地化、固定字体，减少外部资源引入的不确定性。

长视频还会放大计算成本。原文称该机器上 1080p、10 分钟视频约需渲染 11 分钟，但没有给出相应的详细测试记录。至少可以确定，这类工作不适合直接堵在请求处理函数中。Remotion Lambda 和 HyperFrames 的 Lambda 路径是作者提到的扩展方向，他们没有测试云端渲染。

我的判断

我认同把代码视频看作一种批量内容生产方式：每个客户一条、每次数据更新一条、每个 pull request 一条。内容结构稳定、数据不断变化，才容易发挥模板与自动化的价值。

它对替代 Premiere 的证明则很有限。时间线编辑器适合人工调整镜头和节奏；代码适合复用规则。先决定 React 还是 HTML 也合理，因为组件与页面的组织方式不同，后续迁移可能需要重写。

成本更不能只算模型 tokens。按原文转述的 Remotion 条款，三人工作室免费，第四人加入就进入 Company License 范围；为他人提供视频渲染的产品涉及 Automators，价格为 $0.01/render，最低 $100/月。每月 50,000 条对应 $500，而只生成 9 条的项目也会受到最低消费影响。人数门槛与用量计费需要分别确认，实际采用前应核对适用条款。

HyperFrames 使用 Apache 2.0，以 HTML 为创作入口，是值得比较的选择。不过，同样使用 Chrome 和 FFmpeg，不足以证明两者的功能、性能与生态相当。

原文引用的 Claude Code 首次提示词到 MP4 模型成本 $0.13，来自 NiharDaily 的另一次实践，并非作者自己的基准测试。组件库能提升多少质量、技能能减少多少返工，作者也没给对照数据。这些可以作为试用方向，不能直接变成预算承诺。

此外，作者把 Coding Agent 描述为只能理解纯文本，表述过于绝对。他们后面也建议让具备视觉能力的 Agent 查看帧图片。更准确的判断是：代码和错误日志提供了更明确的修改入口，视觉判断仍有不确定性。

能拿来做什么

• 如果你已有 React 技术栈，可以先用 Remotion 做一种固定结构的视频，例如数据更新播报。先确定内容是否适合模板，再决定是否引入 Agent。
• 把标题、字幕、数据卡片和动效封装成组件，让 Agent 填数据、选布局，并用关键帧截图辅助人工检查。
• 在日常 AI 编程流程中，先检查技能目录，再生成代码；先渲染静帧或短片段，再输出完整 MP4，同时固定字体并使用本地媒体。
• 如果要用 Node 提供视频生成服务，先测自己机器的冷启动、短片与长片耗时，再安排异步任务，并把人数授权门槛和最低月费计入成本。