PRODUCT CASE REPORT · 01
音色工作台
产品案例介绍
BACKGROUND
为什么要做音色工作台
1.1 业务背景
在直播口播、角色化内容和创意音频生产中，一个可用的声音并不只是把文字念出来。它需要同时满足音色身份、情绪表达、节奏、真实感、脚本完整性和交付效率。实际工作中，我需要频繁完成两类“手搓”任务：
音色克隆
给定参考音频和生成脚本，得到尽量保留原说话人身份与质感的新音频。
音色设计
给定人物形象或声音描述和生成脚本，创造符合设定的新音色并输出音频。
市面上的模型各有优势，但它们的输入格式、音频限制、参数、标签语法、失败方式和输出结构高度不一致。直接逐个调用模型会带来四类成本：
操作成本
同一批素材需要重复上传、填写和等待。
比较成本
结果散落在不同工具里，难以做公平的横向试听。
知识成本
使用者必须记住每个模型独有的脚本导演方式和输入限制。
交付成本
满意音频缺少统一命名、保存、批量下载和 URL 化流程。
1.2 产品目标
“音色生产控制台”
我希望搭建一个“音色生产控制台”，用统一界面编排多个模型，把一次音色任务从输入到交付串成闭环。
- 让非技术用户不用理解模型 schema，也能调用多个音色模型。
- 让同一份素材能并行经过多个模型，快速比较效果和成本。
- 把模型专属的提示词、导演指令和硬性约束沉淀为产品规则。
- 让失败可解释、可重试，生成过程可感知，结果可试听、可沉淀、可交付。
MVP
什么能力构成最小可行闭环
WORKFLOW
链路工作流框架图
工作台由两个业务分支和一套共享能力组成：克隆分支负责“保留谁的声音”，设计分支负责“创造什么声音”；脚本导演、任务编排、结果校验和资产沉淀则由两条链路共同使用。
↘ 点击任一节点，查看原报告中的能力、主要机制与输入输出
六类TTS模型的脚本导演策略
Seed Audio 1.0
用完整导演 Prompt 锁定参考音色身份，通过情绪锚点、呼吸、停顿、重音和“必须说到最后一词”的完整性约束改变表演，不改写说话人。
ElevenLabs v3
在不改变台词的前提下插入模型支持的方括号标签，控制情绪、气口、非语言人声和停顿，并由专用 v3 TTS 链路消费。
Inworld Realtime TTS-2
在正文最前放一组英文自然语言导演指令，正文中只少量插入可支持的非语言标记，并结合稳定交付模式控制整体演绎。
MiniMax Speech
基于 speech-2.8-turbo 的原生圆括号拟声标签与 <#0.5#> 停顿语法增强真人感，同时保护脚本文字和长度预算。
OmniVoice
不强行插入未经验证的标签，优先保持原脚本与克隆稳定性，把表达变化交给模型原生能力。
Cartesia Sonic 3.5
以结构化导演参数控制情绪、速度、音量等维度，只在适合的位置使用模型支持的少量非语言能力。
MVP → PRODUCT
从 MVP 到稳定产品：迭代复盘
MVP 上线后，我没有一次性堆叠功能，而是把每次真实运行中的异常、认知变化和新需求记录下来，再判断应该由交互、Prompt、硬规则还是系统架构解决。下面是部分能体现产品化过程的迭代。
| 运行中发现的问题 / 新需求 | 具体解决方式 |
|---|---|
| 同时选多个模型后，结果列表过长 | 结果按模型分组为 Tab，每个 Tab 显示该模型的任务数量和结果；既保留多模型并行，又避免页面无限下拉。 |
| 整批重新生成代价太高 | 把“重生成”粒度缩小到单音频、单模型、单脚本版本；只覆盖用户不满意的当前结果。 |
| 生成耗时较长，静态页面让用户误以为卡死 | 增加运行中动效、模型级状态和“还有结果正在路上”的提示，并把任务持久化到本地后台。 |
| 用户为参考音频填写 reference text 很繁琐 | 只在真正需要的模型链路自动走 ASR，并允许查看与修正（omnivoice）。 |
| 批量任务既有共用脚本，也有逐条脚本 | 设计“单段复用 / 逐条对应”分段控制；逐条模式使用稳定素材 ID 映射，避免文件重排后错配。 |
| 音色设计 prompt 从零写门槛高、同质化严重 | 接入专用音色 Prompt 生成规则（沿用手搓经验沉淀），由用户提供形象、年龄、声音需求和数量，再调用 GPT 批量生成可编辑、互有差异的 prompts。 |
| 不同模型对标签和导演指令的支持完全不同 | 建立六模型脚本优化知识库，并在 UI 中为每个已选模型生成独立优化区；用户可选原始、优化或两者都生成。 |
| ElevenLabs 克隆与设计对标签响应不一致 | 确认克隆链路需要专用 v3 TTS 消费优化脚本；同时取消尾部静音补足，并显式提供降噪开关。 |
| 多个脚本优化任务并行时结果互相覆盖 | 定位为前端状态竞争而不是模型只能串行；改成按 model key 原子合并结果，使克隆和设计都能安全并行。 |
| 限流、504、网关 HTML 等错误直接暴露给用户 | 建立错误分类和友好提示：区分限流、超时、网络、配置、schema、素材过大和模型无音频；保留诊断信息但不把整段底层 HTML 展示在页面。 |
| 接口“成功”但得到 0 秒音频 | 把音频可解码、文件非空、时长大于 0 作为成功条件；模型返回与业务成功分离，避免假成功进入音色库。 |
| 持续迭代担心破坏可用版本 | 建立可回退检查点和打包版本；每次大改前冻结可用状态，失败时能够一键恢复。 |
向下滚动继续阅读 · 共 12 条迭代
REFLECTION
一些感悟
在这个项目中，Vibe Coding 不是“让 AI 随便写代码”，而是一种由产品判断驱动的高频协作方式：
- 01
先描述用户结果
明确谁在什么场景下，要以什么更顺畅的方式完成任务。
- 02
把需求拆成可验证的小步
先跑通一条真实链路，再扩展批量、多模型、脚本优化和资产管理。
- 03
给 AI 充分上下文
提供报错、截图、模型 schema、成功样例、交互要求和不能改变的业务约束。
- 04
用结果而非代码行数验收
通过浏览器交互、真实音频试听、文件时长和任务恢复验证是否完成。
- 05
持续纠偏
当模型能力判断错误或链路行为与预期不符时，回到证据重新定位，而不是为已有实现找解释。
“我对 Vibe Coding 的理解：它提升的是“从问题到可验证产品”的速度，但方向、边界、优先级、质量标准和最终取舍仍由产品负责人掌握。
产品化思维如何体现在这个项目中
- 从用户任务出发，而不是从模型列表出发：首页先问“你今天要做克隆还是设计”，模型只是完成任务的可选能力。
- 把技术差异转译为产品规则：音频时长、文件大小、标签语法、限流和 profile 都被封装为提示、默认值、预处理与保护机制。
- 把 MVP 做成闭环：我没有停在“能生成”，而是继续做到能比较、能判断、能重试、能保存和能交付。
- 用真实行为修正假设：例如 Inworld 是否需要 ASR、Seed 是否支持标签、MiniMax 哪个版本支持拟声，都通过真实调用和试听结果验证，而不是凭文档猜测。
- 把一次性经验沉淀为系统能力：每次错误修复最终都落到模型规则库、错误映射、输入校验、队列机制或操作文档中。
| 能力 | 项目证据 |
|---|---|
| 问题定义 | 把“调用多个 TTS 模型”重新定义为“批量生产、对比和沉淀音色资产”的完整任务。 |
| MVP 设计 | 明确最小闭环与阶段性不做项，先验证价值再扩展基础设施。 |
| AI 能力理解 | 能区分 Prompt 能力、模型原生能力、硬规则、算子限制和系统可靠性问题。 |
| 交互与信息架构 | 围绕批量、多模型和长耗时任务设计映射、分组、状态反馈与单条操作。 |
| 数据驱动迭代 | 从错误日志、试听结果和真实使用摩擦中持续调整需求和实现。 |
| 工程协作 | 使用 Codex 完成前后端、算子空间编排、文件处理、任务队列、测试和打包交付。 |
| 产品化交付 | 基于Demo能力进行工程侧开发。 |