很多所谓的“中文会议”，真正说起来并不是纯中文。产品团队会说“这个 feature 下个 sprint 上”，运营会讨论 ROI、CPA 和 conversion，技术会议里 API、SDK、deployment、GitHub 几乎不会被翻译成中文。人听起来毫不费力，AI 录音转文字却必须不断判断当前说的是哪种语言。
这种现象叫 code-switching，也就是在一段对话甚至一句话里切换语言。语音识别研究一直把它当成独立问题。2025 年公开的 CS-Dialogue 收集了 104 小时、200 名说话者的自然中英混语对话；TALCS 则包含约 587 小时来自真实在线教学场景的中英混语语音。专门的数据集之所以存在，就是因为单语测试不能代表真实混说。
为什么中英混说比纯中文录音转文字更难？
模型首先要听清声音，然后还要判断语言边界。例如“这个 onboarding flow 明天再 review”里，中文语法中连续嵌入了几个英文词。系统如果在错误的位置切换词表，就可能把英文写成近音中文，或者把中文片段误判成英文。
Interspeech 2020 的研究曾使用中文、英文双编码器加语言识别 gating network；2023 年另一项研究专门学习不同语言的声学边界。这些论文不是任何消费级 App 的准确率测试，但说明了一个关键事实：支持两种语言，与能处理句内混语，是两个不同能力。
发音也是问题。嵌入中文语流里的英文通常带着中文节奏和本地口音，缩写还可能逐字母念。2021 年关于中英混语 ASR 的研究就专门讨论了嵌入英文的发音变体。因此用标准英语朗读测试，很容易高估真实会议表现。
哪些词最值得优先检查？
第一类是短缩写。API、CRM、KPI、QA、PR 声音短、上下文少，模型一旦判断错语言，很容易变成近音词。更麻烦的是，错误后的句子可能依然通顺，快速浏览时不容易发现。
第二类是产品名、公司名、人名和内部项目代号。通用模型不可能认识每个企业内部的专有名词。如果文字后面还要进入知识库、CRM 或项目文档，拼错实体会直接影响搜索和归档。
第三类是数字、日期、金额、百分比和否定词。“15%”听成“50%”、“可以上线”与“不可以上线”，影响远大于标点错误。会议记录的质量应该按错误后果排序，而不是把所有错字视为同样严重。
混合语言应该怎么衡量准确率？
英文语音识别常用 WER，中文常用 CER；中英混语研究因此会使用 Mixed Error Rate 等混合指标。ASRU 2019 Mandarin-English Code-Switching Speech Recognition Challenge 就使用专门的混语数据和评测方式，而不是直接拿单语成绩拼在一起。
普通用户没必要复刻学术 benchmark。更实用的办法是提前建立“关键术语清单”：从一场会议里挑 20 至 50 个不能错的词，包括产品名、人名、公司名、缩写、数字、版本号和行动项，再看不同工具能正确保留多少。
同时把错误分成四类：内容识别错误、语言切换错误、说话人归属错误、格式错误。这样才能知道工具到底差在哪里，而不是只凭“这篇文字看起来挺顺”做判断。
怎么公平测试中英混说的会议录音转文字？
不要录几句刻意准备的双语句子。真正的会议有插话、口头禅、不完整句子、英语缩写、专有名词、远场收音和语速变化，这些才是需要解决的问题。
- 选 10–20 分钟真实录音直接取日常产品会、访谈、课程或跨国会议的一段，不要为了测试重新朗读。
- 先列关键术语记录人名、产品名、英文缩写、数字、日期和内部项目名，避免事后凭感觉评分。
- 所有工具使用同一文件只有音频完全相同，才能把差异归因于识别系统，而不是麦克风和环境。
- 先检查内容先看词、数字和说话人，再看标点、分段和界面，不要被漂亮排版干扰。
- 最后比较 AI 总结确认关键文字正确后，再判断总结有没有保留决定、负责人和下一步。
测试样本最好同时包含三种情况：中文句子嵌英文名词、完整英文短句、英文缩写。如果只测试“中间夹一个常见英文单词”，结论会过于乐观。
应该选择中文、英文还是自动识别？
工具如果明确提供 multilingual 或 mixed-language 模式，应先测试这种模式。但“自动语言识别”这个名称并不统一：有些产品只是先判断整个文件主要是什么语言，并不意味着每句话都能自由切换。
如果必须指定一种语言，就选会议占比最高的主要语言。例如 80% 中文、20% 英文术语，可以先选中文，然后重点核对英文部分。这个办法适合以一种语言为主的会议，不应直接套在接近五五开的双语讨论上。
Atter AI 支持 90+ 语言，可以作为多语言录音的候选工具之一。但语言数量只能说明覆盖范围，不能证明某一对语言的 code-switching 表现。最终仍应以自己的会议录音为准。
收音和多人抢话会不会比混语更影响结果？
会，而且几个问题经常叠加。会议室回声、远距离麦克风、电脑风扇、网络会议压缩和多人同时讲话，都会先降低声学信息质量；在声音本身已经模糊时，判断语言切换自然更困难。
所以测试不同工具必须固定原始文件。不能拿 A 工具测手机近讲、B 工具测会议室远场，再比较“混语准确率”。同一个音频、同一段时间、同一份人工答案，才有比较价值。
说话人分离也应该单独评分。一句话文字完全正确，却被分配给错误的人，对会议决策记录依然是严重问题。特别是承诺、审批和 action item，谁说的本身就是内容。
为什么一个英文词听错，AI 总结可能错得更多？
AI 会议总结通常读取逐字稿。如果上游把产品 A 写成产品 B、把 not 漏掉、把 15% 写成 50%，下游模型得到的就是错误事实。总结写得越流畅，反而越可能让人忽略底层问题。
重要会议更适合“先核对关键字段，再看总结”。人名、数字、日期、决定、负责人、截止时间和否定词应该优先确认。没必要逐字修改每个语气词，但会改变行动的错误不能放过。
这也意味着选工具时要把“转写忠实度”和“总结文笔”拆开。摘要好看，不等于录音转文字更准确。
98.7% 能代表真实混语会议吗？
不能。Atter AI 的 98.7% 是干净音频条件下的已验证准确率，不能外推到每场中英混说、多人重叠、远场或高噪声会议。任何准确率数字都必须结合测试条件理解。
研究界专门建立 CS-Dialogue、TALCS、SEAME 和 ASRU 混语数据，也是因为单语 benchmark 不足以回答 code-switching 问题。CS-Dialogue 特别强调自然、完整对话，而不是孤立的人工双语句子。
企业评估时，可以按自己的错误成本加权。财务会议重点看数字和否定词，软件团队重点看 API、仓库名和产品名，客户访谈则可能更在意姓名、品牌和说话人。不同场景的“最好工具”并不一定相同。
怎么提高中英混说逐字稿的可用性？
先改善录音。让麦克风离说话人更近、减少回声、避免多人共用远处的笔记本麦克风，通常能给所有识别系统更好的输入。其次维护团队术语表，把固定的人名、产品名、缩写和项目代号集中起来。
如果工具支持自定义词汇，可以使用术语表；即使不支持，术语表也能显著加快人工检查。不要要求团队为了 AI 刻意把英文念成播音腔，那样测试出来的不是实际工作环境。
最后把转写验收与总结验收分开。先问“文字是否忠于录音”，再问“总结是否有用”。这是避免被流畅生成文本误导的简单办法。
什么时候应该换一个录音转文字工具？
偶尔标点不理想通常不值得迁移。如果工具持续把核心英文术语、产品名、数字或说话人弄错，而且这些内容还要进入正式记录，就应该用同一音频测试替代方案。
可以继续使用当前工具
- 关键中英文术语能稳定保留
- 错误容易定位和修改
- 说话人归属足以支持会议记录
- 同一录音结果比较稳定
值得测试其他工具
- 产品名和缩写反复被改写
- 数字、否定词或人名经常出错
- 多人讨论的说话人标记混乱
- 校对时间已经接近人工整理
真正有用的标准不是哪家写着“支持更多语言”，而是哪家在你的音频、你的词汇和你的会议流程里产生更少的高成本错误。
中英混说会议的检查清单
拿到文字后，先搜索所有英文大写缩写，再核对产品名、人名、日期、百分比、金额和版本号。接着抽查每个语言切换点前后 5 至 10 秒，观察是否有吞字、重复、音译或错误切换文字系统。
然后检查多人重叠和说话人标签。最后才处理标点、段落和视觉格式。如果你更担心的是地方口音而不是语言切换，可以继续看口音会影响 AI 录音转文字吗。
常见问题
AI 能把中英混说的会议转成文字吗？
可以，但必须测试句内切换，而不是只看产品是否分别支持中文和英文。真实会议中的缩写、产品名和自然发音更有参考价值。
为什么中英混说比纯中文更容易转错？
系统要同时处理语音、语言边界和两套词汇概率。嵌入英文的本地化发音与混语数据不足还会进一步增加难度。
怎么测试多语言会议录音转文字？
用相同的 10 至 20 分钟真实录音测试所有工具，提前列关键术语，并分别记录内容、切换点、说话人和格式错误。
中英混说应该选择中文还是自动识别？
有明确混语模式时优先使用。若只能选一种语言，就选主要语言，并重点检查另一种语言的片段。
转写错误会不会影响 AI 会议总结？
会。错误的数字、产品名、否定词和决定会成为总结的输入，因此重要信息应该在生成或采纳总结前核对。
98.7% 准确率适用于中英混说会议吗？
不能直接套用。该数字只对应 Atter AI 已验证的干净音频条件，真实混语会议应单独测试。