软件产品启动视频
制作一段30-60秒的视频，让观众理解并想要该产品。
决定一切的决策：重建，而不是录屏
屏幕录制与你作对。真实延迟就是死寂时间。重拍成本高昂。 你无法定格某一帧，无法放慢一个节拍又加快另一个，也无法在不压缩成糊的情况下进行精细裁剪。
所以，将UI重建为Remotion内部基于帧驱动的React。每个可视化元素都是useCurrentFrame()的纯函数。文字输入沿着精确曲线落下，加载状态在节拍上结束，重拍只需要改一个数字。
之所以这样做是合理的，是因为你可以读取产品的实际代码（如果是本地项目）或DOM+CSS（如果是托管服务），并忠实地复现它们。去做吧——使用真实的类名、真实的颜色、真实的文案。重建应该与录屏无法区分，然后做得更好。
何时选择录屏： 重度3D场景、产品内部的视频内容、Canvas/WebGL表面或原生桌面应用。如果某个特定表面无法重建，只录制该表面，然后使用<OffthreadVideo>合成。
第一阶段——理解产品
在开始此阶段之前，请阅读references/discovery.md。它涵盖了浏览和分类流程、凭据对话，以及如何从在线站点提取设计系统。
简版：
- 给定URL：浏览它。先看登陆页面（它会告诉你产品如何定位自己），然后看应用本身。弄清楚产品为谁做了什么工作。
- 给定本地仓库/开发服务器：阅读代码。信息丰富得多——你能获得真实的组件、真实的主题令牌和真实的种子数据。
- 对页面进行优先级排序。大多数产品有20个页面，只有3个是关键。认证、设置、计费、隐私、账户、新手入门样板——这些几乎从来都不是故事核心。找到产品执行其唯一功能的那个页面。
- 如果好东西在登录后面，先询问——测试凭证，或他们本地开发中的种子账户。如果两者都不可用，不要放弃，也不要伪造你从未见过的会话：切换到章节式结构，从登陆页面自己的功能卡片、文案和组件开始构建。
discovery.md包含了收集流程和诚信规则。
然后在构建之前与用户确认你的理解——对产品的错误理解会导致整个构建失败。向他们展示：你认为产品是做什么的，你计划展示的2-4个页面，核心场景，镜头列表以及音乐问题（参见第四阶段）。一个检查点，然后开始运行。
第二阶段——选择结构
阅读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涵盖了章节卡片设计、如何编写标签（命名结果，而非机制；借用产品自身的词汇）、过渡和排序。
第三阶段——内容真实性验证
无论产品属于哪个领域，不要虚构其内容。如果是法律产品，法律条文必须是真实的。如果是分析产品，数字必须合理且内部一致。如果是代码工具，代码必须在读者脑海中是可编译的。
从仓库、API、种子数据或文档中提取真实内容。领域专家会看这些视频，一个虚构的细节就会让你失去他们所有人的信任。方名、日期和金额数字可以虚构——这些是特定于客户的，不是对世界的声明。
在数据文件中保留来源注释，说明每个事实来自哪里。未来的你会需要它。
第四阶段——构建
运行脚手架脚本，它会固定实际能协同工作的版本并写入配置：
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 vendor化；如果使用CSS变量表示颜色，你必须将它们带过来，否则所有内容都会渲染成无色。
-
src/scenes/ProductScene.tsx——一个导出的B对象，保存每个节拍作为绝对帧编号。所有内容都从中读取：DOM、摄像机、声音。重定时意味着编辑该块而不做其他任何事。
阅读references/camera.md了解镜头系统，references/motion.md了解时长和排版。
第五阶段——音频
两个轨道，两个文件，两个<Audio>标签：音效和音乐。保持它们分开，这样任何一个都可以被替换而无需重新生成另一个。
音效——references/sound.md。克制是整个准则：一个45秒的视频通常总共需要三到五个音效事件。Pop表示某物出现，Swish表示元素在镜头内移动，Whoosh表示镜头本身移动。
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。根据产品的性质选择情绪——严肃的主题需要更平静的背景音，而忙碌的剪辑需要更稀疏的配乐。
第六阶段——用静态图像验证，再渲染
这是紧密循环，跳过它会浪费数小时。
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标签页，默认值（核心数）会导致内存交换。
第七阶段——如实交付
发送文件。然后坦率地说：
- 你无法验证的内容。你可以阅读静态图；但你无法判断八秒钟感觉如何，也无法听到音频。如实说明。
- 任何你重建而非观察到的屏幕——尤其是在受限产品上。列出它们，并主动提出如果他们分享访问权限，你可以重做那些节拍。
- 你做出了哪些他们可能不同意的判断。
- 如何替换音乐：将任何WAV或MP3文件放入
public/music.wav并重新渲染。 - 在构建过程中你在他们的产品中发现的任何问题——渲染bug、错误标签、缺失状态。你刚刚比大多数人都更仔细地阅读了他们的UI。这个观察结果往往比视频本身更有价值。
参考文件
当你到达相关阶段时阅读这些文件——它们很详细，提前全部加载没有意义。
| 文件 | 何时阅读 |
|---|---|
references/discovery.md | 第一阶段——浏览、页面分类、凭据、设计系统，以及从受限产品的着陆页构建 |
references/structure.md | 第二阶段——单一叙事与章节式、章节卡片设计、编写功能标签、过渡、排序 |
references/camera.md | 构建镜头——布局空间、焦点摄像机、切/推/变、隔离组件 |
references/motion.md | 动画时长、排版、钩子模式、问题滚动 |
references/sound.md | 声音设计——pop/swish/whoosh词汇、克制、合成键盘和点击声 |
references/music.md | 获取与合成背景音乐、选择情绪、将章节对齐到剪辑点、混合在音效下 |
references/pitfalls.md | 在第一次渲染前阅读。 导致实际数小时问题的bug，每个都附有修复方法。 |
内置脚本
下面的<skill-dir>是该技能自己的目录——技能加载时提供给你的路径。不要假设固定的安装位置；该技能可能以个人方式安装、作为插件安装或签入到项目中。
| 脚本 | 功能 |
|---|---|
scripts/scaffold_video.py | 创建Remotion项目，带有工作版本固定和配置 |
scripts/make_sfx.py | 从JSON事件列表合成音效轨道。无样本，除了numpy外无依赖。 |
scripts/make_music.py | 以六种情绪之一合成音乐背景，其编排对齐到你的剪辑点。相同的依赖。 |
assets/useCamera.ts | 焦点摄像机hook——复制到src/hooks/ |
assets/ChapterCard.tsx | 章节式结构的章节卡片——复制到src/components/ |
简版
重建而不是录制。一个故事，一个成果——除非产品受限或其功能确实独立，那么就使用三个带简单标签的章节。验证每个领域事实。帧是一切的基本单位。隔离组件而不是裁剪页面。UI动画150-300毫秒，摄像机移动约1秒。四个音效就足够了。制作音乐前先询问。渲染前查看静态图。说明你无法检查的内容以及你推断的内容。