基于腾讯云AI语音识别的会议纪要自动化方案：实时转写与说话人分离实战

1. 会议记录这件事，到底卡在哪儿了

开会这件事，但凡在职场待过几年的人都有体会。真正让人头疼的往往不是开会本身，而是会后那一堆烂摊子：谁说了什么、哪个节点要交付、哪条需求被否决了，全靠脑子记或者手打。我见过太多团队，会开得热热闹闹，散会之后一片空白，等到要复盘的时候，大家各执一词，谁也说不清当时到底定了什么。

早几年我的做法很原始，就是拿个本子边听边记，结果发现根本跟不上语速，尤其是多人讨论的时候，你一句我一句，笔头再快也白搭。后来改用录音笔，会后再听一遍整理，问题是两小时的会，整理成文字得花三四个小时，效率低到让人崩溃。再后来市面上出现了一些语音转文字的工具，我陆陆续续试过不少，要么识别率感人，要么对中文口语和行业术语支持得稀烂，要么就是按分钟计费贵得离谱。

直到我开始认真研究腾讯云 AI 语音识别这套东西，才算是找到了一个相对靠谱的解法。这篇文章我想聊的，就是怎么用腾讯云的语音识别能力，从零搭一个属于自己的会议小帮手——它能实时把会议语音转成文字，能区分不同说话人，能自动整理成结构化的会议纪要，甚至还能把关键结论提取出来。整套方案的核心关键词就是：语音识别、实时转写、说话人分离、会议纪要自动化。

这套东西适合谁看？如果你是个开发者，想给自己的团队做个内部工具，那这篇基本可以照着抄；如果你是个产品或者项目负责人，不懂代码但想搞清楚这套方案的可行性和成本，也能看明白；就算你只是想找个办法把自己每天的会议记录自动化，这里面的思路同样适用。我不打算讲太多虚的，重点放在怎么落地、踩过哪些坑、参数怎么调这些实打实的东西上。

2. 整体方案怎么设计，为什么这么选

2.1 先想清楚：会议小帮手到底要解决什么问题

在动手之前，我习惯先把需求拆干净。一个会议小帮手，听起来简单，实际上要解决的问题可以分成好几层。

最基础的一层是把声音变成文字，也就是语音转写。这一层看着简单，但会议场景特别难搞：多人同时说话、口音五花八门、还有各种专业术语和英文缩写，普通识别引擎很容易翻车。

第二层是知道谁在说，也就是说话人分离。一场会有五六个人发言，如果转出来的文字是一大坨，根本没法看。必须能标出"说话人1""说话人2"，最好还能对应到具体的人名。

第三层是把文字整理成有用的东西。光有逐字稿没用，谁有空看两万字的流水账？真正有价值的是结构化的纪要：议题是什么、结论是什么、待办事项有哪些、谁负责、什么时候交付。

第四层是实时性。理想情况下，会议开着，文字就同步出来了，散会的时候纪要基本成型，而不是等半天才出结果。

把这四层想清楚，方案的设计方向就明确了。我最终选的是腾讯云实时语音识别 + 说话人分离 + 后处理结构化的组合，下面说说为什么这么选。

2.2 为什么是腾讯云，而不是自己搭模型

有人可能会问，现在开源语音识别模型那么多，为什么不自己部署一个？我认真评估过这条路，结论是：除非你有专门的算法团队和充足的算力，否则不划算。

自己搭模型的问题在于，语音识别这东西，模型只是冰山一角。真正难的是声学模型、语言模型、热词定制、口音适配这一整套工程。你部署一个开源模型，在标准普通话测试集上可能表现不错，但一放到真实会议场景，各种背景噪音、多人交叠、行业黑话，识别率立马掉一大截。而且你还得自己维护服务、处理并发、做容灾，这些都是隐形成本。

腾讯云这套语音识别服务，我实测下来有几个明显的优势。第一是中文识别准确率高，尤其是对口语化表达和常见行业术语的支持比较到位。第二是支持热词定制，你可以把公司内部的产品名、项目代号、专业术语加进去，识别率能明显提升。第三是实时流式识别做得比较成熟，延迟低，适合会议这种需要边开边转的场景。第四是说话人分离能力，这个对会议纪要来说太关键了。

当然，选它也不是没有代价。它是按用量计费的，会议多的话成本要算清楚。另外它是云服务，涉及到数据出本地的问题，如果会议内容特别敏感，得提前评估合规性。这些后面我会专门讲。

2.3 整套方案的架构长什么样

我把整个会议小帮手拆成了四个模块，用一张表说清楚每个模块干什么、用什么技术。

模块	职责	关键技术/服务
音频采集	从麦克风或会议系统抓取音频流	本地录音、系统音频回环
实时转写	把音频流实时转成文字	腾讯云实时语音识别
说话人分离	区分不同发言人	腾讯云说话人分离能力
纪要生成	把逐字稿整理成结构化纪要	文本后处理、关键词提取

数据流向是这样的：音频采集模块把声音切成一小段一小段（通常是 40ms 到 100ms 一帧），通过 WebSocket 推给腾讯云的实时识别接口，接口一边识别一边把结果推回来。识别结果里带着时间戳和说话人标签，我在本地把这些片段按时间顺序拼起来，再交给后处理模块做结构化。

这里有个设计上的取舍值得说一下。实时识别和录音文件识别，我最终选了实时。录音文件识别是等整段音频传完再识别，准确率通常更高，但延迟大，散会才能出结果。实时识别是边说边转，延迟低，但因为是流式的，模型能看到的上下文有限，准确率会略低一点。对会议场景来说，我更需要"边开边看"的体验，所以选了实时。如果你的会议不要求实时性，用录音文件识别反而更省事、更准。

2.4 成本这块得提前算明白

云服务这东西，用起来爽，账单来了可能就笑不出来了。我大概算过一笔账，腾讯云实时语音识别是按音频时长计费的，具体单价会随活动和套餐变化，这里不写死数字，但可以给个估算方法。

一场一小时的会议，音频时长就是 60 分钟。如果一天开三场会，一个月按 22 个工作日算，就是 60 × 3 × 22 = 3960 分钟，差不多 66 小时。这个量级下，成本是可控的，但如果整个公司几百号人都用，那就得好好规划了。

省钱有几个思路。一是只在需要的时候开启识别，不是所有会都值得记录，站会、闲聊会就别开了。二是做好音频预处理，把静音段、噪音段过滤掉，减少无效时长。三是关注套餐和阶梯计价，用量大的话走预付费套餐通常比按量付费便宜。这些细节后面实操部分会展开。

3. 核心细节拆解：每个环节的坑在哪

3.1 音频采集：别小看这一步，坑最多

很多人以为音频采集就是打开麦克风录个音，实际上这一步是整个链路里最容易出问题的地方。我踩过的坑包括：麦克风增益没调好导致声音忽大忽小、采样率不匹配导致识别率暴跌、多路音频混流导致说话人分离失效。

先说采样率。腾讯云实时语音识别对输入音频的采样率有要求，常见的是 16000Hz 单声道 16bit。如果你用系统默认的 44100Hz 立体声直接推过去，识别率会明显下降，因为服务端还得做重采样，中间可能引入失真。我的做法是在采集端就统一转成 16000Hz 单声道，用音频处理库做重采样，保证推给云端的音频格式是干净的。

再说声道。会议场景如果是多人共用一个麦克风，那单声道就够了，说话人分离靠的是声纹特征，不是声道。但如果是每个人一个麦克风，那可以考虑多路采集，不过这样说话人分离反而简单了，直接按麦克风来源标人就行。我一般推荐单麦克风方案，部署简单，成本低。

还有音频帧的大小。实时识别是流式的，你得把音频切成小帧推过去。帧太小，网络请求太频繁，开销大；帧太大，延迟高，实时性差。我实测下来，每帧 40ms 到 100ms是个比较舒服的区间，我一般用 40ms，兼顾延迟和开销。

注意：采集端一定要做回声消除和降噪。如果会议是用音箱外放的，麦克风会把音箱的声音也录进去，形成回声，识别出来就是一堆重复的废话。用带 AEC（回声消除）的音频库处理一下，效果立竿见影。

3.2 实时转写：参数怎么调才不翻车

腾讯云实时语音识别的接口，参数不少，我挑几个最关键的说说。

引擎模型的选择很重要。腾讯云提供了好几种引擎，有针对通用场景的，有针对电话场景的，还有针对视频字幕的。会议场景我一般选通用引擎，它对口语和多人对话的适配比较好。如果你的会议有大量专业术语，记得开热词表，把术语加进去，识别率能提升不少。

VAD（静音检测）这个参数值得单独说。VAD 的作用是自动检测音频里哪段是说话、哪段是静音。开了 VAD，静音段就不会被送去识别，既省流量又省费用。但 VAD 的灵敏度要调好，太灵敏了会把说话间隙也当成静音，导致断句奇怪；太迟钝了又会把噪音当成说话，识别出一堆乱码。我一般把 VAD 的静音阈值设在中等偏上的位置，具体值得根据你的会议室环境实测。

标点预测建议开启。会议逐字稿如果没有标点，读起来简直是灾难。腾讯云的标点预测做得还不错，能自动加逗号句号问号，虽然偶尔会加错，但比没有强太多。

中间结果这个特性也很有用。实时识别会先返回中间结果（可能还会变），再返回最终结果。中间结果适合做实时字幕展示，最终结果适合做纪要存档。我在做会议小帮手的时候，界面上展示的是中间结果，让参会的人能实时看到，后台存的是最终结果，保证准确性。

3.3 说话人分离：会议纪要的灵魂

说话人分离是我认为整个方案里最有价值也最难搞的部分。没有它，逐字稿就是一团乱麻；有了它，纪要才能对应到人。

腾讯云的说话人分离，原理是基于声纹特征做聚类。简单说，就是提取每段语音的声学特征，把相似的归为一类，每一类就是一个说话人。它不需要你提前录入每个人的声纹，是自动聚类的，这点很方便。

但它有几个限制得知道。第一，说话人数量不能太多，一般支持到 10 个左右，超过就容易混。第二，说话人不能同时说话，如果两个人抢话，声纹叠在一起，分离就会出错。第三，每个人的说话时长要够，如果某人只说了两个字，声纹特征不够，可能识别不出来或者归错类。

我的应对策略是：会前尽量约定好发言秩序，别抢话；如果实在分不出来，就在后处理阶段人工修正，把明显的错误改掉。另外，说话人分离出来的标签是"说话人1""说话人2"，你得自己做个映射表，把它对应到真实人名。这个映射可以基于发言内容猜，也可以让参会的人会后再确认一遍。

3.4 纪要生成：从逐字稿到有用信息

逐字稿转出来了，说话人也分好了，但这还只是原材料。真正让会议小帮手有价值的是把逐字稿变成结构化纪要。

我的做法是分三步走。第一步是分句和分段，把连续的发言按语义切成一段一段，每段对应一个议题或者一个观点。第二步是关键词提取，把每段里的核心词、数字、时间点抓出来，这些往往是结论和待办。第三步是结构化输出，把内容整理成"议题—讨论—结论—待办"这样的格式。

关键词提取这块，我一开始想用大模型来做，后来发现对于会议纪要这种场景，规则 + 关键词表的组合反而更稳定。比如"下周""月底""之前"这些时间词，"负责""跟进""确认"这些动作词，用规则匹配就能抓得八九不离十。大模型适合做更复杂的语义理解，但成本和延迟都更高，看你的需求取舍。

这里有个小技巧：把会议纪要的模板固定下来。比如每次都是"会议主题、参会人、议题列表、决议事项、待办清单"这几个部分，后处理的时候按模板填充，输出就整齐了。模板固定了，甚至可以做成自动化的，散会五分钟内纪要就发到群里。

4. 实操过程：从零搭一个能跑的版本

4.1 环境准备和依赖安装

先说环境。我用的是 Python，因为生态成熟，音频处理和网络请求的库都很全。核心依赖有这么几个：

pip install websocket-client pip install pyaudio pip install numpy pip install webrtcvad

websocket-client用来和腾讯云的实时识别接口通信，pyaudio负责音频采集，numpy做音频数据的处理，webrtcvad做静音检测。如果你在 Linux 上跑，pyaudio可能需要先装portaudio的系统库，这个用包管理器装一下就行。

腾讯云这边，你需要先在控制台开通语音识别服务，拿到SecretId和SecretKey，这两个是调用接口的凭证。注意这俩东西千万别硬编码在代码里，用环境变量或者配置文件管理，不然泄露了很麻烦。

提示：开通服务后，建议先在控制台用它的在线体验功能试一段音频，确认服务正常、识别效果符合预期，再动手写代码。这样能排除掉很多环境问题。

4.2 音频采集模块的实现

音频采集这块，核心是把麦克风的声音读进来，转成符合要求的格式，切成小帧。下面是我用的核心代码逻辑：

import pyaudio import numpy as np CHUNK = 640 # 40ms @ 16000Hz FORMAT = pyaudio.paInt16 CHANNELS = 1 RATE = 16000 audio = pyaudio.PyAudio() stream = audio.open( format=FORMAT, channels=CHANNELS, rate=RATE, input=True, frames_per_buffer=CHUNK ) while True: data = stream.read(CHUNK, exception_on_overflow=False) # data 就是 40ms 的音频帧，可以直接推给识别接口

这里CHUNK设成 640，是因为 16000Hz 采样率下，40ms 正好是 640 个采样点，每个采样点 16bit（2 字节），所以一帧是 1280 字节。这个大小推给云端比较合适。

如果你要做回声消除和降噪，可以在stream.read之后加一层处理。Python 里可以用speexdsp或者webrtcaec这类库，效果比裸采集好很多。我实测下来，加了 AEC 之后，外放场景的识别率能提升一大截。

4.3 对接实时识别接口

对接腾讯云实时识别，核心是建立一个 WebSocket 连接，然后把音频帧一帧一帧推过去。下面是我简化后的代码框架：

import websocket import json import hashlib import hmac import base64 import time import urllib.parse def build_url(secret_id, secret_key, engine_model): # 构造鉴权参数 params = { "secretid": secret_id, "engine_model_type": engine_model, "voice_format": 1, # 1 表示 PCM "needvad": 1, "filter_dirty": 0, "filter_modal": 0, "filter_punc": 0, "convert_num_mode": 1, "word_info": 0, "timestamp": int(time.time()) } # 签名逻辑略，按官方文档实现 # ... return "wss://asr.cloud.tencent.com/asr/v2/..." + "?" + urllib.parse.urlencode(params) ws = websocket.WebSocketApp(url, on_message=on_message, on_error=on_error) ws.run_forever()

on_message回调里处理识别结果。返回的 JSON 里，result字段是识别出来的文字，index是序号，start_time和end_time是时间戳。如果是最终结果，final字段是 1；如果是中间结果，final是 0。

我处理结果的时候，会把中间结果和最终结果分开存。中间结果用来实时展示，最终结果用来存档。这样界面上能看到字在跳，但存下来的稿子是稳定的。

4.4 说话人分离的接入

说话人分离在腾讯云这边，是在识别请求里开一个参数。开了之后，返回的结果里会多一个speaker_id字段，标识这段话是哪个说话人说的。

需要注意的是，说话人分离的speaker_id是动态分配的，同一场会议里，"说话人1"始终是同一个人，但不同会议之间，"说话人1"可能是不同的人。所以你得在会后做一次映射，把speaker_id对应到真实人名。

映射的方法，我一般是用发言内容 + 时长来猜。比如某段发言里提到了"我负责后端"，而你知道后端是谁，那就能对上。或者某个人发言特别多，时长最长，那大概率是主持人。猜完之后，让参会的人确认一遍，就准了。

4.5 后处理：把逐字稿变成纪要

后处理这块，我写了一个简单的规则引擎。核心逻辑是：

1. 按speaker_id和时间戳，把识别结果拼成完整的对话流。
2. 用正则匹配时间词、动作词、数字，标记出可能是待办或结论的句子。
3. 按议题切分，把相关的讨论归到一起。
4. 按模板输出结构化纪要。

下面是一个简化的待办提取逻辑：

import re ACTION_WORDS = ["负责", "跟进", "确认", "完成", "提交", "对接"] TIME_WORDS = ["下周", "月底", "之前", "明天", "本周内"] def extract_todos(text): todos = [] sentences = re.split(r"[。！？]", text) for sent in sentences: has_action = any(w in sent for w in ACTION_WORDS) has_time = any(w in sent for w in TIME_WORDS) if has_action and has_time: todos.append(sent.strip()) return todos

这个逻辑很朴素，但实测下来对会议场景够用了。如果你想要更智能的，可以接一个大模型做语义理解，但成本和延迟都会上去，看你的取舍。

4.6 一个完整的运行流程

把上面这些串起来，一次完整的会议记录流程是这样的：

1. 会前，启动会议小帮手，输入会议主题和参会人名单。
2. 会议开始，音频采集模块开始工作，实时把音频帧推给识别接口。
3. 识别结果实时返回，界面上展示带说话人标签的实时字幕。
4. 会议结束，停止采集，等待最后几帧的识别结果返回。
5. 后处理模块把逐字稿整理成结构化纪要，提取待办事项。
6. 纪要输出到指定位置，可以发邮件、发群、存文档。

整个流程跑下来，一场一小时的会，散会后大概一两分钟就能拿到纪要初稿，比人工整理快太多了。

5. 常见问题与排查技巧实录

5.1 识别率低，问题出在哪

识别率低是最常见的问题，原因可能有很多。我整理了一个排查表，按可能性从高到低排：

现象	可能原因	排查方法
整体识别率低	音频采样率或格式不对	检查是否 16000Hz 单声道 16bit
专业术语识别错	没开热词表	把术语加入热词表重新测试
断句奇怪	VAD 灵敏度不对	调整 VAD 阈值，实测对比
多人对话识别乱	说话人交叠	约定发言秩序，避免抢话
外放场景识别差	回声干扰	开启 AEC 回声消除

我的经验是，先排查音频格式，再排查环境噪音，最后才怀疑模型。大部分识别率问题，都是音频采集环节没做好，而不是云端模型不行。

5.2 延迟高，实时性差怎么办

实时识别的延迟，主要来自三个地方：音频帧大小、网络传输、服务端处理。

音频帧太大，推得就慢。我一般用 40ms 一帧，如果你用 200ms 一帧，延迟自然就上去了。网络这块，尽量用有线网络，WiFi 抖动大的话延迟会很明显。服务端处理这块，你控制不了，但可以选离你近的接入点，减少网络往返。

还有一个容易被忽略的点：中间结果的展示策略。如果你等最终结果才展示，那延迟就是整个识别周期；如果你展示中间结果，用户感觉到的延迟就低很多。我一般界面上展示中间结果，让用户觉得"字在实时跳"，体验好很多。

5.3 说话人分离不准怎么修

说话人分离不准，通常有几个原因。一是说话人太多，超过 10 个就容易混；二是有人抢话，声纹叠在一起；三是某人说话太短，声纹特征不够。

修复的思路，一是会前约定发言秩序，这是最有效的；二是会后人工修正，把明显的错误改掉；三是结合其他信息辅助判断，比如发言内容里提到了自己的名字或职位，可以用来校正。

我实测下来，如果会议秩序好，说话人分离的准确率能到 90% 以上；如果大家抢话，那准确率就掉得厉害。所以这东西，技术是一方面，会议纪律也是一方面。

5.4 成本超预期怎么控制

成本超预期，通常是两个原因：一是用量没控制好，二是没选对计费方式。

用量控制这块，我建议按需开启，不是所有会都值得记录。另外，VAD 一定要开，静音段不送去识别，能省不少时长。计费方式这块，用量大的话走预付费套餐，比按量付费便宜不少，具体可以咨询腾讯云的商务。

还有一个省钱的思路：分级处理。重要的会，用实时识别 + 说话人分离，全套上；不重要的会，用录音文件识别，会后批量处理，成本低很多。

5.5 数据安全怎么保障

会议内容往往涉及公司内部信息，数据安全不能马虎。用云服务，数据要传到云端处理，这个得提前评估。

我的做法是：敏感会议不用云服务，或者用私有化部署的方案。腾讯云这边也提供私有化部署的选项，但成本高很多，适合对数据安全要求极高的场景。另外，传输过程一定要用加密通道，存储的纪要也要做权限控制，别谁都能看。

注意：如果会议涉及个人隐私信息，比如客户名单、联系方式，转写和存储都要特别小心，最好做脱敏处理，或者干脆不记录这部分内容。

6. 几个让体验更好的进阶技巧

6.1 热词表怎么维护才有效

热词表是提升识别率的利器，但维护不好反而添乱。我的经验是：热词要精不要多。加太多热词，模型会过度偏向这些词，反而把正常的词识别错。

我一般只加三类词：公司内部的产品名和项目代号、行业专业术语、参会人的名字。每加一批，都要实测对比识别率，确认有提升才保留。热词表要定期清理，过期的项目代号就删掉，别一直堆着。

6.2 实时字幕的展示优化

实时字幕如果只是把文字堆上去，体验很差。我做了几个优化：一是按说话人分色，不同人用不同颜色，一眼能看出谁在说；二是自动滚动，新内容出来自动滚到底部；三是高亮关键词，把待办、数字、时间点高亮出来，方便快速抓重点。

这些小优化看着不起眼，但实际用起来体验提升很明显。尤其是分色展示，开会的时候大家看着屏幕，谁说了什么一目了然。

6.3 纪要模板的定制

纪要模板不要千篇一律，不同类型的会，模板应该不一样。项目例会，重点是待办和进度；决策会，重点是结论和依据；头脑风暴，重点是点子和想法。

我一般准备几套模板，会前选一套，后处理的时候按模板填充。模板固定了，输出就整齐，也方便后续检索和归档。

6.4 和现有工具的集成

会议小帮手做出来，别让它孤立着。我把它和团队的日历、文档、即时通讯工具做了集成：会前自动从日历拉取会议信息和参会人，会后自动把纪要存到文档库、发到群里。这样整个流程就闭环了，不用手动搬运。

集成这块，各家工具都有 API，对接起来不难。关键是想清楚数据怎么流转，别搞得太复杂，够用就行。

7. 我踩过的那些坑，你别再踩

7.1 别一上来就追求全自动

我一开始的设想是，会议全程无人值守，散会自动出纪要。实际做下来发现，全自动在现阶段不现实。识别会出错，说话人会分错，待办会漏掉，这些都需要人工兜底。

我的建议是，先做半自动：机器负责转写和初步整理，人负责校对和补充。等人用顺了，再逐步把稳定的环节自动化。这样落地阻力小，效果也实在。

7.2 音频质量是天花板

这句话我反复强调：音频质量决定了识别率的上限。你云端模型再强，如果采集的音频一团糟，识别出来也是垃圾。所以别在麦克风上省钱，一个好的会议麦克风，能省掉后面无数的麻烦。

我实测过，同一个识别服务，用笔记本内置麦克风和用专业会议麦克风，识别率能差 20% 以上。这个差距，靠调参数是补不回来的。

7.3 别忽略会议纪律

技术能解决很多问题，但解决不了"大家抢着说话"。说话人分离再强，两个人同时说，它也分不出来。所以推动团队养成好的会议习惯，比优化技术更有效。

我一般会在会前说一句："咱们尽量一个一个说，方便记录。"就这么一句话，识别效果能好很多。

7.4 成本要持续监控

云服务的账单，不监控的话很容易失控。我建议做一个简单的用量看板，每天看看识别时长、调用次数，发现异常及时排查。有时候是程序 bug 导致重复调用，有时候是有人忘了关，这些都能通过监控发现。

7.5 数据备份别偷懒

识别结果和纪要，一定要做备份。云服务偶尔会抖动，网络偶尔会断，如果没备份，一场会的记录就没了。我一般本地存一份，云端存一份，双保险。

8. 后续还能怎么扩展

这套会议小帮手跑通之后，能扩展的方向其实挺多的。

一个是多语言支持。腾讯云的语音识别支持多种语言，如果团队有跨语言的会议，可以加上语言自动检测和翻译，纪要直接出双语版本。

另一个是和知识库打通。会议里提到的项目、需求、决策，可以自动关联到知识库里的相关文档，形成知识网络。这样以后检索的时候，能顺着会议记录找到相关的所有资料。

还有就是做会议分析。统计每个人的发言时长、发言次数，分析会议的讨论热点，这些数据对团队管理挺有价值的。当然，这个要谨慎，别搞成监控，得把握好度。

我自己目前是把这套东西用在了团队的日常例会上，跑了大半年，稳定性还不错。最大的感受是，会议记录这件事，从"负担"变成了"顺手"。以前散会之后大家各回各家，现在散会五分钟纪要就出来了，谁该干什么清清楚楚，扯皮的事少了很多。

如果你也想搭一套，我的建议是从小场景开始，先在一个小团队、一种会议类型上跑通，再逐步推广。别一上来就搞大而全，容易烂尾。技术这东西，能用起来、用得住，比功能多更重要。