浏览器语音Demo不该只有一个按钮：录音状态机、反馈与兼容性设计

2020-09-17 09:00 • AI 技术, 语音技术 • 阅读 29

语音识别网页常被实现成“点击录音，再点击识别”，但用户实际经历的是一条充满不确定性的链：浏览器是否允许麦克风、设备是否真的采到声音、编码格式能否被服务端读取、上传有没有完成、模型是否仍在排队、空白结果到底意味着什么。若界面只保留一个按钮和一块结果区，这些状态会全部折叠成“没反应”。

设计Demo的目标不是展示按钮能调用接口，而是让第一次访问的人在没有说明书的情况下完成一次有效录音，并在每种失败下知道下一步。最直接的方法是先画状态机，再写页面逻辑。每个状态只允许有限操作，进入和离开都产生可见反馈，异步任务也必须有取消与超时路径。

七个界面状态比一个布尔变量更可靠

权限被拒绝、没有输入设备和设备正被其他应用占用，虽然都导致无法录音，修复方式却不同。页面应保留浏览器返回的错误类别，转换为简明提示。若权限被永久阻止，需要告诉用户到站点设置中恢复；若设备不存在，则提示连接或选择麦克风，而不是反复弹出同一个授权请求。

红点与计时只能证明录制流程启动，不能证明音频有效。可以通过音频分析节点计算短时能量，显示简洁的音量条；若长时间接近静音，在停止前提示检查设备。音量反馈不必保存波形，更不能自动把实时音频发往服务端。它的作用是让用户在本地发现静音、输入选错或距离过远。

避免用夸张跳动的伪波形制造“正在识别”的错觉。界面反馈应对应真实状态：采集、编码、上传和推理不能混成一个动画。

不同浏览器与系统对录音容器和编码支持不同。前端应查询可用的MIME类型，选择服务端明确接受的格式，并把真实类型随文件上传。不能只把扩展名改成WAV就假设内部变成PCM；若服务端统一转码，也要校验容器头、声道、采样率和时长，并为无法解码返回独立错误。

录制停止通常会异步产生数据块。必须等待最终数据到齐后再组装文件，随后释放媒体轨道和音频上下文。若用户取消或离开页面，也要停止硬件采集；否则浏览器的麦克风指示会继续存在，下一次录制还可能占用旧资源。

识别开始后，按钮应变为取消或明确禁用，而不是让用户连续创建请求。为每次操作生成会话内编号，只接受当前请求的回调；用户重录后，较早请求即使晚到也不能覆盖新结果。网络超时后，页面要说明任务是否可能仍在服务端执行，重新提交则携带幂等标识或创建明确的新任务。

首先判断本地音频是否有时长和有效音量；其次确认上传完成且服务端成功解码；然后区分有效静音、语言不匹配和模型未输出标签。对用户不必展示内部堆栈，但可以提供“没有检测到声音”“文件格式无法读取”“服务暂时繁忙”或“未识别出可显示文字”等不同提示。支持人员则可通过请求编号查到阶段日志。

转写文本应允许选择、复制和手动修正，分段结果可显示时间信息，但不要用未经校准的单个置信数字给用户造成确定性错觉。若Demo只用于体验，可以在重录时清除上次音频；若需要保留历史，必须由用户主动选择，并说明保存位置与期限。下载音频也应默认关闭，避免公共设备留下敏感录音。

无障碍方面，所有操作可通过键盘完成，按钮文字随状态变化，动态结果用适度的实时区域播报，计时和错误不能只靠颜色。移动端还要测试来电、锁屏、横竖屏切换和页面后台化；这些事件可能中断音频轨道，恢复后应回到可解释状态，而不是继续显示录制中。

准备没有麦克风、首次拒绝权限、录制纯静音、录制过短、格式不支持、弱网中断、服务超时、连续双击、识别中重录和旧响应晚到等场景。让未参与开发的人完成任务，记录他们在哪一步误解状态。技术测试则核对媒体轨道被释放、同一录音不会重复提交、取消后结果不再写入、敏感数据不进入控制台日志。

一个成熟的语音Demo会把不确定性摊开给用户：当前正在做什么，系统收到了什么，等待何时结束，失败后保留了什么，以及录音将如何处理。完成这些状态与边界后，网页才不只是模型外面的一层薄壳，而是一条可理解、可恢复、可被信任的体验路径。