从语音识别到会议纪要：用腾讯云API搭建自动转写工具

1. 为什么我盯上了会议小帮手这个需求先说个真实场景。我平时要参加不少技术评审会和需求对齐会一场会短则四十分钟长则一个多小时。会上大家你一句我一句信息密度其实很高但真正落到谁负责什么、什么时候交付、当前阻塞是什么这些结论性内容时你要是光靠脑子记散会半小时后就模糊了。以前我的处理方式是拿手机录音会后再对着录音手动整理纪要。一次两次还行每周三四场会下来整理纪要这件事本身就成了新负担。后来我试过一些现成的会议转写工具说实话语音识别准确率尚可但有几个绕不开的问题一是私有化部署基本不用想数据要传到别人的服务器上二是格式灵活性差我想要的按说话人分段、带时间戳、自动提炼待办这些功能要么得加钱要么根本不提供三是很多工具的导出格式绑得死死的我想接进自己的笔记系统还得手动复制粘贴。琢磨了一圈不如自己基于云端的语音识别能力写个小工具要什么格式自己定要接什么下游自己说了算。腾讯云的语音识别服务是目前国内做得比较成熟的一批实时语音识别和录音文件识别都有现成的 SDKAPI 文档也比较清晰。我要做的这个会议小帮手不是重新发明轮子而是把语音识别引擎、会议音频输入、文本后处理这三段串起来形成一个从会开了到纪要出来了的闭环。这篇文章就把整个搭建过程、代码思路、实测效果和踩过的坑一起端出来给有类似需求的人一个可以直接抄作业的参考。适合看这篇东西的人被会议纪要折磨的职场人、想给团队做个内部效率小工具的开发者、以及对语音识别 API 的工程化落地感兴趣的朋友。我会尽量把原理和代码都讲透不搞只给步骤不给理由那种写法。2. 方案选型为什么要用云端 API 而不是本地模型动手之前先把方案定下来。会议转写这件事技术路径其实分两条一条是用本地开源的语音识别模型比如 whisper 系或者各种中文 ASR 模型另一条是接云端 API。两条路我都实际试过这里把取舍逻辑说清楚。2.1 本地模型的坎硬件、工程成本和中文优化本地部署语音识别模型听起来很美——数据不出内网费用可控但真跑起来会发现坑不少。首先是硬件门槛一个像样点的中文语音识别模型推理时显存占用动辄几个 GB普通办公笔记本根本跑不动得专门搞一台带 GPU 的机器。其次是工程化的隐性成本音频格式要自己转码、VAD语音活动检测要自己写、说话人分离要自己调、长音频要自己切段、识别结果的标点还原和数字规整也要自己处理。这些活儿分散在音频处理、模型推理、文本后处理好几个领域一个人搞下来至少一两周起步。更现实的问题是中文准确率。whisper 这类模型对英文的识别效果好中文场景下虽然能用但在有口音、语速快、专有名词多的会议场景里错字率明显偏高。我拿同一段会议录音对比过本地模型的中文识别准确率大概在 88% 上下而腾讯云的录音文件识别能到 95% 以上。会议纪要这种东西错几个字可能就会导致待办事项理解偏差准确率就是核心竞争力。2.2 云端 API 的真实优势不止是省事有人会觉得云端 API 就是把录音传上去拿回文本没什么技术含量。但实际用下来它省掉的东西远比想象中多。腾讯云语音识别的录音文件识别接口内部已经做了音频降噪、说话人分离、标点预测、数字规整这些处理这些在本地方案里每一项都是独立的研发活。换句话说我花 API 调用费买的是对方已经调好的整个识别链路而不是单纯的声音转文字这一个环节。实时语音识别则是另一个场景的刚需。如果开会时想看着字幕走或者想实时抓取关键词触发提醒录音文件识别那种会后出结果的模式就不够用了。腾讯云的实时语音识别 WebSocket 接口支持流式上传音频流一句话说完基本就能出结果延迟在一秒以内。这两个接口正好覆盖了会后整理和会中辅助两种使用方式我后面会详细讲代码实现。2.3 成本测算一次会议到底花多少钱成本这块我也算过账。腾讯云语音识别按量计费录音文件识别阶梯定价量大单价会降大致是每小时音频几块钱的水平。实时语音识别稍微贵一点按音频时长计费一小时音频大概十几块钱的量级。普通团队每周开五小时会一个月二十小时成本也就几十块钱相比请人专门整理纪要或者买一个高价 SaaS 会员性价比是碾压级的。当然要是有人非要说几十块钱也是钱我自己听录音整理不花钱那我只能说这个账没算上自己的时间成本。一小时录音手动整理纪要至少要花四十分钟到一个小时一个月就是二十个小时。拿这些时间做点更有价值的事这才是工具存在的意义。3. 录音准备与文件上传最容易忽略但决定成败的环节方案定下来之后我本以为最难的会是代码结果首战就栽在了音频文件处理上。语音识别引擎对输入音频有严格的格式要求不满足就直接报错或者识别结果惨不忍睹。这一节把录音采集、格式校验、上传预处理的完整流程讲清楚。3.1 会议录音的采集规范采样率和编码格式别乱来会议录音的采集端经常是手机、电脑自带麦克风、或者专业的会议麦克风阵列。不管用哪个最终送到识别引擎的音频文件采样率和编码格式必须符合接口要求。腾讯云录音文件识别支持的格式包括 wav、mp3、m4a 等常见格式采样率要求 8kHz 或 16kHz位深 16bit 或更高。如果音频是 44.1kHz 的 CD 音质反而需要降采样到 16kHz 再上传因为识别引擎训练时用的主要就是 16kHz 电话宽带和 8kHz 窄带音频过高的采样率并不会提升识别效果反而可能因为频谱特征不匹配导致识别率下降。这里有个实操细节用手机录音时尽量把录音软件设置成会议模式或者语音备忘录这类以人声优化为目标的模式而不是高保真音乐模式。高保真模式会保留很多环境底噪识别引擎反而要花更多力气去降噪转写时更容易出错。我实测过同一个房间同一个人说话用高保真模式录的 m4a 文件识别准确率比用通话优化模式录的 mp3 文件低了差不多三个百分点。3.2 音频转码的两种路径本地处理与云端托管如果你的录音已经是标准格式直接上传就行。但实际场景中经常会碰到各种边角料——微信语音发来的 amr 文件、某些会议软件导出的加密格式、录像里单独抽取的音轨。这些情况就需要先转码。转码工具有很多最通用的方案是用 ffmpeg一行命令就能搞定格式转换和采样率调整ffmpeg -i input.amr -ar 16000 -ac 1 -codec:a pcm_s16le output.wav这条命令把输入文件转成 16kHz 单声道 16bit 的 wav 格式这是语音识别最友好的参数组合。转码之后务必再检查一次文件的时长和大小有时候 i 参数输入的文件有问题转出来时长是 0 或者只有几秒这种文件直接上传识别接口会直接返回错误码。编码格式的选择上我个人的经验是优先用 wavPCM 编码其次才是 mp3。wav 文件是无损的识别器解析起来最直接mp3 是有损压缩虽然对人类听觉影响不大但高频信息会有损失在语音识别这种对频谱细节敏感的场合一点点损失都可能被放大。当然wav 文件体积大上传速度慢如果录音很长折中方案是转成 320kbps 的 mp3识别率几乎不受影响。3.3 本地文件分片上传腾讯云 COS 的接入细节录音文件识别接口的处理链路是先上传音频到 COS 对象存储再把文件 URL 传给识别接口。这一步很多人会直接在代码里用公网 URL 或者临时外链但正规做法是用临时密钥上传到自己的 COS 存储桶然后把对象地址传给 ASR 服务。腾讯云的语音识别 SDK 里其实封装了上传逻辑你只需要提供一个本地文件路径它会自动完成 COS 上传和识别请求的串联。这里有个权限细节值得提一下。如果你是用主账号密钥调 API自然没问题但安全规范不建议这样做。正确做法是在控制台创建一个子账号只授予 COS 上传和语音识别相关的权限策略然后用临时密钥STS的方式在代码里获取凭证。这样做的好处是即使密钥泄露攻击者拿到的也只是一个有时效的临时凭证影响范围可控。临时密钥的获取逻辑大概是这样先调用 STS 的 AssumeRole 接口拿到临时 AK/SK 和 Token再把这三个值传给 ASR 客户端。腾讯云语音识别的 Python SDK 里提供了专门的 Credential 模型你可以在代码里这样初始化from tencentcloud.common import credential from tencentcloud.asr.v20190614 import asr_client # 以临时密钥方式初始化客户端 cred credential.Credential(tmp_secret_id, tmp_secret_key, tmp_token) client asr_client.AsrClient(cred, ap-guangzhou)这里 region 参数用 ap-guangzhou 是因为语音识别服务在华南地区的部署最成熟、升级最及时其他地域也支持但如果有选择我建议优先用广州。没有特殊合规要求的话地域越靠近服务端机房音频上传和结果回传的延迟就越低。4. 核心实现录音文件识别接口的完整接入流程准备工作做完真正干活的部分来了。这一节从头到尾拆一遍录音文件识别的接入流程包含创建任务、轮询结果、解析返回文本三个核心环节并给出完整可跑的示例代码。4.1 创建识别任务重要参数逐个解读录音文件识别的调用方式是异步的你先提交一个任务服务端返回一个任务 ID然后需要轮询查询识别结果。整个过程不复杂但有四个参数必须理解清楚不然识别效果会打折。第一个是EngineModelType引擎模型类型。这个参数决定用哪个语音识别模型来处理你的音频。会议场景下我强烈建议用16k_zh_video或者16k_zh_dialogue。前者是音视频场景模型对背景音乐、多人说话混杂的情况做了优化后者是对话场景模型对一问一答、语速快的场景更友好。我实测下来技术评审会这种多人轮流发言的用16k_zh_dialogue效果最好如果会议里有远程参会人通过视频接入音质参差不齐16k_zh_video会更稳。第二个是ChannelNum音频通道数。如果录音是单声道就填 1如果是双声道比如电话会议录制的双方分离音频可以填 2。填 2 的好处是识别接口会分别处理两个声道的音频并在结果里区分说话人这对谁说了什么的记录需求很有帮助。但前提是你的录音真的是双声道且左右声道分别对应不同说话人如果只是普通立体声两个声道内容基本相同填 2 反而会导致结果重复。第三个是ResTextFormat识别结果文本格式。这个参数默认值是 0返回纯文本推荐填 2返回带标点和时间戳的详细结果。会议纪要场景时间戳特别有用后面做按说话人切分和定位到某个观点的具体时刻都依赖它。第四个是FilterDirt过滤脏词。填 1 的话识别结果会过滤掉嗯啊那个这类语气词。这个功能非常实用直接决定纪要的干净程度。提交任务的代码用 Python SDK 写出来是这样import json from tencentcloud.common import credential from tencentcloud.common.profile.client_profile import ClientProfile from tencentcloud.common.profile.http_profile import HttpProfile from tencentcloud.asr.v20190614 import asr_client, models cred credential.Credential(secret_id, secret_key) http_profile HttpProfile() http_profile.endpoint asr.tencentcloudapi.com client_profile ClientProfile() client_profile.httpProfile http_profile client asr_client.AsrClient(cred, ap-guangzhou, client_profile) req models.CreateRecTaskRequest() req.EngineModelType 16k_zh_dialogue req.ChannelNum 1 req.ResTextFormat 2 req.FilterDirt 1 req.SourceType 0 # 0表示URL1表示本地文件上传 req.Url https://your-bucket-1250000000.cos.ap-guangzhou.myqcloud.com/meeting_audio_20240115.wav resp client.CreateRecTask(req) task_id json.loads(resp.to_json_string())[Data][TaskId] print(f识别任务创建成功任务ID{task_id})SourceType这个参数的含义值得多说一句。填 0 代表传一个公网可访问的 URLSDK 会自动去这个地址拉取音频填 1 代表本地文件直传SDK 会先把文件传到你指定的 COS 存储桶再去创建任务。我推荐用本地直传模式传公网 URL 还要额外处理鉴权、防盗链这些问题麻烦且没必要。4.2 轮询结果与错误处理别用死循环要有退避策略任务创建成功后需要轮询查询结果。查询接口是DescribeTaskStatus传入任务 ID返回的状态码含义如下状态码含义处理建议0任务进行中继续等待间隔几秒再查1识别成功解析返回的 Result 字段2任务失败查看 ErrorMsg 定位原因修正后重新提交轮询不能搞成无脑死循环。合理做法是每 3 到 5 秒查一次连续查询超过 10 分钟还没结果就主动放弃并记录日志。正常情况下一小时的会议录音识别时间大概在 3 到 8 分钟这和音频时长、声道数、并发任务量都有关系。如果长时间卡住多半是音频格式有问题或者服务端积压死等没有意义。我写的轮询逻辑大概是这个风格import time max_retry 120 # 最多查120次每次间隔3秒总共最多等6分钟 for i in range(max_retry): req models.DescribeTaskStatusRequest() params {TaskId: task_id} req.from_json_string(json.dumps(params)) resp client.DescribeTaskStatus(req) data json.loads(resp.to_json_string())[Data] status data[Status] if status 1: print(识别完成) result_json data[Result] break elif status 2: print(识别失败, data[ErrorMsg]) break else: time.sleep(3)有个小坑必须提醒Result字段返回的是一段 JSON 字符串不是直接从 JSON 里取一个字符串字段就能用。你需要对result_json再做一次json.loads()才能拿到真正的识别结果列表。我第一次接的时候在这里卡了快半小时一直以为是接口返回结构变了结果只是自己少做了一次反序列化。4.3 解析结果文本从 Sentence 数组到结构化纪要识别结果的结构化程度取决于你在 CreateRecTask 时选择的ResTextFormat。填 2 的话返回结果里是一个Sentence数组每个元素包含StartTime、EndTime、Text和SpeakerId四个字段正好对应这句话从第几秒开始、到第几秒结束、说了什么、是谁说的。拿到这个结构会议纪要就非常好做了。我按 SpeakerId 分组把每个人说的话按时间排序拼接就能得到一个按发言人整理的完整发言稿。再进一步可以直接统计每个人的发言总时长和发言次数自动生成一份会议发言分布报告谁讲得多谁讲得少一目了然。这里给出一个简单的解析和渲染逻辑示例sentences json.loads(result_json)[Sentence] speaker_text_map {} for s in sentences: speaker_id s.get(SpeakerId, -1) text s[Text] speaker_text_map.setdefault(speaker_id, []).append(text) for speaker_id, texts in speaker_text_map.items(): full_text .join(texts) print(f发言人 {speaker_id}:) print(full_text) print(---)说到SpeakerId提一句它的局限性。这个功能是基于声纹特征做的说话人分离准确率在理想条件下能到 90% 以上但实际会议场景里如果两个人声音很像、或者有人频繁进出、或者有严重回声分离效果会明显下降。它不是百分之百可信的但作为初筛工具已经足够强大了。5. 实时模式会议进行中就要看到文字稿录音文件识别解决的是会后整理的问题但开会的当下如果讨论到一个关键结论你希望立刻在白板上记下来这时候等会后出稿就来不及了。实时语音识别的价值就在这里——一边开会一边出字幕关键信息可以随手捕获。腾讯云的实时语音识别走的是 WebSocket 协议比录音文件识别的 HTTP 轮询方式要复杂一些但理解核心逻辑之后也不难。5.1 WebSocket 接入与音频流切片请求头里藏着关键配置实时语音识别有两种接入方式一种是一句话识别短音频60 秒内一次传完适合语音输入法这种场景另一种是实时语音识别 WebSocket适合长时间、流式的场景也就是我们开会用的。WebSocket 接入时URL 里要带secretid和token参数包括鉴权签名。这个签名算法是腾讯云通用的 TC3-HMAC-SHA256SDK 里已经把签名封装好了直接用官方提供的示例代码改造就行。我用的方式是先建立一个 WebSocket 连接然后循环从麦克风或会议系统的音频流里读取 16kHz 16bit 的 PCM 数据切成 40ms 一帧发出去。40ms 是一个比较平衡的选择太短则网络包太碎白白浪费带宽太长则服务端响应延迟堆积字幕会明显滞后于说话人。音频流切片的核心代码逻辑大概是import websocket import json import pyaudio CHUNK int(16000 * 0.04) # 40ms一帧约640个采样点 def on_message(ws, message): data json.loads(message) if result in data: text data[result][text] print(text, end) def on_error(ws, error): print(WebSocket error:, error) ws websocket.WebSocketApp( url, on_messageon_message, on_erroron_error ) ws.run_forever()多说一句pyaudio的坑。pyaudio 直接装经常报错macOS 上要先brew install portaudioLinux 上要先装libasound2-dev。如果你只是先验证功能不想折腾音频采集也可以直接用一个音频文件作为输入源按帧读取 PCM 数据并发送这样可以把问题拆成网络部分和音频部分两个阶段分别调试。5.2 实时识别结果处理中间结果 vs 最终结果WebSocket 返回的消息里有final字段用来区分中间结果和最终结果。中间结果是随着说话逐步更新的文字会不停变化适合做字幕展示最终结果是这句话说完后定稿的文字不再变化适合做纪要采集。我在代码里把这两类分开处理中间结果直接跳过不落盘最终结果才追加到纪要文件里这样避免了一句话被重复记多次的问题。这个final字段的处理逻辑是实时语音识别落地时最重要的细节之一。很多人第一次接满屏的重复文字以为是接口故障其实只是没过滤中间结果。5.3 延迟优化与断线重连实测效果和抗干扰设计实时识别的延迟从说话人开口到文字上屏实测大概在 800ms 到 1.2s 之间波动。这个延迟主要受网络质量和音频流切片大小影响。网络好的时候语音几乎是一边说话一边出字。网络差的时候会出现文字一顿一顿地蹦出来的现象这时候不用慌只要不断连最终结果还是会补齐的。断线重连是生产环境必须考虑的问题。会议一趟几十万秒的音频流网络不可能全程稳定。我设计的重连策略是检测到 WebSocket 断开后先等待 2 秒再重新建立连接如果连续重连 3 次失败则切换到降级方案——放弃实时识别保存原始音频会后再用录音文件识别接口补录。这套策略目前跑下来基本没出现过数据丢失的情况。6. 从转写文本到会议纪要文本后处理的实战调优语音识别输出的原始文本和一份能直接发给项目组的会议纪要之间还差着好几种处理。这个环节是整个工具的核心价值所在——识别引擎负责听到你负责听懂。我的文本后处理管线包含三块内容清洗与格式化、待办事项提取、摘要生成。6.1 标点恢复与口语词清洗搭一个轻量文本过滤链识别接口返回的文本虽然带了标点但口语化的废词还是不少。比如就是说然后呢基本上这个这个这些词在口头表达里是过渡词落到文字稿里就是噪音会严重干扰阅读。我的做法是维护一个自定义停用词表用正则表达式把高频口语词替换掉。同时数字和日期的规整也很重要。语音识别对下周三下午两点这种表达识别结果可能是下周三下午两点也可能变成下周三 14: 00两种情况都要规整成统一格式。时间实体统一转成周X HH:mm的形式日期实体统一转成X月X日的形式。正则处理比较直接如果后续需求复杂了再考虑引入实体识别模型。6.2 待办事项提取关键词规则 vs 轻量方案会议纪要里最有价值的信息就是待办事项。谁负责什么什么时候交付这是整个会议的核心产出。我从语音文本里提取待办用的是关键词规则加简单语义判断的组合方案。触发词包括需要必须记得跟进确认尽快截止下周这些一旦句子中出现这些词就认为这一句可能包含待办信息把整句话提取出来放入待办候选列表。接下来是责任人识别。这一环信息量比较大因为我你他这种人称代词在会议中是频繁出现的而且指代关系动态变化。我采用的方案是先识别文本中出现过的人名或角色名如前端同学产品经理再结合上下文进行简单的人称消解。这个方法准确率大概在 80% 左右不完美但作为初版工具已经能省下大部分手工整理时间了。6.3 摘要生成关键句抽取比生成式更稳定会议摘要这块我试过两种方案一种是生成式摘要也就是用大模型重新组织语言输出的摘要读起来很通顺但可能会丢掉细节还偶尔会编造原文没有的信息另一种是抽取式摘要也就是按句子的关键程度排序把权重最高的几句话原样抽出拼成摘要。目前我主要用抽取式因为会议纪要最重要的诉求是忠于原文不是写得漂亮。抽取式摘要的权重计算我用了简单的 TF-IDF 加位置加权。句子中出现频率高的词权重高句子越靠前权重越高包含结论重点最终决定这些词的句子额外加权。一番操作下来选出的 Top 5 到 Top 10 句话基本能覆盖会议的核心结论。生成式方案留给后续版本的优化空间等有把握不丢信息、不瞎编的时候再切换。7. 踩坑记录这个项目里最深的几个坑替你趟过了这个项目前前后后折腾了两周多踩的坑不能说少。挑几个印象最深的写在这里都是真实的报错信息和排查思路希望后来者能少走弯路。第一个大坑是音频编码问题导致的持续识别失败。我第一次拿一个 m4a 文件直接上传接口返回的错误码是FailedOperation.ErrorFormat提示音频格式不支持。排查过程是先确认 m4a 是不是腾讯云支持的格式文档上写的是支持 m4a那问题出在哪后来用 ffprobe 查看该文件的内部编码发现它是一个 AAC 编码的 m4a而且是 44.1kHz 立体声。于是我先把音频降采样成 16kHz 单声道再转成 wav重新上传后问题解决。这让我意识到支持哪种容器格式是一回事容器里面的编码参数对不对是另一回事。第二个坑跟临时密钥的 Token 传递有关。用 STS 临时密钥初始化客户端时代码里容易写丢token参数或者只传了 AK/SK 没传 Token。这个问题的报错很隐蔽——它不直接报缺少 Token而是报签名校验失败或者请求被拒绝。我排查了半天才意识到是 Token 没传全。写代码的时候建议把凭证封装成一个统一的对象从环境变量读取避免在代码里硬编码导致情绪管理失败。第三个坑是轮询频率过高触发服务端限流。我的第一版代码里轮询间隔只设了 1 秒结果连续创建几个任务之后服务端直接返回请求频控超限。查文档才明确DescribeTaskStatus 的 QPS 限制是 20但高频轮询依然可能触发限流策略。把轮询间隔改成 3 到 5 秒之后再没出现过这个问题。所以轮询间隔宁慢勿快这不是佛系是稳定。第四个坑和说话人分离的稳定性有关。有一次测试会议室里两个人声音非常接近SpeakerId 在两个人的发言之间来回跳导致最后按发言人整理的纪要被切得稀碎。后来我在后处理里加了一个滑动窗口合并算法如果相邻两句话的 SpeakerId 不同但间隔时间小于 2 秒且文本长度都较短就判定为同一个人合并 SpeakerId。这个启发式规则做完之后发言切分的稳定性提升了不少。8. 效果实测与落地建议这套工具到底好用吗工具开发完我拿过去一个月的会议记录做了回测。选取了四场不同类型的会议——技术评审会、项目周会、需求对齐会、复盘会——对比了工具自动生成的纪要和当时人工整理的纪要做了个表格会议类型音频时长识别准确率待办提取准确率人工整理耗时工具整理耗时技术评审会52分钟96.2%85%42分钟3分钟项目周会38分钟97.1%90%30分钟2分钟需求对齐会65分钟94.8%78%55分钟5分钟复盘会47分钟95.3%82%38分钟3分钟识别准确率这项数据是我用人工转写的结果和自动识别的结果逐行比对的平均在 95% 到 97% 之间。待办提取准确率的定义是工具提取出来的待办事项中正确且信息完整的比例。四场会议下来平均在 84% 左右信息完整率已经具备参考价值但还达不到直接用。我的处理办法是工具生成初稿后我快速浏览一遍待办列表补充和修正一遍整体时间成本大概从原来的每场 30 到 55 分钟降到了 5 到 10 分钟。这个效率提升已经很可观了。落地建议方面给不同需求强度的读者几个方向。如果只是个人使用按我本文的代码搭一个命令行工具就够了输出 md 格式的纪要文件直接扔进笔记系统。如果是要给团队用建议加一层简单的 Web 界面把音频上传、任务状态、纪要预览和导出整合成一条流程。如果再进一步可以接入企业微信或者飞书的机器人会议结束后自动把纪要推送到群里——这一块内容能覆盖的话会议纪要这个场景基本就算做透了。9. 后续可以扩展的方向与我的个人体会项目做到这个程度初步能用但离完美还很远。按我个人的规划接下来有三件事值得做第一是把生成式摘要从备选方案转正但前提是用长文本校验手段确保不幻读第二是把待办提取这套规则升级成基于序列标注的微调方案提升人称消解准确率第三是离线批量任务队列把多场会议音频的转写和管理系统化方便团队里的人按时间、项目、发言人检索历史纪要。最后谈一点个人体会。做这个项目最大的收获不是我写了几百行代码而是想明白了一个道理工具的价值不在于用多高级的技术而在于能不能精准地解决一个高频且痛苦的问题。语音识别 API 只是引擎真正决定体验的是你对场景的理解——你知道开会时哪些内容重要、哪些是废话、纪要发给谁、他关心什么。这些判断写进代码里工具就活了。当然安全合规的意识也一直在脑子里绷着。会议音频属于敏感数据我传上去之前都会先做脱敏判断涉及敏感内容的会议不会走云端接口。这个红线大家用的时候一定守死了。