可复现测试契约：让角色类AI语音挑选可被审查

问题不在生成，而在审查

一个语音挑选器可以列出几十个候选，却依然让制作团队说不清为什么某一条被采用。“感觉对了”不是一条有用的事件日志——它无法告诉下一位编辑：是哪个脚本、哪种场景角色、哪版混音、还是哪个时间点促成了这次决策。

对角色类语音而言，界面应当保留被测试的那个问题本身。候选声音只是其中一个变量，测试夹具（fixture）、视觉节拍、输出状态与发布边界同样重要。

据原始分析，这类产品问题的本质是审查问题：当场景任务与验收条件没有显式写出，挑选过程就无法复现。

先定义夹具，再生成音频

不要用整段脚本当测试材料，而应使用一小组固定台词：

1. 一条确立说话者身份的状态行；
2. 一条包含关键名词或数字的信息行；
3. 一条紧跟可见事件的反应行；
4. 一条带有明确结果的宣告行。

例如，面向高地位动画角色时，Stewie Griffin AI Voice 这类候选可以被分配到状态夹具上。这一分配是一种测试输入，而不是对模型内部行为或官方表现的断言。验收问题是可观察的：这句台词是否在剪辑点之前就传达了它的角色功能？

对比候选时，夹具必须保持不变。如果脚本和声音同时变动，审查就无法识别差异的成因。

type SceneRole = "status" | "information" | "reaction" | "announcement";

type VoiceFixture = {
  id: string;
  role: SceneRole;
  script: string;
  mustRemainAudible?: string;
  visualBeatMs?: number;
};

type ReviewState =
  | { kind: "draft"; fixture: VoiceFixture }
  | { kind: "preview"; fixture: VoiceFixture; candidateId: string }
  | { kind: "accepted"; fixture: VoiceFixture; candidateId: string; note: string }
  | { kind: "blocked"; fixture: VoiceFixture; reason: string };

上述类型是一份可审查界面的设计提案，并非对 VideoAI 内部实现的断言。

测试夹具（fixture）这一术语借自软件测试工程，指的是为验证某项功能而预先固定好的输入数据集与运行环境。在软件测试中，夹具的核心价值在于可复现性：只要夹具不变，任何人重复执行都能得到可比较的结果。将其引入语音挑选场景，意味着把「整段脚本」拆解为一组受控的最小台词样本，并固定视觉节拍、混音状态与输出边界。这样一来，候选声音成为唯一受控变量，审查者才能判断差异究竟来自声音本身，还是来自脚本或上下文的变化。缺乏夹具概念时，团队往往在比较中同时改动多个变量，导致结论无法沉淀为可传承的经验。

把表达方向与内容清晰度拆开

第二个夹具应当刻意普通，比如一句“The next round starts at seven.”。先不加音乐测试，再加入粗混测试。如果“seven”被吞掉，换一个更戏剧化的候选并不是自动正确的修复——更该做的是缩短句子、把关键词前移，或先降低竞争声部。

面向生物型角色的 Stitch AI Voice 候选在反应夹具中可能有用，因为产品问题不同：回应是发生在视觉节拍之后，还是抢在观众看到笑点之前就把笑话解释完了？同一句脚本应当在平静、惊讶、被打断三种上下文中试听。把导演方向存为元数据，而不是为每个候选重写台词。

把游戏式提示建模为事件交接

游戏播报的能量往往由一串事件组成，而非一整个长段落。对阵标签、倒计时和结果提示各有不同的时间要求。

面向这一工作流，Super Smash Bros AI Voice 候选可以挂接在一条短宣告夹具上。验收契约可能是：

• 对阵信息在动画变化之前就能听懂；
• 结果提示在视觉揭示之后才开始；
• 末尾名词不被音效遮蔽；
• 台词可以重播而不改变场景含义。

stateDiagram-v2
    [*] --> Draft
    Draft --> Preview: fixed fixture + candidate
    Preview --> Review: audio and rough cut available
    Review --> Accepted: required beat is audible
    Review --> Blocked: missing word, early reaction, or unclear role
    Blocked --> Draft: revise one variable
    Accepted --> PublishedCheck: rights and destination review
    PublishedCheck --> [*]

这张状态图把创意评估与授权/发布决策分开。一次预览可以通过时间检查，却仍需要单独的权限、素材来源与平台政策审查。

**事件交接（event handoff）**指的是把一段连续的语音表演拆解为多个带有时序约束的离散事件节点，每个节点负责向下一环节传递明确的信息。这一模型常见于游戏引擎的音频中间件（如 Wwise、FMOD），播报语音并非作为一整段音频播放，而是由游戏状态机触发一个个独立的语音事件。在本方法中，对阵标签、倒计时、结果提示各自是一个事件，拥有独立的进入条件（如「动画变化之前」「视觉揭示之后」）和退出条件（如「不遮蔽末尾名词」）。审查因此从「听起来对不对」转变为「每个事件是否在正确的时序窗口内完成了它的信息传递任务」，使验收标准变得可测量、可自动化比对。

让对比可重复

每一次审查记录都应包含：

• 夹具 ID 与脚本版本；
• 候选 ID 与导演方向备注；
• 是否启用了音乐与音效；
• 被审查的视觉时间码；
• 一条观察到的失败，或采用理由。

避免用会掩盖失败的分数。“8/10”远不如“地名在转场下丢失了”来得可操作。结构化备注让编剧、剪辑与音频负责人可以各自修改不同层次，而无需猜测上一位审查者的意思。

**结构化备注（structured note）**指的是用预定义的字段与分类词汇记录审查结论，而非自由文本。其价值在于让不同角色的协作者（编剧、剪辑、音频负责人）能够基于同一份记录各自定位问题层次，避免因主观描述产生歧义。例如「地名在转场下丢失」直接指向混音与时序两个可操作维度，而「8/10」则无法被任何岗位直接执行。结构化备注通常与失败分类学配套使用：分类由团队事先商定并保持稳定，备注内容则记录本次审查中观察到的具体现象。随着审查次数增加，这些记录会自然形成一份可检索的决策日志，成为团队知识资产的一部分。

用失败分类学替代星级评分

大多数预览失败可归入少数几类：

• 内容丢失：姓名、数字或动作听不清；
• 角色错位：场景需要反应，台词听上去却像宣告；
• 时间冲突：语音早于视觉节拍进入，或在转场下结束；
• 混音冲突：音乐或音效遮蔽了必需词语；
• 交接模糊：审查者说不清两条 take 之间改了什么。

这套分类让下一步动作更加确定。内容丢失意味着改写或缩短句子；时间冲突意味着移动剪辑点或加入停顿；混音冲突意味着调整声床；交接模糊意味着改进审查记录。更换候选应当是靠后的实验选项，而不是对所有失败的默认反应。

对于多角色或名单式界面，请补上稳定的候选 ID 与人类可读的方向备注。不要仅用显示标签作为唯一标识——标签可能被编辑、本地化，或在新的夹具中复用。审查记录应当回答：选了哪个候选、渲染了哪版脚本、改变了哪一个变量。

证据边界

这是一套接口层的测试方法。它不衡量语音质量、延迟、授权或生产可靠性，也不揭示私有架构——这些主张需要各自的证据。真正有用的工程结果更窄：当场景任务与验收条件被显式写出时，语音挑选器会更容易被审查。