Scribe v3 Live：先让用户说完，再确认预约

ElevenLabs 在 11 月 10 日发布了 Scribe v3 和 Scribe v3 Live。实时版增加了结合对话语境判断说话轮次的能力：系统不只听有没有静音，还会估计对方是否已经说完。这项更新进入了今天的 AI 早报，但并非 11 月 13 日首发。官方公告提供了功能说明与厂商评测，我们没有复现其中的结果。

如果你正在做预约接待助手，这次更新的产品价值比“语音识别更准”具体得多。用户可能一边翻日历一边说话，说到一半改日期，也可能先问身旁的人有没有空。助手过早接话，既会打断思路，也可能把错误时间带进预约记录。

我们的判断是：值得测试轮次预测能否改善完整的预约过程，但写入日历前仍要有明确确认。说完一句话，与授权创建预约，是两件事。下面会用一个具体场景、一张可复用的对话测试表和有限范围的上线条件，帮助小团队做决定。这是建议的评估方法，不是我们已经拨打电话所得的测试报告，也不是基于亲测效果的产品推荐。

1. 先写清用户遇到的问题，再考虑换模型

假设一家虚构的自行车维修店“港湾车行”想用语音助手接收维修需求，并提供可预约时段。来电者说：“周四三点能过来吗……不对，还是周五，接完孩子以后。”中间的停顿很重要，因为需求还没有形成。如果助手此时开始介绍周四的空档，用户只能先打断它，再把话题拉回来。

这里至少可能有三类问题：识别系统听错了词；词没有听错，却过早判断用户已经说完；或者助手理解了周五，但预约系统早已接收了周四那份草稿。只换语音识别模型，不会自动解决所有环节。

评估替代方案之前，先写一个具体目标：用户能够说出、修改自己的时间偏好，不会失去对对话的控制。再把目标变成可观察结果：实际保存的预约与用户明确确认的内容一致；如果没有创建预约，通话结束时应准确说明这一点。声音悦耳当然有帮助，但不能替代这个结果。

本文的车行只是贯穿全文的示意场景，没有真实企业、客户录音、营收提升或使用成效的暗示。它的作用是让不研究语音模型榜单的创始人，也能从头到尾检查一项任务是否完成。

2. 把语音、说话轮次和操作授权分开

自动语音识别（ASR）负责把声音变成文字。语音活动检测（VAD）识别说话与静音区间。轮次预测估计说话者是否结束了这一轮表达。转写片段提交，指系统把一段识别文本定下来。预约确认，则表示用户接受一组具体预约信息。这些术语对应不同环节。

片段提交策略文档说明，默认仍是手动提交。Scribe v3 Live 的轮次预测需要显式开启，不能因为模型名称换了，就认定应用已经使用该能力。文档也说明，预测模式仍保留按静音提交的路径。因此，“结合上下文”并不意味着停顿永远不会结束一个片段。

请搭建工具提供方或实施人员演示：哪些事件会让对话进入下一步？已提交的转写可以用来准备回答，但它本身不应授权修改日历。预测到用户说完，也不能证明用户已经选中一个有效时段、接受取消规则或同意最终日期。

可以用普通话解释每一步：“我听到了一个需求”“我查到了可用选项”“你确认了这个选项”“日历已经保存成功”。如果演示从第一步直接跳到最后一步，就要求展示中间的决策。这种验收不要求你规定技术框架，也不要求自己编写接口。

3. 在正确层级理解准确率

公告展示了转写与说话人标注方面的改进，但这些结论属于厂商的测试条件。我们不把某个错误率降幅直接换算成预约失败率会下降多少。真正的产品还包含对话逻辑、空档查询、日历写入和故障恢复，转写评测并未衡量这一整条流程。

词错误率衡量相对于参考转写的替换、漏词和多词。语义错误评分则试图区分哪些错误改变了意思。但仅看其中任意一项，都不能知道“下周五”是否对应正确日期、用户是否能纠正理解，以及应用有没有重复创建预约。

FLEURS 原始论文介绍了覆盖 102 种语言的多语言语音数据集。它有助于理解语言评测的背景，却不证明每一种电话口音、车间噪声或双语对话都经过验证。某种语言出现在支持列表上，应该成为测试目标用户的起点，而不是各语言体验相同的证据。

即使转写完全正确，意思也可能不明确。“周五下午”可能只是偏好，不是同意某个具体时刻。产品仍需要追问。反过来，一段转写有小错误，用户也可能通过核对详情得到正确预约。因此，既要看文字识别，也要看任务结果，并分别保留它们的统计分母。

4. 给纠正信息留出明确的位置

对港湾车行来说，一套合理流程可以分为五个用户可感知阶段：收集需求、澄清不明确的信息、提供当前可用时段、复述选中的预约、确认保存结果。这是产品阶段，并不要求拆成五项独立服务。用户应该能从助手说的话判断当前处于哪一步。

设想这样的对话：用户先说周四，停顿后改成周五下午。助手等对方说完，必要时问清是哪一个周五，再提供具体空档。保存之前说：“可以为你预约 11 月 20 日星期五下午三点的自行车检查。现在确认预约吗？”这句话包含项目、完整日期和时间；真实应用还要按需说明当地时区与门店。

如果用户回答：“好，不过要换另一家分店。”这句话里有纠正。系统应返回门店选择环节，不能只抓住开头的“好”就保存旧方案。换门店后，空档也可能不同。更新方案以后，再完整复述并重新征求确认。

W3C 关于重要提交错误预防的说明在适用范围内讨论了确认、检查或撤销机制。本文借此解释核对与纠正的设计理由，不声称这个对话示例能证明无障碍合规，也不据此判断每一种预约的法律义务。对不方便使用语音流程的人，应提供可实际使用的替代方式。

5. 专门测试流畅演示容易藏住的瞬间

准备好的演示通常只有一个表达熟练的人、一句简短需求，没有中途修改。你的评估应该有意加入用户还在思考的时刻。让参与者真的查看日历，而不是照读完整台词；让他们自己在两天之间做选择、更换服务，或者用自己的话解释限制。

停顿也要放在不同位置：电话号码中间、纠正之前、完整需求之后，以及等待最终确认的时候。这几种情形不应一律采用相同反应。在号码中间多等一会儿可能有帮助，但用户已经明确回答后仍然等待，就会让服务显得迟钝。

语音转写能力文档区分了实时识别、多语言功能与转写控制。它证明的是有哪些公开选项，不是你的部署表现如何。应分别测试实际支持的配置。公告里的功能名称，不代表搭建工具已经开放它、当前套餐可以使用它，或所有功能组合都能共同运行。

参与者应接近真实目标用户，任务说明应保持中立。GOV.UK 主持式可用性测试指南建议采用可信的目标，避免在指令里透露答案。例如，“安排一次接完孩子后能去的维修”比“说周五，停顿，再纠正成周四”更合适。预设边界台词适合回归检查，但不能替代观察真实表达。

6. 复用这张预约对话测试表

每套配置使用一张表，每次任务尝试保留一条记录。测试前填入确切的模型、搭建工具版本、片段提交策略、音频路径、语言设置、日历环境和日期。不知道的项目就标记未知。留下配置记录，比默认“最新能力已经启用”更有用。

这是建议的工作表，不是经过验证的 benchmark。另加会话编号、预期结果、实际结果、打断发生时间、响应时间、纠正次数、是否获得帮助和最终保存状态。早期测试使用虚构联系方式；收集录音前，先决定哪些录音确有必要。表格应能揭示产品问题，而不是顺手变成不必要的私人对话资料库。

每项观察都要有负责人和后续动作。抢话可能需要调整对话行为；虚假成功则要检查日历写入路径。如果统称为“模型失败”，下一轮就难以决定改什么。保留原始观察，再附上诊断，后来的审阅者才能在不同意诊断时仍看到依据。

7. 把等待时间与恢复成本放在一起看

响应延迟更短，是否有价值要看上下文。计时应从用户真正结束相关表达，到助手开始给出有用回应。同时单独记录抢答。否则，打断用户的系统可能因为起算点错误而显得特别快。

离线复核时，如果条件允许，可让审阅者先标记用户本来在哪里说完，再查看模型的反应。有些轮次边界本身模糊，应保留“无法确定”的标记，不必强行给出精确答案。实时测试还要记录用户是否感觉被打断，但这种感受不能替代可观察的说话与操作顺序。

用可比较的任务、设备与环境对照旧配置和候选配置。尽量轮换顺序，因为参与者第二次熟悉任务后，可能主动缩短回答。录音回放可以帮助隔离识别与时序差异，但不能重现交互：真实用户听到助手后会改变后续说法。回放与实时会话应分别回答不同问题。

批量测试之前，先把一条计时记录写具体。拟议的 HC-01 可以包含测试会话、配置版本、用户请求、审核人标注的轮次结束点、首个可听见的回答、修正后的方案、用户确认，以及日历最终结果。时间和结果在实际观察前全部留空。保留许可允许时，把录音、相关转写片段和测试预约链接放在一起。这是在设计记录，不表示港湾车行或 Scribe 已经通过测试。

沿着这些边界定位等待发生在哪里。识别可能很快结束，日历查询却耗时较长；回复及时，也可能报错日期。不同设备的时间戳，只有在时钟和事件含义能够对应时才能相减。无法对齐时，应报告观察及其不确定性，不要编造精确延迟。即使缺少统一时钟，观察者仍可以判断助手是否抢在用户纠正前说话，或在预约真正存在前宣称成功。

重新开始对话的负担也要保留。用户被打断后重复日期，即使最终预约正确，也应计一次纠错。员工事后查清保存状态，应标记为人工协助，并把恢复所花时间与自动回复延迟分开。配置改变后，先用相同的预约可用状态复测受影响案例，再邀请新用户。否则，较空的日历或更清楚的可选时段，可能被误算成轮次预测带来的改善。

报告延迟分布、打断情况和恢复工作，而不是只给一个平均值。少数特别慢的电话可能影响小店运营，而一次错误预约可能比典型延迟略有改善更重要。小范围试点可以发现失败模式，却不足以证明普遍优越性，也无法准确估计所有罕见事件的概率。

8. 说话人标签与保存结果都要诚实

说话人分离用于标注哪些词来自哪位说话者，不是身份验证。“说话人一”这样的标签，无法证明对方是账户持有人、预约本人或有权批准修改的人。不要因为多人对话演示看起来漂亮，就悄悄扩大应用的操作权限。

实时 API 参考说明，说话人信息可能更新，最终分离结果会在已提交文字之后另行返回。如果产品在最终信息到达前就行动，这一点就很重要。应询问实施人员：后来的标签与早先假设不一致时怎么办？不能默认一个片段提交后，所有属性都已经定案。

回到车行场景，用户仍在选择时，身旁的人可能先说了“好”。助手可以请预约的当事人再次确认完整详情。涉及敏感账户变更时，产品需要自己的适当授权过程。转写文字是这个过程的输入，不是替代品。

发出日历请求后，应等预约系统确认保存状态，才报告成功。连接断开时，要说明结果尚未确认，并在重试前查清状态。具体实现取决于集成方式，但验收问题很简单：团队能否演示重试不会产生第二条预约？如果不能，就不要让这条路径无人值守地上线。

9. 判断产品到底需不需要语音

如果已有观察显示，抢话或迟迟不回应确实妨碍用户完成任务，轮次预测最值得研究。如果大多数失败来自没有空档、服务分类不清，或日历连接不稳定，应先处理这些问题。语音升级仍可能有用，但证据应指出它改善了体验中的哪一部分。

不方便打字、需要帮助选择服务的用户，可能更适合语音。希望直观看日期、修改地址或保留文字记录的人，可能更适合简短网页表单。运营能力允许时，提供清楚的跨渠道入口。员工无法兑现的替代服务，就不要放进承诺里。

本文面向普通预约接待与有限范围试点，不证明系统能用于紧急响应、临床分诊、金融指令或其他高影响任务。这些用途有自己的领域要求，一次轮次测试无法解决。同样，一个单语言车行试点，也不能成为全国上线多语言接待助手的依据。

选择最小但有价值的范围：一家门店、明确的服务列表、已知营业时间，以及团队可以检查的预约环境。取舍是，起初能了解的市场较少，但更容易诊断问题，也能准确描述服务承诺。理解失败模式后再扩展，不必把初期范围小当成需要掩饰的事。

10. 根据完成的任务决定是否扩大上线

试点前，定义任务从哪里开始、到哪里结束。对港湾车行，成功可以定义为：服务、日期、门店和联系方式符合用户意图，用户明确确认，并且日历已接受。通话礼貌结束而没有这个结果，不等于预约成功。正确处理用户拒绝是另一种有效结果，也未必应该算预约失败。

GOV.UK 完成率指南强调明确交易边界，并区分获得帮助后的完成。沿用这个统计思路，分别报告发起预约尝试、成功预约、拒绝、放弃和人工协助结果。不要因为某段转写不好评分，就把困难电话移出分母。确需排除时，写明资格规则与原因。

比较结果出来前，按试点范围设定发布条件。可作为阻断项的观察包括：没有明确确认就创建预约、保存时忽略用户纠正、没有预约记录却宣称成功。这些是建议的产品门槛，并非我们在 Scribe 上观察到的缺陷。等待与打断的容忍度，应根据真实受众和经营需求决定，不要套用没有解释的通用阈值。

保留可以切回的旧配置，指定故障审阅负责人，并写清什么时候暂停试点。计算每次成功预约成本时，要计入员工恢复时间和失败电话；如果没有任何预约成功，这个比值无法定义，不是零。把模型费用、电话线路、集成与人工处理分开，避免表面节省掩盖更多支持工作。

现在最值得做的，是用工作表开展有限对照，逐次检查实际保存的预约，再判断观察到的改善是否值得扩大试点。Scribe v3 Live 提供了一种有文档支持的对话轮次判断方式。产品能否赢得信任，取决于用户能否说完、改正，并清楚知道最后究竟预约了什么。

参考资料

• ElevenLabs：Scribe v3 与 v3 Live 发布公告
• ElevenLabs：转写片段提交策略
• ElevenLabs：语音转写能力
• ElevenLabs：实时 API 参考
• FLEURS 原始论文
• W3C：重要提交的错误预防
• GOV.UK：主持式可用性测试
• GOV.UK：衡量完成率