Hypit 和 HyperFrames 像吗：两条「用代码做视频」的路线，我都在本机跑了一遍
前几天有人问我：Hypit 和 HyperFrames 感觉有点像，帮我分析一下——使用场景、优缺点、原理。
这两个项目确实像。都是开源的、都跟着 Coding Agent 用、都在无头浏览器里把代码渲染成视频——相似度高到有人以为它们是「同类产品的两个版本」。
但把两个都装到本机跑过之后，我的结论是：它们不是一回事。 真正区分它们的不是功能清单，而是更底层的一个问题——视频的时间轴，锚定在什么东西上。
HyperFrames 锚在**「秒」：每个画面的开始时间和持续时长，是写在代码里的坐标。 Hypit（SVML）锚在「词」**：你不写秒数，你写「说到这句话时，放这张图」。
这个差别听起来很细，但它决定了一切：改一句台词会发生什么、能不能批量做变体、上手门槛在哪、坑埋在哪里。下面把两者的原理、我跑出的实测数据、各自的坑，一次讲清。
一、先说它们为什么像
如果只看表面，这两者像到会认错。四个共同点：
① 都在「视频即代码」这条路上。 产物是纯文本源码，不是封闭的工程文件——可 diff、可版本控制、可复用。这一派的共同信念：AI 做视频的瓶颈不是模型能力，而是「视频该用什么语言来写」。HyperFrames 的 HTML 时间轴和 Hypit 的 SVML 都是这个信念的产物。
② 都在无头浏览器里渲染。 HyperFrames 用 Chromium 逐帧截屏、再合成；Hypit 的 <html:Video> 同样把画面交给 Chrome 栅格化。渲染原理同源——也意味着两者的渲染成本都落在本地硬件上，不在 API 账单里。
③ 都不是视频生成模型。 它们不生成像素，生成的是「怎么画每一帧」的指令。真人写实镜头、实拍质感不是它们的地盘——那是 Seedance、H3 这类生成模型的事。
④ 都把 Coding Agent 当第一入口。 你让 Codex / Claude Code 读源码、改源码，人来给判断。人机分工一致：人管品味和方向，Agent 管执行和修改。
二、真正的区别：时间轴锚在「秒」，还是锚在「词」
做个思想实验——也是我在本机真实做过的事：把一句台词改短 1.6 秒，两条路线会发生什么？
HyperFrames 路线： 台词写在 HTML 里，时间点是 data 属性——「这个画面从第 12.0 秒开始，持续 4.4 秒」。台词改短之后，后续所有镜头的开始时间、时长都要跟着挪。渲染引擎会自动重渲，但每一个依赖旧时长的时间数字，都得手动修正。机器不欠你的，是你欠机器的。
Hypit（SVML）路线： 台词在源码里是台词的形态，画面绑在「哪句话」上，不绑在秒上。改完那一行、换掉对应音频、重新构建——后面所有画面自动平移。因为窗口长度本来就是由音频素材的时长推导出来的，不写死。
这就是锚定物的差别：秒锚定 vs 语义锚定。
- 秒锚定的世界，「第 3.2 秒」是一个硬编码坐标，改文案是在动坐标轴；
- 语义锚定的世界，坐标系本身就是台词，秒数只是每次编译时算出来的结果。
由此长出各自独一份的能力：
- SVML 独有：改文案不破同步。 换语言、换配音、重录某一句、批量做 100 个变体——画面自动跟着语义位置重排。这是本地化和系列化内容的使能技术。
- HyperFrames 独有：视觉完全自由。 因为它本质是「写网页」，任意 HTML/CSS/SVG/Canvas/Three.js 都能上。用它的作者有一个案例：把产品界面截图做成像素级复刻，让视频看起来像真机录屏——这类活生成模型做不了，而秒锚定反而是优势：像素级内容的时间点本来就稳定。
三、一条很值钱的负面证据：JSON 和 XML 是死路
HyperFrames 团队讲过一个弯路，我认为是整个「代码即视频」领域最值钱的一条负面证据：
他们最初尝试用 JSON / XML 引入数据结构，让模型通过输出这些结构来描述视频。结果——并不能帮模型「看见」某一帧长什么样，编辑和修改效率极低。换成 HTML/CSS/JS 之后，「情况发生了翻天覆地的变化」。
为什么？因为对模型来说：结构化 ≠ 可被想象。 JSON 只解决「可被解析」，不解决「能被理解」。HTML 之所以行，是因为它落在模型的母语分布里——预训练见过海量网页，模型真的能「脑补」出第 63 秒长什么样。
那 SVML 为什么不是同一个坑？因为它根本没有要求模型「想象画面」。它做的是另一件事：给 Agent 一门面向视频的声明式语言——Agent 读源码、改声明，编译器负责落地。而 SVML 落在的是模型的另一个母语分布：台词 / 文本。
一句话：死路是「为结构化而结构化」；活路是「落在模型原生分布上的表达」。 HTML 落在网页分布，SVML 落在台词分布。
四、本机实测：两条路线各跑成什么样
不吹不黑，全是我自己在 DGX Spark 上跑的。
HyperFrames（0.7.61，npx 直接跑）：
- 环境自检（doctor）全过；质量检查五门（lint / 运行时 / 布局 / 运动 / 对比度）零 error；
- 简单场景渲染 150 帧约 11 秒——约 0.073 秒/帧，60 秒的视频大约 2–3 分钟出片；
- 中文渲染没问题（系统字体 Noto Sans CJK SC 直接可用）。
Hypit（从源码跑）：（第一次上手的完整记录在这篇：Hypit 实测：0 成本、纯代码渲染出第一条视频）
- 做出了一条 85 秒的竖屏成片：9 张图由本机 ComfyUI 生成、10 段配音由本机 VoxCPM2 生成，全程 0 元、0 API key；
- 做了「改一句台词」的成本对照：SVML 工程重渲 47.2 秒 vs 我手头的 Pillow 生成脚本 85.8 秒——SVML 反而更快（因为它用无头浏览器栅格化，Pillow 是纯 Python 逐帧重画）；
- 但真正值钱的不是速度，是这个：我原来的脚本里，字幕和配音是两份独立列表，8 句里已经漂了 4 句（还有一处错别字）；SVML 版本的字幕直接来自台词的投影，结构上不可能漂。 少一个真相来源，就少一处必然发生的漂移。
一个诚实的边界：词级锚定我还没验证。 官方演示里「画面锚到某一个具体的词」，需要 WhisperX 做词级对齐；本机没装，实际落地到的是段落级（整句跟配音时长走）。「改文案不破同步」在段落这一层是真的；词级的那层，等装完对齐工具再补课。
五、各自的坑（都真实踩过）
HyperFrames：
- 改文案要自己挪时间点——上面说的秒锚定代价；
- 开箱默认是「PPT 味」。 这点作者自己也很诚实：21 分钟一条提示词生成的视频「仍然非常像幻灯片演示，有点枯燥」。差的是你的反馈，不是框架的能力；
- 当时它还不支持把参考图直接粘给 Agent——要做像素级复刻，得把截图发进聊天框。
Hypit：
- 必须 clone 源码 + pnpm 构建才能跑；仓库里的老示例和当前版本还不兼容——我第一次搭工程，把 8 个报错坑全踩了一遍（import 不能起别名、素材引用要直接用元素 id、同一条轨道里一个时间窗只能出现一次、字幕必须显式挂进成片、时间间隔必须落在整帧上……每个报错都明确，但一个不落）；
- 手写 400 行重复 XML 很容易出错，最好自己写生成器；
- 口型不能 100% 一致（复杂语句、快语速下差异明显）；
- License 要看清：它是「改良 Apache 2.0 + 附加条件」——禁止多租户 SaaS、禁止商业再分发、不得移除 LOGO。**不是 OSI 意义上的完全开源。**想做基于它的服务生意，先谈商业授权。
六、那到底怎么选
不是二选一，是两层：
| 你要做的事 | 选谁 | 为什么 |
|---|---|---|
| 界面演示、像素级复刻、任意矢量与三维画面 | HyperFrames / Remotion | 视觉 = 浏览器全能力；此类内容时间点稳定，秒锚定的缺点不痛 |
| 口播 / 台词类内容、批量变体、多语言、系列化 | Hypit（SVML） | 改文案不破同步；素材与台词解耦，一份工程出多版 |
一句口径：信息型、数据型内容 → HyperFrames；语义型、系列化内容 → SVML。
但别急着「两个都要」。它们工程文件是两套完全不同的 DSL（HTML composition vs .svml），目前没法直接互相引用；要混合用，得自己写一层「桥」。先想清楚这层桥的维护成本，再决定。
七、最后一个判断
两条路线的共同母题，比任何单点差别都重要——它们都在证明同一件事：AI 视频质量的分水岭不是模型，是「视频用什么写」。
而在本机把两条都跑完一遍之后，我最想留下的是这句话：
「视频即代码」的价值不是快——渲染层面其实只差几十秒——而是让「改一处」有了确定的位置，并且少了一个真相来源。
来源与说明
- Hypit：GitHub 仓库
hypit-ai/hypit（2026-10-10 实测 20,695 Star；创始人 2026-10-19 自述约 2.3 万 Star，单方口径）；创始人访谈（十字路口，2026-10-19）；本机实测为 2026-10-20 的实验记录。官方示例成本（约 $1.07–1.15/条）来自媒体报道，未在本机复现。 - HyperFrames：教程视频（B站 AIJasonZ，2026-09-28）；「4 小时做完发布 / 推特 10 万播放」等案例为作者单方口径；本机实测为 2026-10-10 的环境与渲染记录。
- 本文写于 2026-10-28。两个项目迭代都很快，具体行为以你拿到的版本为准。
- 这是一篇个人实测笔记，不构成任何推荐；文中所有数字均标注了来源方与日期。