越来越多人开始使用 Coding Agent 做视频了。但同样一句“我想做 AI 视频”，两拨人给出的答案完全相反。一拨人说用 Remotion——React 生态、社区成熟、适合严肃的批量生产；另一拨人说该换 HyperFrames 了——写 HTML 就行，AI 上手快、出错少。两边都言之凿凿，谁也不服谁。

这篇文章想把两个框架到底差在哪、各自的底气是什么，以及为什么在“AI 驱动视频生成”这个新场景里，我确实更看好 HyperFrames。

先认识两位主角

Remotion：用 React 写视频

Remotion 是当下最主流的程序化视频框架之一。它的思路是：不打开剪辑软件、不拖时间线，而是用 React 组件描述每一帧画面，再交给无头浏览器逐帧渲染，最后编码成真正的 MP4。

核心模型很纯粹：你在组件里通过 useCurrentFrame() 拿到当前帧号，用 interpolate() 把帧号映射成透明度、位移、缩放，再注册一个 Composition 声明宽高、帧率和时长。画面是帧号的纯函数——代码即真相。

这个模型天然适合数据驱动的批量视频：同一套模板喂不同数据，就能流水线地产出成百上千条视频，配合服务端渲染和 Remotion Lambda，还能在云端大规模并行渲染。项目在 GitHub 上积累了数万 star，文档、模板、社区问答都相当厚实，是经过大量生产验证的成熟方案。

HyperFrames：写 HTML，渲视频

HyperFrames 是 HeyGen 开源的一个视频渲染框架，slogan 只有一句：Write HTML. Render video. Built for agents.——写 HTML，渲视频，天生为 AI Agent 而生。

它的核心理念可以压缩成一句话：HTML 在浏览器里怎么跑，渲染出来的视频就长什么样。 你写一个 index.html，CSS 管样式、GSAP 管动画，CLI 用无头浏览器逐帧抓取、FFmpeg 编码，就得到一段确定性的 MP4。不需要构建步骤，不需要 React，不需要学一套新语法。

工作流短到三行命令：npx hyperframes init 初始化，npx hyperframes preview 在浏览器里实时预览，npx hyperframes render 导出 MP4。它还内置了语音合成、字幕生成和媒体资源处理，并且为 Claude Code、Cursor、Gemini CLI、Codex 这些主流 AI 编程工具准备了 20 多个官方 skills——AI 可以独立完成“策划、写码、预览、渲染”的完整闭环。

真正的分歧：你让谁来写内容

先说一个容易被忽略的事实：两个框架的底层渲染管线几乎相同——都是无头 Chrome 渲染画面加 FFmpeg 编码，都能做到确定性渲染。真正的分歧只有一个：主作者是谁。

Remotion 押注的是 React 组件：画面由开发者用 React 精确编排；HyperFrames 押注的是纯 HTML：页面本身就是视频。这个分歧在人写代码的年代不明显，但在 AI 写代码的年代被急剧放大。

大模型的训练数据，决定了它的上限

原因不复杂：大模型训练语料里，HTML、CSS、JavaScript 是最深的那口井。全球数以亿计的网页，日复一日地在教模型“怎么写 Web 代码”；而 React、TypeScript 这类框架语法，在这片语料里只是沧海一粟。

所以当你让 AI Agent 写 Remotion 代码，它得先花大量 token 学习框架规则：组件怎么写、JSX 怎么组织、动画在 React 里怎么处理、Composition 怎么注册——学完这些才开始创作。让它写 HTML？那是它最熟悉的东西，几乎没有额外学习成本。结果是输出更有创意、错误更少、修改更直接。

同一个 prompt，两种成品

这不算我的一家之言。有人用同一个 prompt 分别让 Claude Opus 4.7 写两个版本，差别很直观：Remotion 版本是标准转场、通用排版，视觉保守得像套模板；HyperFrames 版本则有 GSAP 动画、自定义排版、更鲜明的分镜与构图。

同一个需求，两种成品。这不是框架好不好用的问题，而是 AI 在哪种语言里更有发挥空间 的问题。

同一段标题卡，两种写法

官方文档里有一个很好的对照：同样做一段 3 秒的标题卡（淡入—停留—淡出）。Remotion 的写法是把时序数学写进代码，由帧号驱动一切：

// Remotion 写法（React + TypeScript）
import { AbsoluteFill, interpolate, useCurrentFrame } from "remotion";

export const TitleCard = () => {
  const frame = useCurrentFrame();
  const opacity = interpolate(frame, [0, 15, 75, 90], [0, 1, 1, 0], {
    extrapolateLeft: "clamp",
    extrapolateRight: "clamp",
  });
  return (
    <AbsoluteFill
      style={{ backgroundColor: "#0a0a0a", justifyContent: "center", alignItems: "center" }}
    >
      <div style={{ fontSize: 160, fontWeight: 800, color: "#fff", opacity }}>HELLO</div>
    </AbsoluteFill>
  );
};

HyperFrames 则把“什么时候出现在屏幕上”交给 HTML 的 data-* 属性，把“怎么动”交给 GSAP 时间线，而且用的是秒而不是帧，全部放在同一个文件里：

<!-- HyperFrames 写法（单个 HTML 文件） -->
<div id="stage" data-composition-id="title-card"
     data-start="0" data-width="1280" data-height="720"
     data-duration="3" data-fps="30">
  <div id="card" class="clip" data-start="0" data-duration="3" data-track-index="0">
    <div id="title">HELLO</div>
  </div>
</div>
<script>
  const tl = gsap.timeline({ paused: true });
  tl.to("#title", { opacity: 1, duration: 0.5 }, 0);
  tl.to("#title", { opacity: 1, duration: 2.0 }, 0.5);
  tl.to("#title", { opacity: 0, duration: 0.5 }, 2.5);
  window.__timelines = window.__timelines || {};
  window.__timelines["title-card"] = tl;
</script>

三个容易被忽略的关键差异

动画生态：GSAP 在谁那里才真正“听话”

做视频离不开动画库，而 GSAP 是当前最流行的 Web 动画库之一。它和 Remotion 却不太合得来：Remotion 每帧都要做一次 React reconciliation，而 GSAP 有自己的内部时钟——两个时钟一打架，问题就来了：一段精心设计的 4 秒动画，在 Remotion 里渲染出来，可能一秒就跑完了。

HyperFrames 换了一个思路：不做时钟同步，而是“seek”——渲染器先把动画暂停，跳到精确时刻，再截取这一帧。GSAP、Lottie、Web Animations、Anime.js 这些库全部跟着帧走，4 秒就是 4 秒，分毫不差，而且同一帧每次渲染结果一致，这是真正的确定性渲染。

工作流：没有构建步骤意味着什么

HyperFrames 不需要构建步骤：index.html 在浏览器里打开，就是你渲染出来的视频的样子。改一行 CSS、刷新、看效果——没有等待、没有编译、没有转译。

Remotion 则绕不开打包器：HTML 要转成 JSX，CSS 要用 React 的方式处理，每一步都是“翻译”，每一步都可能出错。对 AI 工作流来说这一点尤其致命：翻译环节越多，AI 跑偏、需要人工修 bug 的概率就越高。

许可证：开源，和“源码可见”是两回事

HyperFrames 采用 Apache 2.0 协议，是 OSI 认证的真正开源：商业使用无限制，没有渲染次数收费，没有团队规模上限。

Remotion 是 source-available（源码可见），但用的是自定义商业许可：个人和不超过 3 人的小团队免费，超过就要购买公司许可，云端渲染服务也有费用边界。

如果你做的是商业产品，或者想把视频生成能力打包进自己的服务给别人用，许可证是必须提前想清楚的事——它决定了商业计划会不会在某个节点突然多出一笔成本。

一张表总结差异

维度	HyperFrames	Remotion
创作语言	HTML + CSS + JavaScript	React + TypeScript
构建步骤	无，index.html 打开即预览	需要打包器（bundler）
动画时序	暂停动画并 seek 到精确时刻再截帧，帧级确定	代码按帧号返回画面，依赖帧驱动
现有 Web 素材	HTML/CSS、GSAP、Lottie 动画基本可直接复用	需要改写成 React 组件
AI Agent 上手	写纯 HTML，可直接生成与修改	需理解 JSX/React 工程与构建
许可证	Apache 2.0（OSI 认证开源，无限制）	自定义商业许可，3 人以上团队需付费

说句公道话

把话讲公平。HyperFrames 不是凭空冒出来的：HeyGen 在生产环境里用了 Remotion 很多个月，HyperFrames 源码里至今保留着向 Remotion 致谢的注释——Chrome 启动参数、image2pipe 到 FFmpeg 的流式传输、帧缓冲这些底层核心模式，都是 Remotion 团队先做出来的。两个框架共享同一套渲染哲学，区别只在于让谁来写内容。

也必须承认，Remotion 在很多方面依然更成熟：文档更厚、社区更大、模板更多，Remotion Lambda 是久经考验的云渲染体系。如果你的团队深度在 React、有现成的组件库、需要从数据大规模生成视频，Remotion 依然是很好的选择，没必要为了换而换。

顺带一提，HyperFrames 提供了一条真实可走的迁移路径：官方 remotion-to-hyperframes skill 能把典型 Remotion 组成的约 80% 机械翻译成 HTML，翻译不了的部分（比如基于 useState 的状态机）会被明确标记出来，而不是悄悄错译。

那你会怎么选

我的判断是：如果你在做 AI 驱动的视频生成，想让 AI 写出更有创意的内容，或者需要一个对商业完全友好的开源方案，HyperFrames 值得认真看一眼；如果你的团队以 React 为核心、以数据驱动的大规模生成为主，Remotion 依然是稳妥之选。

最后留一个问题：视频生产的未来，是人写代码，还是 AI 写 HTML？如果是后者，框架的选择就不只是工具偏好了——它决定了 AI 的创造力能发挥到几成。你会怎么选？