本文由 莫潇羽@源码七号站(www.fuyuan7.com)撰写,转载请注明出处。

一句话结论:html-video 是 Open Design 团队最新开源的 HTML→视频"元层(meta-layer)"项目,基于 Apache-2.0 协议,本机就能跑,无云端渲染、无单次扣费。它把"写一段 HTML/CSS/动画 + 让 AI Agent 自动选模板填内容 + 用无头浏览器逐帧抓帧 + ffmpeg 编码成 MP4"这一整条流水线全部封装好,默认接入 HeyGen 开源的 HyperFrames 渲染引擎,内置 21 套设计干净、版权清晰的模板,自动探测本机 14 种主流编码 Agent,可以一键加 MiniMax 配乐和旁白。

对内容创作者来说,真正的价值在于:你不用再纠结剪辑软件、不用买昂贵的渲染服务,把一篇公众号文章丢进去,Agent 自动拆成多帧分镜、套上一套电影感模板、生成带配乐的 MP4,整个过程跑在你自己的笔记本里,数据不出本机。

想看完整拆解,往下翻。

一、视频生产这件事,到底卡在哪里

聊 html-video 之前,得先聊一件事——视频制作这门手艺,过去十年其实没怎么变。

我自己折腾过几年自媒体,前两年帮朋友的产品做过几支宣传片,光是熟悉 After Effects 和 Premiere 的工程文件结构、关键帧曲线、合成嵌套这些东西,就花了三个月。等真正接活的时候才发现一个尴尬的事实:观众根本不在乎你的工程文件有多漂亮,他们只看最后那个 MP4 像不像样、节奏对不对、能不能让人看下去。

所以从工具角度看,传统视频制作其实在干一件成本极高、复用极低的事。

1.1 时间线编辑器的范式天花板

把时间线编辑器(timeline editor)拆开看,本质就是一条横向的时间轴 + 一堆纵向的轨道,每条轨道里塞素材、关键帧、特效层。这套范式从早期非线性编辑系统一路沿用到今天,操作直观,但有几个绕不过去的问题。

第一,它不是为程序化生产准备的。当你要做 30 期短视频、每期换个标题和数据,timeline 改起来就像在大型工程图纸上一行行 PS。批量化、参数化做起来都别扭。

第二,协作和版本管理几乎是黑盒。AE 工程是二进制文件,Git diff 不出来谁动了哪根关键帧,出了问题只能靠"我昨天那版备份还在吗"。

第三,和 AI 工具的接缝很差。GPT、Claude 这类大模型最擅长生成的是结构化的、有语义的代码,而不是 timeline 里那种"贝塞尔曲线把这个图层的 opacity 从 0 推到 100"。让 LLM 操控 timeline,等于让一个语言天才用脚去打字。

1.2 程序化视频范式的崛起

这两年圈子里慢慢冒出来一股力量,统称叫程序化视频(programmatic video)——用代码描述视频,而不是用鼠标拖时间线。

代表性的有几条路线:

每条路线都有自己的坚持,也都有自己的天花板。Remotion 强,但它要求你得是 React 玩家,而且商用规模上去之后许可证费用躲不开。Motion Canvas 优雅,但它的 DSL(领域专用语言,就是这个工具自己的一套写法)需要单独学。Manim 是神器,但它太"3Blue1Brown 风"了,你硬要拿它做产品宣传片就有点别扭。

HyperFrames 的角度比较特别——它索性把视频当成一个会动的网页:HTML 写结构、CSS 管样式、GSAP(GreenSock 动画平台,目前全球十几万家网站都在用的 JS 动画库,可以理解成"前端动画界的瑞士军刀")负责动效,然后一个无头浏览器(headless Chromium,就是没有窗口、不显示界面的 Chrome,可以在脚本里被控制)逐帧把页面截下来,ffmpeg(开源的音视频处理瑞士军刀)再把这些帧编码成 MP4。整套链路全是开发者熟悉的工具,LLM 看到 HTML 也比看到自定义 DSL 更亲切。

1.3 真正的痛点不是引擎,是"挑哪个引擎"

但是——我自己折腾下来体会很深——上面这几个引擎,单独看每一个都不错,放在一起就头大。

你做产品宣传片可能想用 HyperFrames 的电影感模板;做数据可视化想用 Remotion 的 React 生态;做编程教程想用 Motion Canvas 的代码动画;做物理科普想用 Manim 的几何变换。结果就是:你得学四套范式、记四套 API、维护四个项目骨架、写四份 CI/CD 脚本。

更要命的是,这些引擎之间几乎没有任何资产复用——HyperFrames 写的模板,扔进 Remotion 完全跑不起来。你画的好不容易调好的动效,换个引擎就得从头再做。

这就是 html-video 想要解决的问题。它的定位不是"再发明一个渲染引擎",而是"在所有引擎上面盖一个统一的接入层":你跟 Agent 说一句"帮我做支 30 秒的产品宣传片",Agent 自己决定调哪个引擎、挑哪套模板,你只看最后的 MP4。

这个思路,其实和 Open Design 在设计领域做的事情完全一脉相承——把 Figma、Sketch、各种 prompt 模板、各种 design system 统一收拢到一个 agent-native(原生为 Agent 设计)的工作流里,html-video 是同一套思想在"动画 / 视频"这条赛道上的延伸,这也是为什么 nexu-io/html-video 这个仓库会把自己描述成 "HTML→Video meta-layer for coding agents",字面意思就是"给编码 Agent 用的 HTML→视频元层"。

聊到这,html-video 的轮廓基本就出来了。下面我们正式拆它的内核。

二、html-video 到底是什么:一个被低估的"元层"

很多人初次看到 html-video,第一反应是"哦,又一个开源剪辑工具"。这个理解差得有点远。

我第一次跑通它的 studio 之后,顺手翻了下源码结构,才意识到它在野心和工程实践上,跟普通"AI 视频工具"完全不在一个层。

2.1 它不是渲染引擎,是渲染引擎的"调度中枢"

先把概念分清楚。

• 渲染引擎(render engine):真正干活的那一层。读取你的 HTML/CSS/JS,用无头浏览器一帧一帧把画面截下来,再交给 ffmpeg 编码成 MP4。HyperFrames、Remotion、Motion Canvas 都是渲染引擎。
• 模板(template):基于某个渲染引擎的"半成品"。比如一个写好的"故障艺术标题"动画,你只要往里塞自己的文案,就能直接用。
• Agent(智能体):这里特指本地的编码型 AI——Claude Code、Cursor Agent、Codex CLI 这类工具,它们能读懂代码、改文件、跑命令。
• 元层(meta-layer):html-video 把自己定位成这一层。它本身不渲染,也不写动画,它做的是:把"用户的意图"翻译成"调度哪个引擎 + 挑哪个模板 + 让哪个 Agent 来填内容"的具体计划,然后执行。

打个不太严谨的比方,如果说 HyperFrames 是发动机、模板是车身、Agent 是司机,那 html-video 就是那个让司机听得懂你"我要去火车站"这句话、然后自动选车、选路线、加油门的车载系统。你不需要懂发动机型号,你只管说目的地。

 用户的一句话 / 一篇文章 / 一个仓库
            │
            ▼
   ┌────────────────────┐
   │   html-video       │  ← 这一层(元层 / meta-layer)
   │   - 意图理解         │
   │   - 模板检索         │
   │   - 引擎选择         │
   │   - Agent 调度       │
   └─────────┬──────────┘
             │
   ┌─────────┴──────────┐
   ▼                    ▼
 HyperFrames        Remotion / Motion Canvas / Manim
 (默认引擎,已接好)      (路线图上,适配器接口已经定义)
   │
   ▼
 无头 Chromium 录制 → ffmpeg 编码 → 本地 MP4

这套架构最大的好处是可插拔(pluggable):加一个新引擎,只需要写一个适配器(adapter,把上层统一接口翻译成下层引擎特有调用的中间层),不需要动模板,不需要动 Agent 提示词,不需要动 studio 界面。整个工作流自动获得新引擎的能力。

这一点的工程意义非常大。我做技术选型这么多年,见过太多"号称可扩展"的开源项目,真要换一个底层模块,基本都要把上半截推翻重写。html-video 把这件事做对了。

2.2 默认引擎 HyperFrames:为什么是它先上车

目前在 html-video 里真正跑通、能渲出真实 MP4 的引擎只有 HyperFrames。其他几个还在路线图上,适配器接口设计好了,但具体适配工作没全部完成。

为什么先接 HyperFrames?莫潇羽@源码七号站 在翻完两边的仓库之后,给出的判断是这样的:

第一,HyperFrames 是 HeyGen 开源的项目(没错,就是那家做 AI 数字人视频起家的公司),技术口碑在那儿,而且本身就是 Apache-2.0 协议,没有许可证负担。

第二,HyperFrames 的设计哲学跟 Agent 时代天然契合。它选了"原生 HTML + CSS + GSAP"这条路,而不是 React 组件或者自定义 DSL,核心判断是:大模型在 GitHub 上看到的代码里,HTML 的占比远远高于任何一种小众 DSL,所以让 Agent 写 HTML 是命中率最高的选择。这个判断我个人非常认同——你让 Claude 写一段会动的标题,它写 HTML+CSS 一遍过的概率,远高于让它写 Remotion 的 React 组件。

第三,HyperFrames 的渲染管线非常工业化。它用 Frame Adapter(帧适配器)模式抽象了"动画运行时",GSAP 可以、CSS 动画可以、Lottie 可以、Three.js 也可以,只要这个运行时支持"按时间戳跳到指定帧",就能接进来。视频生产对确定性渲染(deterministic rendering)的要求非常高——同一段 HTML,跑十次,出来的 MP4 必须一模一样,不能因为浏览器轻微的时序差就少一帧。HyperFrames 在这一点上做得很扎实。

2.3 它和 Open Design 是什么关系

html-video 仓库在 GitHub 上的署名是 nexu-io 组织,跟 Open Design 在同一个 org 下,官方在 README 里直接写明这是"由 Open Design 团队出品的官方项目"。

简单理清楚一下生态层级:

• Open Design:整个团队的旗舰项目,目标是做一个开源、本地优先的设计工作台,生成网页、海报、PPT、3D、视频等几乎所有视觉物料。截止到本文写作时,它已经接入了 100+ skills(技能,就是一段可复用的能力描述)、150+ 设计系统、260+ 插件,后端兼容 Claude Code、Codex、Cursor、Gemini、Qwen、Kimi 等 20 多种本地 CLI。
• html-video:Open Design 在"动态视频"这条赛道上的官方延伸。原本视频能力是作为 Open Design 内部的一个 skill 存在(也就是 video-hyperframes 这个技能包),后来团队把它单独拆出来,做成一个独立的、可单独使用的项目,这样不依赖 Open Design 主体的用户也能直接用。
• HyperFrames:HeyGen 开源的、html-video 当前默认调用的渲染引擎。

这个层级一定要分清楚。我在群里见过有人误以为"HyperFrames 是 Open Design 写的"或者"html-video 就是 HyperFrames",这两个说法都不准。html-video 是元层,HyperFrames 是它接入的第一个引擎,两者是封装与被封装的关系,而不是同一个东西。

2.4 为什么要把它单独拎出来做一个项目

理论上,这套能力嵌在 Open Design 里就够了,为什么还要拆?

我的理解是有三层考量。

一是面向不同用户群。Open Design 是一个完整的设计工作台,装上之后是几百个 skill 一起来的,对只想做视频的用户偏重。html-video 单独拆出来,体量小、上手快,一个仓库 + 几条命令就能跑通,降低了第一次接触的成本。

二是技术路线本身值得独立演进。视频和静态设计在工程上是两套世界——前者要管时间轴、帧率、音视频同步、编码格式;后者要管布局、栅格、字体度量、导出分辨率。把视频独立成项目,可以更激进地把"程序化视频"这条赛道的事情做透,不被设计工作台的节奏拖。

三是为多引擎打基础。如果未来要把 Remotion、Motion Canvas、Manim 都接进来,这个项目会越长越大,继续塞在 Open Design 里反而会让主体变重。独立项目可以独立发版、独立迭代、独立做版本兼容测试。

2.5 给非开发者的一句话翻译

如果你不是技术背景,跳过上面那些架构图,记住这一句就行:

html-video = 一个让 AI Agent 帮你把"想法"变成"真实 MP4"的本地工具,过程中你完全不用懂代码,只要会描述自己想要什么样的视频。

不需要装 Adobe 全家桶,不需要付云渲染费,所有计算都在你自己的电脑上跑完。视频做完了,文件就在本地硬盘,你想发哪个平台都行。

这就是 html-video 的核心价值。下面我们看它的内部到底是怎么转起来的。

三、内核拆解:从一句话到一支 MP4,中间发生了什么

把 html-video 装好、跑一遍流程之后,我建议每个认真用它的人都去翻一翻它的 packages 目录,把内部链路理一遍。一旦你看清楚这条链路,后面遇到任何问题,debug 起来都心里有数。

下面我把核心管线按"上游 → 下游"的顺序拆开讲。

3.1 三种输入,统一抽象成"内容素材"

html-video 接受三种入口,它们对应三类完全不同的使用场景,但底层抽象是统一的——最终都会被转换成一份结构化内容素材(structured content)。

这里有个细节值得拎出来表扬。对于像微信公众号这种服务端渲染(SSR)的页面,html-video 是开箱即用的——它内部跑了一套抓取逻辑,能处理掉公众号那种典型的反爬措施和加密格式。我自己拿一篇公众号文章试过,链接粘进去,几秒钟内容就解析出来了。

更关键的是,抓到的内容是真正会被用进视频的素材,不是用来装样子的。这一点和某些"AI 视频工具"很不一样——它们号称支持链接,实际只是抓个标题,正文还是 Agent 自己瞎编。html-video 是把整篇文章的论点、数据、关键词都喂给 Agent,Agent 据此分镜、写帧文案,出来的视频内容是有真实依据的。

3.2 content-graph:用图结构表达分镜

把素材准备好之后,接下来是这个项目里我觉得设计感最强的部分——content-graph(内容图)。

什么意思?Agent 拿到素材之后,不是简单地"切成 N 段、每段一帧"。它会读完整篇内容,自己判断需要几个场景,然后画出一张"图":

• 节点(node):每个要点变成一个节点,对应视频里的一帧或一组帧。
• 边(edge):节点之间的关系——这一帧是承接前一帧、还是和前一帧形成对比、还是从前一帧的某个细节放大、还是和前一帧并列。

这张图就是分镜的"故事板(storyboard)",决定了视频的叙事节奏。我用伪代码大致表示一下结构:

content_graph:
  nodes:
    - id: scene_1
      type: title
      content: "html-video 是什么"
      template_hint: glitch_title
    - id: scene_2
      type: data_viz
      content: "21 套模板覆盖六大类目"
      template_hint: nyt_data_chart
    - id: scene_3
      type: explainer
      content: "本地渲染流程拆解"
      template_hint: takram_organic
  edges:
    - from: scene_1
      to: scene_2
      relation: introduce_detail
    - from: scene_2
      to: scene_3
      relation: continue_explain

这种"图状叙事"的设计,比传统的"按线性时间轴排"灵活得多。比如要做对比类视频,可以让两个节点平行存在;要做层层递进类,可以让节点之间有显式的"包含 / 展开"关系。这给后面的模板匹配和镜头切换提供了非常清晰的语义。

3.3 模板匹配:从"风格意图"到"具体模板"

content-graph 画好之后,下一步是给每个节点选模板。

html-video 走的不是"用户从一堆模板里手动挑"的路子,而是意图驱动(intent-driven):Agent 根据每个节点的内容性质和叙事位置,自动匹配最合适的模板。

举个具体例子。假设 content-graph 里第一个节点是"开场标题",叙事意图是"制造冲击感",那 Agent 会优先在"title card / VFX 类"模板里检索,然后挑中比如"故障艺术标题(glitch title)"这种自带视觉冲击的模板;如果意图是"建立电影感",那它就会去翻"cinematic 类"模板,挑"漏光胶片帧(light leak cinema)"这种暖调慢镜头风格。

CLI 里也提供了显式的检索命令:

node packages/cli/dist/bin.js search-templates \
  --intent "github stars race" \
  --top 3

这条命令的意思是"给我找 3 个最匹配'GitHub Star 数增长'这个意图的模板"。背后是一个轻量级的语义匹配,根据模板的标签、描述、典型用途打分排序。

我自己跑下来感觉,这个匹配的准确率还是相当能用的。不是 100% 完美,但至少能把检索范围从 21 个收敛到 3 个,人工再选一下就行,效率比"瞎眼挑"高了一个数量级。

3.4 渲染管线:无头浏览器 + ffmpeg 的工业流水线

模板匹配完、内容填好、动效写完之后,就是真正出片的环节。整条渲染管线分四步走:

┌─────────────────────────────────────────────────────────┐
│  Step 1: Agent 生成完整的 HTML/CSS/GSAP 代码              │
│           ↓                                              │
│  Step 2: 启动无头 Chromium 加载这份代码                   │
│           ↓                                              │
│  Step 3: 按目标帧率(比如 30 fps)逐帧截图               │
│           ↓                                              │
│  Step 4: 把所有帧丢给 ffmpeg,libx264 编码成 MP4          │
└─────────────────────────────────────────────────────────┘

每一步都用的是开源世界里最成熟的工具,没有任何黑魔法。

无头 Chromium(headless Chromium) 是真正的关键。它是把 Chrome 浏览器去掉了图形界面、只保留渲染引擎的版本,可以通过脚本控制。html-video 用它的原因很直接——网页该怎么渲染、动画该怎么播,浏览器最懂,直接拿来当"视频抓帧器"用,确定性、跨平台、兼容性都没问题。如果你的电脑里还没有可用的 Chromium,直接装 Playwright(微软出的浏览器自动化框架)自带的就行:

npx playwright install chromium

libx264 是 ffmpeg 里负责 H.264 编码的具体模块。H.264 是当前互联网最通用的视频编码格式,B 站、抖音、YouTube 都吃。用它编码出来的 MP4,基本不存在"哪个平台播不了"的问题。

整条链路里没有任何云端服务,所有计算都在你的本机完成。这意味着两件事:第一,你的素材不会上传到任何第三方服务器,数据安全这件事天然成立;第二,渲染次数不收费,你想出多少版就多少版,只受你硬盘空间和耐心限制。

3.5 为什么"逐帧抓帧"是对的

讲到这,可能有同学会问:既然是 HTML 动画,为什么不直接录屏?屏幕录制不也是常见做法吗?

不行,而且差得很远。

录屏是实时性的——电脑当前帧率多少,录出来就是多少。如果你的动画有复杂的 GSAP 时间线,而电脑这一刻在跑别的任务,有几帧没渲染出来,录屏里就是卡顿。这种结果完全不能交付。

逐帧抓帧是确定性的——浏览器被显式地"暂停"在某个时间戳上,所有 GSAP 动画都被强制推到这个时间点,然后才截图。下一帧再暂停在下一个时间戳,再截图。中间多花几秒、几分钟都没关系,反正每一帧的画面都是"那个时刻动画应该长的样子"。

录屏模式:  时间线只能跟着真实时钟走 → 性能差就丢帧
逐帧模式:  时间线可以被显式定位 → 性能差就慢一点,但帧数对

这个区别,是程序化视频和"AI 自动剪辑"两条路最大的分野。逐帧抓帧的最终产物是"完美的、可重复的"MP4,这是工业级生产线必须要的。莫潇羽@源码七号站 在做对比测试的时候发现,同一段 HTML 在不同性能的机器上跑出来,逐帧模式产出的 MP4 完全一致,文件级别都能 diff 出来,这就是确定性渲染的真正含义。

3.6 为什么押注 HTML,而不是 React

最后讲一个我觉得非常值得思考的设计选择——为什么 html-video 的默认引擎选了押注 HTML 的 HyperFrames,而不是更红的 Remotion?

这背后是一个对"AI 时代代码生态"的判断。

简单粗暴一点说:大语言模型在训练数据里见过的 HTML/CSS/JS,远远多于任何一种特定的视频 DSL 或 React 视频组件库。GitHub 上随便一个仓库都有 HTML,而 Remotion 这种特定项目的代码占比小得多。结果就是:你让 Claude/GPT 直接写 HTML 动画,一遍过的概率非常高;让它写 Remotion 的 <Composition> 组件,容易出现各种 API 用错、状态管理用错的低级问题。

这个洞察其实不只适用于视频。我个人的判断是:未来一段时间里,任何想"让 AI 写代码生成内容"的工具,都应该优先选 AI 训练数据里高频出现的语言和范式,而不是逼着 AI 学一套新东西。这个原则对所有 AI 工具的架构师都是有价值的。

理解了这一点,你就能理解为什么 html-video 不是"在 React 上面再封一层",而是直接拥抱"HTML+CSS+GSAP"这条最朴素的路线。看起来不够时髦,但工程上极其合理。

四、21 套模板矩阵:覆盖了哪些真实需求

模板这个东西,做得好不好,直接决定了一个视频项目的天花板。我见过太多开源视频工具,模板看着花哨,真要用,要么版权不清不楚,要么风格千篇一律。

html-video 的 21 套模板,我自己挨个跑过一遍,有几个判断可以分享。

4.1 整体的设计审美在线

先说结论:这 21 套模板的审美水平,在开源界算是头部水准。不是那种"程序员勉强凑出来的可视化",而是有明显的"设计师介入"痕迹——栅格对齐、字号层级、留白比例、动效曲线,这些细节都讲究。

更关键的是,所有模板都是"许可清晰(license-clean)"——意思是版权来源明确、可以商用,不会出现"用了之后被版权方投诉"这种坑。这对独立创作者是一个非常实在的保障。

按内容类型大致分成六个类目:

4.2 每个模板都是"会动的单文件 HTML"

这一点我必须强调一下,因为它和市面上很多"模板库"不一样。

html-video 仓库里展示的每一个模板,不是 PSD、不是 AE 工程,而是真实可运行的单文件 HTML。打开它,在浏览器里就能看到完整的动画播放;丢进 html-video 的渲染管线,就能直接出 MP4。

这意味着两件事:

第一,模板的二次开发门槛极低。你哪怕完全不懂动画原理,只要会改 HTML 里的文字内容、改 CSS 里的颜色变量,就能定制出一个属于自己的版本。模板的源码本身就是一份学习材料。

第二,模板是"自我说明"的。不需要额外的文档来描述这个模板长什么样,你直接点开就看到了——文档即代码,代码即效果。这是 Web 范式相对于专有视频工具最大的优势。

举个例子,假设你想改"NYT 风折线图"模板的颜色,可能只需要改这么几行 CSS:

:root {
  --chart-line-color: #c8102e;    /* 主曲线颜色 */
  --chart-grid-color: #e5e5e5;    /* 网格线颜色 */
  --headline-color:   #111111;    /* 大标题颜色 */
  --annotation-color: #666666;    /* 标注文字颜色 */
}

剩下的动画逻辑、布局排版、动效曲线,完全不用动。这种"通过 CSS 变量做主题切换"的设计方式,是现代 Web 开发的标准做法,极其友好。

4.3 模板背后的"动效语法"是标准化的

更深一层,这 21 套模板用的动效语法是统一的 GSAP + CSS,不是各自为政。

// 几乎所有模板里都能看到的典型动效写法
gsap.timeline()
  .from('.headline', { y: 40, opacity: 0, duration: 0.8, ease: 'power3.out' })
  .from('.subhead',  { y: 20, opacity: 0, duration: 0.6 }, '-=0.4')
  .from('.data-point', { scale: 0, stagger: 0.1 }, '-=0.3');

这段代码的意思是:大标题先从下方淡入、副标题稍后跟上(并且和大标题动效有重叠)、再然后是数据点一个一个弹出来。看着复杂,其实就是几个标准的 from / to / timeline 组合。

为什么要把动效语法统一?因为这决定了 Agent 能不能"跨模板复用经验"。如果每个模板都用不一样的动画库、不一样的语法风格,Agent 改起来就要重新学一遍;统一成 GSAP 之后,Agent 在 A 模板上学会的写法,可以无缝迁移到 B 模板。

4.4 多比例适配:横屏、竖屏、方屏一键切换

视频做完之后,最头疼的事之一就是平台适配。B 站要 16:9,抖音要 9:16,小红书要 4:5,微信视频号还要看具体场景。传统工具里这意味着要重新做工程文件、重新对齐元素、重新出片。

html-video 把这件事变成了"切个按钮"的操作。支持的比例:

• 16:9 横屏:B 站、YouTube、官网 Banner
• 9:16 竖屏:抖音、视频号、Reels
• 1:1 方屏:Instagram、朋友圈、信息流广告
• 4:5 竖屏小屏:小红书首图、Pinterest

底层是 CSS 在干活——所有元素的尺寸都用相对单位(rem、%、vw/vh)写,容器一改,内容自动重排。当然,极端情况下还是要 Agent 微调一下文字截断、图标位置,但 90% 的情况是自动适配的,人工补刀很少。

4.5 一个真实的使用思路:把模板当"积木"

我个人摸索出来的最佳实践,是把这 21 套模板当作积木来用,而不是当作"成品视频"用。

一支正经的视频通常是多个模板拼接的:

开场用"故障艺术标题"(2.5 秒)
↓
切换到"极光液态渐变"做主视觉(3 秒)
↓
插入"NYT 风折线图"展示核心数据(5 秒)
↓
用"打字机光标"模板做技术细节解说(8 秒)
↓
最后用"Logo 收尾卡"签名(2 秒)

20.5 秒的视频,五个模板,每个模板贡献一种独特的视觉体验。这种"积木式拼接"的玩法,比传统"找一个大模板从头改到尾"高效得多,也更不容易撞款。

五、Agent 自动识别:本地 14 个编码 Agent 任你切

聊完渲染引擎和模板,接下来说 html-video 的另一个亮点——Agent 接入层。

这个东西怎么强调它的工程价值都不为过。我自己用过太多 AI 编程工具,每个都得单独配 API key、单独装客户端、单独学命令格式。html-video 的做法非常聪明:它不要求你用某一个特定 Agent,而是自动扫描你电脑上已经装好的所有 Agent,让你随便切换。

5.1 支持的 14 个本地 Agent

来看一下完整名单(顺序遵循 html-video studio 默认的优先级):

这个支持矩阵覆盖了当前主流的所有编码型 Agent。无论你是 Claude 重度用户、Cursor 老粉、还是公司里用通义灵码的 Java 团队,都能直接复用现有配置,不需要为了 html-video 单独装新工具。

5.2 自动探测的原理

html-video 是怎么知道你电脑上装了哪些 Agent 的?答案很朴素——扫 PATH 环境变量。

什么是 PATH?简单说就是你电脑里"系统能直接调用的命令清单"。任何 CLI 工具装上之后,都会把自己的可执行文件路径加到 PATH 里。html-video 启动的时候,会按内置的 Agent 名单一个一个去 PATH 里查:能找到 claude?那 Claude Code 可用。能找到 cursor-agent?那 Cursor Agent 可用。

studio 顶栏会显示一个 Agent 切换下拉框,没装的 Agent 是灰的、装了的是可点的,一目了然。

如果你想自己确认探测结果,CLI 提供了一个 doctor 命令:

node packages/cli/dist/bin.js doctor

这条命令会同时检查:

• 系统里装了哪些 Agent
• 渲染引擎是否就绪(HyperFrames 是否能正常调用)
• Node.js、pnpm、ffmpeg、Chromium 这些依赖的版本

跑一次就知道当前环境哪里有问题、哪里就绪。我每次在新机器上装完 html-video,第一件事就是跑 doctor,比一项一项手动验证快太多。

5.3 优先级和兜底机制

studio 顶栏的下拉框是有默认排序的,Open Design (Vela) 排在最前面,后面依次是其他 Agent。这个排序不是随机的,背后是 html-video 团队基于实际效果做的权重判断。

具体的逻辑大概是这样:

启动 studio
  │
  ▼
是否检测到 Open Design (Vela)?
  ├─ 是 → 默认选中 Vela(成本低、模型多、登录一次能用全套)
  └─ 否 → 找列表里第一个可用的 Agent
            │
            ▼
       一个本地 Agent 都没装?
          ├─ 是 → 自动切到 Anthropic Messages API(需要 API key)
          └─ 否 → 用找到的第一个

这套兜底机制的设计哲学是:让用户永远有一个能用的后端。哪怕你什么本地 CLI 都没装,只要在 settings 里填个 Anthropic API key,studio 立刻可用。

我个人很欣赏这种"零摩擦上手"的产品意识。开源工具最容易死在第一步——"装完跑不起来"。html-video 把"跑不起来"这种事提前用兜底机制堵掉了,这是真正的工程功底。

5.4 切换 Agent 的实际体验

studio 里切换 Agent 真的就是点一下下拉框的事,不需要重启,不需要重新登录,当前的视频项目状态完全保留。

我自己测试过:

• 用 Claude Code 起手写了一个分镜
• 切到 Cursor Agent,继续改某一帧的文案
• 再切到 Codex CLI,让它优化动效曲线

整个过程视频项目是连续的,每次切换只是换了"谁在背后写代码"。这种顺滑感在开源工具里非常少见,大部分项目都是"绑死一个后端、换一个就要重新配"。

5.5 为什么这件事比看起来重要

你可能会想,Agent 切换不就是个便利功能吗,值得专门写一节?

我的看法是,这件事意义远不止"方便"。它背后是对 Agent 生态多元化的尊重。

当前 AI 编程工具的格局还在剧烈洗牌中。三个月前你重度用 Codex,现在可能已经全面切到 Claude Code;明年说不定又冒出来一个新的更强的 Agent。如果你的视频项目和某一个特定 Agent 绑死,那这种工具更替的时候,你就得跟着重做一遍。

html-video 把 Agent 抽象成了"可热插拔的工作流后端",用户的项目数据、模板选择、内容素材都不依赖于具体哪个 Agent——你的视频项目可以跟着你穿越不同的 Agent 时代。

这是产品架构上的远见。

六、本地实操全流程:从依赖安装到出片

讲了这么多原理,该上手了。这一节按"装环境 → 启动 studio → 实际出片"的顺序走完整流程,你跟着做一遍,大概 20 分钟就能出第一支视频。

6.1 依赖清单

先把环境检查清楚。html-video 对运行环境的要求不算苛刻,但有几个版本要对齐。