排错说明片有多个可能原因怎么讲？LibTV用验证镜头区分假设

排错说明片有多个可能原因时，先展示同一个症状，再让每个候选原因通过不同验证得到支持或排除。不要把三个猜测依次说成答案。视频要教会观众怎样区分，而不是看完记住一串“可能是网络、格式或权限”。

制作的是解释成片，不是单段报错录屏

真实界面与测试过程由外部录屏工具采集。LibTV官网已公开剧本创作、画布和视频生成方向，可承担原因解释的脚本、镜头规划与明确标注的情景画面；没有证据表明它本身能录屏或验证故障。生成的报错、按钮与修复结果不能作为事实素材。

本文用虚构的文件无法预览说明方法，不替任何真实软件确定原因。先由产品负责人核实已知条件：什么格式被支持、哪些权限可用、哪些状态需要联系支持。验证顺序与处理方法必须来自当前真实资料。

每个假设给一个能区分的观察

若怀疑格式不受支持，就查实际文件类型与当前支持范围；若怀疑权限，就确认当前角色对同类资料的访问条件。不能把“换一个文件成功了”直接当作原文件格式错误，因为内容、大小和位置也一起变了。一次只改变必要条件，并保留其他变化记录。

1. 症状：以真实画面说明不能预览具体表现，不只给一个抽象红叉。
2. 候选：每次只介绍一个待检验解释，使用“先检查”而不是“原因就是”。
3. 验证：展示真实检查依据，说明结果支持什么、还不能排除什么。
4. 下一步：确认条件后进入对应处理；证据不足就转支持渠道，不继续编结论。

情景镜头帮助理解，不替代检查

可以用整理文件、寻找不同钥匙之类的情景比喻解释分类与访问的区别，作为LibTV视频创作的素材方向。但要回到真实界面指出对应条件，不能让比喻暗示所有权限都像一把钥匙那么简单。示意上写清用途，实际结果仍来自真实操作。

在画布上把症状、假设、验证和去向排成一条分镜链，若出现没有观察依据就跳向处理的箭头，先补证据。完成点不是每个原因都有漂亮场景，而是观众知道该观察什么才能进入下一步。

最终交付排错分镜图、事实素材清单与示意镜头清单。请不了解脚本的人指出哪些原因已确认、哪些只是候选。如果他把所有旁白都听成确定诊断，就调整措辞与镜头层级；若真实检查本身有分歧，先请负责人核对，别交给生成模型裁定。

这与教程里已知错误的恢复分支不同：恢复分支已经知道问题是什么；此处要先教会怎样判别。两类内容可以衔接，但不要让观众在尚未确认原因时直接套用修复动作。

可以先在脚本里保留四个镜头占位：“真实症状—原因解释场景—真实验证—结果去向”。LibTV参与的是解释场景与讲述组织，外部录屏负责事实依据。若手里只有一段需要发给客服的报错，直接提交复现资料即可；要把多个原因讲成可反复观看的用户说明片，才进入本文的创作流程。