多模态语音识别：打造一个能看见你所见的监听器

只依赖音频的语音识别已经足够好，以至于它剩下的问题很容易被低估。干净语音基准掩盖了真正的产品问题：用户是在应用里听写，在可见代码旁听写，在多语言混杂的环境里听写，也会说“这个函数”“上面那条 bullet”这类不完整引用。

ASR 仍会失败的地方

最经典的例子是同音或近音。"From foo import bar" 和 from foo import bar 听起来相似，却属于完全不同的语境。如果模型不知道光标在 TypeScript 文件里，"cache the auth client" 和 "cash the auth client" 也可能被混淆。单靠音频无法稳定推断目标输出场景。

代码标识符会把问题放大。用户可能说“fetch profile”，但可见函数名是 fetchProfile。转写模型听到的是词；听写模型应该保留标识符。多模态语音识别把可见文本当作证据，而不是装饰。

指示词是第三个尖锐边界。当用户说“把这个替换成 guard clause”时，语音本身看似完整，但“这个”到底指向什么，完全依赖选择区和光标位置。没有选择感知或稳定的光标参照，系统只能猜；而猜错一次，往往比重新输入更浪费时间。只听音频的 ASR 无法解析这种指示关系，只能把指示词转写出来，然后希望下游工具自己理解。

• 同音歧义：普通英文与代码语法。
• 实体：包名、类名、文件路径和命令参数。
• 指示：“这个”“那个”“上面”“选中的部分”。
• 格式：正文、列表、代码注释、commit message 或 prompt。

多模态监听器架构

Loqua 的监听器有三个本地输入：流式音频特征、屏幕派生上下文和应用元数据。音频路径提出“用户说了什么”的候选；上下文路径概括“文本将落在哪里”：应用、字段类型、选中文本、附近 token 和可见结构线索；应用路径补充约束，例如是否适合换行、Markdown 或代码语法。

监听器并不需要像人一样理解整块屏幕。它只需要对听写有用的最小证据。在 VS Code 里，这可能是可见标识符、语言模式和选中的代码；在 Slack 里，可能是线程主题和最近的语气；在 Notes 里，则可能是标题层级和列表上下文。

我们刻意不做什么

有些能力被我们有意排除在范围外。监听器不会对远程内容截图做 OCR，不会总结用户没有正在输入的窗口，也不会建立持久的视觉历史。它同样不会从图像里推断细粒度意图：图表、视频帧或设计画布本身不会被解释，只有周围文本会被使用。每一次删减都是产品选择：用能力换取可预测性和更清晰的隐私边界。

因此，我们只在狭义产品意义上称它为音频视觉听写：音频加上用于写作的视觉上下文。目标不是通用视觉推理，而是在光标处少写错词。

屏幕上下文如何消解歧义

屏幕上下文听写通过收窄可能性来改变输出。如果光标在 Python 文件里，且可见行已经包含 from fastapi import，用户说出的“router”更可能是一个符号，而不是普通名词。如果光标在 Gmail，同一句话就应该变成自然句子。

监听器也支持选择感知编辑。如果有文本被选中，听写会默认被解释为作用在这段文本上的指令，除非用户明确要求插入新的正文。仅仅这个区分，就能消除一整类意外重复文本。

当上下文信号冲突时，我们会先信任最硬的证据。活动应用是最可靠的信号，因为它由操作系统结构性保证；选中文本排在其后；附近可见 token 是最软的信号，因为它们可能过时或只是偶然出现。两类信号不一致时，监听器会优先采用更硬的信号并降低置信度，而不是随便选一个然后提交。

隐私：屏幕上下文留在本地

上下文感知语音识别如果实现粗糙，会带来隐私代价。Loqua 的规则是：监听器需要的屏幕上下文默认留在本地。上下文摘要在设备上计算，用来塑造当前这次语音输入；它不会被保留成通用屏幕日志。

具体来说，进入设备端监听器的是一段短暂的上下文包：活动应用标识、语言和字段类型、选区范围，以及附近几百个字符的可见文本。默认永远不会离开设备的是更广泛的窗口内容、其他标签页、其他应用，以及上述任何内容的持久历史。用户开启可选云功能时，云端只会在我们混合隐私说明中描述的边界内接收听写音频或文本；它不会接收原始上下文包。

这个边界很重要，因为一个能看见你所见的监听器可能接触代码、消息和草稿。我们把它视作敏感数据。隐私架构在我们的混合隐私说明里有更详细的解释，简短版本是：屏幕上下文路径本地优先，可选云功能不会收到原始的周边屏幕内容。

开放研究背景

相关研究背景包括音频语言建模、视觉语言投影和多模态指令微调。可以从 Whisper 的稳健 ASR、LLaVA 的视觉指令微调模式，以及 ImageBind 的跨模态对齐开始了解。

这些论文是文献背景。Loqua 的多模态语音识别栈是面向 Mac 听写界面的原创工作：本地上下文、低延迟流式处理和应用感知输出。我们借用的是领域词汇，而不是依赖链。

路线图

下一步是更好的不确定性表达。如果上下文指向两个可能的标识符，系统应该保留这种歧义，而不是假装确信。我们也希望为终端、电子表格、IDE 聊天面板和设计工具做更细的应用适配，因为这些场景里“有用输出”的形状差异非常大。

终端适配器是最具体的近期工作。终端在结构上只是光标处的一行，但上下文上却是一长串历史命令和输出，它们都应该影响用户下一句要输入什么。电子表格适配器几乎相反：可见上下文窗口很小，但列语义非常刚性。两个适配器复用同一套监听器架构；差别在于什么算证据，以及文本渲染器从哪里获得格式线索。

长期方向不是“让模型看见一切”。方向更窄，也更安全：监听器只看足够的本地上下文，在你想写的位置写出你真正想表达的内容，并减少后续清理。这就是多模态语音识别的产品承诺。