Claude Design 的动画视频导出能力，宝玉直接拆成一个本地 Skill 开源出来了。GitHub 上叫 baoyu-design，MIT 协议，1.2K star，原理文档写得相当通透。它做的事情不复杂——把任意时间点 t 的画面状态用 f(t) 函数绝对确定下来，再用无头 Chromium 逐帧抓图，最后丢给 ffmpeg 编码成视频。听起来像流水线，实则每个环节都藏着工程取舍。下面把这条链路拆开看。
声明式引擎：f(t) 是怎么锁死画面状态的
传统动画引擎走命令式：你在第 30 帧插入一个状态，第 60 帧再插一个，中间靠插值动画过渡。听起来优雅，但导出视频时坑很多——时间轴一复杂，状态就漂移，导出和预览对不上。baoyu-design 反过来搞了一套声明式 f(t) 设计：给定任意 t，直接算出那一刻的完整画面。t 是 0.5 秒也好，87.3 秒也罢，函数返回的就是该时间点该有的样子，没有任何"上一帧继承了什么"的隐式状态。
为什么 f(t) 比时间轴更适合导出
导出视频的本质是"在确定的时刻拍一张确定的图"。f(t) 模型天然契合这个需求——它不依赖前一帧、不依赖用户交互、不依赖任何运行时变量。哪怕你在浏览器的 DevTools 里手动调用 f(15.7)，拿到的画面和正式导出第 471 帧应该完全一致。这种可重现性是离线渲染的根基，也是为什么 baoyu-design 能稳定输出帧帧精确的成片。
声明式背后是状态外置
f(t) 能成立的前提是所有动画状态都被参数化。时间、进度、缓动曲线、元素位置——全部变成纯函数输入，不存在全局副作用。这套思路其实和 React 的渲染哲学同源，只不过 baoyu-design 把渲染目标从 DOM 换成了静态帧快照。开发者写 Skill 时不用关心"动画怎么播"，只关心"t 这个时刻画面长啥样"，心智负担直接砍半。
截图管线：Chromium 逐帧 + 2 倍 DPR 的细节账
声明式引擎解决了"画面长啥样"的问题，但怎么把它变成视频？baoyu-design 的答案是最朴素也最稳的那一套：起一个无头 Chromium，每帧加载 HTML、等待渲染、截图、清空、下一帧。别笑，这是目前对兼容性最友好的方案——CSS 动画、Web Font、SVG 滤镜、Canvas，全都能跑，因为本质就是在跑一个真实的浏览器。
两帧 requestAnimationFrame 不是玄学
每帧截图前，脚本会强制等两个 requestAnimationFrame 周期才执行。这个细节看起来多余，实际上是踩过坑的产物：单帧 RAF 之后立即截图，字体可能还没加载完，Canvas 的异步绘制还在 pending，Web Font 的 FOIT（不可见文本期）也没结束。两帧刚好覆盖大多数异步渲染管线的尾部，再激进一点的方案是监听 document.fonts.ready，但那会引入额外复杂度。两帧 RAF 是性能和确定性的甜区。
2 倍 DPR 截图再缩回的代价与回报
导出分辨率定的是 3840×2160，也就是 4K，但最终成片是 1080p。为什么要先拍 4K 再缩？因为无头 Chromium 在高 DPR 下渲染的文字边缘、阴影、渐变更细腻，缩回 1080p 后视觉清晰度肉眼可见地优于直接 1 倍渲染。这是一次"用 CPU 换画质"的典型取舍——95 秒 30fps 总共 2850 帧，每帧多渲 4 倍像素，时间成本翻几倍。但对追求成片质量的创作者来说，这笔账算得过来。
视频拼装：ffmpeg 的最后一公里
2850 张 PNG 躺在硬盘上，还得拼成视频。baoyu-design 直接调 ffmpeg，参数写得相当克制：H.264 编码、30fps、目标码率按分辨率自动推算。没有用 GPU 加速，也没有上 AV1——因为目标用户大概率装的是普通 ffmpeg，兼容性优先。编码这一步反而是整个链路里最不性感的，但它决定了最终文件能不能在朋友圈、Twitter、小红书上正常播放。
为什么不上 WebCodecs 或 MediaRecorder
浏览器其实有现成的视频录制 API，但 baoyu-design 没走那条路。原因很现实：MediaRecorder 出来的 WebM 在很多平台兼容性差，WebCodecs 需要手动管帧队列，复杂度和 ffmpeg 拼图差不多，但灵活性反而更差。开发者最终选择最笨的办法——浏览器只负责渲染，编码完全交给工业级工具。事实证明这套分工是对的，Skill 的输出文件兼容性比很多在线 AI 动画工具都稳。
95 秒动画的算力账单
2850 次截图循环，每次 4K 渲染加双 RAF 等待，按经验估算，普通笔记本 CPU 上跑完大概 20 到 40 分钟。这不是一个能秒出成片的工具，但它胜在零成本、可复现、可二次开发。对独立创作者来说，等半小时换一段帧帧精确的动画视频，比花钱订阅还不知道底层逻辑的 SaaS 划算得多。
从 PPT 导出到视频导出：Skill 的边界在扩张
baoyu-design 不是从零冒出来的。在做动画视频导出之前，它已经支持 PPT 本地生成和可编辑 PPTX 导出。两件事摆在一起看，就能理解作者的产品思路：把 Claude Design 里那些"看着很酷但没法带走"的能力，一项一项拆成可本地复现的 Skill。PPT 是静态文档，导出 PPTX 是顺理成章；动画是动态内容，导出视频就成了下一个必然。
可编辑 PPTX 的隐藏价值
很多 AI 生成的 PPT 工具只能导出 PDF 或图片，用户拿到手改不动。baoyu-design 导出可编辑 PPTX 这一步看似不起眼，实际上击中了办公场景最痛的点——AI 出的方案往往只完成 70%，剩下 30% 要靠人工微调，而微调只能在源文件里改。导出格式决定了 AI 工具是"一次性玩具"还是"工作流起点"，宝玉显然想清楚了这件事。
动画导出会不会是 PPT 导出的镜像
顺着这个逻辑推，动画视频导出的下一步可能是"可二次编辑的视频项目文件"——比如导出 After Effects 工程文件、或者 Lottie JSON、或者至少是关键帧数据 CSV。这样创作者拿到的不只是成片，而是可以继续打磨的素材。当前版本还没做到那一步，但 Skill 的架构留好了口子，声明式 f(t) 模型天然适合回溯出关键参数。
整套链路看下来，baoyu-design 的价值不在于技术多炫，而在于把"AI 设计稿如何变成可分发内容"这件事的工程路径彻底公开了。声明式动画引擎、无头浏览器逐帧、ffmpeg 编码——每一个环节都是成熟技术的组合，但组合方式和取舍逻辑只有真正做过的人才写得出来。开源、MIT、1.2K star，这个数字会继续涨，因为对想要掌控自己创作工具的人来说，这才是真正能用的东西。
