语音转文字是怎么跑起来的：从声学模型到光标插入，顺带聊聊为什么终端里特别难

语音转文字是怎么跑起来的从声学模型到光标插入顺带聊聊为什么终端里特别难上周同事看见我在 Windows Terminal 里敲命令突然来一句你手怎么不动。我确实没动手——按住热键说了句话松手命令就出现在光标那儿了。这个反应我遇到过太多次所以想把这件事本身写清楚语音转文字到底在算什么为什么在控制台里特别难做以及大模型跟语音识别到底是不是一回事。至于我最后折腾出来个什么文末再说。一、语音转文字的四步缺一步效果就垮很多人以为语音识别的过程是把声音转成拼音再转成汉字。这个理解在二十年前是成立的现在不是了。今天的做法一般分四步缺一步效果就垮第一步是前端。麦克风采到的是 16kHz 的波形切成一帧一帧常见 25ms 一窗、10ms 一帧移每帧算一组频谱特征比如 40 维或 80 维的 FBank。这一步决定了模型能看到什么降噪、自动增益、回声消除都在这一层做。做得糙后面模型再好也白搭。第二步是 VAD也就是判断这段声音里有没有人说话。这件事听着简单实际很难键盘声、空调声、隔壁说话都可能被当成语音。VAD 判断错了一段话会被切碎或者一直不结束。第三步才是声学模型。早期是 HMM-GMM后来是 CTC 加深度网络再后来是 Attention 的编码器-解码器Whisper 就属于这一类现在端上常用的是非自回归结构比如 Paraformer、SenseVoice整段音频一次进出不用一个词一个词往外蹦。自回归的好处是语言层面的连贯性更好坏处是慢——每多一个字就多一次前向计算。非自回归把这一步省了代价是要靠别的手段补语言层面的信息。第四步是后处理。标点、数字规范化“二零二五→2025”、专有名词纠错都在这里。很多人觉得识别不准其实声学模型没错是这一步没做好。顺便说一个容易忽略的点热词。给模型一个这段时间可能会出现的词表比如项目名、人名、缩写解码时会提高这些词的先验概率这叫上下文偏置contextual biasing。它不需要重训模型是最划算的准确率提升手段之一。二、为什么有的工具憋到最后才出字这是体验上最明显的差距技术上其实就一句话有没有按停顿切段。如果你说的是帮我查一下磁盘占用最高的十个目录一口气说完再识别模型得等你说完、等端点检测确认静音才开始算再一次性吐出来——中间那两三秒就是干等。更好的做法是 VAD 一边判停一边把已经说完的片段送去识别先把前半句落下来。代价是切分点可能落在词中间需要做合并和二次修正。我在实现里为了这个改过两版最早是等整段静音 700ms 才提交长句体验极差后来改成按短停顿分段、先给结果、后面再覆盖修正主观感受差别很大。三、延迟到底花在哪把一秒二拆开有人问松手到出字要多久我说不好因为这件事得拆开看。找了个安静的下午用录屏数帧把一次 20 字左右的输入拆成四段按键到开始采集预热之后基本是 0只有冷启动那一次要 400~800ms模型加载 麦克风初始化说完最后一个字到端点确认300~500ms这个值就是 VAD 的静音判定阈值首段推理150~300msi5 这个级别的 CPU注入模拟按键按字符走20 个字 100~200ms剪贴板路径固定 50~80ms加起来松手到看见第一个字大概半秒整句落完不到一秒。我第一版是两秒多问题主要出在等整段静音 700ms和整段一次性推理拆开之后就顺了。这里有个取舍端点阈值调小短词反应快但说长句时中间的换气会被当成结束于是半句先落下去、后半句再补一段视觉上会跳。我最后是按停顿长度 已积累字数两个条件一起判短句宽松、长句保守代码是啰嗦了点但体感稳。四、语音识别模型和大模型不是一回事这两个词现在经常被混着说其实差得很远。大语言模型LLM做的是给定前文预测下一个 token。文本被切成 token送进 Transformer靠自注意力机制算每个位置该关注前文的哪些部分然后自回归地一个个生成。参数量动辄几亿到几千亿跑起来吃显存所以要么上云要么在本地做量化int8、int4并接受速度损失。语音识别模型是专用模型输入是声学特征输出是字符序列参数量通常在几千万到一两亿量级而且很多是非自回归的——一次前向就出整段结果。所以一个 int8 量化后两百多兆的模型在普通笔记本 CPU 上跑实时完全没问题。算笔粗账就更清楚了一段 5 秒的语音特征大约 500 帧模型每帧的计算量在百万次乘加级别整段也就几亿次运算现代 CPU 单核算力是每秒几十亿次这个量级留给模型的时间绰绰有余。而一个 7B 的 LLM 生成 20 个字要跑 20 次前向、每次几十亿次运算——这才是为什么要显卡。所以端上跑不了 AI这个说法不准确。跑不动的是通用大模型跑得动的是垂直小模型。语音识别恰好属于后者。五、为什么终端和控制台里特别难这是我这段时间踩坑最多的地方也是很多语音输入工具在控制台里直接失效的原因。往窗口里写字这件事Windows 上至少有四条路没有一条通吃输入法IME最自然但依赖焦点窗口的输入上下文。控制台宿主conhost和 Windows Terminal 是两个完全不同的窗口体系对 IME 的支持历史包袱很重很多工具在这就断了。模拟按键SendInput直接投递按键消息控制台能吃。问题是遇到中文、emoji 或者目标程序自己处理字符的方式特殊时会丢字或乱码而且速度太快容易被程序当成重复输入丢掉。无障碍接口UI Automation正经但覆盖率差很多控制台程序根本没实现文本模式。剪贴板粘贴最稳长文本基本都走这条路。但要注意两件事一是有的程序粘贴快捷键不是 CtrlV终端里常是 CtrlShiftV 或右键二是你得把用户原来的剪贴板完整还原只存纯文本会把人家复制的表格、图片弄丢。还有一层UIPI。如果目标窗口是管理员权限运行的普通权限的进程根本没法往里注入这不是 bug 是设计。遇到这种情况只能明确提示用户而不是默默失败。实际操作里稳妥的做法是探测目标窗口 分级策略短文本走按键长文本走剪贴板特殊程序单独配粘贴键和延迟。听着很脏但这是唯一能覆盖绝大多数场景的办法。六、几个具体到数字的坑开麦 500 毫秒。第一次按下热键到真正开始录音中间有一段设备初始化体感就是我说话前两个字没了。解法是别等按键再开麦程序启动后先把备用设备拉起来保持采集按键只是切一个标记位。浮窗抢焦点。提示条一弹出来正在打字的窗口失焦输入法候选框消失用户立刻就炸了。要用 WS_EX_NOACTIVATE 之类的窗口样式再配合逐像素透明和鼠标穿透让它看得见但碰不到。标点靠猜。语音里没有说话人打的标点只能从停顿长度、语气词位置推。短停顿不该加句号长停顿必须加句尾还要判断是不是疑问。这一层做不好输出就是一逗到底。同音字。“部署和部属”、“在线和再线”声学上几乎一样只能靠上下文或者拼音索引去纠。我最后是拿一张拼音表做了一个轻量的同音纠错只在热词附近生效避免把正常文本改坏。七、关于免费这件事端上推理也就是常说的离线语音识别有个好处没有按分钟计费的服务器成本。云端方案每转写一分钟都要付钱用户量越大账单越高所以要么限时、要么订阅本地跑就是耗点电边际成本接近零。这也是这类工具能长期免费的前提。当然免费不等于没有成本——模型托管、下载带宽、签名证书都要钱所以常见的做法是免费额度加广告或者付费去广告。我自己的做法是每天给一个固定次数超出就等第二天启动时放一条赞助位。算不上优雅但至少不用为了用个输入工具先办个会员。八、怎么判断一个语音输入工具好不好用不用听宣传按这几条自己试五分钟能试完打开 cmd 或者 PowerShell直接说一句带标点的话看能不能落进去。这一条能筛掉一大半工具。掐表松手到看见第一个字。超过一秒的日常用会觉得烦。说一段话中途故意停两次看会不会被切成三段、标点是不是乱加。先复制一段带格式的表格再用语音输入一大段文字然后粘回去看原来的剪贴板还在不在。打开一个以管理员身份运行的窗口看它失败时是弹提示还是默默没反应。断网再试一次。云端方案在这一步会原形毕露。九、几个常被问到的问题准确率到底多少安静环境、普通话、正常语速字准确率 95% 上下算及格剩下的错主要集中在专有名词和同音字上。热词表能救一部分其他只能手改。别信99%这类说法那多半是特定测试集的结果。模型多大吃内存吗我用的这套量化之后两百多兆常驻内存 200~400MB跟句子长短有关。听着不小但跟一个 Electron 应用比算客气的。中英混说行不行行前提是模型支持多语言。麻烦的是AIAPI这类词有的模型会转成中文音译得靠热词纠回来。会不会上传我的语音看实现。离线方案音频不出本机云端方案必然要传。企业环境里这条基本是一票否决。说错了怎么改按 Esc 取消或者说完直接改字。用语音去改文字“把刚才那个词删掉”目前的体验普遍不好我不建议指望它。最后如果你只是想解决打字慢这件事不用管上面这些原理找一个按住说话、松手出字、在终端里也能用的语音输入工具就行。绕了一圈我自己写了一个叫速录SpeedScribeWindows 10/11装完常驻托盘默认热键 CtrlAltSpace识别全程离线断网也能用免费额度每天一百次。做得不完美但上面这些坑基本都趟过一遍。如果你想自己搭一套路线也很清楚sherpa-onnx 做推理运行时SenseVoice 这类非自回归模型做声学模型silero-vad 做分段剩下就是注入层和 UI 的活。上面几节提到的坑基本都会撞一遍。模型和运行时都是开源的sherpa-onnx、SenseVoice、silero-vad搜名字就能找到。项目主页我放在 https://gitee.com/mengdj/quickin使用说明和界面截图都在上面有问题可以直接在仓库里提。