主题
会议录音转文字，识别率差在哪
同一个转写模型，有人拿到的结果几乎不用改，有人满屏错字。差别通常不在模型，在喂进去的音频本身。
决定识别率的三件事
信噪比。背景空调声、键盘声、隔壁说话声，都会和人声抢频段。人耳能自动忽略，模型不能——它把噪声也当成待识别的信号。这是影响最大的一项。
采样与编码。过度压缩的音频（比如码率极低的微信语音转存件）高频信息已经丢了，而中文的辅音（s、sh、f、x）恰恰集中在高频。丢了高频，「四」和「十」就分不开。
说话方式。多人抢话、远距离拾音、语速过快，都会显著拉低准确率。这一项事后无法补救，只能靠录制时注意。
正确的处理顺序
顺序错了，后面的步骤会白做：
第一步：如果是视频，先提取音轨。 直接把视频丢给转写工具，很多工具会先做一次内部转码，而这次转码的参数你控制不了。先单独提取音轨，能确保后续步骤拿到的是干净的原始音频。
第二步：降噪。 这一步必须在转写之前。降噪的目标是压掉稳态背景噪声（空调、风扇、电流声）并增强人声。注意降噪不是万能的——它对稳态噪声效果好，对突发噪声（关门声、咳嗽）效果有限。
第三步：过长的录音先切分。 三小时的会议一次性转写，中途一旦出问题就得整体重来，而且很难定位是哪一段出的错。按议题或按小时切开，出错时只需重跑一段。
第四步：转写，导出字幕格式。 如果后续要做视频字幕或需要按时间定位，导出 SRT 比纯文本有用得多——每句话带时间戳，回原音频核对只要几秒。
音频格式怎么选
处理链路上会遇到几种格式，各有各的位置：
| 格式 | 压缩 | 用在哪 |
|---|---|---|
| WAV | 无压缩 | 中间处理环节，保真但体积大 |
| FLAC | 无损压缩 | 需要保真又要控体积时的归档 |
| MP3 | 有损 | 通用分发，兼容性最好 |
| M4A | 有损 | 苹果生态默认，同码率下比 MP3 略优 |
原则和图片一样：中间环节用无损，最后一步才转有损。如果在降噪之前就把音频转成低码率 MP3，降噪算法能拿到的信息已经少了一截，效果自然打折。
反复转码同样是不可逆的——MP3 转 WAV 再转 MP3，第二次的损失叠加在第一次之上，转成 WAV 并不能把丢掉的高频找回来。
转写结果怎么校对
拿到文本别从头读到尾，按这个优先级扫：
- 数字和金额：识别错误率最高的一类，且错了后果最严重。
- 人名、公司名、专业术语：模型没见过的词会被替换成读音相近的常见词。
- 否定词：「不」「没有」这种单音节字最容易被吞掉，而一旦吞掉，整句意思反转。
这三类扫完，剩下的错字大多不影响理解。
一个反直觉的建议
别指望「先转写再修」比「重新录一遍」快。 如果录音条件很差（远距离、多人混说、噪声大），转写出来的东西可能需要逐句对照音频修改，耗时远超重新整理。
判断标准很简单：随机抽一分钟转写结果读一遍。如果需要改的地方超过三处，后面两小时的内容大概率不值得靠修改来救。
反过来：文字转语音
同一类里还有反方向的需求——把文稿合成语音，用于视频旁白、有声内容或无障碍朗读。
这里最影响成品质量的不是音色，是文本本身的书面语程度。为阅读写的句子往往长、从句多、书面词密集，合成出来会显得念稿感重。改成短句、把「其」「之」这类书面虚词换成口语说法，同样的合成引擎听感会好很多。
数字、英文缩写和多音字是另外三个坑：合成引擎对「2026 年」「3.5 万」「API」「重（chóng/zhòng）」的处理未必符合预期，这几处最好先在文稿里改成期望读法。