语音克隆藏在有声书流水线里，这设计省了80%的麻烦

AudioProducer.ai上线语音克隆功能时，对外最顺口的讲法是：带上你自己的声音， narrate 你自己的书。这话没错，但漏掉了生产端真正有意思的部分。语音克隆是个系统组件，对开发者来说，值得聊的是它跟什么接在一起、什么地方没动、工程坑落在哪。

这是克隆模块在整个有声书流水线里的位置复盘：编辑器里长什么样、嵌在逐章生成流的哪个环节、长任务里堆出来的取舍，以及一条结构性约束——它不是脚注，是硬规则。

最核心的设计决策：克隆语音和库内语音是同一个对象类型。

两者共用用户账户首页的 Voices 页面，同一张列表，同一种选择交互。克隆完成后，就是语音库里的一行，跟132个内置语音一样，有同样的槽位、同样的逐行附件、同样的下拉选择框。

听着像小事。但这是语音克隆"可维护"和"平行系统到处需要特殊处理"的分水岭。

用户跑 Auto-Assign Characters 时，AI 不用管你库里有没有克隆语音。它的活：按说话人给每行打标签，按章节需要的语音数在 Characters 面板里填槽。用户打开面板，给每个槽指派语音，下拉框里库内语音和克隆语音混着排，随便挑。

跑 Auto-Assign Sounds 时，音乐底床和单发音效的位置跟语音选择无关。点 Generate Audio 时，渲染器问每个角色槽要指派好的语音，拿到一个语音描述符——可能解析成库内资产，也可能是克隆资产——然后继续跑，不用分叉判断来源。

"库内"和"克隆"的边界因此极薄，只活在语音解析层，用户可见的流水线里几乎没它的事。

新项目的流水线阶段（之前写 Auto-Assign 时提过）：

1. 源文本进去，粘贴一章或导入 EPUB

2. Auto-Assign Characters，AI 按说话人给每行打标签

3. Auto-Assign Sounds，AI 放音乐、声景、音效

4. Generate Audio，渲染成品文件

克隆语音不改变任何阶段。只改一个指派：第2步之后的 Characters 面板里，用户可以给任何角色选克隆语音（或克隆与库内混着用）。

流水线没感知到变化。第4步的渲染器只认"这个角色用的什么语音描述符"，不关心描述符从哪来。

长任务里堆出来的取舍开始显现。

克隆语音的推理成本比库内语音高。不是倍数关系，是结构差异：库内语音的模型权重热在 GPU 里，克隆语音需要从用户存储拉权重、解压、进显存。对单章短任务，延迟藏在生成时间里看不出来。对整本书的批量生成，这变成流水线调度问题。

我们的解法：克隆语音的权重在首次使用后缓存15分钟。不是永久缓存——用户库可能膨胀，显存不是无限——而是刚好覆盖单本书的连续生成窗口。批量生成时，同一克隆语音的各章复用缓存，不用每章重新加载。

缓存失效的边界情况：用户中途改克隆语音的附件（比如换说话风格标签），权重需要重载。这时候下一章生成会多几十秒延迟，UI 里不特殊提示，但日志里记一笔。

另一个取舍在质量一致性。库内语音经过统一后处理，响度、底噪、频响曲线在一个窄带里。克隆语音来自用户上传的音频，质量方差大。流水线里我们不做实时音频修复——那会把生成时间翻几倍——而是前置在克隆创建流程里：上传后强制跑一轮标准化，通不过的打回重录。

这导致克隆创建比"上传-等待"的体感慢，但保证了进流水线后的克隆语音不会在某章突然爆音或底噪起飞。

最后那条结构性约束：克隆语音的存储归属。

不是技术约束，是合同结构。用户上传的音频、生成的权重文件、派生的合成样本，存于用户账户下，但平台保留在服务质量下降时的迁移权。这意味着我们不能承诺"你的克隆永远跑在 A100 上"，只能承诺"你的克隆可用"。

这条约束渗透到架构：克隆语音的解析层必须抽象到"语音描述符"级别，不能硬绑特定硬件或模型版本。今天跑的是某开源克隆方案，明年可能切自研或第三方，用户侧的 Voices 页面和 Characters 面板不动。

回到开头那个"带自己的声音 narrate 自己的书"的讲法。对用户是真的，对流水线是副产品。真正的工作是把克隆压成跟库内语音一样的形状，让剩下整个系统不用改。