刚录完一段视频时，我遇到过一个很容易被误解的问题：录屏和摄像头素材都在，自动成片也确实跑完了，但最后导出的画面只有屏幕，没有预期中的圆形摄像头画中画。乍看像是合成失败，继续查才发现，素材本身并没有丢，缺的是编辑器平时会自动生成的一份工程文件。
这类问题最容易把人带向两个极端。一个极端是认为“没有工程就不能导出”，把原本能够完成的自动流程直接判定为失败；另一个极端是为了让流程跑通，直接在录像旁边凭空写一份默认工程。前者浪费了已有素材，后者则可能碰到更隐蔽的风险：用户之后打开编辑器生成了自己的工程，自动流程却把那份未来要继续编辑的内容覆盖掉。
这次真正要补的不是一份文件，而是缺失工程时的最小状态。
画面缺失，根因却不在画面
当时的自动成片流程会监听新的录制会话。录制结束后，目录里已经有会话记录和摄像头视频，但录像旁边还没有工程文件。工程文件不是录制的必要产物，只有用户在编辑器里打开过这段录像，编辑器才会把布局、遮罩、尺寸和位置等编辑信息保存下来。
因此，自动流程按照原有路径寻找工程时，找不到就只能走没有画中画的导出路径。这个结果并不说明摄像头视频不可用，也不说明编码链路坏了。它只说明原有流程把“素材存在”和“工程存在”当成了同一个前提。
如果不处理这个分叉，后果不只是少一个小窗口。自动录制的价值就在于停止录制后可以继续完成出片；一旦每次都要先手动打开编辑器，自动化就会退化成半自动。更麻烦的是，用户可能看到成片没有摄像头，误以为录制失败，再去重复录制，真正的问题却始终没有被定位。
这件事让我重新意识到，自动化流程的边界通常藏在“平时不会缺的东西”里。工程文件平时总能由编辑器补出来，所以原流程没有暴露问题；一旦出片发生在编辑器介入之前，这个隐含前提就变成了故障源。
先定义一个足够小的默认工程
我没有先去改整个导出流程，而是先问：在缺少用户编辑意图时，什么信息是可以安全默认的？答案不能是“把所有可能的编辑选项都猜一遍”，而应该是一组最小、稳定、可解释的状态。
这组默认状态包含画中画布局、圆形摄像头遮罩，以及应用本来就使用的默认尺寸和位置。它的目标不是模拟用户打开编辑器后的全部行为，而是让已有的屏幕视频和摄像头视频先组成一个合理的成片。尺寸和位置沿用现成工程的默认值，意味着结果有明确参照，不需要在自动流程里另造一套坐标规则。
这里最容易误判的是“默认值越完整越安全”。其实，默认工程承担的只是恢复缺失状态。把编辑器运行时才计算出来的缩放范围、用户偏好的位置、后续可能调整的参数也一起猜进去，反而会让自动成片看起来像是在替用户做决定。
没有用户工程时，默认值只应恢复最低限度的可用结果，不应假装知道用户尚未表达的编辑意图。
旁路生成，避免碰未来的编辑空间
确定默认状态后，下一步不是把它写回录像目录，而是给它安排一个旁路位置。自动流程在临时目录里拼出最小工程，调用已有的无界面导出路径，等成片完成后清理这份临时状态。用户原来的录像目录只作为素材来源，不作为默认工程的落点。
我选择这样做，是因为“今天没有工程”不等于“以后也不需要工程”。用户可能过一会儿打开编辑器，调整摄像头大小和位置，再回来继续修改。如果默认文件已经写进录像旁边，编辑器可能把它当成用户工程；更糟的是，后续流程可能分不清这份文件是系统补的，还是用户亲自编辑过的。旁路方案把这两种意图分开了：自动成片可以先完成，用户工程仍然保留自己的生命周期。
不处理这个边界，会导致一次看似成功的自动导出，变成对后续编辑的隐性覆盖。成片本身可能没问题，问题却被推迟到用户下一次打开项目时才暴露。那时再追溯是默认值、编辑器还是自动任务造成的，成本会比一开始多得多。
错误捷径是把默认工程直接放在录像旁边，因为这样最省代码，也最容易让原有导出入口“看见”它。我没有这么做，是因为省掉的只是临时目录处理，换来的却是用户数据边界不清。自动补全应该是可丢弃的旁路状态，而不是伪装成用户资产的正式文件。
已有工程时，保持原来的选择
旁路默认工程只在两个条件同时满足时启用：有屏幕录像和摄像头素材，但旁边没有工程文件。只要已经存在用户工程，就继续走原有路径，不强行套用默认画中画，也不把默认值写回已有工程。
这个判断看起来保守，却是必要的。用户工程里可能没有画中画，可能用了不同的遮罩，也可能只是暂时保存了一种中间状态。自动流程没有足够证据判断这些选择是有意还是未完成，所以不应该擅自替换。自动化的职责是补齐确定缺口，不是把“我认为更好”的画面覆盖上去。
这里还有一个现实限制：默认旁路工程可以恢复画中画，但不能自动知道用户后来想要的尺寸和位置。那些只有打开编辑器、结合具体画面才能确认的参数，应当留给用户工程路径处理。这不是功能不完整，而是对未知意图的明确止步。
用像素证据验收遮罩
画中画能否导出，不应该只看文件存在或播放器能否打开。圆形遮罩尤其容易出现“看起来差不多”的假成功：摄像头画面可能确实叠上去了，但圆形外的方形角落仍然残留，或者遮罩位置偏移，导致成片不符合预期。
这次验收采用了一个很小但有区分度的对照。先导出带摄像头的成片，再用同一屏幕底图生成无摄像头版本。在摄像头所在矩形区域取四个角和圆心，比较两份画面的像素。四个角与屏幕底图的像素差为 0，圆心则出现摄像头画面，与底图存在明显差异。四角回到底图、圆心保留摄像头，才说明圆形遮罩在正确的位置生效。
验证遮罩不能只看“有画中画”，还要证明遮罩外的像素没有被摄像头覆盖。
这个方法的好处是把视觉判断变成了几何和像素判断。它不依赖某个播放器的缩放方式，也不需要凭肉眼判断边缘是否干净。对于自动成片来说，这种小范围的对照足以覆盖最关键的失败模式：摄像头没有叠加、位置错了、遮罩没有生效，或者矩形角落仍然露出来。
除了这次离线成片的抽样检查，完整测试也通过了 26 个用例。测试覆盖默认工程的内容、触发条件、旁路文件不落到录像目录，以及一段小视频的完整流程。测试的意义不只是证明这次样例能跑通，还把“已有工程不覆盖”和“没有工程才补默认值”固定成了以后不能轻易破坏的行为。
把补全流程变成可复用规则
回头看，这个问题可以整理成一条不依赖具体软件的流程。先区分素材、用户工程和运行时临时状态；再在缺失用户工程时定义最小默认状态；随后把默认状态写入旁路临时目录，复用已有导出链路；导出结束后清理临时文件；最后用底图对照和关键采样点验收几何效果。
这条规则同样适用于其他自动化场景：系统发现输入素材齐全，但描述素材关系的配置尚未生成时，不必立刻失败，也不必把猜测写成用户配置。可以先建立一个足够小、可丢弃、可验证的运行时状态。关键是让它和用户未来会编辑的正式状态分离。
表面上我是在补一份工程，其实我是在处理自动化和用户意图之间的边界。真正难的不是拼出画中画，而是判断哪些信息可以由系统默认，哪些信息必须等用户表达。一个流程成熟的标志，不是它能在理想输入下跑通一次，而是输入缺一部分时，它仍然知道该补什么、不能碰什么、最后怎样证明补对了。
下次我会怎么做
下次遇到“素材在、工程不在”的自动成片问题，我会先把缺失项拆成 3 类：能从已有工程稳定复用的默认状态、只有用户才能决定的编辑意图，以及必须在结果上验证的画面证据。先处理第 1 类，明确绕开第 2 类，再用第 3 类验收，不让一个临时修复同时承担所有责任。
我也会把旁路和清理写进设计的第一版，而不是等导出成功后再补。临时状态如果没有明确的生命周期，很容易在一次次“先跑起来”里变成新的正式资产。已有工程则始终优先，默认工程只在缺失且确有素材时触发。
最后，我会保留像素级的最小对照。四角等于屏幕底图、圆心不同于底图，是比“播放器里看着像”更可靠的验收语言。真正可复用的不是某个默认画面，而是一套既能恢复缺口、又不占用用户未来选择的工作边界。