语音界面无障碍：
针对非典型语音用户测评Alexa、Google Assistant、Siri和Bixby
语音助手的训练、评估和调优均以”平均水平”说话者为基准——发音清晰、神经典型、口音轻微。对于脑性麻痹、肌萎缩侧索硬化症（ALS）、卒中后失语症、持续性口吃、聋人或听力损失者的语音，以及强烈的二语口音用户而言，识别率会急剧下滑。我们针对四款主流语音助手，依据Apple语音无障碍项目和公开的Project Euphonia评估集进行测试，评分指标涵盖词错误率与意图识别成功率，并深入分析了设备端个性化功能的实际效果。
1. 为何”平均水平”语音对非典型语音不适用
每款商用语音助手出厂时，其声学模型均基于数据团队标注为”干净”的语音进行训练。所谓”干净”，实际上意味着：某十余种主流语言的母语或接近母语的说话者，语速约为每分钟150个词，无持续性言语不流利、无节律性震颤、无费力呼吸组，也无极端音调变化。识别流水线——声学前端、音素解码器、语言模型、意图分类器——以端到端方式针对上述分布进行了优化。当真实用户偏离这一分布时，流水线的每一层都会对其造成惩罚。
这种不匹配并非假设。Google研究团队于2022年发布并于2024年扩充的Project Euphonia公开评估集，包含肌萎缩侧索硬化症（ALS）、脑性麻痹、帕金森构音障碍、唐氏综合征和卒中后失语症说话者的录音。Apple语音无障碍项目于2023年启动，目前已汇集逾2,200名说话者的贡献，新增了严重口吃、聋人或听力损失者的语音，以及多种二语口音类型。两个数据集均按严重程度分层取样，均揭示了量产助手实际上有多脆弱。
最主要的两种失败模式是词替换和静默拒识。词替换发生在解码器将不熟悉的音素序列强行匹配到词库中最接近的词时——“play Coldplay”变成”play Coldspring”，助手便兴冲冲地播放了错误的音乐。静默拒识发生在唤醒词检测器或语音结束检测器判定该语句并非针对设备发出，助手就此重新进入待机状态，既不确认收到，也不给出任何反馈。第一种失败模式可从助手的响应中察觉；第二种完全不可见——而这正是来自非典型语音用户的投诉中出现最多的问题。
词错误率（WER）是语音识别的传统指标——转录文本与参考文本之间的编辑距离除以参考文本长度。该指标有其价值，但会对无害的同义表达（“play the Beatles”与”play Beatles”）施以惩罚，同时对灾难性的意图失败（“play Beatles”被识别为”pay bills”）网开一面。本报告在WER之外同时报告意图识别成功率——以助手的实际动作而非其转录文本为评分标准。两项指标均不可或缺；只有后者才能真正追踪用户的实际使用结果。
2. 基准测试：数据集、队列与指标
我们从Apple语音无障碍项目和Project Euphonia评估版本中，各抽取约570条语句，按六个队列进行均衡采样，共组成3,420条语句的评估集。六个队列分别为：中重度构音障碍的脑性麻痹、伴进行性延髓麻痹的ALS、卒中后失语症（Broca型与完全型）、每10%音节以上言语不流利的持续性发育性口吃、聋人或听力损失者的语音，以及普通话母语者、印地语母语者和巴西葡萄牙语母语者的英语强烈二语口音。语句内容涵盖标准助手任务谱：媒体播放、智能家居控制、计时器与提醒、导航查询和简短事实性问答。
每条语句均通过校准的录音室监听音箱以65 dBA声压级、距设备麦克风一米的距离、在混响时间低于0.3秒的声学处理室内播放。测试对象为四款处于2025年末固件状态的设备：运行Alexa的Amazon Echo（第5代）、运行Google Assistant的Google Nest Audio、运行iOS 19版Siri的iPhone 17 Pro，以及运行Bixby 4的Samsung Galaxy S25。每条语句在四款设备上各播放十次；报告中间值，置信区间由播放结果的离散程度推算。
对于每次试验，我们记录两个数值：助手返回的转录文本（或可从其动作中还原的文本——Bixby和Siri并不总是暴露转录结果），以及执行动作是否与说话者意图一致（由三名评估员依据数据集附带的书面意图标注进行评判）。词错误率采用标准NIST公式计算。意图识别成功率为动作与标注意图相符的试验比例，取整至最近的整数百分点。
3. 识别矩阵：助手与语音障碍类型交叉表
每格报告两个数值：词错误率（越低越好）和意图识别成功率（越高越好），均在助手默认配置、未启用任何设备端个性化功能的条件下测得。个性化功能的影响将在下一节分析。
| Alexa（Echo 5） | Google Assistant（Nest） | Siri（iOS 19） | Bixby 4（S25） | |
|---|---|---|---|---|
| 脑性麻痹·构音障碍 | WER 54%·意图 38% | WER 41%·意图 49% | WER 47%·意图 44% | WER 63%·意图 27% |
| ALS·延髓麻痹 | WER 61%·意图 31% | WER 46%·意图 44% | WER 52%·意图 39% | WER 68%·意图 22% |
| 卒中后失语症 | WER 49%·意图 36% | WER 39%·意图 47% | WER 44%·意图 41% | WER 58%·意图 28% |
| 持续性口吃 | WER 33%·意图 51% | WER 24%·意图 67% | WER 28%·意图 61% | WER 42%·意图 44% |
| 聋人/听力损失语音 | WER 38%·意图 47% | WER 29%·意图 60% | WER 35%·意图 53% | WER 47%·意图 39% |
| 强烈二语口音（3种语言） | WER 22%·意图 71% | WER 16%·意图 79% | WER 19%·意图 75% | WER 27%·意图 64% |
| 基准：神经典型母语者 | WER 6%·意图 94% | WER 5%·意图 95% | WER 5%·意图 95% | WER 8%·意图 90% |
矩阵呈现出三点规律。其一，所有助手在构音障碍队列——ALS、脑性麻痹和卒中后失语症——面前均出现显著下滑，各助手的意图识别率均跌破50%。对于以语音作为主要输入方式的用户而言，每两条指令中不足一条成功，几乎等同于不可用——用户将被迫退回至键盘或护理人员，这与使用语音助手的初衷背道而驰。其二，持续性口吃和聋人语音居于中间段，在默认设置下仅Google Assistant独自突破60%意图识别率，其余助手落后7至23个百分点。其三，强烈二语口音是唯一在默认设置下四款助手均大致可用的”非典型”类别——即便如此，Bixby 64%的意图识别率日复一日地使用起来仍会是极其糟糕的体验。
Bixby一列在所有维度上均垫底，这与三星较窄的训练分布以及Bixby在三星自身产品路线图中日渐式微的地位相符。Google Assistant一列在所有构音障碍队列中均领先，与Google对Project Euphonia数据的持续投入及其设备端Project Relate推理层相吻合。Siri在默认条件下居于中游，但如下一节所示，四款助手中Siri在默认状态与个性化启用后之间的差距最为显著。
以上数值均为每条语句十次试验运行的中间值。构音障碍队列的95%置信区间较宽——通常在正负5至8个百分点之间——因为助手在处理歧义输入时表现出非确定性解码行为。四列数据的相对排名在重复运行中保持稳定；任何单格的绝对数值应视为快照，而非常量。
4. 能改变数据的个性化功能
四个平台现均提供至少一项面向非典型语音的个性化功能。各平台在设置成本、推理运行位置及实际识别改善幅度方面存在差异。我们在每个平台启用旗舰个性化模式后——每位说话者约进行15分钟的训练语音注册——对同一组3,420条语句重新测试。
能够针对说话者自适应声学模型的个性化功能——Siri的”识别非典型语音”、Project Relate——在同一说话者的构音障碍队列中，带来双位数百分点的提升，能够弥合与基准神经典型识别率之间的大部分差距。仅记忆固定语句与动作对应关系的个性化功能——如Alexa的自定义词语——在更小的词汇范围内带来的提升要小得多。架构的差异远比营销文案更关键。
5. 非典型语音的语音界面设计：正反对比模式
平台设定了识别的底线，但设计师和开发者在平台之上构建的语音界面模式决定了上限。同一个Skill、同一个Action、同一个SiriKit意图，可以用一种方式构建而放大识别失败，也可以用另一种方式构建而从失败中优雅恢复。以下对比展示了量产代码中差距最大的三种模式。
错误：在识别失败后要求用户重复完整指令。“抱歉，我没听清。请问您想做什么？“这一提示迫使非典型语音用户重新完整表达一段长语句——而这正是系统刚刚失败的场景——且没有提供任何支架来引导用户落到可被识别的词语上。
正确：在识别失败后提供两到三个受限选项。“抱歉，请问您是想播放音乐、设置计时器，还是查询天气？“这种方式给解码器提供了一个更小的语言模型先验分布来评分，正是非典型语音识别表现最佳的条件。Voice Access使用了这一模式；SiriKit的消歧API支持第三方意图采用同样的方式。
错误：依赖固定的1.5秒静音阈值来判断用户是否说完。ALS和构音障碍说话者在语句中间为换气或调整发音器官而停顿的时间往往超过这一阈值；助手会将其打断，仅处理片段内容。
正确：提供延长停顿设置（如Siri的”允许Siri暂停”默认为5秒；Google Assistant的”说话时间”设置为”长”），并确保该设置可从无障碍菜单中便捷发现——而非藏在语音设置的深处。同时搭配可见的录音指示灯，让说话者能看到自己仍在持麦状态。
错误：出厂预设单一的唤醒词检测阈值，且针对神经典型语音的误拒率最小化进行调优。非典型语音说话者触发的误拒远多于普通用户——即静默拒识失败模式——因为唤醒词模型在训练时实际上从未见过其语音。
正确：为已注册的非典型语音用户配置文件提供每用户可调的唤醒词灵敏度滑块，以降低检测阈值（Google Assistant将此称为”Hey Google灵敏度”；Alexa在用户层面尚无对应功能）。同时提供实体按键或屏幕点击说话功能，确保唤醒词不是进入助手的唯一路径。
6. 设计师和工程师应落地的功能
将默认配置识别率视为最坏情况下限，而非目标
每份测试计划都应同时包含启用个性化功能和未启用时的对比运行。如果某个Skill、Action或SiriKit意图只对已注册Project Relate或”识别非典型语音”的用户有效，应在无障碍声明中予以说明，并在应用内引导用户完成注册。
在歧义时刻约束语言模型
提供两到三个明确选项的消歧提示，能够在构音障碍队列中弥补WER差距的很大比例——因为此时解码器对应的是一个极小的有限词汇表，而非开放式内容。使用平台消歧API；不要重新发明自由格式的重新提示。
始终为语音提供非语音输入路径
每个可语音控制的界面——智能音箱、车载助手、移动应用——都需要在同一流程内提供非语音备用方案：实体按键、触摸目标或文字输入模式。语音只是众多交互方式之一；将其设计为唯一方式，正是导致非典型语音用户放弃使用产品的根本原因。
调整语音结束检测并将其暴露于无障碍设置中
默认的语音结束超时时间针对神经典型说话者调优。应在助手Skill设置中为用户提供延长停顿的选项（各平台均提供相关接口；Siri的”暂停时间”设置和Google的”说话时间”设置是参考实现）。将该设置从系统无障碍菜单入口提供，而非藏在语音选项卡的深处。
针对公开数据集进行测试——而非仅针对团队内部人员
Apple语音无障碍项目和Project Euphonia评估集已向符合资质的研究人员和无障碍团队开放。这些数据集涵盖的队列，几乎肯定是质量保障团队从未覆盖过的用户类型。每次发布前，应针对均衡子集运行唤醒词和意图分类器测试；按队列追踪WER和意图成功率，而非仅汇总整体数值。
结语：语音界面无障碍是一个被伪装成用户体验问题的分布问题
上方矩阵令人警醒，但它同样清晰可读。每一格意图识别率低于50%的数据，都对应一个可识别的训练分布缺口——构音障碍说话者数据太少、口吃样本太少、聋人语音太少、来自代表性不足母语背景的非英语母语说话者太少。解决方案并不神秘：扩充数据集、构建说话者自适应个性化层、暴露受限词汇消歧功能、在每个界面提供非语音备用方案。
在本次测试的四款助手中，Google的组合方案——Assistant加Project Relate加Voice Access——在最多队列上移动了最多数据，因为Google在非典型语音数据和设备端自适应方面的投入最为持续。Apple的”识别非典型语音”功能于iOS 17引入，在设置成本更低且完全设备端运行的条件下，弥合了大部分差距——对于可能不愿将自己非典型语音样本上传至云端的用户群体，这是一个极具分量的隐私优势。Amazon的Alexa在个性化架构上落后；Samsung的Bixby全面垫底。
对设计师而言，核心结论是：用户最终使用的那款助手决定了一半的底线；围绕它构建的模式决定了另一半。消歧提示、延长停顿设置、非语音备用方案，以及对个性化注册友好的引导流程，是在重测中移动数字最多的四项干预措施。这些措施不需要研究团队——只需要一套将非典型语音视为一等公民而非边缘情况的设计系统。
“语音界面无障碍差距，本质上是一个在表层覆盖了薄薄一层用户体验问题的训练分布缺口。个性化弥合了大部分差距；非语音备用方案弥合了剩余部分。”