字幕已经剪好，配音也录完了，接下来想让画面随着讲解逐步出现。最容易想到的办法是把每句话配一张图，再给图片加擦除动画。做完才会发现：说到原因时结果已经露出来了，人物的半张脸先出现，箭头却要等到下一句话。问题出在画面的信息顺序，而不只是动画效果。
srt-whiteboard-animation 是一套可以参考的开源制作流程。它把字幕时间、图片区域和绘制顺序分别保存，最后渲染视频。本文按 2026 年 9 月 23 日的仓库代码说明怎样准备素材、怎样检查分镜，以及哪些地方仍需要自己调整。字幕解析部分做了本地运行验证，完整视频渲染未作为实测结果。
先拿三十秒内容做一幕
假设要解释一次网页请求，配音分成三段：浏览器发出请求，服务器查询数据，结果返回浏览器。画面可以一直保留浏览器和服务器，只在对应时间补出箭头、数据库和返回内容。这样观众看见的是同一件事逐步发生，不必反复辨认新的画面。
先选这类关系清楚的短片段，比直接处理整段十分钟课程更容易发现问题。把字幕和音频放到同一个项目目录，人工听一次：专有名词有没有识别错，停顿是不是被压掉，字幕结束时间是否超过音频。动画程序无法根据时间戳判断一句话是否念完，也不会发现讲解漏掉了一个条件。
在仓库目录内，可以使用解析脚本生成建议分镜：
python3 scripts/parse_srt.py lesson.srt \
--target-sec 30 --min-sec 25 --max-sec 35 > scenes.json
这里的 lesson.srt 是你自己的字幕文件，输出 JSON 包含逐条字幕与建议场景。标准错误还会打印简短的场景摘要，便于检查。这个解析步骤只使用 Python 标准库，不需要先安装视频渲染依赖。解析脚本
要留意这三个秒数的含义。脚本会按字幕的起止跨度分组，并不会把一条过长字幕切开。用三条连续字幕组成三十秒内容，本地验证得到一个三十秒场景；再用一条四十秒字幕输入，结果仍是一幕四十秒，超过了 --max-sec 35。最后一幕也可能短于最小时长。因此，这些参数适合给出初稿，不能当作视频时长的强校验。
分组之后还要看语义。上一幕以“但这种方法有一个问题”结束，下一幕才揭示问题，通常应该重新分段。遇到公式推导、条件判断或流程分支，宁可按讲解的完整步骤拆幕，也不要为了凑满三十秒，把两个不同问题塞进同一幅图。
配图时就给后面的动画留出位置
一张适合静态阅读的插图，未必适合逐步绘制。复杂背景、交叉的线条和紧贴的人物，会增加区域标注的难度。制作第一版时，可以把元素放得松一些，先保证每个对象能单独识别。
例如网页请求这一幕，让浏览器在左、服务器在右、数据库在服务器下方，预留两条不同高度的箭头通道。请求箭头与返回箭头若完全重合，后面就很难表达“先请求、再返回”。图里也不必写大段解释文字，具体术语可以交给字幕或后期排版；生成图像里的错字一旦进入笔迹动画，修改成本会更高。
仓库示例使用暖米黄色底和较简单的线稿。风格可以保持一致，但同一项目更需要统一画布比例、线条粗细和人物大小。第二幕突然换成另一种透视，即使颜色相同，也会使观众重新理解空间关系。项目说明与示例
正式标注前导出最终尺寸的图片。后面若裁切或缩放，区域坐标便要跟着调整。为了保留修改余地，可以另存原图、用于动画的图和标注文件，文件名保持对应；不要把不同尺寸的图片都叫 final.png，然后靠记忆判断哪个文件与标注匹配。
标注的是“什么时候让人看见什么”
标注文件里的画布宽高应与图片一致，元素区域用原图像素坐标。每个对象除了位置，还要有绘制顺序和开始时间。可以先在纸上列出一张很小的表：第一句出现浏览器和请求箭头，第二句出现数据库查询，第三句出现结果和返回箭头。
开始时间应相对这一幕计算。字幕原本处于整段音频的第二分钟，不能直接把两分钟的时间戳写成当前三十秒场景的开始时间。应先减去本幕起点，再结合停顿安排绘制。否则本幕播完，某些对象可能还没有开始出现。
一个元素从开始到完成，要同时满足两个条件：让观众有时间辨认，且不会拖到下一条关键信息后面。过短的复杂图会像突然闪现；过长的简单箭头则会让画面显得迟钝。可以先让主要对象早于被提到的词完成，再把少量强调笔迹放在讲解时出现，避免所有对象都机械地跟随句首。
两个区域有重叠时，要特别检查“提前露出”。例如先绘制服务器，但数据库图标的一角落在服务器区域内；第一轮揭示时，那个角也可能被带出来。标注中的保护区用于暂时保留后续元素对应的位置。不过保护区设得太大，又可能把本来该出现的线条一起挡住。检查时应逐帧看重叠处，而不只是确认整张图最后完整。示例标注文件
预览台顺畅，不代表最终笔迹已经合适
仓库里的浏览器预览台方便检查区域和时序，但其中手部移动的代理效果与最终流式绘制不同。先用预览找到叙事顺序和重叠错误，再渲染一个短场景，才能看见实际线条怎样铺开。
如果发现手指位置看起来不对，先区分是整个区域定位错，还是笔迹生成方式不适合这张图。前者需要改坐标，后者可能要调整线稿或渲染选项。仅在预览里反复拖动手部路径，未必能改变最终笔迹。
第一次渲染不需要追求整段成片。选一个有两个重叠对象、一次箭头变化的场景，检查开头、中间和结束三个位置：开头是否已经漏出未开始的内容，中间是否能理解动作顺序，结尾是否留有看完整图的时间。再关闭声音播放一次，看信息顺序是否成立；打开声音检查关键动作是否落在对应讲解附近。
若某个复杂对象始终画得很乱，可以简化图形。知识类视频里，一个轮廓清楚的数据库符号，常比有很多装饰线的机柜更便于理解。增加渲染参数不能弥补图像本身不适合分区的问题。流式渲染入口
合并之前，把每幕的时间算清楚
字幕时间轴与逐幕视频之间还有一个容易忽略的问题：空隙。两条字幕之间可能存在停顿；两个场景的范围也可能不连续。若将视频文件直接顺序拼接，却把原音频原封不动放上去，累计几次空隙后就可能不同步。
制作时要明确一种处理方式：让场景覆盖连续时间，包含必要静止停留；或者在剪辑时间线上显式补齐空隙。不能一部分场景保留空隙，另一部分又把它压缩掉。检查最后一幕的对应时间，通常比只看开头十秒更容易发现累计偏差。
合并脚本完成的是视频文件拼接，成片的声音、字幕样式和平台导出参数仍应在实际流程中核对。不要把“导出了 MP4”当成全部交付：声音是否存在，字幕是否遮住关键对象，手机上文字是否能读清，都需要播放确认。场景合并脚本
项目交付时保留字幕、图片、标注、渲染参数和最终视频。以后只改一句配音，可以先定位它影响哪一幕，再判断是否需要调整对象出现时间；不必重新猜整段动画怎样做出来。对白板讲解来说，能方便地改对一个事实，与第一次渲染得快同样实用。