React on KnightLi的博客

Remotion：用 React 以编程方式生成视频

Wed, 27 May 2026 14:39:22 +0800

remotion-dev/remotion 是一个用 React 以编程方式创建视频的框架。它把视频制作从传统时间轴工具里抽出来，变成可以用组件、状态、数据、API、CSS、Canvas、SVG、WebGL 和算法控制的前端工程问题。

项目地址：remotion-dev/remotion

这类工具很适合今天的 AI 编程工作流：如果一个 agent 能生成网页、图表和数据视图，它也可以继续生成视频脚本、动画组件和可渲染的短片。

Remotion 解决的是什么问题

传统视频工具擅长人工剪辑，但不擅长规模化、参数化和自动化。

比如这些任务：

给每个用户生成一条个性化年度回顾视频
根据数据库自动生成产品演示视频
把图表、代码片段和讲解字幕组合成技术短片
批量生成营销素材、社交媒体短视频或课程片段
用 CI/CD 或后端服务按需渲染视频

如果用传统剪辑软件，这些任务很难完全自动化。Remotion 的做法是把视频当成 React 应用来写：每一帧都是组件和数据在某个时间点的结果。

为什么是 React

Remotion README 里给出的理由很清楚：React 可以复用 Web 技术和组件化能力。

它让你可以使用：

CSS 做布局和动画
SVG 做矢量图形
Canvas 和 WebGL 做复杂绘制
JavaScript / TypeScript 做变量、函数、API 调用、数学和算法
React 组件做复用、组合和快速迭代

这意味着前端开发者不需要重新学习一套完全陌生的视频 DSL。很多已有的 UI、图表、设计系统和数据逻辑，都可以迁移到视频生成场景里。

快速开始

如果已经安装 Node.js，README 给出的入口命令是：

`1`	`npx create-video@latest`

创建项目后，你通常会编写 React 组件来描述画面，再让 Remotion 按帧渲染输出视频。

更完整的文档可以看：

文档：remotion.dev/docs
API Reference：remotion.dev/api

它适合哪些场景

Remotion 最适合“视频内容由数据或代码驱动”的场景。

个性化视频

例如年度回顾、用户成就、订单总结、学习报告。每个用户的数据不同，但视觉结构相同。用 React 组件加数据驱动，会比手工剪辑更自然。

技术演示视频

如果视频里包含代码、图表、产品界面、步骤动画和说明文字，Remotion 很适合把这些元素组织成可重复渲染的模板。

数据视频和图表动画

数据可视化本来就是前端强项。Remotion 让图表不仅可以出现在网页里，也可以按时间轴进入视频。

AI 生成视频工作流

AI agent 可以先生成脚本和素材结构，再生成 Remotion 组件，最后渲染视频。这比让模型直接生成最终视频更可控，因为中间产物是代码，可以检查、修改、版本管理和复用。

对 AI 编程工具的意义

Remotion 对 Codex、Claude Code、Cursor、Gemini CLI 这类 AI 编程工具特别有意思。

原因是视频生成被拆成了开发任务：

生成 React 组件。
调整样式和布局。
接入数据。
预览画面。
根据反馈修改。
渲染输出。

这套流程非常适合 agent：每一步都有文件、有代码、有预览、有明确反馈。相比“直接生成一个视频文件”，代码化视频更容易被审阅和迭代。

如果再结合浏览器侧边栏、截图检查、自动化渲染和评论反馈，Remotion 可以成为 AI 工作流里的视频产物层。

使用前要注意许可

Remotion README 特别提醒：Remotion 有特殊许可，在某些公司使用场景下需要获得 company license。

所以不要只把它当成普通 MIT 小工具来用。个人项目、开源项目、商业项目、企业内部工具，许可要求可能不同。正式用于公司生产前，应该先阅读它的 LICENSE 页面和官方许可说明。

这点很重要，尤其是把 Remotion 接进自动化内容生成、营销素材生成或企业内部视频流水线时。

我的判断

Remotion 的价值不只是“用 React 做视频”，而是把视频变成可编程、可复用、可自动化的产物。

对普通前端团队来说，它适合做数据驱动的视频模板。对 AI 工具来说，它更像一个稳定的输出目标：模型不需要一次性生成黑盒视频，而是生成可读、可改、可渲染的 React 代码。

如果你的内容需要批量生成、个性化生成、根据数据更新，或者需要让 agent 反复调整视觉细节，Remotion 值得放进工具箱里。它不是传统剪辑软件的替代品，而是把视频生产接入软件工程流程的一种方式。

web-video-presentation：把文章做成可录屏网页视频的 Agent Skill

Fri, 15 May 2026 09:02:15 +0800

web-video-presentation 是 ConardLi/garden-skills 里的一个 agent skill。它要解决的问题很具体：把一篇文章或一段口播稿，做成可以录屏的视频化网页演示。

项目地址：https://github.com/ConardLi/garden-skills/tree/main/skills/web-video-presentation

它不是普通 PPT 模板，也不是单纯的 React 组件库。更准确地说，它是一套面向 AI agent 的视频演示生产流程：先把内容改成口播稿，再拆成 outline，再选主题，再用 Vite + React + TypeScript 做一个 16:9 的点击驱动网页，最后录屏成视频。

它想做的不是幻灯片

README 里有一个很关键的定位：这个 skill 生成的是 “video production surface”，不是 slide deck。

也就是说，它不希望每一页只是标题加 bullet list，而是让每一次点击推进一个口播节拍。每个 step 独占 1920×1080 的舞台，画面随着叙事变化。进度 UI 平时隐藏，只有悬浮时出现，这样录屏画面更干净。

这类形态很适合：

把博客文章做成 B 站 / YouTube 解说视频
把已有口播稿做成动态视觉稿
做产品 demo
做教程视频
做 keynote 风格的视觉演讲
做“动态 PPT，但不像 PPT”的内容

它的核心价值不在于省掉剪辑软件，而是让网页成为一个可控的、可迭代的视频画布。

核心设计原则

这个 skill 的几个原则很清楚。

第一，固定 16:9 舞台。内容在稳定的 1920×1080 坐标系里设计，再缩放到不同视口。这样录屏时不会因为浏览器窗口变化导致布局漂移。

第二，全局 step cursor。用户点击或用键盘推进 (chapter, step)，本地保存进度。它像视频时间线，但用网页状态来控制。

第三，一个 step 只讲一个想法。每个节拍都应该是完整画面，而不是在同一页上不断堆 bullet。

第四，脚本节拍驱动结构。口播稿决定节奏，outline 决定章节和 step，画面跟着叙事走。

第五，motion first。每个场景都应该有一个会动的视觉锚点。如果只是静态段落，说明这一步还没有被设计成视频语言。

第六，主题 token 化。主题不是简单换颜色，而是通过语义 token 控制字体、颜色、卡片、背景、分割线、装饰和整体气质。

这些原则加在一起，能把 AI 从“生成页面”拉到“设计视频节奏”。

工作流分四段

它的工作流分成四个阶段。

第一阶段是内容编写。用户给原始文章时，agent 要把它改写成 script.md，再生成 outline.md。如果用户已经给了口播稿，就直接落盘成 script.md，再生成 outline。

第二阶段是网页开发。agent 用脚手架生成 Vite / React / TypeScript 项目，然后按章节实现画面。第 1 章必须由主线程完整做出来，并让用户验收，因为它是后续章节的风格锚点。

第三阶段是可选音频合成。skill 支持从章节里的 narrations.ts 抽取音频片段定义，再走语音合成流程。

第四阶段是录屏和后期。网页本身作为录屏舞台，用户用录屏工具把点击驱动的演示录成视频。

这个流程里有几个硬检查点：脚本、outline、主题、素材计划、开发模式要先对齐；第 1 章做完必须验收；是否合成音频也要停下来确认。它不允许 agent 从原文一路冲到最终代码。

为什么 outline 不写动画

这个 skill 里一个很有意思的约束是：outline.md 只规划节奏和信息密度，不规划具体动画。

也就是说，outline 可以写：

章节切分
每章 step 数
每步屏幕内容
每章信息池
素材清单
估计时长

但不应该写：

用什么 CSS 动画
用 blur、wipe 还是 spring
每个动效多少毫秒
具体 clip-path 或 filter 实现

原因很合理：如果 outline 把动画写死，后面的章节开发 agent 就会退化成“按说明翻译页面”。真正的视频感应该在实现单章时，根据内容关系即时设计。

这也是它比普通模板更有意思的地方。它把“结构”和“视觉决策”分开，让 AI 有空间做内容驱动的设计，而不是机械套版。

narrations.ts 是唯一真相源

项目结构里有一个关键文件：narrations.ts。

每章都有自己的 narrations.ts，它保存 step 数和对应口播文本。skill 明确要求，章节 .tsx 里出现的最大 step 数，必须和 narrations.length 对齐。

这样做是为了避免五处内容漂移：

script.md
outline.md
章节代码
chapters.ts
音频文件

如果口播、画面、音频和 step 数不一致，视频生产会非常难维护。把 narrations.ts 作为唯一真相源，是这个流程里很实用的工程约束。

内置主题不是简单换皮

README 里列了一组内置主题：

paper-press
warm-keynote
midnight-press
blueprint
chalk-garden
terminal-green
bauhaus-bold
sunset-zine
newsroom
monochrome-print

这些主题不是“红色版”“蓝色版”这种换皮，而是不同视觉方向。比如 paper-press 偏编辑纸张和印刷质感，blueprint 偏技术图纸，terminal-green 偏老式终端，newsroom 偏媒体桌面。

agent 在 Checkpoint Plan 阶段要根据稿子的主题和语气，主动推荐 2 到 3 个合适主题。用户也可以要求自定义新主题。

这点很重要。视频类网页最怕所有主题都长一个样：大标题、渐变背景、卡片、几个圆角按钮。主题系统如果能约束视觉语言，就能减少 AI 生成内容常见的同质化。

开发模式有三种

第 1 章无论如何都必须主线程做完并验收。之后可以选择三种模式。

模式 A 是逐章确认。每章做完都暂停验收，风险最低，也最适合对成片质量要求高的内容。

模式 B 是顺序开发。第 2 章到最后一章由主线程顺序做完，最后统一验收，速度中等。

模式 C 是并行开发。第 1 章通过后，把后续章节交给 subagent 并行实现。它最快，但各章风格可能会有差异。skill 认为这是预期，因为主题 token 负责兜底统一，章节内部可以自由发挥。

这个设计很现实：视频生产既需要风格锚点，也需要生产效率。第一章先定调，后续章节再按风险承受能力选择速度。

适合谁用

这个 skill 特别适合已经有内容素材的人。

如果你手里有一篇文章、一段脚本、一个产品介绍、一份教程、一篇技术解读，它可以把这些内容转成可录屏的网页视频。

但如果你只是说“帮我想一个视频主题”，它并不适合直接接手。SKILL.md 里也明确说了：用户什么都没有时，agent 应该反问，让用户先给素材或大纲。它不是创意选题工具，而是内容转视频的生产流程。

小结

web-video-presentation 的价值，不是帮你生成一套好看的 React 页面，而是把内容视频化这件事拆成可协作、可验收、可复用的流程。

它把文章、口播、outline、主题、章节实现、音频合成和录屏串起来，同时用硬检查点防止 agent 一路跑偏。

如果你经常把技术文章、产品介绍或教程做成视频，这个 skill 值得研究。即使不直接使用它的脚手架，里面关于“一个 step 一个想法”“先定第 1 章风格锚点”“narrations.ts 做唯一真相源”“outline 不写死动画”的方法，也很适合迁移到自己的 AI 内容生产流程里。