直接回答
语音翻译界面提示没有检测到语音时，应根据证据定位最早失败阶段，而不是先责怪翻译模型。检查用户是否主动开始、权限是否有效、录音器是否启动、音频帧是否到达、缓冲格式是否符合下游接口、分段器是否产出数据，以及识别器是否返回文本。只有存在源转录后才排查翻译阶段。`ANDROID-AUDIO-01` 描述 Android 音频采集 API 和应用责任；`COVE-ASR-02` 描述仓库中 PCM 顺序分段并合并非空结果的实现。这些事实支持分阶段记录，但不能指出任何“常见错误”，也不能证明某台设备的麦克风一定可用。 先记录状态，不要先复制修复清单。记录应用构建、测试设备/系统、权限状态、录音状态、可见的音源选择、输入路由、声明的采样格式和生命周期事件。让用户显式点击开始，并在界面显示录音状态。权限拒绝或撤销后，应干净停止并说明如何重试。不能通过申请无关的广泛存储权限来解决麦克风问题。Android `AudioRecord` API 提供初始化与录音状态、读取结果和错误码；排查应依据该 API 契约和实际观察，不要照搬未经核实的论坛修复。 先检查采集，再检查识别。确认录音会话确实开始；读操作返回了数据，而不是错误或空块；缓冲区被交给预期任务。`ERROR_DEAD_OBJECT` 应作为 API 定义的录音状态，按平台指导重建录音器，而非认定翻译出错。还需检查路由变化和音频焦点打断，但“麦克风权限已允许”不等于“音频帧已到达”。不要记录原始 PCM 或私人语音；合成音或经许可的短样例可以证明采集路径是否有输入。 然后检查分段边界。记录片段标识、格式、可用时的时长元数据、空片段状态，以及是否提交或跳过。覆盖静音、句首截断、短暂停顿和正常句子。如果存在语音活动门控，它可能跳过较轻的语音；不能随意调阈值或在未复现前宣称修复成功。若任务用前台服务采集麦克风，要核实声明的服务类型、权限和生命周期状态；不能说只要增加服务就能保证后台录音有效。 只有确认源转录非空后才检查翻译。先拿识别文本和源样例比较，再独立评估目标译文。转录缺失时将故障标为采集或识别阶段，翻译记作尚未到达；若转录存在但译文空白，则作为输出、解析器或运行时的另一问题。保留取消、空结果、格式错误和失败运行；没有事实卡证据时不要称某错误频繁或常见。 准备受控恢复矩阵：首次安装、允许/拒绝/撤销权限、仅在相关时的有线或蓝牙路由变化、应用后台前后切换、进程重建、录音器初始化失败、空读取、分段器空输出、识别失败及翻译失败。每种状态定义用户界面、清理和重试。恢复后再录一次，确认没有复用过期录音器对象或订阅者。报告应说明哪个阶段已验证、哪个仍未知，并去除私人内容后保留准确日志。 不要承诺改采样率、选择某芯片、重装应用或加权限能解决所有无声问题。结果取决于实现和环境。有效结论应是一条从权限、采集和识别直到翻译的可复现链路，能缩小排查范围但不编造设备兼容性，也不宣称某条通用错误消息有固定万能修复。
用户点击麦克风后没有看到转录
应用显示通用无语音消息。团队没有原始诊断记录，暂时不能判断权限、音频采集、分段或识别阶段哪里失败。
决策
加入隐私安全的阶段追踪，用经许可的短样例复现；调查应停在第一个尚未验证的边界。
预期结果
支持人员能说明是否采到音频、识别器是否运行，不必猜通用修复，也不记录用户语音。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- ANDROID-AUDIO-01：Android 音频采集接口与应用责任
- COVE-ASR-02：PCM 分段及识别结果合并行为
- BENCHMARK-01：设备结论需原始运行记录
发布结论只对所记录的配置和验收集有效；扩大适用范围需要更多记录。
实施流程
- 记录权限与生命周期状态. 采集授权/拒绝、用户开始动作、Activity/服务状态、音频焦点打断及录音器初始化结果。不要请求与麦克风无关的额外权限。
- 确认音频帧和格式. 按 AudioRecord 文档检查状态和读取结果，记录格式元数据以及是否有非空缓冲到达下游使用者。
- 追踪分段和静音判断. 记录片段编号及静音、句首截断、停顿和参考句的空/跳过决定。没有复现记录前不要随意调阈值。
- 分离识别与翻译阶段. 有转录时先和源样例比较。没有转录时把翻译标为未到达；空解析/运行时输出另记为不同阶段问题。
- 恢复后重新录制. 注入权限变化、相关路由变化、进程重建和录音/识别失败。确认资源释放且下一次录音使用全新状态。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 追踪记录定位最早已确认阶段，并区分权限、采集、分段、识别和翻译结果。
- 空录音或失败后可以恢复，资源与订阅器完成清理，重试不复用过期音频状态。
- 诊断排除私人音频/文本，没有记录依据时不称“常见错误”、不许诺通用修复或机型支持。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 权限已授予 | 访问授权检查 | 不证明录音已开始，也不证明音频帧已到达应用。 |
| 采集缓冲非空 | 音频获取证据 | 证明输入数据到达，但识别和翻译仍需独立核查。 |
| 转录非空 | 识别阶段证据 | 允许进一步调查翻译，但不证明目标译文正确。 |
需要避免的失败模式
- 没有转录就先怪翻译模型
- 把权限已允许说成音频帧已到达
- 日志中写入原始录音或私人转录
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
麦克风权限能证明应用收到语音了吗？
不能。权限只授权访问，不证明录音初始化、路由、缓冲读取、分段或识别成功。需要分别追踪这些阶段、有效读取和错误码并记录样例。
无语音错误应该直接改采样率吗？
没有复现记录时不应这么做。先按消费者接口核实声明格式与实际帧，再进行受控变更并保留前后证据，避免盲目试错，确认结果可重复。
客服可以默认让用户发送原始录音吗？
不可以。优先使用合成或明确获准的短样例，诊断信息应脱敏，不要默认将私人音频和转录写入日志或支持包，并避免外传。