解说视频 Prompt 基准：分析 33 份 Brief

01

我们分析了什么

来源是 TapVid 内部策划的 Good Case 库的冻结的 9 月 1 日 2026 导出。仅当记录包含完整提示、公共共享 URL、生成 URL 和 MP4 附件时，我们才包含记录。这就产生了严格的 64 Brief语料库。标签可以重叠，因此一条记录可以属于多个分析切片。本文使用标记为解释者的 33 记录。

我们使用十个显式字段的确定性关键字字典对每个提示进行编码：

该方法测量某个字段是否出现在提示文本中。它不会衡量创建者是否在产品设置中选择了相同字段或通过上传提供了该字段。它也不对输出质量进行排名。该库包含选定的示例，而不是每一代的随机样本，因此结果描述了策划输出中的规划模式。他们没有建立因果关系或成功率。

这里不再复制私人客户提示。调查结果是汇总的，稍后显示的案例链接到其现有的公共共享页面。

02

解释器视频提示基准测试结果

Inspect image

Prompt 中位数包含 3,621 字符。该数字是描述性的，而不是目标。当资产、批准的副本和输出设置通过单独的结构化字段到达时，简短的简介就可以发挥作用。如果长篇大论详细描述了气氛，但从未明确哪个屏幕截图属于哪个声明，那么它仍然可能会失败。

三项发现对产品团队很重要。

首先，视觉方向很常见，因为它很容易表达。颜色、相机、排版、动作和情绪都自然地融入提示中。其次，产品真相层不太一致。不到一半的简报明确锁定事实。第三，通常会假设观看者的背景。尽管相同的功能可能需要对买家、运营商或技术审核员进行不同的解释，但 33 简报中只有 8 份明确指定了受众。

这些并不是在每个提示中添加十个段落的理由。它们是将必须明确的决策与可以在其他地方提供的设置和资产分开的原因。

03

缺失的一层是事实与视觉的契约

Inspect image

大多数公共解说提示指南都侧重于主题、风格、时间安排和场景。例如，Ngram 的解释器库为读者提供真实的标准化提示并报告特定于产品的模式，例如常见持续时间和源附件行为。 Golpo 将示例与提示、脚本和音频配对。当读者需要灵感时，这些页面很有用。它们不会取代告诉生产系统什么必须保持字面意思以及什么视觉效果证明每个陈述的合同。

从事实到视觉的合同由五个部分组成：

• 声明：批准的句子、编号、名称或规范。
• 来源： 支持它的文件、屏幕、文档或 URL。
• 视觉绑定：在说出主张时应出现的确切图像、UI 状态或演示。
• 允许的转换： 裁剪、调整大小、突出显示、注释或设置动画，而无需重新绘制源。
• 审查测试： 在批准之前人类必须验证的内容。

这是一个虚构的分析产品的紧凑示例：

该合同防止了常见的失败：旁白讨论了一种能力，同时出现了一个视觉上相似但不正确的屏幕。这就是为什么 TapVid 的准确性模型分为三个部分：保留提供的资源、保留文字信息以及保留脚本与正确视觉效果之间的对应关系。这是一种审查纪律，而不是绝对保证。

04

如何根据基准编写解释视频提示

使用以下顺序。它使产品真实性领先于装饰方向。

1. 指定一位受众和一项决定

避免 `Explain our platform to everyone`。使用角色、情况和问题：

向运营经理解释保存的报告工作流程，评估团队成员是否可以重复使用相同的筛选视图。

观众字段在我们的语料库中并不常见，但它改变了术语、证明、节奏和 CTA。技术审核员可能需要检查实际的 UI 状态。企业买家可能需要前后工作流程。一个视频不应试图在每个场景中通过单独的信息来满足两者。

2.附上源包

在请求视觉风格之前列出已批准的资产和文字事实。将每个项目标记为以下三种类型之一：

• 必须显示： 准确的屏幕截图、徽标、产品图片或演示。
• 必须说： 确切的名称、编号、规格或法律短语。
• 可能生成：装饰背景、过渡、抽象隐喻或非产品连接视觉效果。

这种区别使生产系统可以使用生成视觉效果，欢迎解释，同时保护产品证据免遭创造性重写。

3.围绕解释单元构建场景

每个场景应完成一个单元：问题、机制、证明或动作。一个场景并不仅仅因为它具有不同的摄像机角度而有用。

对于 45 第二个软件解释器，大纲可能是：

• 显示当前报告问题。
• 显示批准的仪表板屏幕截图并命名已保存的报告功能。
• 演示过滤器如何成为已保存视图的一部分。
• 显示打开相同报告状态的队友。
• 密切关注具体的评估行动。

场景结构出现在 33 解释简介的 24 中。该模式是有道理的，因为解释取决于顺序。如果证据出现在观众理解其机制之前，那么它就变成了装饰而不是证据。

4.在真相层后添加样式

视觉方向是语料库中最常见的显式字段。保留它，但让它用于解释。指定层次结构、易读性、运动行为以及产品镜头和生成的上下文之间的差异。

好的方向：

使用受限制的技术视觉系统。保持提供的 UI 屏幕截图完好无损。仅将生成的运动图形用于过渡和抽象数据流。不要发明屏幕、菜单标签、指标或产品状态。

弱方向：

使其具有未来感、优质感、电影感和病毒感。

弱版本产生没有审查标准的品味词。

5.以可验证的CTA结束

只有八个 33 提示明确包含 CTA。解释者并不总是需要销售结束，但应该以解释支持的下一个决定结束。示例包括 `Review the saved-report workflow`、`Compare the two input files` 或 `Build one draft from your approved script`。

05

可复制的讲解视频提示模板

为需要做出[一项决定]的[一位观众]制作一段[时长]讲解视频。

使用这些提供的资产作为产品的真实来源：
- [资产名称]证明[声明或工作流程步骤]
- [资产名称]证明[声明或工作流程步骤]
- [徽标或品牌资产] 可以裁剪/调整大小，但不能重新绘制

保持这个措辞的字面意思：
- [产品名称]
- [数量、规格、价格、型号或认可短语]

在这些场景中构建解释：
1. [观众情况和明显的摩擦]
2. [提供正确视觉效果的产品机制]
3. [第二种机制或比较]
4. [可观察的证据或改变的状态]
5. [下一步具体行动]

视觉系统：
- [构图、排版、动作、色彩、灯光]
- 生成的视觉效果可能支持[允许的装饰作用]
- 请勿发明或重新绘制产品屏幕、徽标、标签、指标或事实

音频：
- [声音、节奏、音乐、声音规则]

发货前审核：
- 每项声明均与其经批准的来源相符
- 每条旁白都与正确的产品视觉相匹配
- 文字内容保持不变
- 不添加不支持的结果、价格或规格

该模板是有意模块化的。如果界面中已经控制了持续时间和宽高比，请将它们保留在那里，不要仅仅为了使提示更长而重复它们。

06

案例：技术讲解员需要的不仅仅是风格

公开的 TapVid 案例 Vera CPU 技术讲解员运动图形动画展示了为什么技术主题受益于场景结构和受控视觉系统。它的简短是8,486字符，但长度不是教训。有用的部分是，制作方向协调了多场景的技术解释，而不是要求一个电影剪辑。

打开公开的TapVid案例或打开生成的视频。

该案例是生产结构的示例，并非对其内部显示的任何技术声明的独立验证。产品事实仍然需要其自己认可的来源。

07

哪些内容要简短，哪些内容要明确

该基准测试不支持提示越长越好的规则。它支持更好的细节分配。

当结构化字段已经控制了宽高比、运行时间或语音时，请保持散文简短。当错误会改变产品标识、事实含义或视觉对应时，请明确详细信息。把相机形容词放在最后。首先放置源资源、锁定措辞、场景目的和审查测试。

如果您已经有产品屏幕截图和批准的脚本，TapVid 可以将这些材料转变为可审查的解释器工作流程。从产品演示视频工作流程开始，或在构建制作简介之前使用解释视频脚本指南。

08

常见问题