过去一段时间，我用 HyperFrames 连续做了几种完全不同的视频：HHY Web Runtime 发布片、HHY v1.7.0 产品发布片、两分钟左右的入门教学、可批量生产的课程，以及一条 9:16 的移动端创意短片。
它们的目的不同。发布片要在几十秒里建立记忆点，教学视频必须让代码和旁白对应，课程需要重复生产，竖屏短片则更依赖单一视觉概念。但做完这些项目以后，我越来越确定：视频生产真正难的部分，不是让一个元素动起来，而是让内容、时间、素材、声音和验证形成同一个系统。
HyperFrames 对我有价值，是因为它把视频写成 HTML。场景是 DOM，动画有可定位的时间，图片、代码、音频和子合成都是项目文件，最终再由确定的渲染流程输出 MP4。这种方式很像做软件：画面依然需要审美判断，但结构可以阅读，变化可以复现，错误可以检查。
我先定义视频要证明什么
最容易走偏的做法，是一开始就选择转场、粒子或 3D 效果。画面可能很忙，但观众看完不知道产品是什么。
我现在会先写一个很短的制作约束，至少回答五个问题：
| 问题 | 我需要得到的答案 |
|---|---|
| 核心信息 | 观众看完只记住一句什么？ |
| 目标受众 | 是开发者、学习者，还是移动端泛用户？ |
| 证据 | 哪些代码、界面、结果可以真实展示？ |
| 边界 | 哪些能力尚未交付，不能写进画面？ |
| 载体 | 横屏、竖屏、网站、社交平台还是课程？ |
例如 HHY v1.7.0 发布片的主线不是“我们做了很多功能”，而是：HHY 已经从 Flow-first 语言走向可以构建真实应用的系统。 41 秒被拆成 Logo、语言、编译器、ETL、CMS 和邀请六段，每一段只承担一个信息任务。
这也帮助我控制技术表述。发布片可以写“Verified optimizing compiler and Runtime”，但不能因为某个局部基准更快，就把它变成对所有程序的性能承诺。视频文案越短，越容易把条件删掉，因此内容边界必须在动画之前确定。
Storyboard 不是画面清单，而是时间预算
我以前理解 storyboard，容易把它当成“第一幕出现标题，第二幕出现代码”。真正进入制作以后，我发现它更像一份时间预算。
一段 6 秒的场景，不能同时容纳标题进入、三行代码逐字出现、架构图展开、结果计数和离场转场。即使技术上都能实现，观看时也没有足够时间完成阅读。
我会把每个场景继续拆成小阶段：
0.0–1.4s 建立标题
1.4–3.2s 展示输入与方向
3.2–4.8s 给出核心模型或结果
4.8–6.0s 保持画面，让观众读完
最后这个“保持”很重要。动画系统很容易让人产生一种错觉：画面不动就是浪费。但如果所有元素一直运动，观众真正看到的只有变化，没有结论。
在发布片里，我通常让一个场景有一个主动作，其余动画服务于它。|> 从远处接近并翻转成 HHY Logo，是开场的主动作；后面的版本文字和网址只需要清晰到位。把每个细节都做成主角，会让品牌记忆点消失。
HTML 让我把画面当成可维护的结构
HyperFrames 的合成不是录制浏览器操作，而是把可渲染页面本身作为视频源。一个元素何时出现、持续多久、属于哪条轨道，都可以在 DOM 中明确表达；动画时间轴可以暂停和 seek，因此同一时间点应当得到同一画面。
这给我带来几个工程上的直接收益：
- 文案不是压进一张图片里，后续可以修改和本地化；
- 代码、终端、数据卡片可以保持真实文本和稳定布局；
- 场景可以拆成子合成，避免一份 HTML 无限增长；
- 横屏和竖屏可以复用设计语言，但分别控制构图；
- 固定时间截图可以成为评审证据，而不是依赖“从头播放时感觉没问题”。
但 HTML 也不会自动带来好设计。网页允许用户滚动、等待和点击，视频却按照时间强制推进。一个在网页上合理的卡片布局，放到 1920×1080 的视频里可能显得细碎；一个漂亮的长页面，缩到画面中可能完全看不清。
因此我的处理原则是：视频里尽量使用大字号、短句、明确的视觉层级和有限的同时信息量。真实产品截图需要足够大；代码只展示当下要解释的部分；背景和装饰不能与正文争夺对比度。
真实素材决定视频有没有可信度
我会优先使用项目本身的 Logo、真实代码、真实命令和真实界面。模型或插画可以建立氛围，但不能替代产品证据。
HHY v1.7.0 发布片里的 CMS 画面来自实际网站和管理界面；ETL 场景中的客户数、部门数和数据结果来自已经验证的 fixture；入门教学使用可以运行的 .hhy 文件和真实命令，而不是为了画面临时写一段不存在的语法。
这里有一个很实际的经验：先验证素材，再设计围绕它的动画。 如果最后才发现截图比例不适合、命令运行失败、数据与发布版本不一致，前面的构图和节奏都会返工。
素材进入项目后，我也尽量冻结成当地文件。渲染不依赖网络请求，不在运行时随机选择图片，也不让远程资源的变化影响以后重新输出。这既是稳定性问题，也是可追溯性问题。
教学视频的时间轴必须跟着理解过程走
产品发布片可以依靠节奏建立情绪，教学视频不能只追求快。观众需要看见概念、代码、执行和结果之间的关系。
我制作 HHY 入门视频时，把内容拆成欢迎、安装、绑定、函数、Flow 和运行六个子合成。每一段都有独立旁白和画面，组合后形成一条完整时间轴。
这类视频给我的几个经验是：
- 先让观众知道本段要得到什么结果，再解释语法。
- 代码出现的速度要服从旁白，而不是服从动画模板。
- 命令、源码和输出必须在画面上有不同层级。
- 字幕不能挡住正在讲解的代码。
- 对长句，应根据实际语音时长切分字幕，而不是平均分配时间。
课程生产进一步放大了这个问题。一条视频可以手工微调，16 集课程如果每一集都从空白开始，风格和质量很快会漂移。因此我把课程拆成脚本、可运行示例、旁白、句子时间、字幕、合成、渲染、媒体验证和网站同步几个阶段。
模板的价值不是让每集长得完全一样，而是固定不应该反复争论的部分：分辨率、品牌颜色、标题区、代码区、字幕安全区、字体、声音格式和输出检查。每一集真正变化的是教学目标、示例和节奏。
声音不是最后再贴上去的一条轨道
没有旁白的发布片，我会先确定几个视觉节拍，再让音乐和关键音效支撑切换。带旁白的教学视频则相反：实际语音时长决定场景长度，画面需要围绕句子进入和停留。
如果先按想象做完 60 秒动画，最后得到 73 秒旁白，通常不是把语速加快就能解决。字幕、代码揭示、段落停留和场景连接都需要重新分配。
我现在更愿意把声音当成时间数据：先生成或录制，测量每句话的长度，再建立场景和字幕。渲染时，视频素材本身静音，声音由单独轨道管理，便于调整、替换和验证。
音效也要克制。键盘确认、程序完成或场景切换可以有一个明确声音，但每个文字进入都配音效，会快速消耗注意力。声音应该帮助观众理解事件，而不是证明制作工具拥有多少效果。
同一套语言，不等于同一个画面比例
横屏发布片强调左右关系和宽阔留白；竖屏短片更接近单列叙事，主体必须始终处在手机可视区域。把 16:9 画面简单裁成 9:16，通常会同时失去文字和主体。
在 HHY 的竖屏创意短片里，我使用了一个连续场景：人物生活在 macOS 桌面中，Terminal 从 Dock 上方出现，真实命令逐字输入，运行成功后 HHY Logo 从终端结果中进入画面。22 秒没有切镜，所有变化都围绕同一空间关系发生。
这个项目让我意识到，创意并不一定等于更多镜头。一个清楚的空间规则，加上分阶段揭示，往往比连续切换背景更容易形成完整体验。竖屏尤其需要控制顶部菜单、终端、人物、Logo 和收尾文案之间的安全区域。
检查固定时间点，比只看一遍成片更可靠
视频最容易遗漏的问题，经常只出现几帧：文字刚好重叠、元素还没完全退出、转场中间出现空白、图片比例短暂变形，或者某一行代码在动画过程中被裁切。
我会保留三层验证：
| 层级 | 检查内容 |
|---|---|
| 静态规则 | 时间属性、资源路径、确定性和合成结构 |
| 运行与布局 | 页面错误、元素越界、文字遮挡、对比度 |
| 成片证据 | 指定时间截图、contact sheet、音视频元数据和最终 MP4 |
完整播放仍然必要，但它更适合判断节奏和情绪。定位布局问题时，固定时间采样更有效。发布片会在场景主体稳定时取 poster，也会专门检查切换前后；教学视频还要检查字幕、代码揭示和声音是否在相同时间点对齐。
自动检查不能替代审美判断。一次 check 通过，只说明既定规则没有发现错误，不说明故事足够清楚、字体一定合适或节奏已经最好。我的做法是让工具负责发现可计算的问题，人负责判断信息是否值得出现、观众是否来得及理解。
我最终保留下来的工作流
经过几类项目以后，我现在使用的顺序大致是：
一句核心信息
→ 内容与证据边界
→ Storyboard 和时间预算
→ 准备并验证真实素材
→ HTML 场景与可 seek 时间轴
→ 声音、字幕和画面对齐
→ 固定时间截图与自动检查
→ 完整播放审阅
→ 渲染并验证最终文件
其中最值得保留的不是某个转场参数，而是三个原则。
第一，先决定观众应该理解什么，再决定画面怎么动。
第二，把真实内容放进视频，而不是用视觉包装替代证据。
第三，让视频能够被重新生成、检查和修改。 当版本号、代码、配图或语言变化时，我希望修改的是结构化源文件，而不是重新打开一个只能凭记忆调整的工程。
HyperFrames 没有消除视频创作中的判断。它把判断放进一个更适合工程师的媒介：HTML、时间轴、文件、规则和可重复渲染。对我来说，这不是把视频变成网页，而是把一次性的制作过程变成可以持续演进的内容系统。
好的工程化视频，不是动画最多的那一条，而是信息、证据、节奏和画面在同一条时间线上达成一致。