踩了10个坑后,我弄清了Vibe Motion的真实玩法

0 评论 882 浏览 1 收藏 29 分钟

Vibe Motion正在颠覆传统视频制作逻辑,用代码驱动动画生成的Remotion和HyperFrames两大框架让视频生产变得工程化、可调试。从全合成动画到真人口播视频,作者通过踩遍10个技术坑,揭示了AI时代视频制作的底层逻辑与实战经验。这场从React组件到HTML/CSS的技术迁移,正在重新定义动态视觉内容的创作边界。

最近又出了一个新概念,叫Vibe Motion。

一开始是有点无感的。自从卡帕西定义了Vibe Coding以后,圈子里基本什么都往 vibe 上套。Vibe Writing、Vibe Design、Vibe Marketing… 感觉只要跟 AI 沾边的,前面都能挂个 vibe。

而且我第一反应是,这大概是用 Seedance、可灵这类视频生成模型做视频的方法论。AIGC 直接生成视频嘛,往 vibe 上包装一下也正常。但作为一个 AI 极客,新概念出来了肯定还是会去研究的。

调研了一圈才发现,完全不是我想的那样。

Vibe Motion 不是用 AI 直接生成视频,而是用代码来驱动动画和视频的生成。

目前这个方向最火的两个开源框架是Remotion和HyperFrames。有意思的是,这两个框架其实比 AI 编程热潮还要早。Remotion 2021 年就有了,HyperFrames 是 2026 年 4 月才开源的新玩家,但底层思路一脉相承。

底层逻辑其实不复杂:它们都是把网页代码逐帧截图,然后拼成视频。区别在于写法。Remotion 用 React 组件来描述视频的每一帧,你写的是 JSX 和 CSS;HyperFrames 用原生 HTML + CSS + GSAP 动画,写的就是网页。最终都通过无头浏览器逐帧捕获,再用 FFmpeg 编码成 MP4。

两者的优势和短板也很明显:

Remotion的强项是组件化和复用。你做过一个动效模版,下次同风格的视频直接 import 进来改参数就行。而且因为是 React,能做参数化批量生成,数据驱动出 100 条不同内容的视频都没问题。短板是,它对真人实拍素材的混编不太友好。你要把一段真人口播和代码画面揉在一起,会很别扭。

HyperFrames的强项是对 AI Agent 极度友好。因为写的是 HTML,而大模型写 HTML 的能力天生就很强,Agent 改个文件、调个样式、抽帧检查都很顺畅。加上完全免费(Apache 2.0),没有按人头或渲染次数收费的门槛。短板是太新了。2026 年 4 月才开源,生态、文档、社区沉淀都不如 Remotion 成熟,踩坑的概率更高。

这些优劣势后面在具体案例里会反复体现,这里先有个印象就行。

往深想一层:AI 正在逐步覆盖我们的感官

但说坑之前,你有没有发现,从 Vibe Coding 到 Vibe Writing、Vibe Design,再到现在的 Vibe Motion,有些事悄然发生了变化。

AI 最早搞定的是代码。代码的验收标准很客观,能跑就行,不能跑就是 bug,AI 很容易得到明确的反馈去迭代。

然后是文字。早期 AI 写东西一股子机器味,但随着模型能力增强,拟人感越来越强,人们开始接受用 AI 来写文章、写书、甚至写论文。

接着是设计。这一步难度跳了一个台阶,因为审美是主观的,AI 不光要理解语义,还要理解人觉得什么好看。

现在轮到了动态视觉。视频比静态设计又多了一个维度:时序。不光要好看,还要在对的时间出现对的东西,节奏感、信息密度、画面编排全都要对。

但这个路径:语义理解-逻辑执行-审美判断-时序编排。每往前走一步,AI 需要理解的东西都在叠加。

但这不只是AI 变强了这么简单。

它其实是在往人类理解世界的方式上靠拢。我们人感知信息就是这个顺序,先读文字,再看逻辑,再感受美不美,再体验节奏和动态。AI 正在沿着这条线,逐步覆盖我们的不同感官通道。

这是一件值得认真想想的事。

而且这件事正在加速。就在我写这篇文章的时候,Figma 刚在 Config2026 上发布了几个功能,有一个就是Figma Motion,把动画时间线直接内置进了设计画布,还支持 MCP 协议,动画帧可以直接传给 AI 编码 Agent 去实现。连设计工具的巨头都开始把 Motion 当一等公民了。这个方向,确实有的搞的。

但 Vibe Motion 不是你想的那样

聊完大趋势,回到 Vibe Motion 本身。

很多人看到这个概念的第一反应是:AI 是不是能一句话帮我生成一条视频了?

不是。至少现阶段不是。

我实测了两周,最大的感受是:Vibe Motion 更像是把视频制作变成了一套工程流程。可调试、可验证、可复用。

以前剪视频,哪里不对靠感觉改。代码做视频,哪里不对你能定位到具体的时间码、图层和坐标。这是本质区别。

所以这篇文章不是概念科普,是我实测下来,大概踩了 10 个坑以后的一次复盘。从最早的实验验证,到想做成可重复产出架构时一路踩坑,再到最后沉淀出一套选型框架。

测试验证:CC + Remotion

了解完概念之后,我第一个上手测的组合是Claude Code + Remotion。

原因很简单。我当时的需求是做一些 AI 产品概念的解释视频,纯动画,不需要真人出镜。Remotion 是 React 写视频,我平时用 Claude Code 写代码已经很顺了,这俩接在一起是最自然的选择。

最早拿来练手的是PE 系列(Prompt Engineering 概念解释视频)。第一条视频做出来的感受就是:能出片,但很糙。

画面有了,但动效很死板,就是文字一行一行弹出来,背景换个颜色,偶尔来个淡入淡出。没有音效,没有节奏感,更谈不上什么视觉冲击力。说是视频,其实更像一个会动的 PPT。

但至少验证了一件事:用代码做视频这条路,确实跑得通。

接下来就是多轮的调整和迭代。根据发到抖音后的流量反馈,加上自己反复看片的感觉,每条视频都在前一条的基础上改进。画面越来越丰富,动效开始有层次,整体完成度在肉眼可见地提升。

PE 系列验证了代码做视频跑得通以后,我开始想一个问题:怎么把这套流程做成可重复产出的架构?不能每次都从头来一遍,得有一套系统化的生产流程。

从这里开始,坑就来了。

坑 1:想用 Multi-Agent 提效,跑了一晚上没出来

Claude Code 有一个 subagents 的能力,可以拆分任务让多个子 Agent 并行跑。我当时的想法是:一个 Agent 负责写脚本,一个负责做分镜,一个负责写动效代码,最后汇总渲染。听起来很合理对吧?

结果是灾难级的。

生成速度反而变慢了,因为多个 Agent 之间的上下文不共享,A 写的脚本 B 看不到,B 做的分镜 C 不知道,最后汇总出来的东西牛头不对马嘴。跑了整整一个晚上,什么都没出来。

教训很清楚:并不是架构越复杂越好。对于视频生产这种高度依赖上下文连贯性的任务,单 Agent + 清晰的文档结构,比多 Agent 并行要稳得多。

最后回退到了一个更朴素的方案:DESIGN.md + CLAUDE.md + 多个 SKILL 文件的架构。一个 Agent 从头到尾跟完整条视频,但通过文档来给它清晰的上下文边界和规范约束。

这套架构后来一直沿用到现在。

坑 2:跳过 DESIGN 直接写代码,整片风格乱飞

Multi-Agent 的坑踩完以后,我开始认真打磨单条视频的质量。

但又踩了第二个坑:着急写代码,没有先锁视觉系统。

表现就是,每个镜头单看还行,但放到一起整片的风格完全不统一。这个镜头用了蓝色背景,下个镜头突然变成黑色。这段用了一种字体,下一段又换了一种。动效有的是弹入,有的是淡入,有的是直接出现。看完整条视频的感觉就是:每一帧都在告诉你,这是不同的人做的。

后来我才明白一个道理:做视频和做产品一样,先有 Design System,再有代码。

我开始在每个视频项目里先建一个DESIGN.md,进去之前先把色板、字体、容器样式、动效规范、转场方式全部锁死。Agent 写代码的时候严格按照 DESIGN.md 来,不允许自由发挥。

效果立竿见影。整片的统一感一下子就上来了。

升级验证:Loop Engineer,全合成动画的上限

经过前面的踩坑和迭代,到Loop Engineer这条视频的时候,整套流程已经比较成熟了。

Loop Engineer 是一条讲技术概念的视频。我选了一个终端赛博风的视觉方向:GitHub Dark 配色、等宽字体、macOS 终端窗口、CRT 扫描线、故障字效果。全片靠代码绘制,零外部素材。

这条视频验证了 Claude Code + Remotion 这套组合的上限:

首先是素材流程跑通了。我在自己的素材库里囤了大概 300 条动效参考。做 Loop Engineer 的时候,五种文字效果和两款赛博背景全部命中了素材库。但这些源码不能直接拿来用,需要做一遍移植,改成视频引擎能用的格式。

其次是复用机制建立了。这条视频做完以后,五个移植好的动效模版被沉淀进了一个公共的模版库里。下一条同风格的视频直接导入,改参数就行。做一条片等于产一批可复用的资产,越做越快。

第三是整体工作流稳定了。从口播稿到 DESIGN、分镜、代码合成、远程渲染、带字幕交付,整条链路跑得很顺。

做完 Loop Engineer,我觉得全合成动画这条路已经走通了。流程稳定,效果能打,资产能复用。

然后我就犯了一个经典错误:觉得既然全合成能跑,口播应该也差不多吧。

坑 3:全合成套路直接套口播,完全跑不通

做内容的人都知道,纯动画视频可以发,但口播才是日常产出的主力。大部分时候就是你真人拍一段,然后在画面上叠加图文、资料卡、截图、录屏这些辅助信息。

所以我想,反正流程都跑通了,换个输入不就行了?

结果是,之前积累的所有经验几乎全部失效。

全合成视频的逻辑是:从零生成一切,所有画面都是代码画出来的,AI 有完全的控制权。口播视频完全不一样,你有一条真人实拍的素材,画面、声音、节奏都已经定了,AI 要做的是围绕这条已有的时间轴去搭建图文层。

这两种模式的底层逻辑完全不同。

坑 4:Claude Code + HyperFrames 做口播,对不齐、模块乱飞

既然全合成的组合做口播不行,我就换引擎试试。

HyperFrames 用的是 HTML,做图文叠加应该更灵活。加上 Claude Code 我已经用得很顺了,这个组合听起来没毛病。

结果是另一种灾难。

口播和画面的时间对不齐,嘴上说到 A 点了,画面上还停在 B 点。模块飞来飞去,字幕和标题互相压,PIP 小窗和资料卡抢位置。整个画面像是几个人各做各的然后硬拼到一起。

核心问题是,Claude Code 虽然写代码很强,但它处理真人口播视频这种高度依赖精确时间码的任务时,对齐能力不够。

坑 5:砸钱试 Codex + Remotion,还是不行

两个组合都翻车了。我开始想,是不是应该换 Agent 试试。

Codex 是 OpenAI 的编码 Agent,能力也很强。Remotion 我已经很熟了。这个组合应该能行吧?

花了钱,结果还是不行。

Remotion 的 React 组件化在全合成场景下是优势,但在口播重剪场景下反而变成了负担。你要把一段真人实拍的视频塞进 React 的帧驱动渲染管线里,光是让视频正常播放就要费很大力气,更别说在上面灵活叠加图文了。

到这里,四种组合我已经系统性地逐一验证了三种,全灭。

还剩最后一个组合。从排除法的角度看,如果 Remotion 做口播不行(不管搭配谁),Claude Code 做口播也不行(不管搭配谁),那问题就很清楚了:口播场景需要的是 Codex 的执行能力 + HyperFrames 的 HTML 灵活性。这不是碰运气,是四条路径逐一验证后剩下的唯一选项。

破局:Codex + HyperFrames,口播跑通了

最后一个组合验证下来,确实跑通了。

回过头看逻辑也说得通:HyperFrames 写的是 HTML,而口播视频的本质就是在一条真人视频上面叠透明的图文层。HTML 天生就是做这件事的。资料卡、截图、字幕、PIP 小窗、红框标注,这些东西用 HTML/CSS 来写,比用 React 组件去强行包装要自然得多。

而 Codex 在处理这类改文件、调样式、逐帧检查的任务时,和 HyperFrames 的配合非常顺畅。它能直接读 HTML、改 CSS、跑渲染、抽帧检查,整个循环转得很快。

但跑通不等于一帆风顺。接下来做《创始人手册》这条口播视频的时候,又踩了五个制作层面的坑。

《创始人手册》:口播制作实战 + 坑 6-10

《创始人手册》是一条约 3 分钟的真人口播视频。内容从 Humane AI Pin 的失败开场,引出 Anthropic 的创业手册,再转到我自己做 Lollipop 的创业经历,最后落到一个思考:AI 时代做东西变快了,但想东西没有变快。

整条视频迭代了五个版本。每一版我都完整看一遍,按时间码标出所有问题,交给 Codex 去修。最夸张的一次,我一口气给了 21 个具体问题。

这个过程里踩的五个坑,是代码做口播视频最核心的经验。

坑 6:预览通过但最终渲染冻结

这是最诡异的一个坑。

在 HyperFrames 的预览里看,视频播得好好的。但渲染成最终 MP4 以后,54 秒、1 分 21 秒、2 分 53 秒这三个位置的视频全变成了静帧,画面冻住不动了。

原因是 HyperFrames 渲染视频的方式是逐帧截图再拼起来。浏览器预览时视频正常播放,但逐帧捕获时视频的 seek 机制出了问题,导致某些帧被反复截到同一画面。

解决方案:不再把动态视频嵌在 HyperFrames 内部。HF 只负责透明的图文叠加层,真正的背景视频交给 ffmpeg 在最后的合成阶段再接进去。

最终 MP4 才是事实。预览、抽帧检查、inspect 报告都只是中间证据。

坑 7:真人在不该出现的时候反复闪回

做口播视频时,底层有一条全程运行的真人实拍视频。上面叠加图文层来遮挡和切换画面。

问题是,只要图文层的某一段没有完全覆盖,底层的真人全屏画面就会露出来。转场的时候闪一下真人,片尾突然弹出真人全屏,观感非常差。

解决方案:在分镜里,每一段必须显式标注是全屏真人 / PIP 小窗 / 无真人。不允许隐藏的真人全屏作为默认兜底。片尾用最后一帧画面冻住,不让底层露出来。

坑 8:画面跑在嘴巴前面

视频里的图文元素按大段落整批出现。比如一段讲了三个槽点,第一个槽点的口播刚开始,三个槽点的文字卡片就全弹出来了。观众还没听到,画面已经剧透完了。

金额动画也是一样。嘴上说账号余额耗尽的时候,金额动画已经跑完了。

解决方案:所有元素按真实口播的时间码逐个触发。不是这一段都能放,而是说到哪里出哪里。这条规则后来写进了制作规范里,每条新视频强制执行。

坑 9:元素互相打架

口播视频的画面层级很复杂:真人画面、PIP 小窗、字幕条、标题大字、资料卡、截图、红框标注、logo,这些东西要同时出现在一个画面里。

结果就是各种互相遮挡。49 秒合照和标题重叠,1 分 15 秒大字和左边模块打架,1 分 56 秒对话被上方文字压住,2 分 31 秒弹窗被字幕和人像挡住。

解决方案:给 PIP、字幕、资料卡、截图、红框都划固定的安全区。长文案先压缩文字,不靠缩小字号硬塞。画面大字和字幕互斥,同时出现时只保留一个。

最后,才终于让里面的卡片、我的口播小窗口、标题文字以及字幕这些东西之间不会打架。

坑 10:AI 自作主张把素材重画了一遍

我给了 Codex 一张 Lollipop 的 logo 图片,让它放在视频里。结果它不光放了,还自作主张把这张图重新画成了 SVG,而且把前面一个不该换的 logo 也给换掉了。

解决方案:用户给的素材,优先直接引用原文件。没有经过用户确认,不重绘、不换用途、不改格式。图片就用 PNG/JPG 圆形蒙版,不为了代码化去重构成 SVG。

尽管看起来这个问题算是一个小问题,不至于是一个坑,但它其实体现了 Codex 的一个问题:如果它本身自带生图能力,就会优先调用内部的能力,这会导致用户上传的素材产生极大的差异,从而影响整个画面或其他内容。

经过五轮迭代,《创始人手册》终于出片了。可以看上面这个图片,我是让口袋 S 给我复盘了一下都遇到了哪些坑,以及我反复强调的点。几乎一屏幕完全截不下,但是我又怕看不清,大概就截了上半部分。

不过好在最后的效果不错,因为里面有一些轻动效。可以看下面这个视频的某一帧截图,这 4 个模块会依次出现,并跟随着我的口播。关键的这一句话:“做东西这件事变快了,但想东西这件事没有变快”,也能跟随着口播的节奏应时出现。

回过头看:为什么是这两个组合?

做完这两条视频,回过头来看,答案其实很简单。

不是工具好坏的问题,是输入形态决定了该走哪条生产线。

你手里有什么,就决定了你该用什么。

这不是我一开始就想清楚的。是踩完了所有坑以后,自然沉淀出来的。因此,项目及指令需要反复迭代微调,最后你要给 Claude 或者是 Codex 一套规则或者是契约。

沉淀:我的方法论

一个月下来,踩了 10 个坑,做了两类视频,最后沉淀出来的方法论其实就几条:

1. 做视频之前先问:我手里有什么?

这一条决定了你走哪条线。有真人素材就走 Codex + HyperFrames,只有文字和想法就走 Claude Code + Remotion。不要在错误的生产线上浪费时间。

2. 不要跳过文档直接写代码。

DESIGN.md 锁视觉系统,STORYBOARD 锁分镜。跳过这两步直接写代码,必然返工。做视频和做产品一样,先有规范,再有实现。

3. 每次踩坑 = 下一次的规则。

真人闪回这个坑踩完,FULL/PIP/NO_HUMAN 显式标注就成了每条视频的强制检查项。cue 不准踩完,按时间码逐个触发就成了制作规范。代码做视频最大的好处就是,规则可以写进代码里,下次不会再犯同样的错。

4. 每条片 = 一批可复用的资产。

Loop Engineer 沉淀了 5 个动效模版,下一条同风格视频直接用。这就是代码做视频的复利效应,做得越多,后面越快。

5. 最终文件才是事实。

预览没问题不代表成片没问题。渲染出来的 MP4 才是你要验收的对象。这条规则拿血换的。

最后说两句

AI 做视频不会自动有审美。

但它能在你给了明确标准的情况下快速返工。你说49 秒的合照和标题重叠了,它五分钟就能改好。你说1 分 21 秒的录屏冻住了,它能定位到原因然后修复。

真正重要的不是 AI 能不能做视频,而是你能不能把自己的审美反馈翻译成可执行的检查项。

Vibe Motion 这个词听着很 vibe,做起来其实很工程。

但也正因为很工程,它才有可能变成一套可重复、可积累、越做越快的生产方式。

这大概就是用代码做视频,最有意思的地方。目前我还在测试中,这只是我在做的案例中明显感觉是坑的点,分享一下。后续如果有什么发现我会再同步。

本文由 @小普 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自作者提供

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!