那天先传回来的不是一段失败日志，而是一条让人很容易兴奋的成功消息：真实口播素材已经在手机上完成导入、处理、导出，又被拉回本地检查。画面是竖屏 9:16，视频和音频轨道都在，首帧上的标题文字清楚，成片也不是测试用的黑帧。
如果只看结果，这件事似乎已经结束了。自动出片能跑，接下来把识别字幕、背景音乐和更多输入范围加上去，好像只是继续填功能。但我在复核时停了一下，因为“出过一条片”与“这条链路已经可靠”之间，隔着很多不能省略的判断。
一次成功，为什么还不能直接扩功能
这次验收其实覆盖了不少环节：先做环境预检，再把真实素材推到设备，打开素材选择，加入文字，发起导出，最后把手机上的文件拉回并检查媒体信息。每一段都有回执，媒体探针也确认了时长、分辨率、编码和轨道。它证明的不是某个按钮能亮，而是从输入到产物的最小闭环能够走通。
可是在这条成功记录里，还藏着一个容易被忽略的条件。正门对素材数量写死了下限，要求一次至少有 2 段，最多 12 段；而原本准备验证的真实素材只有 1 段。按原样提交，它会在校验阶段直接失败，连素材都还没有碰到。这个失败说明的是输入契约不匹配，不是手机无法处理真实视频。
为了保持代码不动，验证时把同一段真实素材列了 2 次。这样满足了入口的数量要求，也让整条链路继续跑下去，但最终成片其实是同一段画面拼接了 2 遍。它仍然足以证明导入、字幕加入、导出和拉回检查都能工作，却不能被包装成“单段素材已经被支持”。
一次成功只能证明给定条件下的链路成立，不能自动证明所有边界都已经成立。
这件事让我重新意识到，自动化最危险的时刻不一定是报错时，反而可能是刚刚成功时。成功会让人自然地把输入条件、环境条件和功能条件一起忽略。如果不把它们拆开，后面一旦失败，就很难知道究竟是素材不对、正门拒绝了输入，还是新增能力破坏了原来的路径。
表面上是加功能，实际上是分离变量
当时最直接的冲动，是把下一步都做了：放宽到 1 段素材，加入自动识别字幕，再接背景音乐，顺便补测试。看起来这些需求互相有关，都是“让自动出片更完整”。但它们实际上改变的是不同层面。
放宽数量下限，改变的是输入契约；自动识别字幕，改变的是语音到文字再到时间轴的处理链；背景音乐，改变的是音频混合和导出结果；补测试，则改变的是未来判断问题的方式。把它们一次提交，最后得到的即使是失败，也只会得到一团模糊的失败。
最容易误判的地方，是把“功能都在同一条流水线上”理解成“功能可以同时验证”。流水线越长，变量越多，越需要控制每次只改变一件事。我选择先保留已经跑通的最小闭环，是因为它能作为稳定参照：后面每接入一个能力，都可以和这条基线比较，而不是重新猜一遍问题从哪里开始。
这并不是拒绝扩展，而是给扩展安排顺序。先证明真实素材能够进来、完成处理并回来，再单独验证单段输入；单段输入稳定后，再处理识别字幕；字幕链路可核对后，最后接入背景音乐。每一步都要能回答一个小问题，不能只等一条“最终成片成功”。
先把成功拆成可核对的阶段
这次实际留下的证据给了我一个很实用的结构。第一层是预检，确认设备和运行环境处于可以执行的状态。第二层是素材推送，检查文件确实到达设备，并用摘要确认传输前后没有变化。第三层是素材选择，核对选中的数量和时长是否符合预期。第四层是编辑动作，确认加入的文字确实出现在结果中。第五层是导出，确认手机端真的生成了文件。第六层是拉回校验，用媒体信息和抽帧检查产物，而不是只看界面提示。
这里的重点不是阶段越多越专业，而是每一段都对应一个可能出错的边界。推送成功，不代表选择器选对了文件；选择器显示添加成功，不代表导出的文件含有预期画面；导出按钮返回成功，也不代表文件有音频轨道。只有把这些断点留下来，失败才有机会被定位。
我更愿意把回执看成给未来的自己留的路标。它不只是记录“做过”，还应该记录“看到什么”。比如这次可以确认真实画面而不是测试帧，可以确认竖屏分辨率和音视频双轨，可以确认字幕文字实际出现。这样的证据比一句“跑通了”更有用，因为下一次修改后可以逐项比较。
如果不处理这些阶段差异，后果会很具体：一旦自动字幕加入后成片没有声音，团队可能先怀疑识别模型；其实问题也可能发生在素材没有完整推送，或者导出时音频轨道被丢弃。没有分阶段回执，就只能靠重新跑一遍来碰运气。
硬限制要单独复现，不能用绕路掩盖
正门要求至少 2 段素材，是这次最值得留下的边界。验证时重复列入同一段素材，是为了在不改代码的前提下完成端到端检查，这个选择有明确用途，也有明确局限。它证明了现有链路可以处理真实视频，却没有解决单段输入的产品问题。
所以，我不会把这种绕路当成正式修复。绕路可以帮助判断后续环节是否工作，不能替代对入口契约的处理。单段输入是否应该放宽到 1 段，要先单独复现原始失败，再修改约束，再用真正只有 1 段的素材重新跑完整链路。只有这样，才知道修复的是下限问题，而不是恰好避开了它。
这件事表面上是在检查一个数量字段，其实是在检查系统有没有把“限制”说清楚。一个限制如果是产品设计，就应该让使用者知道；如果只是早期实现留下的临时门槛，就应该有独立的修改和回归证据。把两者混在一起，用户会把技术方便误解成产品能力。
字幕和音乐，必须各自拥有验收标准
后面想加入的自动字幕，不能用现有的标题文字冒充。当前验证里的文字只是添加了一张标题文本，它能证明编辑动作与画面显示，却不能证明系统听懂了口播、生成了逐句内容并把文字放到了对应时间点。两者都叫“字幕”，但验收对象完全不同。
识别字幕至少要分别看 3 件事：文字内容是否来自真实语音，时间点是否跟画面中的说话对应，导出后字幕是否仍然存在。任何一项不成立，都不能只因为画面上有字就判定成功。背景音乐也是一样，字段存在不等于能力存在。当前它只是一个暂未实现的字段，不能把“以后支持”写成这次已经接入。
我会给每个新增能力设一个最小可证实结果。字幕先用一段短而清晰的真实口播，核对识别文本和时间轴；音乐先使用一份可控的本地音频，核对混音后人声仍然可听、音频轨道仍然存在，再考虑更多曲目和更复杂的选择。这样做的理由很简单：先证明能力真的进入产物，再讨论体验是否丰富。
新功能的完成标准不是界面上出现了入口，而是它留下了能在最终媒体中被复核的结果。
这也解释了为什么我不会在同一轮里同时放宽输入、替换字幕链路、接入音乐并追求一次性出片。那样即便成功，也不知道是哪一项真正起作用；如果失败，则连回退顺序都不清楚。自动化不是把动作压缩到最少，而是让每个判断都能被重做。
下次我会怎么做
下次遇到类似的手机自动出片任务，我会先准备 1 份真实素材，先跑最小闭环，并记录预检、传输、选择、编辑、导出和拉回校验的结果。验收时不只看页面提示，还会看最终文件的画面、时长、分辨率和音视频轨道。这样得到的是一条基线，而不是一句口头上的“成功”。
接着，我会把硬限制单独拿出来复现。单段素材被拒，就记录失败发生在入口校验，而不是把同一文件重复使用后假装问题消失。若决定放宽下限，就只改这一项，再用真实的单段输入回归。输入边界稳定后，再按单一变量接入识别字幕和背景音乐，每一步都保留可以对照的回执和媒体证据。
最后，我会把“已验证”“待验证”和“尚未实现”分开写。当前真实素材端到端导出已经被验证，单段输入的正式支持仍需单独处理，自动识别字幕与背景音乐则不能从已有标题文字和字段推断出来。一个流程成熟的标志，不是它能跑通一次，而是下次修改时仍然知道哪一条证据可以作为基线。
这次经验让我更愿意把自动出片看成一种工作习惯，而不只是一个工具技巧：先让真实东西完整走一遍，再把边界拆开；先让失败有位置，再让功能变多。速度当然重要，但真正能节省时间的，是不让下一次排查重新从“到底哪里出了问题”开始。