本地优先的语音识别，产品上意味着什么

语音识别产品容易被几个数字牵引：WER、CER、实时倍率、延迟、支持语言数量。这些指标必要，但它们只回答“模型表现如何”，不回答“用户是否敢把音频交给这个系统”。

做 OpenASR 时，一个不太讨巧的判断是：本地优先不能只写在介绍页上，它必须进入默认路径。音频默认留在本机，模型包必须可验证，运行时应该 fail-closed。音频是否离开设备，不能由实现细节悄悄决定，也不能靠用户去猜。

这件事看似偏技术，最后落到产品上却很具体。上传按钮要不要出现，模型来源怎么展示，任务失败时给什么提示，日志里哪些内容应该暴露给用户，都是信任边界的一部分。很多产品把隐私写成一句承诺，本地优先产品更适合把隐私写成一组可检查的行为。

.oasr 模型包的价值也在这里。它把权重、元数据、校验信息和运行约束放进同一个用户侧格式里。用户拿到的不再是一个模糊的模型文件，而是一个能被检查、能被解释、也能被运行时拒绝的包。

“一键可用”在普通工具里通常是优点，在模型和音频场景里却要谨慎。自动下载会把来源、许可证、缓存、网络和隐私混在一起。把下载变成显式动作，看似多了一步，换来的是更清楚的责任边界：用户知道自己安装了什么模型，也知道模型来自哪里。

项目推进到这里，会明显感到顺滑和可信有时不是同一件事。顺滑追求少一步操作，可信追求每一步都说得清楚。模型不是普通素材，它带着许可证、来源、适配范围和安全假设。产品如果把这些信息藏起来，短期看更轻，长期看会让用户在出问题时无处判断。

失败状态同样是产品的一部分。模型包不合法、运行时不支持、参数不匹配、音频格式异常，这些失败应该有可读的解释和下一步动作。只把原因写进底层日志，等于把复杂度原样交还给用户。

这里也需要一点科研精神。除了 WER、CER、RTF 和 p95 延迟，还要看模型来源能否追溯，包体哈希能否校验，许可证是否暴露给用户，转写任务有没有明确的状态，失败结果会不会被包装成成功。模型效果决定上限，边界和失败处理决定下限。

本地优先不是反对云，也不是把所有复杂度都甩给用户。更准确地说，它是在默认情况下把决定权交还给用户。能不能上传，什么时候下载，模型从哪里来，失败后怎么处理，都应该有清楚的答案。做到这一步，一个语音识别工具才不只是“能跑”，而是开始显得可靠。