语音遇见视觉：全模态模型如何打开多模态语音输入

Loqua 是一款面向 Mac 的上下文感知语音输入工具。真正关键的变化，是从 transcript 转向 destination-aware writing：同一句话，在 Slack、Cursor、GitHub、Apple Notes 和代码编辑器里，应该落成不同的文本。

这是我们“语音 + 视觉 AI”思路的入门版本。音频、语言和多模态系统的公开研究，为这个领域提供了有用的词汇和方向；但 Loqua 的生产级栈是我们为 Mac 听写场景内部训练、内部优化的原创工作。

从转写到上下文

纯音频 ASR 回答一个问题：用户说了哪些词？听写还要回答第二个问题：这些词在当前光标位置应该变成什么？正是这个第二问题，让多模态语音输入变得必要。一段转写可以完全准确，却仍然不适合它要落入的目标位置。

当你在代码编辑器里听写时，标点、标识符、注释和选中文本都会影响结果。当你在邮件里听写时，语气和段落形状更重要。当你在任务工具里听写时，负责人和截止时间才是关键。屏幕感知语音输入会把这些可见线索变成写作时的约束。

为什么屏幕上下文会改变听写

同一句话会因为所在 App 不同而有不同含义。“Add a guard before fetch profile” 在 IDE 里应该变成贴近代码的文本，在 Linear 里应该变成一条任务，在 Slack 里则更像一个普通请求。只靠音频，很难稳定判断该选哪一种形态。

Loqua 的上下文层读取的是本地信号，比如当前 App、选中文本、附近可见文本，以及目标输入框类型。它不需要完整的屏幕叙事，也不需要理解你屏幕上的一切。它需要的是足够的本地证据：保留标识符，判断你是在插入还是编辑，并选择正确的输出形状。

光标处会发生什么变化

输出会变，是因为目标位置变了。这就是全模态听写作为一个产品类别的实际价值：上下文可以做出转写本身无法做出的写作决策。

隐私边界

屏幕上下文足够强大，因此边界必须清楚。Loqua 的上下文路径默认 local-first。当前 App、选中文本和附近可见内容只用于塑造这一次发言的输出，而不是生成一份通用的屏幕日志。

完整边界可以看 以隐私为设计前提的混合架构。简短版是：音频和屏幕上下文都被当作敏感的本地信号处理；可选的云端能力不会接收周围屏幕的原始内容。

延伸阅读

如果想了解文献背景，可以从用于稳健语音识别的 Whisper、用于视觉指令微调的 LLaVA，以及用于跨模态对齐的 ImageBind 开始。这些链接用于解释领域脉络，不代表 Loqua 的来源声明。