SaaS 产品演示视频怎么做：从目标、脚本、演示数据到交付的可复现流水线

概念示意图：可复现演示不是功能巡游，而是一条从目标、状态变化到验收与交付的证据链。

制作 SaaS 产品演示视频，最容易失败的地方不是录屏按钮没选对，而是没有把"这条视频必须证明什么"写成可验收的工程目标。结果往往是录了很多功能、剪了很多转场，观众却看不出操作前后发生了什么变化。

一套可复现的做法是：先定义目标状态，再把脚本写成状态转换；用可重置的演示数据复现这条转换；按镜头模块录制；先剪因果链，再处理视觉细节；最后按真实播放环境验收交付物。本文给出完整目录、模板、执行步骤和故障树，独立开发者或 SaaS 团队可以直接照着跑一遍。

0. 先固定本次制作环境与产物

下面是一套适合网页端 SaaS 演示的基线。它不是平台的强制参数，实际项目应按发布位置调整。

项目	本文示例
录制设备	Mac，一块主显示器
产品形态	浏览器中的 SaaS 控制台
主版本用途	官网功能页，16:9
录制画布	1920 × 1080
帧率	30 fps
目标时长	60～90 秒，只证明一项任务
声音	麦克风口播；系统声音仅在它属于证据时保留
主交付物	MP4、封面帧、字幕文件、脚本、可编辑工程

不要把所有文件扔进同一个目录。先建立下面的项目结构：

text 复制代码

saas-demo/
├── 00-brief/          # 目标、受众、发布位置
├── 01-script/         # 脚本、镜头表、界面文案
├── 02-demo-data/      # 演示数据与重置说明
├── 03-captures/       # 按镜头编号保存的原始录制
├── 04-edit/           # 可编辑工程与素材
├── 05-exports/        # 候选导出文件
└── 06-qa/             # 验收记录与问题截图

文件名建议包含镜头编号、内容和拍次，例如：

text 复制代码

S03-import-feedback-take02.mov
S04-group-result-take01.mov

这样界面更新时，可以只重录受影响的镜头，不必重新寻找整段素材。

1. 把"介绍产品"改写成可验收目标

先填写一句项目定义：

面向【观众】，展示他们如何把【开始状态】通过【关键操作】变成【可见结果】，最终发布在【位置】。

本文用一个虚构的"客户反馈整理 SaaS"作为贯穿示例：

面向每周整理客户反馈的产品经理，展示如何把 12 条未分类消息导入工作区，生成 3 个带负责人和优先级的问题组，最终放在产品功能页。

这句话里有四个可以检查的对象：观众、输入、操作和结果。如果目标只是"介绍智能分类功能"，后面很难判断该保留哪个镜头。

在 00-brief/goal.md 中写下验收条件：

markdown 复制代码

- 观众在前 5 秒内知道任务是什么
- 画面明确出现 12 条未分类消息
- 演示一次导入与整理操作
- 最终画面能确认 3 个问题组、负责人和优先级
- 不展开与该结果无关的设置页面

每增加一个功能镜头，都问一次：删掉它会不会让"输入如何变成结果"断裂？不会，就先移出主版本。

2. 把脚本写成状态转换表

产品演示的镜头表不应该只写"点击导入按钮"。按钮被点击是动作，状态变化才是证据。建议给每个镜头保留以下字段：

csv 复制代码

shot_id,start_state,action,end_state,proof,narration,target_seconds
S01,"消息散落在多个来源","无","12 条消息等待处理","输入规模可见","每周整理反馈，常常从一堆未分类消息开始",6
S02,"工作区为空","导入示例文件","12 条消息进入收件箱","数量与示例标题可见","先把本周反馈导入同一个工作区",10
S03,"消息尚未归组","执行整理操作","出现 3 个问题组","组名与数量可见","系统按问题主题整理出三个组",14
S04,"问题组未分配","设置负责人和优先级","三个组均有明确状态","负责人和优先级可见","现在团队可以直接进入处理",12
S05,"结果页已完成","无","停留并总结","输入与结果可对照","十二条消息已经变成三个可执行问题组",8

录制前朗读一遍脚本，同时在真实界面执行。遇到以下情况立刻改表，而不是寄希望于后期：

口播已经结束，界面仍在加载：缩短操作、预加载非关键页面，或如实保留必要等待；
界面先完成，口播还在描述步骤：删除对鼠标路径和按钮文字的重复说明；
最终状态只出现一瞬间：给结果镜头增加停留时间；
一个镜头包含两个独立结果：拆成两个镜头编号。

3. 准备能重置的演示数据

演示数据既要像真实业务，又不能包含真实客户信息。最稳妥的方式是制作一套合成数据，并保存数据清单和恢复起点的方法。

在 02-demo-data/manifest.json 中记录：

json 复制代码

{
  "workspace": "Northstar Demo",
  "input_file": "weekly-feedback-demo.csv",
  "input_rows": 12,
  "expected_groups": 3,
  "expected_status": "ready_for_assignment",
  "reset": "delete demo workspace, then import seed file again"
}

数据准备完成后做三次检查：

可理解性：姓名、公司、问题描述和数值能让观众快速理解，不使用"Test 1"一类无意义占位；
一致性：脚本中的数量、界面中的数量、口播中的数量完全一致；
可恢复性：清空工作区后，另一位成员也能按说明恢复到相同起点。

同时关闭通知，清理浏览器标签页、密码管理器浮层、个人头像、邮箱、内部域名和真实账号。录制前再搜索一遍客户名、手机号、令牌格式和内部项目代号。后期遮挡是补救手段，干净数据才是第一道防线。

4. 用"十秒测试 + 分镜拍次"完成录制

正式录制前先做一个十秒技术测试：

录下同一窗口中的一次点击和一次输入；
说出"麦克风测试一二三"；
如果产品会播放必要声音，让它单独响一次；
停止录制，立即回放保存文件；
确认画面清晰、指针可见、口播正常、必要系统声音存在。

测试通过后再按 shot_id 分段录制。每个镜头开始前留 2 秒静止，动作完成后留 3～5 秒结果停留；拍错时不要立刻乱点，先停一秒，再重新开始本镜头。后期会因此获得清晰的切点。

每拍完一条，在 03-captures/take-log.md 记录：

镜头	拍次	是否通过	问题	采用文件
S01	1	是	无	`S01-start-take01.mov`
S02	1	否	通知弹出	不采用
S02	2	是	无	`S02-import-take02.mov`

不要连续录完整条视频后才检查。每完成一个决定性结果镜头，就快速回放一次，确认数据状态与脚本一致。对于需要多次尝试的操作，先恢复演示数据，再开始下一拍，避免拍次之间的输入状态漂移。

5. 先剪因果链，再做视觉处理

真实编辑界面：先在时间线上剪掉失误和无关等待，再处理缩放、字幕等视觉层；截图只展示剪辑状态。

剪辑顺序会直接影响返工量，建议固定为：

text 复制代码

选择拍次 → 拼接状态转换 → 删除失误与无关等待
→ 校准口播 → 稳定时间线 → 处理缩放/光标/标注
→ 字幕 → 声音检查 → 导出

第一遍只检查因果关系：开始状态是否出现、动作是否足够完整、结果是否能被确认。不要在结构还会变化时精修字幕时间和镜头动画。

第二遍处理可读性：

小号按钮在最终播放器里看不清时，才局部放大；
鼠标只负责定位，不在结果出现后继续绕圈；
每个局部特写结束后，适时恢复上下文；
加速等待时明确保留前后状态，不能制造错误的性能印象；
字幕避开正在点击的控件和最终结果数字。

第三遍做声音检查。口播峰值不能触顶失真，句首句尾不能被切掉，背景音乐不能掩盖关键名词。发现某句话必须靠字幕才能听懂时，优先修口播或重新录该句。

6. 从一个母版生成交付矩阵

不要拿到一个 MP4 就宣布完成。先为每个发布位置记录尺寸、时长、字幕和封面要求：

交付物	画幅	内容策略	验收方式
官网功能页	16:9	完整证明链，保留结果停留	嵌入真实页面后播放
社交短版	9:16	重新构图同一任务，放大关键 UI	手机尺寸播放
销售跟进版	16:9	保留决策所需上下文	在会议软件共享画面
帮助中心版	16:9	节奏更慢，步骤更完整	以文档页实际宽度播放

竖屏版本需要逐镜头重新构图，不能只裁掉桌面画面的左右两边。完成导出后，把播放器缩放到真实嵌入尺寸，检查细小文字、字幕安全区、光标位置和结果数字；再戴耳机完整听一遍。

建议使用如下文件命名：

text 复制代码

feedback-demo-web-v03-1920x1080.mp4
feedback-demo-social-v02-1080x1920.mp4
feedback-demo-web-v03-zh-CN.srt
feedback-demo-cover-v02.png

版本号必须同时出现在验收记录中，避免团队审核的是 v03，实际上传的却是旧文件。

7. 发布前验收表

真实成片示例：字幕需要在最终播放器尺寸下检查安全区、可读性与遮挡；画面只示范验收对象，不代表所有交付格式。

在 06-qa/release-checklist.md 中逐项勾选：

至少让一位没有参与剪辑的人观看。他只能回答两个问题：视频展示了什么任务？最终结果是什么？只要回答含糊，就回到目标与状态转换表，而不是继续增加动画。

8. 常见故障树

A. 视频看起来完整，但观众说不清产品做了什么

检查开头是否交代了开始状态；
检查结果是否只是口播说明，画面没有证据；
删除功能巡游，只保留一条状态转换；
把最终结果停留时间加长，再做一次无声观看测试。

B. 每次重录都会出现不同结果

检查演示账号是否残留上一次操作；
检查种子文件、输入行数和脚本数字是否一致；
把重置过程写进 manifest.json；
每个拍次开始前按同一清单恢复起点。

C. 编辑器里清楚，放到网页后 UI 看不清

按真实容器宽度播放导出文件；
缩小浏览器录制区域，减少无关空白；
对决定性操作单独重新构图；
检查压缩后字号、细线和字幕是否仍可辨认。

D. 剪辑很顺，但操作像"凭空完成"

检查是否删掉了决定性的输入或确认动作；
在剪切前后各保留足够的状态上下文；
压缩等待可以，但必须让观众看见前后状态；
必要时重录一个包含完整动作的短镜头。

E. 团队已经确认成片，上传后却发现版本错误

核对导出文件名与 QA 记录中的版本号；
为每个交付物记录文件大小、导出时间和用途；
将已确认版本放入独立的 release/ 子目录；
上传前再次打开目标文件，核对开头、结尾和字幕。

ScreenSage Pro 在这套流程中的位置

ScreenSage Pro 是面向教程和产品演示的 Mac 录屏与编辑产品，这一定位已按项目内公开内容核对。本文的目录、状态转换表、演示数据、拍次记录和验收方法并不依赖某个工具；在 Mac 上执行时，可以把 ScreenSage Pro 作为录制与编辑环节的工具之一。当前产品信息以 ScreenSage Pro 官网为准。

作者说明：本文由 ScreenSage 团队根据 SaaS 演示视频制作流程整理。文中对产品的描述仅限于已经核对的定位，不包含效果保证。

结论

SaaS 产品演示视频可以像一个小型交付项目一样管理：目标负责定义证据，脚本负责描述状态转换，演示数据负责复现，分镜拍次负责隔离错误，剪辑负责保留因果链，交付矩阵和 QA 负责避免最后一公里出错。

先完成一个 60～90 秒、只证明一项任务的版本，再按渠道重新构图。只要脚本、数据和镜头都能独立复现，产品更新后也能局部重录，而不是每次从零开始。