语音 Agent 的数字字段该如何验收

语音助手听懂一句话，不等于能把其中的账号、电话号码或金额正确提交。原文的主张很明确：数字字段能不能交给 AI 自动处理，要靠覆盖整条业务链路的验收测试，不能靠厂商一句「识别准确率很高」。

对接语音 Agent 的开发者，真正需要检查的是：识别结果如何变成业务字段，用户确认了哪个值，工具最后收到的又是不是同一个值。作者给出了一套设计和验收思路，但没有提供已经跑完的实验结果。

95–98% 的准确率，为什么不能用来验收账号

原文引用的语音识别综述声称，领先系统的真实场景准确率达到 95–98%。但该声明没有同时说明数据集、语言、通信信道、标注规则、置信区间，以及统计单位究竟是词、字符、实体还是完整任务。作者因此把它视为未经验证的概括，不能直接拿来设上线门槛。

词错误率（WER）通常按替换、删除和插入的词数，除以参考文本的词数计算。业务字段的完全匹配率问的是另一件事：这串账号是否与预期值完全相同。整段转写只有一个数字错了，平均成绩可能很好，付款对象却已经变了。

原文用一个假设说明这种差别：如果每位数字独立地以 99% 的概率识别正确，8 位数字全部正确的概率是 0.99^8，约为 92.3%。这只是数学示例，真实错误可能相关，99% 也不是任何产品的实测成绩。

验收单位必须与业务动作一致：需要整串标识正确，就测整串是否完全匹配。

还要分别观察确认前的候选值、确认后的提交值，以及用户纠正错误的成本。格式化成功不能掩盖数字丢失，安全停止也不能算作识别成功。

数字采集应该有状态边界，不能听完就调用工具

作者建议先写清四件事：字段是什么、允许哪些转换、错误有什么后果、用什么证据证明用户确认值与下游接收值相同。任何一项没说清，都应该暂缓提交。

电话号码可能需要国家码和分机；账号可能必须保留前导零；金额需要币种和小数解释；日期 04/05 则可能存在月日歧义。它们应有各自的类型和规范化规则，不能共用一个含糊的「number」槽位。

状态至少要分成三份：

• raw 保存识别器原始输出，并记录来源、限制访问。
• candidate 保存应用按确定规则解析出的候选值。
• confirmed 保存用户接受或纠正后的值，并绑定待执行动作。

不要用美化后的文本覆盖 raw，也不要让模型后续改写替换解析器的结果。若无法保留原始录音或转写，应按数据政策留下最小审计记录，包括字段类型、规范化版本、确认事件、载荷摘要、执行结果和删除计划。

原文的 JavaScript 示例用于解析英文固定长度数字串，遇到不支持的表达就要求澄清：

const WORD_TO_DIGIT = Object.freeze({
  zero: '0', oh: '0',
  one: '1', two: '2', three: '3', four: '4', five: '5',
  six: '6', seven: '7', eight: '8', nine: '9',
});

function parseDigitSequence(input, expectedLength) {
  const tokens = String(input).toLowerCase().trim().split(/[\s-]+/).filter(Boolean);
  if (!tokens.length) return { ok: false, reason: 'empty' };

  let digits = '';
  for (const token of tokens) {
    if (/^\d+$/.test(token)) {
      digits += token;
      continue;
    }
    if (Object.hasOwn(WORD_TO_DIGIT, token)) {
      digits += WORD_TO_DIGIT[token];
      continue;
    }
    return { ok: false, reason: 'ambiguous-token', token };
  }

  if (!Number.isInteger(expectedLength) || expectedLength < 1) {
    return { ok: false, reason: 'invalid-schema' };
  }
  if (digits.length !== expectedLength) {
    return { ok: false, reason: 'length-mismatch', actualLength: digits.length };
  }
  return { ok: true, digits };
}

function confirmationMatches(candidate, confirmed) {
  return candidate.ok && confirmed.ok && candidate.digits === confirmed.digits;
}

重点看返回 { ok: true, digits } 的一行：digits 始终是字符串，001234 不会变成 1234。这个解析器不处理 double four、金额、国家码推断或其他语言的数字语法；confirmationMatches 也只比较值相等，不能证明用户身份或操作授权。

正则只能检查形状，校验和只能发现部分错误，API 查询只能证明记录存在。三者都不能证明调用者有权使用这个账号。

确认不是收集一句「是」，而是约束最终提交

2026 年 5 月的一则 Genesys 社区报告提到，电话号码槽位会重新格式化一个 10 位号码，却只要求用户确认末 4 位。发帖者已经用正则限制长度，问题仍然存在：长度正确，加上局部确认，无法证明整串号码正确。这只是单个产品报告，不能据此推断发生频率。

2026 年 10 月的 3CX 讨论则提出相反困扰：转写把数字序列保留为单词，用户希望转换成方便复制的数字形式。字段的标准表示应该先定义清楚，转换是否保留原值也必须验证。

完整读回也不是通用答案。在公共空间读出完整银行或健康标识可能增加泄露；遮蔽部分数字又会限制纠错能力。按键输入和人工接管同样有适用条件。

用户确认必须绑定当前候选值和具体动作；值一旦变化，旧确认立即失效。

用户打断读回开始纠正时，应停止待执行动作，更新候选值并重新确认。工具调用前还要核对实际发出的载荷，避免界面展示新号码、接口却发送旧号码。

作者提出了一个 15 用例验收套件，但明确说它是测试计划，并未实际运行。提供的原文没有列出这 15 条具体用例，不能把它当成现成完整清单。

可采用的指标包括：候选值完全匹配率、提交字段完全匹配率、静默变更次数、安全不提交率、纠错恢复率、纠正负担和隐私政策失败次数。不要先揉成一个总分，否则一次未经确认的提交，可能被大量正常调用冲淡。

测试应分两层：固定合成用例做回归，另用获得同意、贴近真实电话条件的试点检查运行问题。模型或供应商版本、提示词、电话线路、语言区域、解析器、字段规则和确认方式都应冻结；中途改变就另建版本或分组。报告还要保留尝试数、完成数、安全停止数和排除数，确认前挂断应计为未完成。

我的判断

我赞同作者把验收对象扩展到最终业务载荷。对于集成开发，转写文本看起来正确远远不够，错误也可能发生在格式转换、状态更新和工具参数组装阶段。

相比继续优化提示词，确定性解析和明确状态边界更容易定位问题。但它们不会提高识别器本身的听辨能力，也不能替代身份验证。LiveKit 的任务文档支持返回类型化结果的架构思路，不构成数字识别准确率的证据；AssemblyAI 的厂商基准、Speechmatics 的演示，也需要分别审视测试协议和证据范围。

文章的限制同样明确：没有对照数据证明完整读回、遮蔽确认、按键输入或人工接管哪种更优。2017 年的电话标识检索研究和 2022 年的电话实体识别研究，只能支持专项评估的必要性，不能移植为当前产品成绩。对于确认方式的取舍，这仍是一套设计建议。

原文建议高后果字段出现一次静默变更或未确认提交就阻止发布。这适合作为严格门槛，但小样本零失败不能证明风险已经消失。提供的原文末尾也有截断，无法据此补出作者尚未写完的阈值建议。

能拿来做什么

• 在 Node 语音服务中，为电话号码、账号、金额和日期分别定义 schema 与规范化规则，把账号保存为字符串，并在模型提示词之外执行校验。
• 在采集接口中区分 raw、candidate、confirmed，让确认事件绑定候选值摘要和待执行动作；提交前重新验证实际工具参数。
• 给回归测试加入前导零、读回中途纠正、旧工具响应迟到、确认后值变化等场景，直接断言最终载荷和是否发生副作用。
• 上线前先写出通过条件与人工接管阈值，再分别报告正确提交、安全停止、未完成和纠错负担，避免只展示成功演示。