批量转写最容易让人兴奋的，是速度突然变快。原本1条1条等的音频，换成并发处理以后，任务像被推上了传送带：下载、转写、整理，几条线路同时往前走。可真正让我停下来想的，不是还能不能再加1台机器，而是传送带上那些没有明确答案的结果，应该被放到哪里。
这次处理1批历史人物视频文案时，我开始的目标很直接：既然链接数量不少，就尽量批量并发往下做。很快，转写队列里出现了“待人工确认”的项目，数量曾经有37条。它们没有像正常结果那样顺利通过，也不能简单归类为完全失败。于是问题变成了2个：能不能先跳过这些项目，让其他内容继续；以及，后面发现确实是格式或规则问题时，能不能自动修复并写回？
表面上，这是1个并发能力问题。实际上，我在处理的是结果的不确定性。批量流程真正要加速的，不只是转写动作，还包括对不同可信程度结果的分流。 如果把所有非成功状态都塞进“失败”这一栏，速度看起来会更清楚，后面的判断反而会变得更混乱。
速度问题为什么会变成判断问题
批量任务刚开始时，人很容易把目标写成1句话：尽快全部完成。这个目标听起来没有错，却把“完成”说得太粗。1个结果可能是文字完整、时间轴正常、可以直接进入下一步；也可能已经有大部分内容，只是个别切句需要整理；还可能因为声音、内容或上下文不足，暂时无法判断是否正确。
如果这3种结果都只用“成功”和“失败”表示，流程就会出现2个相反的问题。第1种是保守：1条异常结果让整批任务停住，所有已经可用的内容都要等人工回来看。第2种是冒进：为了让进度条继续，把异常结果也自动写成看似完整的稿子，等到后面才发现原文已经被覆盖，没人知道哪些地方曾经不确定。
这次我看到本地转写和另1台工作机上的显卡转写服务可以同时工作，服务已经常驻，能够开机启动，异常后也会自行重启。1条255秒的音频，远程显卡服务大约14秒完成，速度足以支撑更高的并发。可这并不意味着所有结果都应该自动放行。机器变快以后，错误也可能更快地进入下一环。
所以，增加并发入口解决的是吞吐量，不能替代结果判定。如果不把不确定结果单独留痕，后果不是少处理几条，而是把无法确认的内容伪装成已经确认。 这会让后续人工复核更难，因为人面对的已经不是“这里需要判断”，而是一份表面完整、来源不明的文本。
待人工确认不是失败
我开始也有过1个很自然的想法：既然有37条待人工确认，那就先跳过，别让它们拖住全部流程。这个想法有50%是对的。跳过确实可以让高置信结果继续前进；但“跳过”不能等于删除，也不能等于把状态改成失败后不再关心。
待人工确认至少说明了一件事：当前规则还不足以替这条结果作决定。它可能存在识别错词、切句异常、音频质量不足或上下文不够等问题，也可能只是需要把原文和候选修复稿放在一起比较。没有更多证据时，我不能把它们统统归为同一种错误。
这件事让我重新意识到，流程里的状态不是给机器看的标签，而是给下一次判断留下的线索。状态写成“失败”，下一步通常只会重试或丢弃；状态写成“待确认”，则保留了继续分析的可能。两者的动作可能暂时相同，含义却完全不同。
我会把每条任务至少拆成3层。第一层是高置信结果：转写完成，关键字段齐全，经过基础检查后可以自动进入下一步。第二层是可自动修复结果：问题模式已经足够明确，例如某类格式或切句规则可以稳定处理，但修复后仍需要一次复核。第三层是真正不确定的结果：不能从现有信息判断原文到底是什么，应进入隔离队列，等待人工确认。
这样的分层不是为了增加表格字段，而是为了防止不同风险共用同一个出口。高置信结果追求速度，可修复结果追求规则化，不确定结果追求可追溯。真正成熟的批量处理，不是让每条任务都自动通过，而是让不同程度的确定性走不同的路。
自动修复必须有边界
后来我继续追问：修复能不能自动写回，而不是只报错？这个问题很关键，因为只报错会把所有成本推给人工；但自动写回也并不天然更先进。能不能写回，取决于我们是否知道改动为什么成立。
最容易误判的错误捷径，是把“有异常”直接等同于“可以自动改”。例如，系统发现一段文字不符合某种格式，就把它改成看起来更整齐的版本。结果可能确实更好看，也可能把原本有意义的停顿、专名或语气一并改掉。格式规则能识别表面形状，却未必理解内容。
我的判断是：只有修复规则明确、输入范围稳定、改前改后可以对照时，才允许自动写回。写回也不应该只留下修复后的版本，而要同时保留原始转写、修复原因和修复结果。这样人工复核时，面对的是一条有来路的变化，而不是凭空出现的新文本。
我没有选择“发现问题就全部自动改”，是因为批量处理最怕错误被放大。一条错误手工改坏，影响有限；同一条宽松规则跑过几百条，错误就会变成系统性污染。相反，如果只要看到异常就完全停住，已经确认的结果又会被无谓地拖慢。两边都不是好方案，关键在于把确定性放在规则前面。
让失败也能继续往前走
这次的另一个提醒，是流程不能只记录最终成败，还要记录为什么停在这里。转写服务本身经过验收：常驻、可自启，异常后能重启，远程样本也能在较短时间完成。这说明基础能力已经足够支撑并发，但服务正常不等于每条内容都可直接采用。
因此，每条任务的记录里，我会留下转写状态、可信程度、修复建议、是否已自动修复、是否需要人工确认，以及原文和修复稿的对应关系。人工队列也不能只是一个数字。至少要能回答：它为什么进来、已经尝试过什么、下一步要看什么。
如果某条结果只是暂时排队，它和明确无法识别的结果不能混在一起；如果某条结果已经自动修复，它和原始成功结果也不能混在一起。后续处理者需要知道自己是在继续加工，还是在重新判断。否则，队列虽然没有丢数据，人的认知却已经丢了。
这里还有一个容易被忽略的后果：如果不保留原因，人工复核会变成从头检查。原本只需要看一个可疑片段，最后却要重新听整段音频、重新比对全文。并发带来的时间收益，就这样被不必要的重复劳动抵消了。队列的价值不只是把任务存起来，更是把下一次判断所需的上下文一起存起来。
一套可以复用的分层流程
把这次经历抽象成流程，我会先做一次“确认程度”判定，而不是先问“成功还是失败”。每条任务进入系统后，先保存原始输入和原始转写；然后做基础检查，判断内容是否完整、格式是否可读、是否出现需要额外证据的异常。
接下来分3路处理。高置信结果自动通过，但仍留下检查结果，方便事后追溯。规则明确的异常进入自动修复，修复时不覆盖原文，并在写回后做一次轻量复核。无法确定的结果进入隔离队列，保留原因和待确认项，不阻塞其他任务。
人工确认完成后，再把判断反馈给规则：如果只是稳定的格式问题，可以沉淀为自动修复规则；如果每次都需要结合语境，就不要急着硬编码成自动动作。这样，人工不是批量流程的补锅工，而是帮助系统区分“可以规则化”和“必须判断”的边界。
这套方法还要求一个停止条件：当结果已经足够可靠、风险已经被记录、后续动作有明确归属时，就不要为了追求全部自动化继续扩大规则。自动化的边界越模糊，所谓省下来的时间越可能在返工时加倍付出。
我更愿意把它看成一种工作习惯，而不是一个转写技巧。先保留事实，再表达判断；先让确定的部分继续，再把不确定的部分隔离；能说明为什么改，就自动修复；说不清为什么改，就留下来让人确认。方法并不复杂，但它把速度和谨慎放到了同一条流程里。
下次我会怎么做
下次再遇到大批量转写，我会在启动并发前先定义3种出口：自动通过、修复后复核、人工确认。每个出口都写清进入条件和离开条件，避免任务跑起来以后才临时解释状态。
我会先让已确认的结果继续，不让少量待确认项拖住整批处理；但所有跳过都必须是可恢复的跳过，原文、原因和队列位置都要保留。这样“先跳过”代表调整顺序，而不是放弃结果。
我也会把自动写回限制在可解释的规则内。每次修复保留前后对照，能自动复核的就做复核，不能确定的就不假装确定。对于重复出现的异常，再判断它是否值得沉淀成规则，而不是因为出现次数多就直接放宽门槛。
工具真正改变的不是速度，而是我们能不能把判断过程留下来。对批量转写来说，最快的流程并不是所有结果都瞬间通过，而是确定的结果不被拖住，不确定的结果不被吞掉，人工确认过的经验还能回到下一轮。一个流程成熟的标志，不是它能跑通一次，而是下次面对更大的批量时，仍然知道哪些可以自动做，哪些必须停下来问一句。