语音转写会漏掉口语测评所需信息

用浏览器做一个 60 秒英语口语测试，看起来只要拿到转写文本，就能计算每分钟词数、填充词和长停顿。作者做完才发现，这三项都会被识别结果误导：语气词被删掉，停顿没有时间戳，Android 还可能重复返回已经识别的句子。

这篇最有用的地方，是把这些偏差和补救代码摆了出来。它也划清了一条边界：浏览器转写可以支撑日常自测，但文本里没有保留下来的信息，不能靠计数重新找回来。

转写越干净，填充词统计可能越失真

语音识别追求可读文本，通常会清理掉「um」「uh」。紧张的学习者即使频繁犹豫，转写结果也可能显得流畅。

作者没有找到从页面端保留这些声音的办法，只能统计转写中幸存的表达。词表包含 um、umm、uh、uhh、er、erm、hmm、ah，以及 basically、actually、literally、matlab、you know、i mean、kind of、sort of、like。其中 matlab 在印地语里相当于「I mean」，作者因此把它加入面向印度英语使用者的词表。

但「like」不能逢词就算。「I like Python」表达喜好，「It was, like, a huge refactor」里的 like 才是填充词。下面这段代码通过前一个词排除部分正常用法：

var LIKE_OK = /^(i|you|we|they|would|i'd|feel|feels|look|looks|sound|sounds|just|really|don't|didn't|also|not|is|was|it's|that's|seems)$/;

if (w[i] === "like") { if (i > 0 && LIKE_OK.test(w[i - 1])) continue; }

要看的是第二行的 continue：前词命中白名单，就跳过这次计数。作者认为这种粗略规则足够用于自测，但没有给出准确率。例如白名单包含 was，仍可能漏掉原文那种填充用法；缺少上下文的规则无法彻底解决歧义。

这里统计的是转写中可见的填充表达，无法完整反映实际说出的犹豫声。

识别事件的时间和内容，都需要先校正

作者使用的 API 没有逐词时间戳，因此无法直接从文本判断停顿。他们在 rec.onresult 中调用 Date.now()，当相邻事件间隔满足 now - last >= 2000，就把间隔记入 gaps。

这是用「结果多久没来」估计「人多久没说话」。作者认为，对卡住四秒找词的学习者已经够用；同时承认 Chrome 的识别依赖 Google 服务器，慢网络会让这个指标混入额外延迟。因此，两秒没有结果不能直接证明两秒没有说话。

另一个偏差来自 Android。按作者观察，开启 continuous = true 后，桌面 Chrome 每个最终结果只发一次，Android Chrome 的新结果却可能包含旧文本。直接拼接会让句子出现两三遍，连每分钟词数都可能翻倍。

这段代码用前缀比较合并累计结果：

if (r.isFinal) {
  var prev = finals[finals.length - 1];
  /* Android Chrome repeats earlier text inside each new final result */
  if (prev && tx.toLowerCase().indexOf(prev.toLowerCase()) === 0) finals[finals.length - 1] = tx;
  else if (tx) finals.push(tx);
}

关键是匹配成功后替换 finals 最后一项。这段逻辑依赖「新结果以旧结果开头」的返回形式，原文没有说明其他重复形式怎么处理。

会话生命周期也要补齐：浏览器可能提前结束所谓的连续识别，作者就在计时尚未结束时通过 onend 重启；调用 stop() 后，最后一个最终结果可能超过一秒才到，他们最多再等 1,800 ms 才评分。

清理完输入，评分反而简单：每分钟少于 70 词算慢，超过 165 词算快，但听众跟得上也可以；填充词频率和长停顿共同影响档位。作者说评分约 40 行，用普通 if 判断实现，不过没有公开完整阈值。

我的判断

我赞同作者把评分规则留在可读代码里。对于学习工具，用户能知道为什么被判为偏慢，比得到一个无法解释的分数更有帮助。

但「整理好转写」并不等于恢复了真实讲话过程。语气词漏识别、事件延迟和 like 的歧义仍然存在。原文给了在线工具的代码，也描述了作者遇到的行为，却没有人工标注对照、网络条件对照或跨浏览器误差数据。「足够自测」应当视为作者的经验判断。

相比直接拼接文本，这些修补很实用；如果要准确分析停顿和犹豫声，就需要另行评估音频层面的检测或更完整的时间信息。原文没有比较这些方案的成本和效果。

能拿来做什么

• 做前端口语练习工具时，把指标标为「识别到的填充词」和「估计长停顿」，让用户理解数字覆盖的范围。
• 联调识别结果时，检查桌面 Chrome 与 Android Chrome 的最终结果是否累计，并覆盖提前结束、停止后延迟返回的情况。
• 用 AI 编程助手生成这类功能时，把去重规则、2,000 ms 间隔和 1,800 ms 等待写进需求，同时要求它说明这些近似判断的局限。
• 保留可解释的评分阈值，并提供降级入口。作者的工具面向 Chrome、Edge、Safari，Firefox 使用键入方式；键入结果不能验证真实的语速和停顿。