那天后台自动出片又停在字幕前面。不是视频文件坏了，也不是画中画没有生成，而是流程到了内容审校这一步，发现当前环境拿不到可选的 AI 审校密钥，于是直接退出。对一条依赖后台任务运行的链路来说，这种停止很容易被误解成“审校服务不可用，所以整条任务都不能继续”。
我一开始也把注意力放在了怎么补上密钥，或者怎么找另一个接口。但重新看完整条链路后，我发现真正的问题不是某个服务暂时不可用，而是流程把“增强质量的步骤”误当成了“核心产物的前置条件”。只要这层关系不改，后台环境换一台机器、换一个运行环境，还是会在同一个地方停住。
先分清什么必须完成
这条自动流程的核心目标，是把录制内容处理成可以交付的成片：音频对齐、画中画、字幕和最终文件都要有。AI 审校做的是另一层增强，它会删掉口癖和重复片段，修正某些表达，保护专有名词，还会拦截前后矛盾。它确实有价值，但它并不等于字幕本身，更不等于视频文件。
这件事表面上是一个密钥缺失问题，实际上是一次依赖关系检查。一个步骤是否必须等待，不应该只看它听起来有多智能，而要看它不执行时，核心结果还能不能以较低质量完成。如果没有审校，仍然可以用本地转写结果生成字幕，只是字幕不会带上那一层 AI 判断，音视频也不会自动剪掉口癖和重复段。这个差异需要被承认，但它不必把整条链路判成失败。
增强步骤不可用时，核心产物仍能安全生成，才应该进入明确的降级分支。
我选择把 AI 审校定义为可降级步骤，是因为这更符合任务的真实结构。出片和审校是两个不同的目标：前者解决“有没有成片”，后者改善“成片是否更干净”。把后者的失败传导给前者，会让一个可接受的半成品变成一个完全没有结果的任务。
失败停在哪里，决定了流程是否可靠
原来的表现很直接：审校服务拿不到密钥，就抛出错误，后台任务结束。对手动运行来说，操作者可以看到错误并补环境；对后台自动运行来说，问题更麻烦。它可能只留下一个失败状态，下一次仍然重复失败，而真正需要的音频、字幕和画中画都没有产出。
如果不处理，后果不只是“这次少了一份字幕”。后面的报告、通知和状态文件会把它看成普通失败，使用者无法判断是输入损坏、转写失败，还是某个可选增强服务缺席。下游也不能决定是否先交付当前版本、稍后再补审校。错误边界模糊，才是自动流程最难排查的部分。
这里最容易误判的是，既然 AI 审校负责清理字幕，那没有它就应该停止。这个判断把“质量变差”和“无法交付”混在了一起。质量下降当然要留下记录，但质量下降并不自动意味着流程没有完成。一个成熟的系统，应该把这两种状态分开表达。
降级不是静默绕过
我没有让流程在缺密钥时假装审校成功。具体做法是：审校步骤返回一份明确标记为未审校的结果，后续继续读取本地转写服务的结果生成字幕。这样，流程在结构上仍然有完整的审校结果文件，只是其中写明这次没有经过 AI 审校，也没有要删除的片段。
这带来一个重要边界：字幕仍然可能经过本地规则清理，例如去掉部分口癖、重复词，保护专有名词并做常见纠错；但音频和视频不会因为这次降级而自动剪掉口癖和重复段。两者不能被写成同一件事。字幕文本被整理过，不代表时间轴上的内容也被剪过。
降级的关键不是把失败消息藏起来，而是让结果带着真实的能力边界继续向后流动。
因此，成片报告、后台通知和状态文件都要出现“未经 AI 审校”的说明。机器可读的状态还要能区分审校是否执行，给人看的通知则要让人一眼看出这不是普通的完整结果。只有这样，使用者才知道这份成片可以先看、先交付，但不能把它误认为已经完成了智能剪辑。
我更愿意把这种标记看成结果的一部分，而不是额外的日志。结果文件只告诉你“生成了什么”，降级说明还告诉你“没有生成什么”。后者决定了下一步能不能放心使用，也决定了以后补跑审校时应该从哪里接上。
不要为了兜底而假装有能力
当本地转写服务不可用时，另一个诱人的想法是马上接入外部转写接口。看起来只要多写一个分支，流程就能拥有完整兜底。但检查后发现，现有的外部服务接入只有 dry-run 计划，没有真实调用能力，也没有可以直接验证的现成凭据。
错误捷径就是把这个“计划”包装成“备用服务已经可用”。这样做也许能让日志看起来更完整，却会把未发生的网络调用写成事实。一旦本地转写也失败，流程不是诚实地报出转写失败，而是先经历一轮不可验证的假兜底，最后留下更难解释的状态。
我选择不接这个兜底，是因为只有真实可用的替代能力才配进入自动流程。没有现成授权、没有实际调用、没有可核对结果，就不能把它当成故障恢复路径。于是当前边界很清楚：缺少 AI 审校密钥时可以继续；本地转写服务真正不可用时，仍然失败，并明确说明失败发生在转写环节。
这件事让我重新意识到，诚实的失败比虚构的成功更容易维护。降级解决的是可选增强服务缺席的问题，不是把所有依赖都强行变成“总能跑”。流程越自动，越需要把不能做的事情说清楚。
用无密钥样本验证整条链路
只测一个函数返回“未审校”还不够。真正需要确认的是，降级状态能不能穿过后续步骤，最后出现在成片、报告、通知和状态文件里。因此我用一个不带密钥的离线样本跑了完整流程，检查音频对齐、字幕生成、画中画和最终状态，而不是只看单元测试数量。
这次完整链路通过，成片保留了圆形画中画，视频有音轨，字幕也生成了。报告和通知都带有未经过 AI 审校的说明，状态没有被写成“完整审校”。字幕中还保留了本地规则没有处理掉的句首语气词，这反而说明降级边界确实生效了：系统没有偷偷声称完成了更高层的清理。
验证降级流程时，既要确认它能继续，也要确认它没有越权宣称自己完成了更多。
这两项检查缺一不可。只验证“文件存在”，可能漏掉状态标记错误；只验证“标记存在”，又可能漏掉成片没有声音、画中画消失或字幕没有生成。对自动流程来说，成功不是某个函数返回正常，而是从输入到交付的关键链路都能保持一致的叙述。
方法可以复用到所有可选服务
这次形成的方法并不只适用于 AI 审校。面对任何外部服务，我会先把流程拆成核心产物和增强步骤，再问 3 个问题：服务缺席时，核心产物能否以较低质量生成；降级后的差异是什么；这个差异能否进入机器状态和用户通知？如果第 1 个问题答案是能，就设计显式降级；如果不能，就保留失败，不用模糊话术掩盖。
然后给每条分支写清楚输入、输出和边界。正常路径保持原行为，降级路径复用已有的可信结果，不引入没有真实能力的替代接口；报告要记录状态，通知要说明影响，测试要覆盖完整链路。最后用无增强服务的样本跑一次，观察结果是否与声明一致。
这个流程的价值，不在于让系统永远成功，而在于让每一种成功和失败都可解释。一个流程成熟的标志，不是它能跑通一次，而是它能在下次少依赖临场记忆。看到“未经 AI 审校”，人就知道可以先使用什么、不能假设什么，也知道应该从哪一步补做。
下次我会怎么做
下次设计后台自动任务时，我会在写第一条异常处理之前，先列出核心产物和可选增强。凡是只改善质量、不决定产物是否存在的步骤，都不直接作为硬依赖。缺少凭据时，流程继续走可信的本地路径，同时把降级原因写进报告、通知和状态文件。
我也会把“真实可用”当成兜底资格，而不是把接口名称当成能力证明。备用服务必须有实际调用、可核对结果和现成授权；否则就保留明确失败边界。测试则至少包含 1 次无增强服务的完整离线运行，检查文件、状态和人类可读说明是否互相一致。
这次最重要的收获，是重新定义了自动流程里的“成功”。成功不等于每个增强步骤都执行了，而是核心产物按承诺生成，缺失的能力被准确标注，后续的人不用猜这份结果到底经过了什么。真正可靠的自动化，不是永远不降级，而是降级时仍然诚实、可用、可追踪。