1. 为什么我要做这个会议小帮手开会这件事最让人头疼的不是讨论本身而是会后那一堆没人整理的录音。一场两小时的会议录音文件躺在手机里谁都不想点开重听一遍。更麻烦的是领导突然来一句“上次会议那个结论是什么来着”你只能尴尬地翻聊天记录。我试过用手机自带的录音转文字准确率感人方言和口音一混进来直接崩盘。后来折腾了几套方案最终用腾讯云 AI 语音识别搭了一个自动化的会议小帮手从录音上传到文字稿输出全程不用手动干预。这个项目的核心思路很简单把会议录音丢进去自动切分、识别、整理成带时间戳和发言人的文字稿最后输出一份可以直接复制到文档里的会议纪要草稿。它解决的是“录音没人听、纪要没人写”这个老大难问题。适合谁参考经常需要整理会议记录的产品经理、项目经理、行政人员或者想给自己团队搭一套内部工具的后端开发者。哪怕你只会一点 Python 基础跟着做也能跑通。腾讯云 AI 语音识别在这套方案里扮演的是“耳朵”的角色负责把音频转成文字。但光有耳朵不够还得有“大脑”去处理分段、去重、格式化。所以整个项目其实是语音识别加后处理的组合拳。我踩过的坑主要集中在音频格式兼容、长音频切分、识别结果标点混乱这几个地方后面会一个个拆开讲。2. 整体方案设计与技术选型拆解2.1 为什么选腾讯云 AI 语音识别而不是本地模型一开始我试过本地部署开源语音识别模型比如 Whisper 系列。效果确实不错但有两个硬伤一是对硬件要求高一台普通办公电脑跑长音频推理慢得让人想砸键盘二是中文标点和数字规范化做得不够好识别出来的文字像一坨没有断句的流水账。腾讯云 AI 语音识别的优势在于开箱即用中文识别准确率高自带标点预测和数字转换而且支持热词表定制。对于会议场景里常见的专业术语、人名、产品名可以通过热词表提前注入识别准确率能明显提升。另一个考虑是成本。本地模型看似免费但算上电费、硬件折旧和维护时间其实并不便宜。腾讯云按量计费一场两小时的会议录音识别费用大概几毛钱到一块多对于中小团队来说完全可以接受。而且它支持多种音频格式直接上传不需要我先用 ffmpeg 转码省了一步操作。2.2 系统架构的四个核心模块整个会议小帮手我拆成了四个模块每个模块各司其职音频预处理模块负责检查音频格式、采样率、声道数必要时做转码和降噪。会议录音常见的是手机录的 m4a 或者电脑录的 wav采样率参差不齐直接上传有时候会报错。语音识别调度模块调用腾讯云 AI 语音识别的接口处理长音频的分片上传和结果合并。这里要注意接口对单次请求的音频时长有限制超过限制需要切分。文本后处理模块对识别结果做标点修复、重复词去除、语气词过滤以及按时间戳合并相邻句子。输出与归档模块把处理好的文字稿保存为 Markdown 或 Word 文档同时把原始音频和识别结果归档到指定目录方便后续检索。这四个模块串起来就是一条流水线录音文件进去会议纪要草稿出来。中间任何一个环节出问题都会影响最终效果所以每个模块的容错设计都很重要。2.3 长音频切分的策略选择腾讯云 AI 语音识别的实时识别和一句话识别对音频时长有不同限制会议场景通常用的是录音文件识别支持长音频但也不是无限长。我的做法是先把超过 60 分钟的音频按静音段切分而不是按固定时长硬切。为什么按静音段切因为如果正好切在一句话中间识别结果就会断成两半后处理的时候还得想办法拼回去非常麻烦。用静音检测来切分能保证每段音频的边界落在自然停顿处识别出来的文字段落也更符合语义。具体实现上我用的是 pydub 库的split_on_silence方法设置最小静音长度为 700 毫秒静音阈值根据实际录音环境调整。会议室录音通常底噪比较稳定阈值设在 -40dB 左右比较合适。如果录音环境嘈杂阈值要往上调否则会把说话间隙误判为静音导致切得太碎。3. 核心细节解析与实操要点3.1 音频格式兼容性处理腾讯云 AI 语音识别支持的音频格式包括 wav、mp3、m4a、aac 等但并不是所有编码方式都兼容。我遇到过手机录的 m4a 文件上传后返回格式错误后来发现是采样率的问题。手机录音默认可能是 48kHz而接口对某些格式要求 16kHz。解决办法是用 ffmpeg 统一转成 16kHz、16bit、单声道的 wav 文件。这个转换过程虽然多了一步但能避免后续很多莫名其妙的报错。转码命令我一般这么写ffmpeg -i input.m4a -ar 16000 -ac 1 -sample_fmt s16 output.wav参数解释一下-ar 16000设置采样率为 16kHz-ac 1设置单声道-sample_fmt s16设置采样格式为 16 位有符号整数。这三个参数是保证兼容性的关键。转码完成后我会用ffprobe检查一下输出文件的参数确认无误再上传。注意转码会损失一部分音质但对于语音识别来说16kHz 采样率已经足够覆盖人声频率范围。不要为了追求音质保留高采样率反而可能因为文件过大导致上传超时。3.2 热词表的配置技巧会议场景里经常出现公司内部术语、产品代号、人名这些词在通用语音识别模型里往往识别不准。腾讯云 AI 语音识别支持热词表功能可以提前把这些词加进去提升识别准确率。热词表的配置有几个技巧第一热词不要贪多。我一开始把能想到的词全塞进去了结果发现有些词反而识别错了。后来才明白热词表相当于给模型一个“偏向性提示”如果热词太多太杂模型会过度偏向这些词导致正常词汇被误识别。一般建议热词数量控制在 50 个以内只放那些确实容易识别错的专有名词。第二热词权重可以调整。腾讯云的热词表支持设置权重权重越高模型越倾向于识别成这个词。对于特别重要的产品名我会把权重设高一些对于一般性术语权重设低一些。具体权重值需要根据实际效果微调我一般从默认值开始识别效果不好的词逐步往上加。第三热词表要定期更新。项目迭代过程中会出现新的产品名和术语旧的热词表需要及时补充。我习惯每个月回顾一次识别错误率高的词把它们加到热词表里。3.3 识别结果的后处理逻辑语音识别出来的原始文本有几个典型问题标点符号缺失或错乱、语气词过多、重复词频繁、数字格式不统一。后处理模块就是来解决这些问题的。标点修复我用的是基于规则的方法。识别结果里通常会有逗号和句号但问号和感叹号经常缺失。我的做法是检测疑问词比如“吗”“呢”“吧”“对不对”“是不是”出现在句尾时自动把句号替换成问号。感叹号则根据情感词来判断比如“太好了”“没问题”“必须的”这类词后面加感叹号。语气词过滤比较简单维护一个语气词列表比如“嗯”“啊”“那个”“就是说”“然后呢”把这些词从文本里删掉。但要注意有些语气词在特定语境下是有意义的比如“然后”在描述流程时不能删。所以我设置了一个规则只有当语气词出现在句首或连续出现两次以上时才删除。重复词处理是个麻烦事。语音识别有时候会把一个词重复输出比如“我们我们觉得”。我的做法是用正则表达式检测连续重复的词组如果重复次数超过两次就保留一次。但像“好好好”这种表达强烈同意的重复需要保留所以规则要结合上下文判断。数字格式统一也很重要。识别结果里可能同时出现“一百二十三”和“123”我会统一转成阿拉伯数字方便后续阅读和检索。但像“第一”“第二”这种序数词保持中文格式因为转成“第1”“第2”反而奇怪。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说一下我的运行环境Python 3.9操作系统是 LinuxWindows 和 macOS 也能跑但路径处理上要注意兼容性。依赖库主要有这几个pip install tencentcloud-sdk-python pip install pydub pip install ffmpeg-pythontencentcloud-sdk-python是腾讯云官方 SDK封装了语音识别接口的调用逻辑。pydub用来做音频切分和格式转换它底层依赖 ffmpeg所以系统里要先装好 ffmpeg。ffmpeg-python是 ffmpeg 的 Python 封装方便在代码里调用转码命令。安装完成后需要在腾讯云控制台创建语音识别服务获取 SecretId 和 SecretKey。这两个密钥不要硬编码在代码里我一般用环境变量或者配置文件来管理。配置文件格式如下{ secret_id: your_secret_id, secret_key: your_secret_key, region: ap-guangzhou }region 选择离你最近的区域延迟会低一些。我选的是广州因为团队主要在南方。4.2 音频预处理模块的实现预处理模块的入口是一个函数接收音频文件路径输出处理后的 wav 文件路径。核心逻辑分三步第一步检查文件是否存在以及格式是否支持。我用os.path.splitext获取扩展名如果不在支持列表里直接抛异常提示用户。第二步用 ffprobe 获取音频的采样率、声道数、时长信息。如果采样率不是 16kHz 或者声道数不是 1就调用 ffmpeg 转码。转码后的文件临时存放在一个temp目录里处理完再删除。第三步如果音频时长超过 60 分钟调用切分函数。切分函数用 pydub 读取音频然后按静音段切分。切分后的文件命名规则是“原文件名_part1.wav”“原文件名_part2.wav”方便后续按顺序合并识别结果。这里有个细节要注意pydub 读取大文件时内存占用比较高如果音频超过两小时建议先用 ffmpeg 切成固定时长的片段再用 pydub 做静音检测。我一般设置每段不超过 30 分钟这样内存压力小切分速度也快。4.3 语音识别接口调用与结果合并调用腾讯云 AI 语音识别的录音文件识别接口流程是先创建识别任务然后轮询任务状态最后获取识别结果。创建任务时需要传几个关键参数EngineModelType引擎模型类型中文会议场景我选的是16k_zh如果是英文会议选16k_en。ChannelNum声道数单声道传 1。ResTextFormat返回结果格式我选的是 0表示返回带时间戳的详细结果。HotwordList热词表格式是“热词|权重”多个热词用逗号分隔。创建任务后接口会返回一个 TaskId。然后用这个 TaskId 去查询任务状态直到状态变成“成功”或“失败”。查询间隔我设置的是 5 秒太频繁了浪费请求次数太慢了又影响效率。一般 10 分钟以内的音频2 到 3 次查询就能拿到结果。拿到识别结果后需要把多个分片的识别结果合并。合并逻辑是按分片顺序拼接文本同时调整时间戳。比如第一个分片的时间戳是 0 到 1800 秒第二个分片的时间戳要加上 1800 秒的偏移量。这样合并后的文字稿时间戳才是连续的。提示识别结果里的时间戳单位是毫秒转换成“时:分:秒”格式的时候要注意除以 1000。我一开始忘了除结果时间戳显示成了“3600000:00:00”排查了半天才发现是单位问题。4.4 文本后处理与输出格式化后处理模块的输入是识别结果的 JSON输出是格式化后的 Markdown 文本。我定义了一个处理管道依次执行以下操作提取文本和时间戳从 JSON 里遍历每个句子提取Text和StartTime字段。标点修复根据句尾疑问词和情感词调整标点。语气词过滤删除句首和连续出现的语气词。重复词去除用正则表达式检测连续重复的词组并合并。数字规范化把中文数字转成阿拉伯数字序数词除外。按时间戳合并把时间间隔小于 2 秒的相邻句子合并成一段减少碎片化。生成 Markdown每段前面加上时间戳格式是[00:00:00] 文本内容。输出文件我一般保存为会议纪要_日期.md同时把原始识别结果的 JSON 也保存一份方便后续需要重新处理时不用再调接口。5. 常见问题与排查技巧实录5.1 识别准确率低的排查思路识别准确率低是最常见的问题原因可能有很多。我整理了一个排查顺序问题现象可能原因排查方法解决方案整体识别率低音频质量差用耳机听一下录音是否有明显底噪或回声用降噪工具预处理或更换录音设备专业术语识别错热词表未配置检查热词表是否包含该术语添加热词并调整权重人名识别错人名未加入热词确认人名是否在热词表中添加人名热词权重设高数字识别错引擎模型不匹配检查 EngineModelType 是否选对中文场景选 16k_zh方言识别差模型不支持方言确认会议是否使用方言尽量用普通话或换用支持方言的模型我遇到过一次识别率突然下降的情况排查后发现是音频文件被压缩过采样率从 16kHz 降到了 8kHz。重新用原始文件转码后恢复正常。所以音频预处理这一步不能省宁可多花几分钟转码也不要直接上传原始文件。5.2 接口调用超时与重试策略腾讯云接口偶尔会因为网络波动导致超时。我的做法是设置重试机制最多重试 3 次每次间隔 2 秒。如果 3 次都失败就把任务标记为失败记录日志后续手动处理。重试的时候要注意创建任务和查询任务的重试逻辑不一样。创建任务重试可能会导致重复创建所以重试前要先查询是否已经有任务在运行。查询任务重试则相对安全直接重新查询即可。另外接口有频率限制短时间内大量请求会被限流。我的做法是在请求之间加一个 200 毫秒的延迟虽然会稍微慢一点但能避免被限流。对于批量处理多个会议录音的场景我会用一个队列来管理任务串行处理而不是并发请求。5.3 长音频切分的边界问题按静音段切分虽然好但有时候会遇到“假静音”的情况。比如会议中间有人翻纸、咳嗽、椅子挪动这些声音可能被误判为静音段导致切分点落在说话中间。我的解决办法是设置最小静音长度只有静音持续超过 700 毫秒才认为是真正的停顿。另外切分后的片段如果时长小于 10 秒我会把它合并到前一个片段里避免产生太多碎片。还有一个边界情况是会议开始和结束时的静音。如果音频开头有 30 秒的静音切分后会产生一个空片段。我的做法是在切分前先检测并裁剪掉首尾的静音段只保留中间的有效部分。这样既能减少无效请求又能提高识别效率。5.4 识别结果时间戳错乱的处理时间戳错乱通常发生在合并多个分片的时候。如果分片顺序搞错了时间戳就会乱跳。我的做法是在切分时给每个分片编号合并时严格按编号顺序拼接。另外腾讯云返回的时间戳是相对于当前分片的合并时要加上前面所有分片的总时长。这个偏移量计算要精确到毫秒否则累积误差会导致后面的时间戳偏差越来越大。我写了一个辅助函数来计算偏移量def merge_results(results): merged [] offset 0 for result in results: for sentence in result[Result][Sentences]: sentence[StartTime] offset sentence[EndTime] offset merged.append(sentence) offset result[Result][AudioDuration] return mergedAudioDuration是接口返回的音频时长单位是毫秒。用这个值来累加偏移量比手动计算每个分片的时长更准确。6. 实操心得与避坑经验6.1 录音设备的选择建议会议录音的质量直接决定识别准确率。我试过用手机自带录音、专业录音笔、会议麦克风三种设备。手机录音在小型会议室里够用但人多了之后远处说话的人声音很小识别率明显下降。专业录音笔效果好一些但需要额外携带而且导出文件麻烦。会议麦克风效果最好尤其是全向麦克风能均匀拾取各个方向的声音但价格也最贵。如果预算有限我的建议是至少用两个手机同时录音一个放在会议桌中间一个放在靠近主讲人的位置。后期可以选择识别效果好的那一份或者把两份录音合并。合并录音用 ffmpeg 的amix滤镜就能实现但要注意音量平衡否则会出现一个声音大一个声音小的情况。6.2 会议纪要的自动化整理技巧识别出来的文字稿只是原材料要变成真正的会议纪要还需要进一步整理。我加了一个简单的规则引擎自动提取会议里的“结论”“待办”“负责人”三类信息。规则是这样的包含“决定”“确定”“就这么办”的句子标记为结论包含“需要”“负责”“跟进”的句子标记为待办待办句子里出现的人名标记为负责人。这个规则引擎当然不能做到 100% 准确但能覆盖大部分常见表达。整理出来的草稿再人工过一遍比从头听录音快得多。我实测下来一场两小时的会议人工整理纪要大概需要 40 分钟用这个工具辅助后缩短到 10 分钟左右。6.3 成本控制的几个细节腾讯云 AI 语音识别按音频时长计费虽然单价不高但量大之后也是一笔开销。我总结了几个省钱的细节第一预处理阶段裁剪掉首尾静音段。会议录音开头和结尾经常有几分钟的空白裁剪掉能省不少时长。第二识别前先做静音检测如果整段音频都是静音直接跳过不调用接口。第三对于内部不太重要的会议可以用低精度模型费用更低。重要会议再用高精度模型。第四定期清理归档的识别结果只保留最近三个月的减少存储费用。6.4 数据安全与隐私保护会议录音往往包含敏感信息数据安全不能忽视。我的做法是音频文件上传前先加密识别结果保存时也加密存储。腾讯云的对象存储支持服务端加密开启后文件自动加密访问时需要密钥。另外识别任务完成后及时删除云端的临时文件避免数据残留。如果会议内容涉及更高级别的保密要求建议在本地部署语音识别模型虽然效果可能稍差但数据不出内网安全性更高。本地部署的方案我后续会单独写一篇来分享这里就不展开了。6.5 后续扩展方向这个会议小帮手目前只做了语音转文字和基础整理后续还可以扩展几个方向。一是接入会议日历自动获取会议主题和参会人识别结果里自动标注发言人。二是增加关键词检索功能输入一个词就能定位到会议里所有提到这个词的时间点。三是和团队协作工具打通识别完成后自动把待办事项同步到任务列表里。我个人最想做的扩展是发言人分离。现在识别结果里所有发言混在一起分不清谁说的。腾讯云有说话人分离的接口但需要额外付费而且对录音质量要求更高。等后续需求更明确了我再折腾这个。踩过几次坑之后我最大的体会是语音识别工具的价值不在于技术多先进而在于能不能真正融入工作流。一个识别准确率 95% 但需要手动操作十步的工具不如一个识别准确率 85% 但一键搞定的工具。所以我在设计这个会议小帮手的时候优先考虑的是自动化程度而不是追求极致的识别精度。先把流程跑通再逐步优化细节这个思路我觉得适用于大多数效率工具的开发。 
长河君 · 2026/10/22 14:25:05 · 阅读 1.2k 基于腾讯云AI语音识别的会议纪要自动化工具实战
1. 为什么我要做这个会议小帮手开会这件事最让人头疼的不是讨论本身而是会后那一堆没人整理的录音。一场两小时的会议录音文件躺在手机里谁都不想点开重听一遍。更麻烦的是领导突然来一句“上次会议那个结论是什么来着”你只能尴尬地翻聊天记录。我试过用手机自带的录音转文字准确率感人方言和口音一混进来直接崩盘。后来折腾了几套方案最终用腾讯云 AI 语音识别搭了一个自动化的会议小帮手从录音上传到文字稿输出全程不用手动干预。这个项目的核心思路很简单把会议录音丢进去自动切分、识别、整理成带时间戳和发言人的文字稿最后输出一份可以直接复制到文档里的会议纪要草稿。它解决的是“录音没人听、纪要没人写”这个老大难问题。适合谁参考经常需要整理会议记录的产品经理、项目经理、行政人员或者想给自己团队搭一套内部工具的后端开发者。哪怕你只会一点 Python 基础跟着做也能跑通。腾讯云 AI 语音识别在这套方案里扮演的是“耳朵”的角色负责把音频转成文字。但光有耳朵不够还得有“大脑”去处理分段、去重、格式化。所以整个项目其实是语音识别加后处理的组合拳。我踩过的坑主要集中在音频格式兼容、长音频切分、识别结果标点混乱这几个地方后面会一个个拆开讲。2. 整体方案设计与技术选型拆解2.1 为什么选腾讯云 AI 语音识别而不是本地模型一开始我试过本地部署开源语音识别模型比如 Whisper 系列。效果确实不错但有两个硬伤一是对硬件要求高一台普通办公电脑跑长音频推理慢得让人想砸键盘二是中文标点和数字规范化做得不够好识别出来的文字像一坨没有断句的流水账。腾讯云 AI 语音识别的优势在于开箱即用中文识别准确率高自带标点预测和数字转换而且支持热词表定制。对于会议场景里常见的专业术语、人名、产品名可以通过热词表提前注入识别准确率能明显提升。另一个考虑是成本。本地模型看似免费但算上电费、硬件折旧和维护时间其实并不便宜。腾讯云按量计费一场两小时的会议录音识别费用大概几毛钱到一块多对于中小团队来说完全可以接受。而且它支持多种音频格式直接上传不需要我先用 ffmpeg 转码省了一步操作。2.2 系统架构的四个核心模块整个会议小帮手我拆成了四个模块每个模块各司其职音频预处理模块负责检查音频格式、采样率、声道数必要时做转码和降噪。会议录音常见的是手机录的 m4a 或者电脑录的 wav采样率参差不齐直接上传有时候会报错。语音识别调度模块调用腾讯云 AI 语音识别的接口处理长音频的分片上传和结果合并。这里要注意接口对单次请求的音频时长有限制超过限制需要切分。文本后处理模块对识别结果做标点修复、重复词去除、语气词过滤以及按时间戳合并相邻句子。输出与归档模块把处理好的文字稿保存为 Markdown 或 Word 文档同时把原始音频和识别结果归档到指定目录方便后续检索。这四个模块串起来就是一条流水线录音文件进去会议纪要草稿出来。中间任何一个环节出问题都会影响最终效果所以每个模块的容错设计都很重要。2.3 长音频切分的策略选择腾讯云 AI 语音识别的实时识别和一句话识别对音频时长有不同限制会议场景通常用的是录音文件识别支持长音频但也不是无限长。我的做法是先把超过 60 分钟的音频按静音段切分而不是按固定时长硬切。为什么按静音段切因为如果正好切在一句话中间识别结果就会断成两半后处理的时候还得想办法拼回去非常麻烦。用静音检测来切分能保证每段音频的边界落在自然停顿处识别出来的文字段落也更符合语义。具体实现上我用的是 pydub 库的split_on_silence方法设置最小静音长度为 700 毫秒静音阈值根据实际录音环境调整。会议室录音通常底噪比较稳定阈值设在 -40dB 左右比较合适。如果录音环境嘈杂阈值要往上调否则会把说话间隙误判为静音导致切得太碎。3. 核心细节解析与实操要点3.1 音频格式兼容性处理腾讯云 AI 语音识别支持的音频格式包括 wav、mp3、m4a、aac 等但并不是所有编码方式都兼容。我遇到过手机录的 m4a 文件上传后返回格式错误后来发现是采样率的问题。手机录音默认可能是 48kHz而接口对某些格式要求 16kHz。解决办法是用 ffmpeg 统一转成 16kHz、16bit、单声道的 wav 文件。这个转换过程虽然多了一步但能避免后续很多莫名其妙的报错。转码命令我一般这么写ffmpeg -i input.m4a -ar 16000 -ac 1 -sample_fmt s16 output.wav参数解释一下-ar 16000设置采样率为 16kHz-ac 1设置单声道-sample_fmt s16设置采样格式为 16 位有符号整数。这三个参数是保证兼容性的关键。转码完成后我会用ffprobe检查一下输出文件的参数确认无误再上传。注意转码会损失一部分音质但对于语音识别来说16kHz 采样率已经足够覆盖人声频率范围。不要为了追求音质保留高采样率反而可能因为文件过大导致上传超时。3.2 热词表的配置技巧会议场景里经常出现公司内部术语、产品代号、人名这些词在通用语音识别模型里往往识别不准。腾讯云 AI 语音识别支持热词表功能可以提前把这些词加进去提升识别准确率。热词表的配置有几个技巧第一热词不要贪多。我一开始把能想到的词全塞进去了结果发现有些词反而识别错了。后来才明白热词表相当于给模型一个“偏向性提示”如果热词太多太杂模型会过度偏向这些词导致正常词汇被误识别。一般建议热词数量控制在 50 个以内只放那些确实容易识别错的专有名词。第二热词权重可以调整。腾讯云的热词表支持设置权重权重越高模型越倾向于识别成这个词。对于特别重要的产品名我会把权重设高一些对于一般性术语权重设低一些。具体权重值需要根据实际效果微调我一般从默认值开始识别效果不好的词逐步往上加。第三热词表要定期更新。项目迭代过程中会出现新的产品名和术语旧的热词表需要及时补充。我习惯每个月回顾一次识别错误率高的词把它们加到热词表里。3.3 识别结果的后处理逻辑语音识别出来的原始文本有几个典型问题标点符号缺失或错乱、语气词过多、重复词频繁、数字格式不统一。后处理模块就是来解决这些问题的。标点修复我用的是基于规则的方法。识别结果里通常会有逗号和句号但问号和感叹号经常缺失。我的做法是检测疑问词比如“吗”“呢”“吧”“对不对”“是不是”出现在句尾时自动把句号替换成问号。感叹号则根据情感词来判断比如“太好了”“没问题”“必须的”这类词后面加感叹号。语气词过滤比较简单维护一个语气词列表比如“嗯”“啊”“那个”“就是说”“然后呢”把这些词从文本里删掉。但要注意有些语气词在特定语境下是有意义的比如“然后”在描述流程时不能删。所以我设置了一个规则只有当语气词出现在句首或连续出现两次以上时才删除。重复词处理是个麻烦事。语音识别有时候会把一个词重复输出比如“我们我们觉得”。我的做法是用正则表达式检测连续重复的词组如果重复次数超过两次就保留一次。但像“好好好”这种表达强烈同意的重复需要保留所以规则要结合上下文判断。数字格式统一也很重要。识别结果里可能同时出现“一百二十三”和“123”我会统一转成阿拉伯数字方便后续阅读和检索。但像“第一”“第二”这种序数词保持中文格式因为转成“第1”“第2”反而奇怪。4. 实操过程与核心环节实现4.1 环境准备与依赖安装先说一下我的运行环境Python 3.9操作系统是 LinuxWindows 和 macOS 也能跑但路径处理上要注意兼容性。依赖库主要有这几个pip install tencentcloud-sdk-python pip install pydub pip install ffmpeg-pythontencentcloud-sdk-python是腾讯云官方 SDK封装了语音识别接口的调用逻辑。pydub用来做音频切分和格式转换它底层依赖 ffmpeg所以系统里要先装好 ffmpeg。ffmpeg-python是 ffmpeg 的 Python 封装方便在代码里调用转码命令。安装完成后需要在腾讯云控制台创建语音识别服务获取 SecretId 和 SecretKey。这两个密钥不要硬编码在代码里我一般用环境变量或者配置文件来管理。配置文件格式如下{ secret_id: your_secret_id, secret_key: your_secret_key, region: ap-guangzhou }region 选择离你最近的区域延迟会低一些。我选的是广州因为团队主要在南方。4.2 音频预处理模块的实现预处理模块的入口是一个函数接收音频文件路径输出处理后的 wav 文件路径。核心逻辑分三步第一步检查文件是否存在以及格式是否支持。我用os.path.splitext获取扩展名如果不在支持列表里直接抛异常提示用户。第二步用 ffprobe 获取音频的采样率、声道数、时长信息。如果采样率不是 16kHz 或者声道数不是 1就调用 ffmpeg 转码。转码后的文件临时存放在一个temp目录里处理完再删除。第三步如果音频时长超过 60 分钟调用切分函数。切分函数用 pydub 读取音频然后按静音段切分。切分后的文件命名规则是“原文件名_part1.wav”“原文件名_part2.wav”方便后续按顺序合并识别结果。这里有个细节要注意pydub 读取大文件时内存占用比较高如果音频超过两小时建议先用 ffmpeg 切成固定时长的片段再用 pydub 做静音检测。我一般设置每段不超过 30 分钟这样内存压力小切分速度也快。4.3 语音识别接口调用与结果合并调用腾讯云 AI 语音识别的录音文件识别接口流程是先创建识别任务然后轮询任务状态最后获取识别结果。创建任务时需要传几个关键参数EngineModelType引擎模型类型中文会议场景我选的是16k_zh如果是英文会议选16k_en。ChannelNum声道数单声道传 1。ResTextFormat返回结果格式我选的是 0表示返回带时间戳的详细结果。HotwordList热词表格式是“热词|权重”多个热词用逗号分隔。创建任务后接口会返回一个 TaskId。然后用这个 TaskId 去查询任务状态直到状态变成“成功”或“失败”。查询间隔我设置的是 5 秒太频繁了浪费请求次数太慢了又影响效率。一般 10 分钟以内的音频2 到 3 次查询就能拿到结果。拿到识别结果后需要把多个分片的识别结果合并。合并逻辑是按分片顺序拼接文本同时调整时间戳。比如第一个分片的时间戳是 0 到 1800 秒第二个分片的时间戳要加上 1800 秒的偏移量。这样合并后的文字稿时间戳才是连续的。提示识别结果里的时间戳单位是毫秒转换成“时:分:秒”格式的时候要注意除以 1000。我一开始忘了除结果时间戳显示成了“3600000:00:00”排查了半天才发现是单位问题。4.4 文本后处理与输出格式化后处理模块的输入是识别结果的 JSON输出是格式化后的 Markdown 文本。我定义了一个处理管道依次执行以下操作提取文本和时间戳从 JSON 里遍历每个句子提取Text和StartTime字段。标点修复根据句尾疑问词和情感词调整标点。语气词过滤删除句首和连续出现的语气词。重复词去除用正则表达式检测连续重复的词组并合并。数字规范化把中文数字转成阿拉伯数字序数词除外。按时间戳合并把时间间隔小于 2 秒的相邻句子合并成一段减少碎片化。生成 Markdown每段前面加上时间戳格式是[00:00:00] 文本内容。输出文件我一般保存为会议纪要_日期.md同时把原始识别结果的 JSON 也保存一份方便后续需要重新处理时不用再调接口。5. 常见问题与排查技巧实录5.1 识别准确率低的排查思路识别准确率低是最常见的问题原因可能有很多。我整理了一个排查顺序问题现象可能原因排查方法解决方案整体识别率低音频质量差用耳机听一下录音是否有明显底噪或回声用降噪工具预处理或更换录音设备专业术语识别错热词表未配置检查热词表是否包含该术语添加热词并调整权重人名识别错人名未加入热词确认人名是否在热词表中添加人名热词权重设高数字识别错引擎模型不匹配检查 EngineModelType 是否选对中文场景选 16k_zh方言识别差模型不支持方言确认会议是否使用方言尽量用普通话或换用支持方言的模型我遇到过一次识别率突然下降的情况排查后发现是音频文件被压缩过采样率从 16kHz 降到了 8kHz。重新用原始文件转码后恢复正常。所以音频预处理这一步不能省宁可多花几分钟转码也不要直接上传原始文件。5.2 接口调用超时与重试策略腾讯云接口偶尔会因为网络波动导致超时。我的做法是设置重试机制最多重试 3 次每次间隔 2 秒。如果 3 次都失败就把任务标记为失败记录日志后续手动处理。重试的时候要注意创建任务和查询任务的重试逻辑不一样。创建任务重试可能会导致重复创建所以重试前要先查询是否已经有任务在运行。查询任务重试则相对安全直接重新查询即可。另外接口有频率限制短时间内大量请求会被限流。我的做法是在请求之间加一个 200 毫秒的延迟虽然会稍微慢一点但能避免被限流。对于批量处理多个会议录音的场景我会用一个队列来管理任务串行处理而不是并发请求。5.3 长音频切分的边界问题按静音段切分虽然好但有时候会遇到“假静音”的情况。比如会议中间有人翻纸、咳嗽、椅子挪动这些声音可能被误判为静音段导致切分点落在说话中间。我的解决办法是设置最小静音长度只有静音持续超过 700 毫秒才认为是真正的停顿。另外切分后的片段如果时长小于 10 秒我会把它合并到前一个片段里避免产生太多碎片。还有一个边界情况是会议开始和结束时的静音。如果音频开头有 30 秒的静音切分后会产生一个空片段。我的做法是在切分前先检测并裁剪掉首尾的静音段只保留中间的有效部分。这样既能减少无效请求又能提高识别效率。5.4 识别结果时间戳错乱的处理时间戳错乱通常发生在合并多个分片的时候。如果分片顺序搞错了时间戳就会乱跳。我的做法是在切分时给每个分片编号合并时严格按编号顺序拼接。另外腾讯云返回的时间戳是相对于当前分片的合并时要加上前面所有分片的总时长。这个偏移量计算要精确到毫秒否则累积误差会导致后面的时间戳偏差越来越大。我写了一个辅助函数来计算偏移量def merge_results(results): merged [] offset 0 for result in results: for sentence in result[Result][Sentences]: sentence[StartTime] offset sentence[EndTime] offset merged.append(sentence) offset result[Result][AudioDuration] return mergedAudioDuration是接口返回的音频时长单位是毫秒。用这个值来累加偏移量比手动计算每个分片的时长更准确。6. 实操心得与避坑经验6.1 录音设备的选择建议会议录音的质量直接决定识别准确率。我试过用手机自带录音、专业录音笔、会议麦克风三种设备。手机录音在小型会议室里够用但人多了之后远处说话的人声音很小识别率明显下降。专业录音笔效果好一些但需要额外携带而且导出文件麻烦。会议麦克风效果最好尤其是全向麦克风能均匀拾取各个方向的声音但价格也最贵。如果预算有限我的建议是至少用两个手机同时录音一个放在会议桌中间一个放在靠近主讲人的位置。后期可以选择识别效果好的那一份或者把两份录音合并。合并录音用 ffmpeg 的amix滤镜就能实现但要注意音量平衡否则会出现一个声音大一个声音小的情况。6.2 会议纪要的自动化整理技巧识别出来的文字稿只是原材料要变成真正的会议纪要还需要进一步整理。我加了一个简单的规则引擎自动提取会议里的“结论”“待办”“负责人”三类信息。规则是这样的包含“决定”“确定”“就这么办”的句子标记为结论包含“需要”“负责”“跟进”的句子标记为待办待办句子里出现的人名标记为负责人。这个规则引擎当然不能做到 100% 准确但能覆盖大部分常见表达。整理出来的草稿再人工过一遍比从头听录音快得多。我实测下来一场两小时的会议人工整理纪要大概需要 40 分钟用这个工具辅助后缩短到 10 分钟左右。6.3 成本控制的几个细节腾讯云 AI 语音识别按音频时长计费虽然单价不高但量大之后也是一笔开销。我总结了几个省钱的细节第一预处理阶段裁剪掉首尾静音段。会议录音开头和结尾经常有几分钟的空白裁剪掉能省不少时长。第二识别前先做静音检测如果整段音频都是静音直接跳过不调用接口。第三对于内部不太重要的会议可以用低精度模型费用更低。重要会议再用高精度模型。第四定期清理归档的识别结果只保留最近三个月的减少存储费用。6.4 数据安全与隐私保护会议录音往往包含敏感信息数据安全不能忽视。我的做法是音频文件上传前先加密识别结果保存时也加密存储。腾讯云的对象存储支持服务端加密开启后文件自动加密访问时需要密钥。另外识别任务完成后及时删除云端的临时文件避免数据残留。如果会议内容涉及更高级别的保密要求建议在本地部署语音识别模型虽然效果可能稍差但数据不出内网安全性更高。本地部署的方案我后续会单独写一篇来分享这里就不展开了。6.5 后续扩展方向这个会议小帮手目前只做了语音转文字和基础整理后续还可以扩展几个方向。一是接入会议日历自动获取会议主题和参会人识别结果里自动标注发言人。二是增加关键词检索功能输入一个词就能定位到会议里所有提到这个词的时间点。三是和团队协作工具打通识别完成后自动把待办事项同步到任务列表里。我个人最想做的扩展是发言人分离。现在识别结果里所有发言混在一起分不清谁说的。腾讯云有说话人分离的接口但需要额外付费而且对录音质量要求更高。等后续需求更明确了我再折腾这个。踩过几次坑之后我最大的体会是语音识别工具的价值不在于技术多先进而在于能不能真正融入工作流。一个识别准确率 95% 但需要手动操作十步的工具不如一个识别准确率 85% 但一键搞定的工具。所以我在设计这个会议小帮手的时候优先考虑的是自动化程度而不是追求极致的识别精度。先把流程跑通再逐步优化细节这个思路我觉得适用于大多数效率工具的开发。