软件产品启动视频
制作一段 30–60 秒的视频，让用户理解并渴望拥有该产品。
决定一切的要点：重建，而非录制
屏幕录制会带来诸多麻烦。真实的延迟是死气沉沉的空档。重拍代价高昂。 你无法定格某一帧，无法放慢一个节拍同时加快另一个节拍，也 无法在不造成压缩模糊的情况下进行紧密裁剪。
因此，在 Remotion 内部将 UI 重建为基于帧驱动的 React 组件。每个视觉元素都是
useCurrentFrame() 的纯函数。打字动作落在精确的曲线上，
加载状态在节拍点上完成，而重拍只需修改一个数字。
之所以这样做是合理的，是因为你可以读取产品的实际代码（如果 本地存在）或 DOM+CSS（如果托管），并忠实地重现它们。请这样做——采用 真实的类名、真实的颜色、真实的文案。重建后的效果应与录制难以区分，甚至更优。
何时使用录制而非重建： 涉及重度 3D、产品内部的视频内容、
Canvas/WebGL 表面，或原生桌面应用。如果某个特定表面无法重建，
则仅录制该表面，并使用 <OffthreadVideo> 进行合成。
阶段 1 —— 理解产品
开始此阶段前，先阅读 references/discovery.md。它涵盖了
浏览与分类流程、凭据获取方法，以及如何从实时网站提取
设计体系。
简要说明：
- 给定一个 URL：浏览它。首先访问着陆页（它会告诉你他们如何 定位自己），然后进入应用本身。弄清楚产品为谁完成什么任务。
- 给定一个本地仓库/开发服务器：阅读代码。信息要丰富得多——你可以获得 真实的组件、真实的主题令牌、真实的种子数据。
- 对页面进行分类。 大多数产品有 20 个屏幕，但只有 3 个是关键的。认证、 设置、计费、隐私、账户、入门模板——这些几乎从来都不是核心。 找到产品执行其独特功能的屏幕。
- 如果关键内容位于登录之后，首先请求——测试凭据，或他们本地开发环境中的
种子账户。如果两者都不可用，不要放弃，也不要伪造你从未见过的会话：
切换到分章结构，并从着陆页自身的功能卡片、文案和组件来构建。
discovery.md中包含了收集流程和诚实准则。
然后，在进行构建之前，与用户确认你的理解——错误理解产品 会浪费整个构建。向他们展示：你认为产品做什么，你计划展示的 2–4 个 屏幕，主要场景，镜头列表，以及音乐问题（参见阶段 4）。 检查一次，然后开始执行。
阶段 2 —— 选择结构
阅读 references/structure.md。有两种结构可行；选择错误会浪费
整个构建。
结构 A —— 单一叙事。默认选择。 一个用户完成一项任务并得到一个 成果。不是功能巡览。
| 节拍 | 任务 |
|---|---|
| 吸引注意 (0–5 秒) | 用观众自己的语言陈述问题。暂不展示 UI。 |
| 询问 (5–12 秒) | 用户提出需求。聚焦于输入。 |
| 工作 (12–25 秒) | 产品明显地做一件困难的事情。展示证据。 |
| 成果 (25–35 秒) | 完整展示输出，以可读大小呈现。 |
| 控制 (35–45 秒) | 用户修改它并保持掌控。 |
| 结束画面 (45–50 秒) | Logo，一行文字，域名。 |
工作 和 控制 节拍是区分真实演示和模拟的关键。“它主动询问我，而不是猜测”和“我可以编辑它生成的内容”是信任论据，而信任正是启动视频真正要推销的。
选择产品完成某人无法轻易自行完成的任务的时刻，并使输出具体且可见——生成的文档、 构建的图表、修复的 bug、部署的网站。具体的成果是用户会记住的。
结构 B —— 分章节的功能电影。 三个功能，每个由简单明了的 标签卡片引入，然后展示。
吸引注意 → [01 标签 → 功能] → [02 标签 → 功能] → [03 标签 → 功能] → 结束画面
当产品 受限制 且你从其着陆页出发时，或当功能真正不共享用户旅程时， 或当你希望从一次构建中生成三个独立片段时，使用此结构。三个是数字——四个意味着没有一个能留下深刻印象。
不要对序列进行分章。 如果能力在单个会话中依次发生（研究 → 草稿 → 编辑）， 那是一个工作流程，将其标记为三个功能会与材料产生冲突。如果有人要求对顺序产品进行分章， 则提供中间方案：保持单一叙事，并将标签 覆盖 在每次能力出现时的动作之上。 相同的可读性，相同的片段边界，没有运行时成本，故事完整。
structure.md 涵盖了章节卡片设计、如何编写标签（命名结果，而非机制；
借用产品自身的词语）、过渡、以及排序。
阶段 3 —— 基于真实内容
无论产品处于哪个领域，不要发明其内容。如果是法律产品， 法规必须真实。如果是分析产品，数字必须合理且内部一致。 如果是代码工具，代码必须在读者脑海中编译通过。
从仓库、API、种子数据或文档中提取真实内容。 领域专家会观看这些视频，一个虚构的细节会让你失去所有他们的信任。 当事人姓名、日期和美元数额可以虚构——这些是针对客户的具体内容，而不是关于世界的 声明。
在数据文件中保留来源注释，说明每个事实的来源。 未来的你会需要它。
阶段 4 —— 构建
运行脚手架，它会固定实际可协同工作的版本并写入配置：
python3 <skill-dir>/scripts/scaffold_video.py <target-dir> \
--name "product-launch" --fps 60 --seconds 45
它会创建一个独立的 Remotion 项目（拥有自己的 git 仓库——除非被要求，否则永远不要将视频工具添加到产品的仓库中），
复制 useCamera.ts，并为你留下一个时间线模块待填充。
然后，按顺序进行：
-
src/timeline.ts—— 帧计算和镜头边界。选择一个节拍为整数帧数的 BPM（在 60fps 下：120 BPM = 30 帧，90 BPM = 40）。将每个镜头边界放在节拍上。即使没有音乐，这也能赋予剪辑内在节奏，并且意味着可以在以后添加音乐背景而无需重新剪辑。 -
src/data/script.<lang>.ts—— 所有字符串、所有数字、所有文档内容， 放在一个文件中，并附有来源注释。不要在组件中硬编码任何内容。 重计时和翻译都变得简单。 -
组件 —— 重建产品的 UI。复制真实的类名。如果产品使用 Tailwind， 则引入其配置和主题 CSS；如果使用 CSS 变量表示颜色，则必须引入这些变量， 否则所有内容将呈现无色。
-
src/scenes/ProductScene.tsx—— 一个导出的B对象，包含每个节拍 的绝对帧数。所有内容都从它读取：DOM、摄像机、声音。重计时意味着 编辑该块，而无需修改其他任何内容。
阅读 references/camera.md 了解镜头系统，references/motion.md 了解持续时间和排版。
阶段 5 —— 音频
两个轨道，两个文件，两个 <Audio> 标签：效果 和 音乐。保持
它们分开，以便任何一个都可以被替换而无需重新生成另一个。
效果 —— references/sound.md。克制是全部纪律：
一个 45 秒的视频通常总共需要三到五个事件。一个“砰”声表示一个东西出现，
一个“嗖”声表示一个元素在镜头内移动，一个“呼”声表示镜头本身移动。
python3 <skill-dir>/scripts/make_sfx.py sfx.spec.json public/sfx.wav
音乐 —— references/music.md。在构建之前先询问。 大多数人有
意见，许多人已经有一首曲目；询问只需一句话，可能会节省整个工作量：
你想要音乐背景吗？如果你有曲目，请发送，我会根据它进行剪辑。如果 没有，我可以合成一首——充满活力的、平静的、电影感的、简约的、温暖的、 还是紧张的？
如果他们已有曲目，则根据它进行剪辑：找到其 BPM，设置时间线匹配， 将镜头边界移动到其小节上。否则，合成一个背景音轨，其编曲变化 精确落在你的剪辑点上：
python3 <skill-dir>/scripts/make_music.py music.spec.json public/music.wav
在每个真实镜头边界处放置一个 sections 条目，在你最大的剪辑点上放置一个 hits 条目，
在任何你希望被阅读而不是感受的持续台词下放置一个 ducks 条目。音乐峰值大约在 ~0.30，
效果大约在 ~0.62。根据产品本质选择情绪——严肃主题需要更平静的背景音，
而繁忙的剪辑需要更稀疏的背景音。
阶段 6 —— 通过静态截图验证，然后再渲染
这是紧密循环，跳过它浪费数小时。
npx remotion still <CompositionId> out/f0700.png --frame=700
然后 实际查看 PNG。为每个镜头渲染一张静态截图，并在每个过渡处渲染一张。 检查：主体是否在帧内，是否有任何内容被截断在中间字，是否有空白区域， 文本是否合适。
添加一个无声的组合（defaultProps: { withAudio: false }），这样静态截图
就不需要音频文件存在。
尽可能通过数值进行调整。 缓动曲线、滚动距离、频谱内容—— 这些都是可计算的。编写一个临时的 Python 脚本来采样曲线并打印出你原本 需要通过猜测获得的内容。它比渲染更快，而且准确。
只有在静态截图正确后才渲染完整视频。
npx remotion render <CompositionId> out/video.mp4 --concurrency=4
在 16GB 机器上将并发数限制在 4 左右——Remotion 会为每个时隙生成一个 Chrome 标签页， 默认值（核心数）将导致交换。
阶段 7 —— 诚实地交付
发送文件。然后清楚地说明：
- 你无法验证的内容。你可以阅读静态截图；但你无法判断八秒钟 感觉 如何， 也无法听到音频。请如此说明。
- 你重建而非观察到的任何屏幕 —— 尤其是在受限产品上。列出它们， 并提议如果他们愿意共享访问权限，可以重做这些节拍。
- 你做出的可能与他们意见相左的判断决定。
- 如何更换音乐：将任何 WAV 或 MP3 文件放入
public/music.wav并重新渲染。 - 你在构建过程中发现的任何产品问题——渲染错误、错误标签、缺失状态。 你比大多数人都更仔细地阅读了他们的 UI。这些观察通常比视频本身更有价值。
参考文件
在到达相关阶段时阅读这些文件——它们很详细，提前全部加载没有意义。
| 文件 | 何时阅读 |
|---|---|
references/discovery.md | 阶段 1 —— 浏览、页面分类、凭据、设计体系、以及从受限产品着陆页构建 |
references/structure.md | 阶段 2 —— 单一叙事与分章、章节卡片设计、编写功能标签、过渡、排序 |
references/camera.md | 构建镜头 —— 布局空间、焦点点摄像机、剪裁与推进与变形、隔离组件 |
references/motion.md | 动画持续时间、排版、吸引注意模式、问题轮播 |
references/sound.md | 音效设计 —— 砰/嗖/呼 词汇、克制、合成键盘和点击音 |
references/music.md | 获取与合成背景音、选择情绪、将段落对齐到剪辑点、在效果下混合 |
references/pitfalls.md | 在第一次渲染前阅读。 会浪费实际时间的错误，每个都附有修复方法。 |
捆绑脚本
下面的 <skill-dir> 是该技能自身的目录——技能加载时提供给你的路径。
不要假定固定的安装位置；该技能可能以个人方式安装、作为插件安装，或检出到项目中。
| 脚本 | 功能 |
|---|---|
scripts/scaffold_video.py | 创建 Remotion 项目，包含可工作的版本锁定和配置 |
scripts/make_sfx.py | 根据 JSON 事件列表合成音效轨道。无需样本，仅依赖 numpy。 |
scripts/make_music.py | 合成六种情绪之一的音乐背景，其编曲与你的剪辑对齐。相同依赖。 |
assets/useCamera.ts | 焦点点摄像机钩子——复制到 src/hooks/ |
assets/ChapterCard.tsx | 分章结构的章节卡片——复制到 src/components/ |
简要说明
重建而非录制。一个故事，一个成果——除非产品受限制或功能真正独立， 则使用三个章节和简单标签。基于真实领域事实。帧是万物的单位。 隔离组件而非裁剪页面。UI 动画持续 150–300ms，摄像机移动约 1s。 四个声音就足够了。在制作音乐前先询问。在渲染前查看静态截图。 说明你无法检查的内容以及你推断的内容。