先分清音色变了，还是音量和语气变了
正常速度连续听问题接点，再单独听前后原分段。记录具体差别：忽然更响、句尾变快、从平静转成激动，还是像换了另一个说话者。情绪变化不必等于声线错误；同一人本就可以改变语气。
若单段已经不一致，先查合成；若单段听来相近，只有成片变化明显，再查放置速度、处理和最终所用文件。没有原段或实际听审时，先列待查项，不能凭元数据判定“确实换人”。音量问题可另看配音电平排查。
同一个声线名，要对应真实请求和文件
在所引仓库版本中，普通旁白记录实际选择的provider、模型、声线或参考配置；分段缓存核文本、设置与WAV身份。不同路径的配置不能互相冒充：MiMo可用其声线或获授权参考，Fish用其声线ID，自托管IndexTTS用显式配置的voice，不支持本地参考克隆。
IndexTTS的receipt记的是请求了哪个voice，不是服务端确实发出了同一个人的声音。服务端把同名voice换成新模型或新声线实现，客户端不会自动察觉；按原文说明使受影响的tts_segments/*.cache.json失效，才会重新请求。先保留旧候选和记录，不盲删全部音频。
本页说明这个固定版本的流程，不据此承诺供应商当前全部功能或某种声线效果。
原创核对：三段都选A，第二段却来自旧B稿
原创解说方案有三段已定中文旁白，窗口分别为0–4、4–8、8–12秒；时长只是本例安排，实际语音是否放得下另查。三段文本为“她展开名单”“她停在最后一行”“她把纸折了回去”。作者选择服务里已配置的旁白声线A，当前没有音频或试听结果。
| 段落 | 要核的版本 |
|---|---|
| 0–4秒 | 当前A请求及对应候选文件 |
| 4–8秒 | 曾手动导入的旧B候选，不能只改记录中的名字当成A |
| 8–12秒 | 当前A请求及对应候选文件 |
修订顺序：
- 保留定稿、三个窗口和旧B文件，定位第二段的实际来源与请求记录。
- 用选择的A配置重新合成第二段，不仅重命名旧文件；若服务端A实现已变化，重新判断三段各需重生成的范围。
- 实际串听A的前段、新中段与后段，核文字完整和音色接续；不合适的候选继续修，未听就保持待查。
- 选定实际候选文件后交给合成，再核最终成片用了这三个文件并正常速度串听。
若使用仓库的旁白采用记录，它要对应明确传入的tts_meta与选定文本/请求配置。BOUND_TO_ADOPTION表示这些选择进入混音，不表示声学身份或自然度已经通过。纸面顺序没有实际完成任何重合成、绑定或听审。
别用统一音量和强行变速替代声线修订
先保护准确台词、既定声音分工与配音窗口。调音量可能使接点听感更平，却不会把B声线变成A；改变语速也可能造成新的停顿或发音感受，不应默认为修音色的方法。
时间窗不足时，按配音超时排查处理。采用保全文本策略后，放不下要回到稿件、窗口或明确的速度预算，不截掉尾字来伪装一致。若作者本来安排不同角色或不同叙述者，先确认这个区别是否应该保留。
最后检查原段与成片，记录具体观察
| 检查 | 能证明什么 |
|---|---|
| 请求与缓存记录一致 | 减少配置和旧版本差异，不证明声学身份 |
| 实际候选串听 | 这组声音的直接观察，不代表所有未来生成 |
| 合成消费记录 | 哪些文件和策略进入本次成片 |
| 成片正常速度听审 | 放置与混音后的实际接续体验 |
记录“哪一段、哪个接点、怎样变化”，比“声线PASS”更有用。只听过第二段就不宣布全片一致；选定候选后重新导出，也要核新成片，没有旧试听自动覆盖新版本的保证。
常见问题
声线名字一样，就能证明音色一致吗？
不能。它是请求配置；文件版本、服务端实现和实际声音仍需检查。receipt或合成绑定记录也不代替听审。
音量统一后还是像换人，要继续加效果吗？
先回到实际原段、请求声线与采用文件，判断差异来自哪里。不要连续加处理掩盖错误版本；有意的语气变化则按这条内容需要保留。
用 skill 来做
用 $video-voiceover 检查这组已定旁白的声线一致性。附问题段、实际文件、请求provider/voice和缓存记录，保留定稿与时间窗；先指出配置或版本差异及需重生成范围。没有实际听审就不宣布音色一致，不以音量归一化代替声线修订；服务端实现变化另行处理缓存。
查看具体方法： 声线设置、分段缓存与实际请求 · 同名声线的缓存边界与receipt含义 · 成片实际消费的旁白版本