批量跑多语言版本时出现“一部分成功、一部分失败”，先不要急着改参数或者重跑全量。批量结果里同时混着素材差异和配置差异，日志层面往往分不清哪一类；把语言、音色、输出命名这三项在一条片子上先固化跑通，再放量，定位成本会低很多。单条验证的意义是把变量压到最少：一条片子、一组参数、一次可以完整核对的输出。

建议先挑一条有代表性的片子（时长偏长、覆盖目标语种、字幕完整带时间轴），把语言码、音色、输出命名跑通，确认产物文件存在、时长接近源片、音轨可播放之后再分批放量。批量失败多数来自三项配置不一致或命名互相覆盖，不是模型能力不足。单条未验证前不建议全量提交；分批提交并把重跑写到独立目录，是避免覆盖已成功结果的关键。

选一条有代表性的片子做单条验证

代表性片子不能随便挑，它的作用是在一次验证里尽量多暴露边界情况。挑选时看三点：

• 时长：选批次里偏长的一条。短片刻看不出长句断句、分段拼接、音轨时长是否对齐这些问题。
• 语种：优先选目标语种里字符集最复杂的那条，例如中英混排、带数字和专有名词的片子，不要用纯英文样片去验证小语种链路。
• 字幕质量：字幕要带时间轴、断句正常、没有明显错字。字幕本身是输入的一部分，字幕脏会让后面的失败都归因不清。

这条片子需要覆盖的参数，按“一次只动一项”排开：语言/地区码、音色标识、语速等韵律项、输出容器与编码、输出命名模板、字幕是烧录还是外挂。轮数不必太多，通常跑两到三轮，每轮只改一个变量就够判断。

验证过程建议落一张表，字段至少包含：sample_id、源片时长、字幕文件、目标语言码、音色标识、输出文件名、输出文件时长、音轨是否可播放、结论。这张表后续会成为批量任务的基线，出问题时可以直接对照，不用凭记忆回想当时是怎么配的。

确认语言、音色、输出命名三项配置

批量失败最集中的就是这三项，而且大多是配置写错或者产物互相覆盖，不是任务跑不起来。下面是一个通用配置骨架，字段名以实际配置文件或界面为准，不要照抄：

{
  "source": "samples/ep01.mp4",
  "subtitle": "samples/ep01.srt",
  "target_lang": "zh-CN",       // 语言码，注意是短码还是带地区码
  "voice": "voice_id_or_name",  // 音色，注意是 ID 还是名称
  "output_dir": "out/batch_01",
  "output_name": "{source_stem}_{target_lang}_{voice}"
}

语言码要确认写法是 zh-CN 这种带地区的，还是 zh 这类短码，两种写法在部分实现里落到不同资源。音色要确认该音色是否支持目标语言，部分“失败”实际上是音色不支持该语种，返回空内容或回落到默认音色，而日志里并不报错。

输出命名是最容易出问题的一项。模板里如果没有语言、音色这些维度，同一源片的多语言版本会写到同一个路径，后跑的覆盖先跑的，最终看起来只有一条成功。建议命名至少带上源文件名主干、语言码、音色标识，不同批次再写到不同输出目录，从结构上避免重名。

改配置后的验证顺序建议是：先只改语言跑一条，确认输出语种正确；再叠加音色跑一条，确认音色生效且时长没变；最后改命名模板，确认目录里生成的文件名唯一、没有同名覆盖。三项都过了再进批量，不要在一次提交里同时改两项以上。

设计分批策略与失败重跑方式

一次全量提交的风险是失败之后不知道从第几条开始崩，日志也可能被后续任务冲刷。第一批建议只放少量条目，比如三到五条，覆盖不同语种和不同源片，跑完先看输出目录、命名、时长是否符合单条验证时建立的预期，再逐步扩大。分批的粒度按“一批只引入一个变量”来切：同语言不同片子一批，同片子不同语言另一批。

失败条目重跑要用一份显式清单驱动，而不是重跑整批。下面的命令只是骨架，工具名和参数以实际环境为准：

# failed.txt 每行：源文件 语言 音色
echo "samples/ep01.mp4 zh-CN voice_a" >> failed.txt
echo "samples/ep03.mp4 ja-JP voice_b" >> failed.txt

while read -r src lang voice; do
  baocut run `--input` "$src" `--lang` "$lang" `--voice` "$voice" \
             `--out` "out/rerun_$(date +%Y%m%d_%H%M)"
done < failed.txt

关键只有两点：重跑写到新的输出目录或者给文件名加 rerun 后缀，以及重跑前先把失败清单从批量日志里筛出来固化成文件。这样重跑和已成功的产物是物理隔开的，不存在二次写入覆盖。重跑时不要顺手调大并发，先单条确认失败原因——是字幕解析失败、音色不支持，还是超时——再放开数量。

检查批量结果里的成功与失败标记

任务跑完不等于成功。判断依据要落到可核验的产物上：输出文件存在且大小不为 0；输出时长与源片时长接近，差得太多说明只生成了片段；音轨能正常解码播放；文本或字幕产物非空且语种正确。只读工具返回的状态码，覆盖不到这些情况。

静默失败最典型的表现是：任务状态显示完成，目录里也确实有文件，但文件是 0 字节、只有容器头、或者时长只有几秒；也有工具回落到源语言输出，文件名却仍然是目标语言。这类问题必须靠产物检查才能发现。

# 逐条检查产物：大小、时长、音轨
for f in out/batch_01/*.mp4; do
  size=$(stat -c%s "$f")
  dur=$(ffprobe -v error -show_entries format=duration \
        -of default=nw=1:nk=1 "$f")
  audio=$(ffprobe -v error -select_streams a \
        -show_entries stream=index -of csv=p=0 "$f")
  echo "$f size=$size dur=$dur audio=[$audio]"
done

检查结果汇总成一张失败表：源文件、语言、音色、失败现象、是否已重跑，作为下一批的输入。如果批量结果里全部标记成功、却找不到任何失败标记，同时产物检查又不通过，优先怀疑标记规则只覆盖了任务状态，没有覆盖产物这一层。

归档结果并保留可复现的参数记录

归档目录建议按批次和语言分层，把产物和参数放在同一层，下次复用时不用再猜当时用了什么配置：

archive/
  batch01/
    params.json      # 本次批量完整参数快照
    manifest.csv     # 源文件 -> 语言 -> 音色 -> 输出文件 -> 状态
    failed.txt       # 失败清单，供独立重跑
    zh-CN/
    ja-JP/

参数快照里需要保存的内容包括：配置文件全文或等价的环境变量、工具版本信息、输入清单（源文件路径与对应字幕）、输出命名模板、批量时的并发数和超时设置。manifest.csv 每条保留状态和失败原因，后续补跑只针对状态为失败的行，避免整批重来。

复用上一次配置放量之前，有几项需要重新确认：目标语言码是否仍然可用、所用音色是否仍然可用、输出目录里是否有历史产物可能造成覆盖、输入素材的时长和字幕是否与上次一致。这四项确认完再提交，通常比凭印象全新重跑更省时间，也更容易把新出现的问题和旧配置区分开。