语音听写这件事，大多数人默认是云服务干的。手机上的语音输入，电脑上 Wispr Flow 那种按住说话，背后都是把音频丢给云端服务器，等几秒拿回文字。大家早就习惯了，觉得“语音识别嘛，肯定要联网的”。
但有一群人偏不这么想。医生写病历，律师看卷宗，研究员处理未发表的实验数据，这些场景下音频一旦离开本地，就是事故。于是有了 YazSes——一个按住键盘说话、文字出现在当前窗口、全程不联网的开源工具。它用的不是云端大模型，是本地的 faster-whisper，跑在 CPU 上，int8 量化，没有 GPU 也能跑。
问题来了：本地跑得动的模型，准确率够用吗？不联网的听写，延迟会不会让人想砸键盘？市面上已经有 Handy、OpenWhispr、Talon 这些开源或免费的本地方案了，YazSes 到底凭什么值得多看一眼？
大家都说云端听写更准，但数据指向另一条路
云端的语音识别确实准。OpenAI 的 Whisper 大模型、Google 的 Speech-to-Text，在标准测试集上的词错误率可以压到 2% 以下。但代价是音频要离开你的电脑，经过网络，送到别人的服务器上处理。
这不是危言耸听。Wispr Flow 这类产品默认是存储用户语音数据的，虽然提供了“隐私模式”可以关闭数据留存，但默认是开着的。用户需要主动去设置里翻半天才能关掉。而且即便开启了隐私模式，音频依然要经过 Wispr 的服务器完成转录——“不留存”和“不经过”是两码事。
YazSes 走的完全是另一条路。按住说话，音频在本地录完，交给本地运行的 faster-whisper 模型转成文字，然后通过 xdotool、wtype 这些系统级工具把文字“敲”进当前窗口。整个过程不产生任何网络请求。没有账号，没有 API key，没有订阅。
这听起来很理想，但有一个致命疑问：本地跑的模型，能跟云端比吗？
论文里的数据给出了答案。在 LibriSpeech test-clean 数据集上，200 条来自 40 位说话人的语音，YazSes 默认的 base.en 模型词错误率是 4.82%，small.en 模型是 2.59%。作为对比，云端 Whisper 大模型在同样数据集上大概在 2% 出头。差距有，但没有想象中那么大——small.en 的 2.59% 已经相当能打了。
更关键的是实时因子。small.en 模型的实时因子是 0.520，意思是处理 1 秒音频只需要 0.52 秒。一台普通笔记本 CPU 就能跑赢实时。非解码部分的管道开销只有 0.289 毫秒。换句话说，从你松开按键到文字出现在屏幕上，几乎全部时间都花在语音模型本身——没有什么额外的“系统 overhead”在拖后腿。
所以那个“本地一定又慢又不准”的直觉，在这里被数据推翻了。慢的那一点，换来的是音频从来不出门。
按住说话这件事，比你想象的要复杂
YazSes 的核心交互极其简单：按住一个键，说话，松开，文字出现。
默认的热键，Linux 是空格，macOS 是右 Option，Windows 是右 Ctrl。按住期间录音，松开后转录。就这么一个动作。
但背后要解决的问题一点都不简单。
首先是跨平台。Linux 上有 X11 和 Wayland 两套显示协议，macOS 有自己的一套权限体系，Windows 又有另一套。YazSes 的代码库通过一套“基于协议的平台抽象层”来统一处理这三个系统。同一份代码，三个平台都能跑。
其次是键盘事件的捕获。按住一个键说话，这个键不能真的被系统当成输入发出去——否则你一边说话一边往文档里敲空格。Linux 上要通过 evdev 读取原始输入事件，这就需要用户加入 input 用户组。macOS 和 Windows 则需要相应的权限授权。
然后是文字的注入。转录出来的文字要“敲”进当前窗口。X11 上用 xdotool，Wayland 上用 wtype，但在 GNOME 和 KDE 的 Wayland 下 wtype 是被屏蔽的，只能靠 ydotoold 这个虚拟输入守护进程。每种桌面环境都有自己的脾气。
还有语音活动检测。不是所有声音都要转录。YazSes 内置了 VAD（语音活动检测）阈值，只有超过一定音量的声音才会触发转录。用户可以通过 yazses mic-level --set 校准这个阈值，适应自己的麦克风和房间环境。
这些技术细节堆在一起，构成了一个事实：一个“按住说话”的功能，背后是键盘捕获、音频录制、语音识别、文字注入、跨平台适配、权限管理的一整条流水线。YazSes 把这整条流水线打包成了一个命令——yazses start。
不只是听写，还能当“语音版快捷键”用
如果 YazSes 只能把语音转成文字，那它和 Handy 这类工具的区别就没那么大。
但 YazSes 多了一层东西：语音命令。
说“undo that”，它不打出“undo that”这几个字，而是直接发送 Ctrl+Z。说“save file”，它发送 Ctrl+S。说“go to line 42”，它发送一串按键跳到第 42 行。说“run the tests”，它在终端或编辑器里执行测试命令。
这套命令系统分两层。第一层是正则表达式语法，快速匹配常见的命令短语，单次调用只要 0.021 毫秒。第二层是一个可选的小型语言模型路由器（约 0.5B 参数），处理那些正则表达式拿不准的模糊说法。
命令语法的设计有一个关键细节：它必须零误报。也就是说，如果用户说的是一句普通的话，绝对不能把它当成命令执行。论文里报告的数据是：命令语法的动作准确率 100%，在纯听写场景下的误报率是 0.0%。
这意味着你可以放心地说“run the numbers again before Friday”——它不会真的去“运行”什么，而是老老实实把这句话打出来。只有“run the tests”这种明确匹配命令模式的短语才会触发动作。
这听起来像是一个小功能，但实际用起来会产生一个微妙的变化：语音从“输入法”变成了“控制器”。你不仅在用嘴打字，还在用嘴操作编辑器、终端、整个工作流。
开源、免费、本地——但对手也不少
YazSes 不是唯一一个做本地语音听写的。
Handy（MIT 协议）同样是按住说话、本地转录、跨平台，而且安装包比 YazSes 小得多。OpenWhispr（MIT 协议）是一个 Electron 应用，界面更 polished，还支持用自己的 API key 调用云端模型作为备选。FluidVoice（GPLv3）在 macOS 上能做系统级的语音控制，不只是编辑器命令。Talon 则是另一个极端——功能极其强大，但需要学习一套脚本语言。
YazSes 在 README 里非常坦诚地列出了这些对比。它没有声称自己“最好”，而是说：如果你只要听写，Handy 可能是更好的选择；如果你要深度脚本化控制，Talon 更合适；如果你在 macOS 上想要系统级控制，FluidVoice 值得一看。
那 YazSes 的差异化在哪儿？
第一，Linux 是一等公民。大多数本地听写工具要么只支持 macOS，要么 Linux 是事后补的端口。YazSes 从第一天就把 Linux（X11 和 Wayland）当成主要目标，APT 安装、Snap 商店、systemd 自启动全都安排了。
第二，会议录制和说话人分离。yazses meeting start 可以录制整场会议，然后自动生成带说话人标签的转录稿。这个功能需要额外安装 diarization 扩展（约 45MB 的模型），但全程在本地完成。Handy 和 OpenWhispr 目前都没有这个能力。
第三，可审计的透明度。论文里每一个数字都有可复现的基准测试方法。代码、测试、基准脚本全部公开。这不是一个“声称很快很准”的项目，而是一个“你自己可以跑一遍验证”的项目。
一个反直觉的事实：本地听写正在变得足够好
两年前，本地语音识别还是一个有点尴尬的选择。Whisper 刚出来的时候，模型太大，CPU 跑不动。后来 faster-whisper 做了 int8 量化和推理优化，才让普通笔记本能实时跑起来。
YazSes 正好踩在这个时间点上。它用的 faster-whisper 已经是成熟的技术，论文里的基准数据也证明了 CPU 实时转录是可行的。不是“勉强可行”，是“small.en 模型跑得比实时还快”。
这意味着什么？
意味着“语音识别必须联网”这个默认假设，正在被技术演进瓦解。云端模型依然更准，但差距在缩小。而本地方案在隐私、延迟、离线可用性上的优势是绝对的。
YazSes 的论文里有一句话概括了它的定位：它是“唯一同时满足开源、跨平台（包括 Linux 是一等公民）、完全离线”的工具。这个 claim 是否绝对准确可以争论，但方向是对的——本地语音听写这个赛道上，正在出现真正可用的产品。
不是“勉强能用”，是“我日常就在用”。
怎么装、怎么用、花多少钱
安装分三种路径。
Linux 用户推荐 APT 脚本：bash <(curl -fsSL https://raw.githubusercontent.com/MSKazemi/yazses/main/install-apt.sh)。这个脚本会安装所有依赖（音频库、注入工具、加入 input 组），然后装上 YazSes。Snap Store 也有，但 snap 的严格沙箱会阻断键盘读取和 Wayland 注入，需要手动连接接口。
macOS 和 Windows 用户用 pipx：pipx install yazses。macOS 上还有 Homebrew cask 和 .dmg 安装包，但 .dmg 目前只支持 Apple Silicon。
装完之后两条命令：
yazses quickstart # 三步引导，只读不改
yazses start # 启动守护进程，按住热键说话
费用：零。Apache 2.0 协议，随便用，随便改，随便分发。没有免费版/付费版的区别，因为根本就没有付费版。
模型：第一次运行时会自动下载 faster-whisper 的模型文件，默认 base.en 约 140MB。也可以手动指定 tiny.en（更快）或 small.en（更准）。模型存在本地，只此一份。
有些场景，云端就是不能碰
不是所有人都能在意“准确率差一点点”这件事。
医生口述病历，里面全是患者姓名、诊断结果、用药方案。这些数据一旦上网，就是 HIPAA 违规。律师看案卷，讨论的是未公开的诉讼策略。研究员写论文，手上有还没发出去的实验数据。政府机构的电脑可能根本就连不上外网。
对这些场景来说，“音频不出门”不是锦上添花，是及格线。
YazSes 的设计目标就是这条及格线。论文里明确说它适用于“隐私敏感行业和离线或气隙环境”。没有 telemetry，没有账号，没有“可选的数据共享”。默认就是完全离线，所有额外功能都是 opt-in。
一个有趣的细节：YazSes 有一个可选的本地学习语料库，用来记录用户的纠正操作，然后通过 yazses tune 提出配置改进建议。这个语料库是加密的，而且永远留在本地。连“自我改进”都不让数据出门。
总结一下
云端听写更准，但音频要出门。本地听写保隐私，但以前慢、不准、难配置。YazSes 用 faster-whisper + int8 量化把本地转录推到了“可用”的临界点上——2.59% 的词错误率，0.52 的实时因子，单次命令匹配 0.021 毫秒。它不是要取代云端方案，而是给那些不能把音频送出门的人，一个真正能用的选择。
语音识别正在从“必须联网”走向“本地也行”。这条路还很长，但 YazSes 证明了一件事：门槛已经跨过去了。