HTML 视频化实测

先看两个已经做出来的成品。

第一条是《魔法森林：宝石钥匙》的产品演示。原始材料是一段没有声音的网页游戏录屏，最后做成了 90 秒的视频，有配音、字幕、场景提示和规则讲解。

🎬

【视频号成品链接：魔法森林产品 Demo】

第二条来自一场横屏直播。成片保留了嘉宾和屏幕分享，下方的信息区会跟着口播变化，讲到概念、时间线和原因时，画面会切换成对应的卡片和关系图。

🎬

【视频号成品链接：《法律 Agent 为什么常从诉讼场景开始》】

这两条视频都来自我原本就有的素材。我会录屏，也会做直播和演讲，但录完之后通常就停住了，因为我不知道怎样把一段原始视频做成现在看到的样子。

以前我把困难简单归结为剪辑费时间。真正动手后才发现，时间只是其中一部分，更大的问题是我没有接受过视频运营和剪辑训练。

拿产品录屏来说，我可以完整地演示一遍功能，却不知道哪些停顿该剪掉，哪一步需要补一句解释，规则说明应该放在画面的什么位置。录屏没有声音时，还要自己写旁白、选择 TTS、配字幕，再把声音和操作对上。

直播和演讲也一样。听到一个重要观点时，我会觉得这里应该有一张像 PPT 一样的信息图，帮助观众看懂概念之间的关系。可是这张图该怎么设计、什么时候出现、停留多久、在第几句话之后切换，我都做不来。

专业剪辑师和内容运营平时处理的，正是这些细节。他们会判断一句话适合用标题、流程、对比还是时间轴，也知道怎样把画面卡在正确的时间点。我的问题因此很具体：手里有内容，也能把内容录下来，中间缺了一段把内容翻译成视频画面的能力。

我后来想到，字幕、卡片、流程图和动画都可以用 HTML 来描述。Codex 可以读录屏、逐字稿和产品资料，也能写代码、运行浏览器和调用 FFmpeg。沿着这个思路，我开始尝试让它补上这段工作。

《魔法森林：宝石钥匙》是一款儿童网页解谜游戏。原始录屏约 5 分 41 秒，从开始页一路玩到最终宝箱，完整记录了各个关卡的操作。

熟悉游戏的人当然知道鼠标为什么要点击或拖动，第一次看到它的人却很难跟上。观众会看到页面不断变化，却未必知道当前关卡的目标、完成了哪个机关、答错之后能不能继续，以及十枚宝石碎片最后会发生什么。

我把录屏、游戏说明和关卡资料交给 Codex，请它先设计 90 秒的演示结构。它从完整流程里选出八个场景，保留游戏的真实操作，再用标题、状态提示和旁白把故事连起来。观众能够跟着视频看到任务推进、温和重试、收集碎片和最终开箱。

这条片子的声音也经历了几轮调整。录屏本身没有音轨，Codex 先写出旁白，再生成 TTS 和字幕。第一版声音听起来很生硬，我让它改用播客实际使用的声线，字幕时间也随之重新对齐。

正式导出后还发现过一个画面问题：顶部残留了一条浏览器标签栏。Codex 根据检查帧重新计算裁切范围，保留字幕和音轨，只修正画面，最后才得到开头放出的版本。

整个过程中，我给出的反馈都很日常，例如“声音太难听”“浏览器栏没有裁干净”“这里会不会挡住按钮”。具体怎样修改音轨、字幕和画面，由 Codex 在工程里完成。

第二个场景来自一场横屏直播。横屏画面改成竖版以后，上方放嘉宾和屏幕分享，下方会多出很大一块空间。我原来的做法是在下面放一张固定海报，整条视频都显示“问题、流程、复核”三个词。

这种画面很快就会失去作用。嘉宾已经换了好几个话题，下方仍然停在同一张图上，观众看过几秒之后便不会再注意它。

第一次使用 HTML 改造时，画面丰富了很多，里面有流程、卡片和人工复核节点。后来检查逐字稿，我发现这些内容只是和视频主题大致相关，嘉宾在那段口播里并没有讲到其中一些步骤。画面虽然完整，却会带偏原来的意思。

这次失败促使我修改了方法。每个信息画面都要绑定一段真实口播，标题也不能拿来代替逐字稿。Codex 先读取经过确认的逐字稿和切片起止时间，再生成一份分镜，写清每个场景对应哪段原话、从第几秒开始，以及用什么信息结构来呈现。

《法律 Agent 为什么常从诉讼场景开始》一共 110.7 秒，分镜被拆成七段。嘉宾先谈技术焦点如何从模型走到 Agent，接着解释 Agent 的含义，再用“高分学生进入不同专业”作类比，最后讨论诉讼为什么容易成为专业能力的入口。画面也随内容依次使用时间轴、定义、中心关系、类比、原因和流程等组件。

《法律 Agent 为什么常从诉讼场景开始》的七个场景

字体、颜色和动画方式可以沿用同一套品牌样式，信息结构则跟着每一段口播调整。下方区域由此开始参与讲解，也有了检查依据：某张卡片写了什么，可以回到对应的原话核对。

上一篇文章里，我用 Codex 和 HyperFrames 做过两类视频。第一类是把已经设计好的 PPT 与演讲音频对齐，第二类是从 97 分钟对谈中选出片段，再加入精彩快剪、标题卡和转场。

当时的画面基础已经存在。PPT 本身就是完整的视觉内容，Codex 主要处理页面导出、音频转写、切页时间和渲染检查。对谈切片也保留了原始人物画面，后续增加的内容集中在开头快剪、标题卡和包装。HyperFrames 很适合把这些已有元素编排进一条可渲染的视频工程。

这一次遇到的材料没有现成的讲解画面。游戏录屏只有操作过程，直播也只有人物和屏幕分享。要达到开头两条成片的效果，还需要把产品规则和口播信息重新组织成视觉内容，并且准确放到对应时间点。

所以这次增加的关键能力，是内容到画面的转换。Codex 需要判断当前这段适合时间轴、定义卡、两栏对比还是流程图，再用 HTML 生成画面，把它放进原视频的空白区域或安全位置。逐字稿、产品说明和分镜也一起保留下来，后面修改文字、时间或组件时可以继续使用。

从最终效果看，上一篇主要完成 PPT 切页、长视频裁切和基础包装；这一次的视频里多了一层持续变化的解释画面。它可以讲清产品规则，也可以把演讲中的抽象信息做成类似 PPT 的视觉提示，并随着口播推进。

这里使用的 HTML 和普通网页采用同样的基础技术。文字放在哪里、卡片多大、箭头怎样出现、某个节点何时点亮，都可以由 HTML、CSS 和 JavaScript 控制。

以一段三阶段的制度演进为例，分镜会记录标题从第几秒出现，三个节点分别在什么时候点亮，结论在哪一句口播后进入。浏览器按照这些时间生成连续画面，FFmpeg 再将画面与原视频、声音和字幕合成。

WORKFLOW

用户不需要打开代码文件。我实际使用时，先把录屏、逐字稿或文章交给 Codex，让它生成分镜和预览。看完以后，我直接用自然语言反馈，可能是文字太多、图形选错、切换太早，也可能是信息区挡住了产品按钮。Codex 修改分镜数据和组件参数，再重新生成预览或成片。

《法律 Agent 为什么常从诉讼场景开始》的分镜确认以后，HTML 信息层渲染约 23 秒，与原视频合成约 26 秒。这个数字只代表机器处理时间，前面的内容判断、分镜确认和最终观看仍然需要人工完成。它能说明的是，文字或图形需要修改时，不必重新手工摆放整套图层和关键帧。

几次实际制作之后，我把分镜、HTML 组件、浏览器渲染、视频合成和检查流程整理成了 content-video-studio。现在它可以处理三类常见材料：产品录屏和软件演示、直播或访谈切片，以及文章或法规解读视频。

魔法森林已经完整跑过产品演示流程，《法律 Agent 为什么常从诉讼场景开始》完成了逐字稿分镜、HTML 信息区和最终视频的验证。文章视频目前也有技术样片，可以将一篇定稿内容压缩成较短的口播和全屏讲解画面。

这个 Skill 默认先生成分镜，用户确认后再正式渲染。原因来自前面那次失败：如果视觉内容和原文没有对齐，批量生成只会让问题出现在更多视频里。

如果手里有一段产品录屏，可以同时准备功能说明和希望重点展示的操作；如果处理直播或演讲，最好再提供经过确认的逐字稿。先看分镜和预览，确认讲解画面与内容一致后，再生成最终视频，基本就能达到开头两条成片所展示的效果。