把时间锚在词上而不是秒上，Hypit 把爆款视频做成了一门编程语言

做短视频的朋友大概都接过这种活儿。一条 UGC 广告跑量了，老板丢来一句话，换产品再出 50 条变体。

在剪辑软件里，这就是 50 次从头再来。复制工程、重录口播、逐条对字幕、调 B-roll 时间点、导出，改到第 20 条的时候你已经分不清哪条是哪条了。

Hypit 对这件事有个不一样的看法。

这不是剪辑问题，是编译问题。

这个 7 月底才创建的仓库，7 周攒了 7340 个 Star、868 个 Fork，主体是一套 TypeScript monorepo，120 多个包，2099 个文件。它干的事情一句话能说清，给 AI Agent 一门视频语言，丢一条爆款视频进去，Agent 把整个工作流逆向成源码，然后你换词、换脸、换 B-roll，重新编译，一条命令出 100 个变体。

它到底装了什么

很多人第一眼会把 Hypit 理解成一个「AI 剪辑工具」，这就把它看小了。拆开仓库你会发现它装了三层东西，而且这三层的生命周期是刻意分开的。

第一层是 Agent Skill。npx skills add hypit-ai/hypit -g 装进来的不是可执行程序，是 78 个文件的知识库，skills/hypit/SKILL.md 加上 references 目录里一整套创作方法论。这个 Skill 的写法很有意思，它让 Agent 扮演「导演兼制片人」，通篇在讲怎么理解一条视频为什么吸引人，什么叫节奏，什么叫揭示的时机。playbooks 里分了 craft 和 formats 两类，craft 管手艺，image-direction.md 讲图像模型对什么措辞有反应，voice-direction.md 讲怎么选声音，formats 管体裁，排行榜、街访、短剧、解说各有一套模板。

第二层是可执行程序，单独的 npm 包 @hypit/hypit，提供 hypit 命令、hypit studio 可视化界面、官方包库和 Runtime。文档里反复强调 Skill、可执行程序、视频项目三者「可以住在毫不相干的地方，互不作为副作用安装」。

第三层才是真正的硬核，SVML 语言和它的编译器。

这三层加上底下的编译管线，全貌长这样。

后面几节就沿着这张图，从语言层一路拆到渲染层。

SVML 长什么样

看一个真实的例子，仓库里 examples/ranking-football/reference.svml，一条 20 秒的足球梗排名视频。文件开头是 XML 声明加 import 序言：

<?svml using="@hypit/markup@1"?>
<svml>
  <import from="@hypit/script@1"/>
  <import as="gpt" from="@hypit/gpt-image@1"/>
  <import as="seedance" from="@hypit/seedance@1"/>
  <import as="render" from="@hypit/render-hyperframes@1"/>
  ...
</svml>

这里其实有个容易被忽略的设计。@hypit/markup 这个解析前端自己没有任何视频词汇，README 里原话是「The package has no built-in Script, media or video vocabulary」。<script> 标签能用，仅当某个 import 进来的包通过 Markup Host facet 贡献了这个标签。也就是说，语言的核心是个空信封，所有能力都是包注册进来的。生成视频、生成图片、语音设计、字幕、渲染，每种能力一个包，import 什么就有什么。插件系统不是外挂，是语言的地基。

再看正文。台词写在 <script> 里，长这样：

<script id="story">
  <ronaldo>
    <HOST>Ronaldo is <D | Dee> tier. || Bro has @{hair-gel} more || hair gel than @{trophy} trophies || at this point.@{/trophy}@{/hair-gel}
  </ronaldo>
</script>

|| 是分词边界，@{hair-gel} 是内联语义引用，标记这里要出表情包。往下还有正儿八经的「导演指令」，人设用 <text:Value> 写了三段，长相、机位、场景各一段，拼进 image-kit 模板渲染成图像模型的 prompt，再用 <gpt:Image prompt={presenter-prompt} resolution="2K"/> 生成主持人形象，用 <fish:VoiceDesign> 设计她的音色。

你想想看，一条 TikTok 视频的全部创作决策，人设、台本、镜头、贴纸、音色、音效，全部落在一个可读、可 diff、可版本管理的文本文件里。

时间的锚在词上

整套设计里最值钱的想法，我认为是这一条。

你琢磨一下传统的时间线，一个转场发生在第 3.2 秒，一个字幕出现在第 7.8 秒，时间锚在秒上。换一版口播，所有秒数全作废。Hypit 把锚换到了词上，packages/script 的 README 里有一个很数学的说法，解析后的台本产生恰好 2M + 2N + 2 个语义锚点，M 个 Token 和 N 个 Segment 各自的头尾两端，加上整个台本的起止。

切歌、出贴纸、翻排名板，这些事件在源码里绑定的不是时间戳，是某个词、某个 Segment、某个 Moment。克隆一条爆款，Agent 用 WhisperX 把参考视频的语音做词级对齐，搞清楚每个画面变化响应的是哪个词，然后在新的台本上重建这层响应关系。

改一个词，整条视频的时间自动重排。

README 里那句「rewrite a line and the timing re-flows itself」就是这个机制的自然结果。

我一直觉得这个思路有种熟悉感。它就是 CSS 里流式布局对绝对定位的胜利，内容变了，布局跟着内容走，而不是每次改内容都重新摆一遍坐标。做 50 条变体不再是 50 次重排，是 50 次重新编译。

把这个分岔画出来，就是下面这张图。

同一个改词动作，左边进右边出，差别只在事件绑在秒上还是绑在词上。

渲染端是一台不撒谎的编译器

语言层讲完了，再看它怎么变成 MP4。说真的，这部分我原以为会看到各种胶水代码，实际拆下来，架构洁癖重得少见。

渲染入口是 <render:Video composition={...}/>，packages/render-hyperframes 把它降级成三个独立的字节操作，静音的帧精确视觉流、48 kHz 的整条音频流、最后一步容器封装。三条流各自验证，各自可以换 Provider。视觉这头的实现是 packages/hyperframes，它把组合语义图降级成一份可移植的 HyperframesDocument，骨子里就是 HTML、CSS 加逐帧驱动的 JavaScript。

真正出帧的是 packages/provider-hyperframes-local，无头 Chrome 进程池，通过 CDP 逐帧截图成 PNG，再编码成静音 MP4。帧率、帧数、画布尺寸在文档里就是显式字段，任意一个 worker 都可以独立求值任意合法帧段，所以才能横向切开并行渲染。资源引用在编译产物里全部是 hypit-resource:// 占位符，附上每个依赖的 BlobRef，字节计数和 MIME 都是声明好的，staging 阶段才物化成真实文件。音频也绝不偷偷塞进渲染进程，改音乐永远碰不到视觉那条流。最狠的是出口验收，ffprobe 探测产物，不是 H.264 就直接拒绝。

Worker 数量也有讲究，不是拍脑袋写死的。concurrency.ts 里的 autoWorkerLimit() 按内存算，公式是总内存除以 2 再除以 1.5 GiB，按 CPU 算是核数减 2，两者取小。每个 Chrome 预算 1.5 GiB，一半内存和两个 CPU 槽位留给宿主。运行期还有个 CaptureConcurrency 类做在线吞吐对比，自动模式下从上限的一半起步，每加一个浏览器都拿真实采集批次对比 fps，增量不足 5% 就回退，多余的在批次间退役。

顺带戳破一个印象。README 的三个示例都写着「64 headless Chromium processes 并发渲染」，听着很吓人。按上面那个公式反推，64 个 worker 需要一台 192 GiB 内存的机器。你手里那台 16 GB 的 MacBook，跑 5 个 Chrome 就到顶了。渲染本地不要钱，这没问题，但「本地集群渲染」的硬件门槛，README 没有直说。

模型随便换，中国模型浓度很高

Provider 矩阵是这个项目另一个务实的地方。视频生成有 Seedance，图片有 GPT Image、Nano Banana、Seedream、Grok Imagine，语音有 Fish Audio、ElevenLabs、MiniMax、MiMo，还有 Volcengine 抠图、WhisperX 对齐、yt-dlp 拉素材。国产模型浓度相当高，配上 HypiHub 这个官方托管网关，或者你自己的 API key。

还有一条容易被营销淹没的事实，生成模型是可选的。SVML 的工作流可以纯代码渲染，字幕、动态图形、前端代码画的视觉，不调任何生成模型也能出成品，零生成费用。README 里那句「Not just a script, the whole workflow」的底气在这儿，它管的是结构，素材从哪来是插拔的选择。

三个示例的成本也贴了实数，足球排名 $1.15，播客切片 $1.07，街访 $1.09，每条都是 Seedance 720p 的 A-roll 加 GPT Image 的图。老实说，一块钱出一条 20 秒左右的成品，量产后这个成本结构对投放团队是真有吸引力。

先看清协议，再谈上车

坦白讲，以上都是它好的一面，而且是有源码背书的好的一面。下面这几件事，README 的徽章栏不会替你总结。

最要紧的是协议。徽章写着「Apache-2.0 with conditions」，conditions 展开是三条硬的。禁多租户，拿它做 SaaS 卖给两个以上外部方，先找 Hypit.AI 拿书面授权。禁商业转售，fork 可以，但 fork 产物必须沿用同一协议且不得商业牟利。CLI 和运行报告里的 LOGO 与版权信息不许摘。贡献者条款更值得读两遍，你贡献的代码，官方可以拿去商用，包括云业务，而且官方保留「随时把协议调严或调松」的权利。这在法律上叫非 OSI 认证的自定义协议，GitHub 把它标成 NOASSERTION。个人做内容、公司内部用，都没问题，产物版权也明确归你。但想基于它创业做托管服务的，先去谈商业授权。

钱的方向也值得看一眼。工具本身免费，模型服务收费，这合理。但整个仓库里商业化埋点不少，HypiHub 是推荐的托管服务，Monid 的合作链接挂着 fpr=alvin-45480 联盟码，HiAPI 是 launch partner。这不是错，开源公司要活命，只是读者该知道 Agent 的推荐路径天然导向官方计费侧，尽管任何自有 API key 都能绕开。

成熟度则是时间问题。仓库 7 月 29 日创建，我拆的这天是 9 月 17 日，两天之内发了 5 个 release，从 v0.1.12 直接跳到 v0.2.1。迭代猛的另一面是接口随时会动。贡献者 10 人，前两位贡献了 1274 次提交里的绝大多数，bus factor 是 2。issue 区翻一翻，前排几乎全是官方自己的修复 PR，真实用户的深度反馈还很稀薄。

还有一条我自己补的，克隆爆款本身的法律与平台边界。例子工程里直接用了球员真实照片做排名板素材，逆向别人的创意结构在平台规则里怎么定性，生成内容的标识义务各法域正在收紧，批量 100 条变体投放对账号的连带风险，这些仓库一个字没提。

工具无罪，用它的人得自己掂量。

和 Remotion 们比，它站在哪

竞品其实分两类。Remotion 一系把视频当代码写，工程能力强，但没有生成模型编排，也没有 Agent 入口，时间轴还是秒级的。Opus Clip、CapCut 一系是黑盒 SaaS，好用但你 fork 不了它的结构。Hypit 站的位置很清楚，面向「结构可复用、素材可插拔、变体要量产」的场景，把前面两者的短板各补了一块。代价是学习曲线，你得接受「写视频」这个心智，以及一台内存充裕的渲染机。

结构和素材分开，是门手艺

拆完这个仓库，能带走的不只是一个工具。

它真正做对的事，是把「结构」和「素材」切开了。结构里锚定语义，词、事件、Moment，素材走 Provider 插拔，时间由结构对素材的响应关系推导出来。这个模式不挑行业。落地页的文案变了，版式自动重排，因为版式锚的是内容块不是像素坐标。报表的数据变了，图表自动重绘。凡是「内容高频变体、骨架相对稳定」的生产，都值得问一句，我的时间锚在秒上，还是锚在词上。

至于要不要现在就用 Hypit，我的判断是这样。批量做投放变体的团队、想用 Agent 自动化内容生产的独立开发者，值得花一个周末跑通它的 football 例子，一块钱的成本试错。偶尔剪一条片的普通创作者，Remotion 都嫌重的话，这个更重。而想做托管服务创业的，先去读协议第三遍。