软件产品启动视频
制作一段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 — 章节化功能电影。 三个功能，每个由一张通俗易懂的标签卡引入，然后展示。
hook → [01 标签 → 功能] → [02 标签 → 功能] → [03 标签 → 功能] → slate
当产品有访问限制且你只能从其着陆页工作时使用，或者当功能确实不共享同一用户旅程时，或者当你希望从一个构建中产出三个独立的片段时使用。三个是合适的数量——四个则意味着没有一个能深入人心。
不要对序列进行章节化。 如果这些能力在一次会话中依次发生（研究→草稿→编辑），那是一个工作流，将其标记为三个功能会与素材对抗。如果有人要求在序列化产品上使用章节化，请提供折中方案：保持单一叙事，并在每个能力出现时将标签覆盖在动作之上。同样清晰，同样的片段边界，没有运行时间成本，故事完整。
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秒的视频通常总共需要3到5个音效事件。Popping声表示出现了一个东西，swishing声表示元素在镜头内移动，whooshing声表示镜头移动了。
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 | 声音设计 — pop/swish/whoosh词汇、克制、合成键盘声和点击声 |
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-300毫秒，摄像机移动大约1秒。四个音效就足够了。制作音乐之前先询问。在渲染之前查看静态图。说出你无法检查的内容和你推测的内容。