处理长达一小时的会议录音，真正的挑战往往不在于模型的处理能力，而是你输入的数据本身质量就不达标。

未经任何预处理的录音直接提交给Gemini，结果常常是：关键的决策点被遗漏、张伟与李敏的发言混淆不清、长达37分钟的静音区域被当作有效内容塞入上下文——行动项丢失、责任人混乱、截止日期模糊不清。这才是最令人头疼的核心问题。

因此，动手之前，务必先把音频整理干净。

音频预处理：去除静音 + 降噪 + 导出WA V格式

首先打开Audacity，导入原始录音文件。第一步是降噪：从“效果”菜单选择“降噪”，框选一段约0.5秒的纯环境噪音，点击“获取噪声特征”，然后全选整个波形，再次进入“降噪”，勾选“自动匹配降噪强度”，应用。这一步能有效降低背景底噪。

接下来处理静音区域。全选波形，点击“效果”→“裁剪静音”，阈值设为-45 dB，最小长度设为0.6秒。注意，这一步并非可选：如果不切除静音，模型会将那37分钟的白噪音误认为有效内容，从而挤占对真实发言的理解空间。

导出时选择“文件”→“导出”→“导出为WA V”，采样率强制设置为16000 Hz，位深度选16位。虽然MP3也受支持，但实测结果显示，WA V在Gemini 3.1 Pro上的识别准确率平均要高出11%。

分两轮调用：先转录，再总结

第一轮只做一件事：纯净转录。

上传预处理好的WA V文件，在输入框中粘贴以下提示词：

“请逐字转录这段会议录音，严格按照时间顺序排列；每轮发言前标注[张伟]、[李敏]等真实姓名（若根据上下文可推断）；保留所有技术术语原样，如‘RAG流程’‘SOP灰度发布’；不添加任何解释、不合并重复句子、不修正口误。”

注意，这一轮只获取转录文本，不要任何分析或总结。

待转录文本输出后，进入第二轮——但这一步容易被忽略：务必要新建一个对话窗口。因为Gemini的上下文是连续的，如果直接在原对话中继续，它会带着转录时的“任务状态”去处理总结请求，效果会打折扣。

将上一轮完整的转录文本复制粘贴到新对话中，然后输入：

“请基于以上转录内容，生成结构化会议纪要，包含：①会议基本信息（时间/主持人/主题）；②议题分组（每个议题下写清各方立场及分歧点）；③决议事项（仅列已拍板结论，标注责任人及明确截止日期）；④Action Item列表（格式：[王磊] - 拆分API权限模块 - 6月10日前）；⑤遗留问题（未达成共识项，标★）。”

这样一来，输出的就是可直接使用的会议纪要，而非一堆需要二次整理的原始对话。

三种直连调用方式

如果你的网络环境需要绕行，这里有三种实际可用的方法。

方法一：网页端直传
登录支持Gemini模型的平台，选择“Gemini 3.1 Pro”模型，点击输入框旁的“+”图标上传WA V文件，粘贴分步提示词，发送。

方法二：安卓端边录边分析
这个方案特别适合现场轻量级会议。打开Gemini安卓App，点击底部话筒开始录音。录到关键决策点时先暂停，输入：“提取当前已录内容中所有带有‘必须’‘本周内’‘由XX负责’字样的句子”。继续录制，结束时再发一次指令：“整合全部录音内容，输出完整会议纪要，按议题分段，每段标注核心结论”。

方法三：接口调用（需开发对接）
调用相关API接口，在body中设置模型参数，通过file_id字段传入已上传音频的ID，在messages中嵌入结构化system prompt与user指令。注意，单次请求最大支持2GB文件，但实测超过45分钟的WA V建议分片上传以确保稳定性。

交叉校验：锁定时间戳、术语与插话片段

拿到会议纪要后，不要急着使用。花几分钟做一次交叉校验，能避免很多麻烦。

先说第一步。打开Gemini返回的纪要，随便找一条Action Item，比如“[陈芳] - 更新测试用例文档 - 6月12日前”。

第二步，回到原始的转录文本，用Ctrl+F搜索“测试用例文档”，找到该句出现的上下文。确认前后是否有“陈芳”明确承诺，以及“6月12日”这个日期是否确实是口头说出来的——而不是模型凭空推断的。

第三步，检查术语。像“灰度发布”“LoRA微调”这类词，看转录原文中是否有拼写错误。如果发现“灰度布署”“Lora微调”等问题，立即在新对话中输入：“请将全文中所有‘布署’统一替换为‘部署’，所有‘Lora’统一替换为‘LoRA’，并校验发音相近词如‘洛拉’‘罗拉’是否误写”。

这一步看似笨拙，但在实战中非常有效。一次简单的拼写纠正，就能让整份纪要的准确度提升一个档次。