SaaS 动效设计 是做什么的？
制作产品影片，让真实的用户界面（UI）成为主角，每一个运动都诠释一个功能。
默认设置一览
| 设置 | 默认值 | 仅在以下情况修改 |
|---|---|---|
| 宽高比 | 16:9 (1920×1080) | 用户明确要求 9:16 |
| 帧率 | 60 fps | 用户要求其他帧率 |
| 背景 | 米白色 | 用户指定其他背景 |
| 颜色 | 取自产品自身 UI 主题 | 从不硬编码颜色 |
| 渐变 | 无 | 用户明确要求 |
| 旁白 | 无 | 用户明确要求 |
| 音乐 | 用户选择的Mixkit 高能量 曲目 | 用户想要更平静的情绪、没有合适的曲目，或影片将用于广播（请参见音频） |
每轮运行一个视频。 渲染单一宽高比。切勿同时生成 16:9 和 9:16；仅在用户要求时才制作 9:16 版本。
技术栈
| 工具 | 版本 | 用途 |
|---|---|---|
| Remotion | 4.0.535 | 将每个场景构建为 React 组件，在 Remotion Studio 中预览，导出静态图和渲染 |
| FFmpeg | 最新稳定版 | 音频混合、旁白背景音乐压侧、联系单、最终编码 |
| Node.js | 24 | 运行 Remotion 和构建脚本 |
- 精确定位 Remotion 版本。 安装每个
remotion和@remotion/*包时，使用4.0.535版本，不要带^或~。不匹配的 Remotion 包版本会导致渲染失败。 - 先检查 Node 版本。 在安装任何东西之前运行
node -v。如果不是 v24，请先告知用户。 - 所有动效基于帧计算。 使用
useCurrentFrame()和interpolate()/Easing.bezier()配合下方缓动预设进行动画，切勿使用 CSS 过渡或定时器，以确保每帧输出精确。 - 设置合成为默认 1920×1080 60fps，仅在要求 9:16 时设置为 1080×1920。
- 静态截图用于审核步骤：
npx remotion still <composition> --frame=<n>。 - 最终渲染：
npx remotion render <composition> out/<name>.mp4 --codec=h264。
工作流程
- 规划。 收集需求并编写规划和镜头列表（请参见下面的规划）。获得用户批准。
- 了解产品。 如果有代码库，则阅读前端代码库；否则使用实时 UI，并提取其主题（请参见下面的产品访问和品牌）。
- 编写脚本并获得用户批准（请参见下面的脚本）。
- 构建影片，使用以下动效、编排、镜头和转场规则，并遵循灵感参考文献的精神。
- 添加音频： 列出 Mixkit 曲目供用户选择（请参见下面的音频），然后添加音效，并在要求时添加旁白。
- 运行质量检查。
- 展示静态截图并等待。 向用户展示审核用的静态截图，回答他们的问题并进行任何修改（请参见下面的静态截图审核）。仅在用户批准后才进行渲染。
不要跳过任何审批步骤。每个步骤的修改成本都比后续步骤更低。
规划
在编写任何脚本之前，明确影片的用途。
1. 收集需求
仅向用户询问你无法自行找到的信息：
| 问题 | 未提供时的默认值 |
|---|---|
| 产品是什么？能否分享其前端代码库？如果不能，可以在哪里访问其在线 UI（URL、本地构建、登录信息）？ | 必需。请询问。优先选择代码库。 |
| 影片的受众是谁？ | 潜在客户 |
| 观众应该记住的一件事是什么？ | 必需。请询问。 |
| 应该展示哪些功能或流程？ | 最能证明核心信息的 2-3 个流程 |
| 影片应该多长？ | 30-45 秒 |
| 它将发布在哪里？会在电视或广播上播放吗？ | 网站和 X/LinkedIn (16:9)，仅限在线 |
| 是否需要旁白？如果需要，男声还是女声？ | 无旁白 |
| 行动号召是什么？ | 访问产品 URL |
2. 编写计划
为用户提供一个简短的计划以供批准：
- 目标： 一句话说明影片必须达成的目标
- 受众： 谁在看，以及他们已经知道什么
- 核心信息： 观众应该记住的那一句话
- 格式： 时长、宽高比（除非要求 9:16 否则为 16:9）、是否有旁白
- 故事弧线： 为此产品填充的结构模板（请参见脚本），每个部分一行
- 要捕捉的流程： 要录制的确切 UI 屏幕和交互，以及每个屏幕所需的数据状态（例如“包含 12 个任务的项目看板，其中 3 个已逾期”）
- 证明： 影片将展示的证据（如果有），例如指标、客户徽标、引用、基准测试结果或奖项，以及其来源
3. 编写镜头列表
将故事弧线分解为镜头，每行一个镜头：
| # | 部分 | 镜头 | 动效 | 时长 |
|---|---|---|---|---|
| 1 | 钩子 | 在产品搜索栏中键入问题 | 光标打字，答案流式输入 | 4 秒 |
镜头列表成为脚本的“屏幕内容”列。
产品访问
影片的质量取决于你对产品的访问权限。按优先顺序：
| 访问方式 | 提供内容 |
|---|---|
| 1. 前端代码库（最佳） | 精确的设计令牌、真实组件、真实文案、图标和 Logo 文件。可以在 Remotion 内像素级重建 UI 并自由动画。 |
| 2. 运行中的应用（URL 或本地构建，带测试登录） | 真实的主题和流程，从浏览器中捕获。忠实度高，但逐元素动画更困难。 |
| 3. 录屏或截图 | 最后手段。尽可能从它们重建屏幕，并告知用户结果可能不够精确。 |
如果没有代码库，请在退而求其次之前先向其索要。
从代码库入手
- 主题： 从项目存放设计令牌的任何地方读取，例如 CSS 自定义属性、Tailwind 配置、主题文件或设计令牌包。
- 组件： 在产品自身的 UI 组件在 Remotion 合成中能干净渲染的地方复用它们。否则，从其源代码忠实地重建它们。
- 内容： 从源代码中获取真实标签、空状态、图标和 Logo 文件，而不是自己编造。为计划所需的数据状态使用种子数据或固定数据。
- 只读操作。 切勿编辑产品的代码库。在你自己独立的 Remotion 项目中构建影片。
品牌
不要使用任何固定的品牌色。所有颜色都来自所展示的产品。
- 读取产品的核心 UI，如果有代码库则从其中读取，并提取其主题：主色/强调色、中性色、表面色、边框色、排版、圆角和阴影样式。
- 背景： 默认使用米白色背景，除非用户另有指定。
- 强调色： 使用产品自身的强调色用于强调、光标环、光标箭头和高亮。
- 无渐变 用于背景、文字、发光或转场效果，除非用户明确要求。使用纯色填充。
- 排版： 尽可能使用产品自身的字体，使字幕感觉像是 UI 的原生部分。
- Logo 和文字商标： 使用产品的真实资源。切勿重绘或近似它们。
脚本
脚本驱动一切：字幕、时间，以及旁白（如果有）。根据已批准的计划和镜头列表编写脚本，在构建任何场景之前编写，并在构建之前获得用户批准。
格式
将脚本写成一个表格，每行对应一句台词：
| # | 台词（口头或屏幕显示） | 屏幕内容 | 时长 |
|---|---|---|---|
| 1 | 你的团队每周在状态更新上浪费六小时。 | 计数器在杂乱的待办任务列表上升至 6 | 3 秒 |
规则
- 在开头 7 秒内设置钩子。 以问题、令人惊讶的数字或产品令人愉悦的举动开始，而不是产品名称。
- 每句台词都有对应的画面。 如果一句台词没有匹配的视觉节拍，则删除或重写它。
- 平实的语言。 短句，每行一个想法，没有观众需要解码的行话。
- 节奏： 配音时大约每秒 2.5 个单词。根据单词数预算台词时长。
- 用
*星号*标记强调，每行最多一个关键短语。 - 每个陈述都是真实的。 数字和基准必须真实，并在必要时添加注释。
- 遵守需求中设定的时长。 在加快动效速度之前先修剪台词。
- 默认无旁白。 没有旁白时，脚本仅作为屏幕上的字幕显示。
像人一样说话，而不是像模型
每一句台词都必须听起来像是一个真实的人会对同事说出的话。听起来像 AI 的文案会让观众走神，并使产品显得通用化。这是一个硬性规则，而非风格偏好。
像这样写：
- 具体化。 使用产品的真实功能名称、真实数字和用户实际执行的操作（