Ubuntu 要做原生听写了：Canonical 推出本地语音项目 Myna

Ubuntu 终于要有自己的原生听写了

6 月 17 日，Canonical 公布了一个叫 Project Myna 的新东西——给 Ubuntu 桌面做原生语音转文字。首个版本会跟着今年 10 月的 Ubuntu 26.10（代号 Stonking Stingray）一起出货，并被定位为「桌面体验的核心组成部分」。

名字来源是鹩哥（八哥），一种会模仿人类说话的鸟。这种命名挺 Canonical 风格的，比之前 Snap、Mir 那套延续下来。

关键的判断先放在前面：这不是一个语音助手，也不是 Cortana / Siri / Copilot 那种东西。Canonical 在首版上的克制几乎到了「过分」的程度——没有语音命令、没有桌面控制、没有翻译、没有自动语种检测。按下快捷键，说话，文字就插到当前光标所在的应用里。仅此而已。

在如今所有人都在堆「AI Agent」「桌面操作智能体」的时间点，Ubuntu 反其道而行之，先把最基础的听写做扎实，这个产品思路值得说一下。

一切都在本地跑

技术架构上，Myna 用的是 AI 语音识别模型，但所有识别都在本地完成。下载模型之后，断网也能用。

这是 Canonical 整个 AI 路线图的延续。今年 4 月，Canonical 工程副总裁 Jon Seager 在博客里讲过 Ubuntu 的 AI 整合思路——分「隐式」和「显式」两类：

• 隐式 AI：在系统后台跑模型，悄悄增强现有功能。语音转文字、文字转语音、无障碍工具是优先项。
• 显式 AI：面向有需求的用户提供 AI 原生功能，严格 opt-in。

Myna 显然属于第一类的延伸——把听写做成基础设施级别的能力，而不是塞一个聊天框给你。

隐私上 Canonical 给的承诺也比较干净：

• 麦克风只在用户主动激活听写时被访问
• 音频数据在内存里处理完直接丢弃
• 不上传任何外部服务
• 模型在本地推理，离线可用

对比一下 Windows 11 的 Recall 在去年那场公关灾难，Canonical 这次的「隐私优先」叙事是有底气的。Fedora 在 5 月公布类似方案时，Linux 社区那一波关于「开源 OS 该不该塞 AI」的争论也历历在目，Canonical 显然吸取了教训——开发者最在意的就是数据控制权和可关闭性，Myna 在这两点上没有踩雷。

架构是模块化的，野心藏在后面

Myna 的工程设计比表面看起来要讲究。架构被切成了四块独立组件：

• 语音识别（ASR 模型推理）
• 用户交互（快捷键、UI 反馈）
• 听写管理（会话状态、上下文）
• 文本注入（写到当前 focus 的应用里）

这种切法的好处显而易见：未来想换底层模型（比如从 Whisper 换到某个更轻量的本地 ASR），或者想把文本注入从 Wayland 扩展到 X11、再到其他桌面环境（KDE、Cosmic），都不需要动其他模块。

首版的目标平台是 Wayland 上的 Ubuntu，GNOME 作为主要验证环境。这个选择不意外——Ubuntu 25.04 之后 Wayland 已经是默认会话，X11 在桌面侧基本是历史包袱。文本注入这件事在 Wayland 上比 X11 难一截（沙箱化嘛），Canonical 显然不想从一开始就被旧协议拖住。

源码和架构文档已经放在 GitHub 上，GPLv3 协议。这意味着任何下游发行版（包括 Pop!_OS、Linux Mint、Elementary 这些 Ubuntu 衍生版）都可以直接拿去用，甚至 Fedora、openSUSE 都能 fork 一份。

为什么是「听写」而不是「助手」

这里值得展开讲一下。Canonical 桌面团队的 Jean Baptiste Lallement 说，他们希望「在过多的设计决策被固定下来之前」拿到社区反馈，尤其欢迎依赖听写的用户、辅助技术用户、以及已经在 Linux 上折腾过语音识别的人。

这句话翻译一下大概是：我们不想再造一个没人用的 Cortana。

语音助手这个方向，过去十年从亚马逊 Alexa 到苹果 Siri，再到所有那些试图做「电脑版 Siri」的项目（Mycroft 已经凉了），证明了一件事——在桌面环境下，绝大多数用户其实不会对着电脑说话。你在办公室不会，在家里有键盘的时候也不会。但是，听写完全是另一回事。

听写解决的是输入速度问题。一个熟练的打字员每分钟 60-80 字，而口述可以轻松到 150 字以上。对于：

• 记者、作家、技术写作者
• 需要长时间打字会引起 RSI（重复性劳损）的人
• 视力或运动障碍用户
• 母语非英语但说比写流利的用户

听写是刚需。macOS 的 Dictation 已经做了十几年，Windows 也有。Linux 这边长期靠 nerd-dictation、whisper-typer 这类社区项目零散支持，质量参差，配置门槛高。

Myna 把这个洞填上，方向是对的。

它在跟谁竞争

横向看一下当前 Linux 上的本地语音转文字方案：

| 方案 | 模型 | 集成度 | 维护状态 | |------|------|--------|----------| | nerd-dictation | VOSK | 命令行/自配 | 社区维护 | | whisper.cpp + 各种封装 | Whisper | 需自己组装 | 活跃 | | Speech Note | Whisper/其他 | Flatpak 应用 | 活跃 | | Numen | VOSK | 语音命令为主 | 活跃 | | Myna | 未公开（推测 Whisper 系） | 系统级原生 | Canonical 官方 |

Myna 的真正差异化不在模型本身——大概率底层就是 Whisper 或 faster-whisper 这一类——而在「系统级原生集成」。这是社区项目做不到的：你需要 GNOME 配合，需要 Wayland 协议支持，需要在 Settings 里有原生面板，需要默认安装、默认快捷键、默认可发现。

MacOS 的听写好用不是因为模型多强，是因为它在系统的每一个文本框都能用，Caps Lock 双击就触发。Myna 的目标显然就是这个。

路线图与可能的雷

Canonical 给出的后续节奏：

1. Ubuntu 26.10：首版上线，刻意收窄功能，把基础体验打磨好
2. 后续版本：持续改善桌面集成度，探索更自然、更准确的听写方式
3. 优先级：取决于早期用户反馈

几个潜在的坑值得提前说：

模型大小与首次体验：本地 ASR 模型动辄几百 MB 到几 GB，Whisper Large 接近 3GB。Ubuntu 安装介质本身已经膨胀到 5GB+，如果默认捆绑大模型会进一步膨胀；如果首次启动让用户下载，又会被吐槽体验割裂。Canonical 怎么平衡值得观察。

中文等非英语支持：参考资料里完全没提语种问题。Whisper 多语种版本对中文支持还行，但本地小模型的中文准确率往往不如英文。如果首版只优化了英文（这是大概率事件），中文 Linux 用户基本就是看个热闹。

与输入法的冲突：Linux 桌面的输入法栈（IBus、Fcitx5）本身就是个老大难。Myna 的文本注入怎么跟输入法协同，是个工程细节问题，但很容易出 bug。

资源占用：本地推理对低配设备不友好。Ubuntu 一直标榜能跑在老硬件上，如果 Myna 在 8GB 内存的老笔记本上跑起来风扇狂转，那「核心桌面体验」就成了反向卖点。

一个更大的图景

Myna 只是 Canonical AI 路线图里的一小块。按 Jon Seager 此前的说法，Ubuntu 26.10 还会探索 agentic workflow——比如自动化故障排查这种「Agent 帮你修系统」的能力。但跟 Myna 一样，全部是「strictly opt-in」。

Canonical 在这件事上的姿态相当清晰：AI 是能力增强，不是默认绑架。这跟微软在 Windows 11 上的激进做法形成了鲜明对照，也跟 Apple Intelligence 那种「打包卖给你」的策略不同。

对开发者而言，这种克制是好事。Ubuntu 作为大量开发工作站和服务器的默认 OS，最不需要的就是后台偷跑模型、偷传数据、偷占资源。Canonical 显然懂这件事。

至于 Myna 最终能不能成为 Ubuntu 用户日常用的工具，还是变成另一个无人问津的「内置应用」，要看 Ubuntu 26.10 正式发布时的完成度。GitHub 仓库现在已经开放，想提前给反馈的人可以去试。

顺带一提，做语音应用的开发者如果想在产品里集成更强的云端 ASR 或多模型对比，OpenAI Hub（openai-hub.com）一个 Key 就能调 GPT、Claude、Gemini、DeepSeek 等主流模型的 API，兼容 OpenAI 格式，国内直连，省去一堆账号和网络的麻烦。

参考来源

• IT之家：Canonical 推出本地语音转文字项目 Myna — Project Myna 公布的中文一手报道
• iThome Canonical 标签页 — Fedora 与 Ubuntu 本地生成式 AI 整合计划及社区反响汇总