把 78 分钟录音变成带发言人的逐字稿

开会、听课、采访录了一大段，回头要整理成文字——这种活我原先是一边听一边打字，一小时录音基本要耗掉大半天。

现在改成：录音丢给脚本，等它慢慢转，中间去干别的。

先把三个词说白，后面不再解释：

• 语音转文字（ASR）：把人说的话变成文字的那类技术，语音输入法、字幕生成用的都是它
• 说话人区分：多个人说话时，标出"这句是谁说的"。它不是"认人"，只是按音色把不同的人分成【说话人1】【说话人2】
• 分段：长音频不能一次性丢给模型，要切成一段一段分别转，最后拼起来

先说清楚用了什么

模型走的是"OpenAI 兼容接口"：请求格式跟主流服务一样，换服务商不用重写脚本。接口地址和密钥不写在这里，配好后脚本自己读。

怎么用（两条命令）

# ① 短音频：直接给文件，可选再给个输出文件名
python3 mimo_audio_transcribe.py 录音.m4a
python3 mimo_audio_transcribe.py 录音.m4a 结果.txt

# ② 长音频（要区分发言人）：输入、输出、每段秒数
python3 mimo_meeting_transcribe.py 会议.m4a 会议转录.txt 90

两个可调的环境变量：每段多少秒（默认 90）、用哪个模型。78 分钟的录音，2 路并发跑完大约 20 分钟——建议挂着后台去干别的。

转出来是纯文本，需要的话再转成带发言人格式的文档就行。

我认为最值钱的三个设计

① 每段单独落盘，最后按序号拼
这是被坑出来的：转录文本内部本来就有空行，如果按"空行分块"去定位段落，一定会错位——我实测过，本该 54 段却切出 67 块，越补越乱。改成「一段一个文件 segNNN.txt，末尾按序拼接」，就绝不会串行。

② 认出"拒绝文本"，不当成结果
内容安全过滤偶尔会拦下某些片段，返回的是一句英文拒绝语。它长得像结果、其实是失败——脚本会识别出来标记为失败，不写进文件，否则整篇稿子就被这句话污染了。

③ 失败片段自动换更短的段重试
同一段连续失败，就按 90 秒 → 45 秒 → 30 秒往下切。短片段更难触发审核。当然，如果内容本身就会被拦，重试多少次也没用，脚本不会死磕。

六个真踩过的坑

1. 并发别贪多：接口允许的并发上限是 2 路。我试过 6 路，53 段里挂了 23 段——超过必被限流，老老实实 2 路
2. 审核拦截是真会发生的：被拦的片段返回英文拒绝语，整套流程里最容易把失败当成功的就是这一步
3. 重试要用更短的片段，不是原样重来（拦截是按内容触发的，同样的内容再传几次照样被拦）
4. 每段独立落盘再汇总，别在文本里找段落边界（见上面第①条）
5. 临时目录别写死：这台机器的系统临时目录是脚本自己取的，别把路径写死成 /tmp 这种固定位置
6. 密钥要按块读：配置文件里有多个服务商，全文搜 api_key 会抓到别人家的——要定位到对应服务商那一块再取

效果如实说

• 能用的：长录音整篇转完、区分不同说话人、每句带时间戳、纯文本产出，手机上零本地依赖（不用装任何语音识别引擎）
• 差在哪（老实讲）：它是通用大模型在做音频理解，不是专用识别引擎，纯转录速度比不过专用 ASR——同一段 78 分钟录音，专用工具几分钟就出，它要 20 分钟。要快就用专用工具，要用通用的就接受这个速度
• 副产品：转完还能直接追问——"把要点列成三条""这段话谁说的意见最多"，省一遍通读
• 正常现象：纯音乐、伴奏段返回空字符串，那不是失败，是没有语音

名词小抄（读不懂就翻这里）

隐私提醒

录音里是真人在说话，还可能是别人的话。传第三方服务前想清楚：这段音频里的人是否知情、是否同意。敏感的会议，要么先征得同意，要么用本地工具自己转。我自己的做法是：能公开的才走云端，剩下的不外传。

🛠 本文由自建 Agent 调度内容流水线自动完成：写稿 → 模型 API 生图 → R2 图床 → 排版 → MCP 落站。
配图由模型 API 生成、托管在自建对象存储上；内容仅供参考。