48 分钟 vib 出片：fframes 把视频渲染交给 agent

让 AI agent 做一支产品发布视频，最难受的不是生成不了画面，而是循环太慢：改一帧要等渲染，渲染完要人眼找毛病，找到了再改再等。dmtrKovalenko 的 fframes 把这条路修直了：一个程序化视频渲染框架，Rust 写帧定义、Skia 上 GPU 渲染、内置一整套给 agent 用的检查命令，GitHub 2.2k 星，MIT 协议，官网 fframes.studio。README 自述它的发布视频用 agent 48 分钟 vib 出来、36 秒渲染完成，这个数字虽然出自作者本人，管线设计确实朝着这个方向使劲。

项目简介

fframes 的定位是程序化视频渲染框架，主打快。作者 Dmitriy Kovalenko 把它形容成视频的 vibe coding 框架：视频的每一帧都是一段 SVG，用 Rust 宏 svgr! 直接写在代码里，改视频等于改代码，diff、版本控制、代码复用全套白拿。渲染交给 Skia 图形库走 GPU（macOS 走 Metal，其他平台走 Vulkan），官方口径约比自家 CPU 后端快 10 倍；静态链接的 ffmpeg libav 负责编码输出，不往外 shell 出去调命令行，少一层进程开销也少一层环境问题。和这一赛道的先行者 Remotion 相比路线差异明显：Remotion 用 React 组件描述每一帧，好处是前端团队零门槛，代价是每帧都要跑一遍组件逻辑；fframes 把帧定义放进 Rust 编译期，静态内容缓存成只算一次的产物，动态部分才进渲染循环，快就快在这里。仓库目前 2.2k 星、48 fork、246 次提交，issue 区只有 2 个 open issue，属于年轻但工程完成度不低的项目。

核心功能

真正让它区别于老牌程序化视频工具的是对 agent 的第一等支持。给 agent 用的一套命令行：timeline 列出时间轴结构，inspect 找坏字体、被截断的文本和 panic，strip 生成接触表缩略图，onion 把相邻帧叠起来看动画过渡，frame 导出单帧 PNG，audio analyze 查响度、峰值和削波，snapshot 对渲染快照做差分。这套命令等于给没有眼睛的 agent 配上了眼睛：不用看视频，读命令输出就能判断哪里坏了，改完再跑一次 snapshot 就能确认修复是否生效，整个检查闭环不需要人坐在屏幕前。性能侧的功夫也都实在：静态 SVG 内容在编译期缓存，渲染时不重复计算；支持 SkSL 和 Shadertoy 风格的着色器层，跨帧动画和粒子效果有地方落；另有一个编译成 WebAssembly 的浏览器编辑器，带时间轴，人也能上手调。仓库里示例不少：发布视频、着色器动画、播客可视化、TikTok 风格竖屏，都是可直接改的起点。

快速上手

需要 Rust 工具链，三条命令起项目：

cargo install --locked cargo-fframes
cargo fframes new my-video
cd my-video && cargo run --release -- preview

想让编码 agent 直接会用它，装官方 skill 一条命令：

npx skills add https://fframes.studio

装完 agent 就知道怎么建时间轴、怎么用 inspect 和 snapshot 自查、怎么用 render --draft 快速出草稿迭代，最终再用完整渲染出片。

适合谁用

做数据可视化视频、产品发布片、播客切条、着色器艺术的人是最直接的受众，尤其已经在用 Claude Code 或 Codex 干活的团队：视频生产第一次可以完整塞进 agent 的编辑-检查-修复循环里。批量场景更能吃满它的性能设计：一周几十条播客切条、每条都要字幕动画和响度合规，GPU 渲染加草稿模式意味着迭代按秒计而不是按分钟计。前提也要说清：你得能写或能让 agent 写 Rust，纯模板拼片的需求用不着它；GPU 渲染对机器有要求，CPU 后端会慢一个量级。对大多数内容团队，它更适合当内部视频管线的底层引擎，而不是直接交给设计师的成品工具。