1. 手动整理一小时的痛和 Whisper 给我的转机先说说我为什么会专门写这篇 Whisper 语音转写实战。我手里头有大量音频要处理每周至少两场客户访谈、一期播客、还有零零散散的会议录音。以前靠的是最原始的办法——听一句暂停一下把重点敲进文档里。一小时的对谈我平均要花三到四个小时才能理出一份还算能看的文字稿遇到口音重、语速快的受访者那简直是一场灾难。后来我试过各种“智能转写”在线服务要么按分钟收费贵得肉疼要么免费额度只够转三五分钟要么音频传上去之后等半天才出结果准确率还忽高忽低关键数据一旦听错返工比手动整理更崩溃。直到我发现了 Whisper。如果你也在热搜里看到“whisper是什么”这个词不用绕弯子Whisper 就是 OpenAI 开源的自动语音识别ASR模型。它的核心本事是干两件事把语音变成文字以及把任意语言的语音翻译成英文输出。和那些云端服务最大的区别是它完全开源可以免费下载在本地跑录音文件不用上传到任何人的服务器处理多少个小时的音频都不额外花钱只要你的电脑扛得住。从我的实际体验来说它的中文识别能力在开源模型里是第一梯队对大多数普通话、方言口音和背景噪音的容忍度相当高。这篇文章适合谁看如果你和我一样需要定期把访谈、会议、讲座、播客、课堂录音转成文字稿或者在剪视频时需要给素材生成字幕那你完全可以照着这篇文章从零开始搭一套自己的转写流水线。我会从环境搭建、模型选型、命令行参数逻辑、批量出稿脚本、坑点排查一直讲到最终的成稿排版。整篇文章不会只丢给你几个命令而是告诉你每一个环节为什么要这么选、这么配遇到问题的时候从哪里入手排查这样你才能有本事把流程真正跑通而不是下载完就卡在第一个报错上。2. 装环境的核心决策算力、依赖和模型怎么选2.1 先想清楚你的机器能跑到哪一步很多人一上来就问“用哪个模型最强”这个问题其实得反过来问——你的电脑扛得住哪个模型。Whisper 的模型有六个档位tiny、base、small、medium、large-v1、large-v2后来社区里最常用的多是 large-v3。我的结论很直接如果你要转中文而且是长期用直接上 large-v3哪怕慢一点也值得如果只是偶尔转个把小时或者机器实在不行small 是最低底线。我第一台用来跑 Whisper 的电脑没有独显是一颗英特尔 8 核 CPU16G 内存。当时天真地想直接跑 large结果一条五十分钟的音频跑了两个多小时转出来的内容虽然质量高但这个速度根本没法当日常工具用。后来换了台带 RTX 3060 12G 显存的机器情况才真正改善。这里先给一份我实测下来大致靠谱的性能参考不同机器会有差异但量级不会偏差太大模型参数规模CPU 转写速度约GPU 转写速度约中文识别效果我的建议tiny39M约 4-5 倍实时极快很差仅能听懂大部分单字不建议base74M约 2-3 倍实时极快能听出短句长句易错玩具级别small244M约 0.8-1 倍实时极快日常对话能看但专有名词错得多最低可用档medium769M约 0.3-0.5 倍实时约 2-3 倍实时明显提升口语能听懂八成面向中文的低显存友好档large-v31550M非常慢约 1 倍实时个人认为开源里中文最好的一档长期使用推荐这里的“倍实时”是指处理时长和音频时长的比值。比如 1 倍实时就是一条 60 分钟的音频大约需要 60 分钟处理2 倍实时就是 60 分钟音频大约 30 分钟处理完。CPU 跑 large 你可以直接劝退自己。GPU 显存方面我的经验是medium 需要大概 5G 显存large 系列建议至少 10G 显存8G 显存转 long 音频会偶尔爆显存但配合后面讲的分段参数也能跑。如果你的机器只有 4G 显存就老老实实在 small 和 medium 之间做选择。2.2 依赖安装顺序和最容易翻车的点安装 Whisper 本身非常简单三样东西Python、ffmpeg、whisper 包。但很多人卡住不在 whisper 本身而在 ffmpeg。Python 请用 3.9 到 3.11 版本3.12 及以上目前有些依赖兼容性问题我踩过一次不建议在环境上冒险。ffmpeg 是处理音频和视频的瑞士军刀Whisper 依赖它将各种格式的音频解码成模型能处理的格式。Windows 用户最容易在这里翻车直接去 ffmpeg 官网下载编译好的 Windows 压缩包解压后把 bin 目录路径加到系统环境变量 Path 里然后重新打开命令行验证。macOS 用户用brew install ffmpegUbuntu/Debian 用户用apt install ffmpeg。装完一定要在终端跑一下ffmpeg -version如果输出版本信息说明解码工具就位了。我见过太多人跳过这步直接装 Whisper最后执行转写时报FileNotFoundError: [WinError 2] 系统找不到指定的文件其实就是 ffmpeg 不在 PATH 里。接下来是主体安装pip install -U openai-whisper装完试着查一下版本whisper --help能正常打印帮助信息环境就算齐了。第一次真正转写的时候Whisper 会从网上下载模型文件常用的 large-v3 模型文件将近 3G第一次运行会卡在“下载中”很久。如果你在这一步经常失败而不是速度慢先找找是不是网络环境问题。我的做法是先把模型文件下载到本地缓存目录再让 Whisper 离线加载。2.3 第一次跑通 demo别上来就处理大文件环境装好之后强烈建议先拿一小段音频做测试。录音文件可以是 mp3、m4a、wavOpenAI 官方支持的格式还挺多。最基础的调用方式whisper 测试音频.mp3 --model small --language Chinese --output_format txt这条命令的意思是用 small 模型处理这个文件明确告诉模型内容是中文结果输出成 txt 格式。等它跑完同目录下会生成一个“测试音频.txt”文件里面就是转写出来的文字。第一次跑的时候重点不是看准确率而是确认整个链路是通的音频解码成功、模型成功加载、结果正常落盘。很多人问为什么不直接上 medium 或者 large 测试。原因很简单第一次跑的时候你还不确定自己的机器性能怎么样也不知道显存够不够先用 small 把流程摸顺再换大模型成本最低。我记得我第一次直接用 large 测试结果中途显存爆掉程序崩溃还以为是软件装错了回头排查半天才发现是显存不足这个冤枉时间花得太不值了。3. 命令行参数背后的逻辑先弄懂再跑大批量Whisper 的命令行参数非常多但日常高频使用的其实就十来个。为什么我要单独拿出一章讲参数因为批量转写的时候参数配错一个地方几十个文件全部白跑那个时间成本真的是血泪教训。下面把每个关键参数的意义和最佳实践拆开说清楚。3.1 语言参数千万别省直接用whisper audio.mp3不加任何参数也能跑模型会自动判断音频里是什么语言。但自动检测有一个概率问题尤其是音频开头有音乐、静音、咳嗽声的时候模型有可能猜错语言。一旦猜成别的语言输出的中文内容就会夹杂大量英文音译词比如“环境”变成“environment”。所以我的习惯是明确知道音频语言是中文的时候一定要加--language Chinese这能让模型在解码时把搜索空间限定在中文里错误率明显下降。如果你实在不知道音频是什么语言可以先不加语言参数跑一小段片段看到开头输出的 language 标签再手动指定。Whisper 支持的语言代码列表很长中文就是Chinese英文是English。3.2 输出格式决定了你的后续处理方式--output_format支持这么几个值txt、srt、vtt、tsv、json。很多人只选一个但我的建议是直接全要whisper audio.mp3 --output_format allall会同时生成全部五种格式。我问过自己为什么要这么干其实后面的处理场景不一样txt 用来做文字稿初稿srt 直接能当视频字幕用json 里面有每个词的时间戳和置信度可以做二次加工和说话人分段分析tsv 是表格形式方便导入 spreadsheet。所以别省这个参数反正生成五种文件的计算成本是一次性的。3.3 时间戳细粒度词级还是行级默认情况下Whisper 输出的 srt 是按句子级别切分时间戳的一行字可能跨越好几秒。如果你只需要看懂内容足够用了。但如果要拿字幕去剪映、PR 里对齐视频你可能希望时间戳更准确一些。这里有一个参数叫--word_timestamps True开启后会把时间戳精细到每个词。代价是处理时间会增加一些而且对中文这种没有天然空格分隔的语言词级切分逻辑会有点奇怪输出的词可能不是一个完整词语。我实际用下来的结论是做字幕用句子级就够做音频剪辑对齐轨道才需要词级。大多数情况下默认的句子级即可别盲目追求精细。3.4 分段长度和上下文的关系Whisper 内部会把长音频切成一段一段处理默认段长 30 秒。--condition_on_previous_text这个参数默认是开启的意思是处理后面段落的时候会把前面段落的文字也作为上下文参考这样长文档的转写连贯性会好很多。但这也带来一个问题如果前面段落识别错了后面可能会受错误内容的“诱导”跟着错。我实测下来保持默认开启是利大于弊的因为连贯性收益远大于个别错误传递。真正需要关掉它的场景是音频内容主题跳变非常剧烈的比如开会时突然有人插进来讲了个完全无关的话题这时上下文不仅没有帮助反而成了干扰。不过这种场景属于少数不用一上来就动它。3.5 半精度和初始提示词--fp16 True是指在支持 fp16 的 GPU 上启用半精度计算能显著提升速度且几乎不损失准确率。CPU 上跑就不要开这个参数反而更慢。还有一个非常实用但很多人忽略的参数--initial_prompt。你可以用一段文字告诉模型“这个音频是讲计算机技术的会出现 CUDA、Python 这类词”模型在转写时会把注意力偏向这些领域。我之前处理一批人工智能相关的访谈在 initial_prompt 里塞了一段包含大量专业术语的描述专有名词的识别明显好了不少。这个问题后面在坑点章节里会详细说。我把这些高频参数整理成一个速查表方便你直接抄参数作用我的建议值--model指定模型大小中文首选large-v3--language指定音频语言明确语言必填--output_format输出格式用all--fp16半精度加速GPU 用TrueCPU 用False--word_timestamps词级时间戳默认关闭--initial_prompt初始上下文提示按领域填写--verbose打印过程信息批量时用False--task转写或翻译一般用transcribe4. 批量出稿流水线一个循环搞定几十个音频命令行一条条跑偶尔处理一两个文件没问题但真正要批量出稿时你会发现用脚本来做才是正解。我有一个文件夹每周都会新增四五条访谈录音命名规则是“客户名_日期.m4a”我需要把这些全部转成文字稿和字幕。手工一条条复制命令效率太低所以我写了一个 Python 脚本把批量处理流程固化下来。4.1 第一步录音文件先统一成 16kHz 单声道 wav这一步很多教程不会重点讲但我的经验是它非常值得做。Whisper 虽然能直接读 m4a、mp3但不同格式的采样率和声道数会影响处理效率。尤其是手机录音有的是 48kHz 立体声有的还有奇怪的编码后缀。先用 ffmpeg 统一转成 16kHz 单声道 wav处理速度会快不少而且能规避一些 ffmpeg 解码特定 mp3 编码时的兼容问题。import subprocess import os input_path a.m4a output_path a_16k.wav cmd [ ffmpeg, -i, input_path, -ar, 16000, -ac, 1, -y, output_path ] subprocess.run(cmd, checkTrue)-ar 16000是采样率降到 16000Hz-ac 1是转成单声道-y表示覆盖已有文件。为什么是 16kHz因为 Whisper 训练时使用的就是 16kHz 采样率这是它最熟悉的输入格式相当于把食材切成它最习惯的大小再下锅当然更顺滑。如果你不想在脚本里再调 subprocess也可以直接在 Whisper 转写前用 Python 库实现同样的转换但 ffmpeg 是最稳的建议保留。4.2 第二步批量遍历目录并调用 Whisper这一步是脚本的核心。我用pathlib遍历指定目录下的所有音频文件过滤出扩展名是.m4a、.mp3、.wav的文件然后逐个调用whisper.transcribe()。为什么不直接调命令行而是用 Python API因为命令行每次调用都要重新加载模型处理几十个文件模型反复加载的开销非常可观。用 Python API 可以把模型常驻内存里处理完一个接着处理下一个速度成倍提升。import whisper from pathlib import Path import json model whisper.load_model(large-v3) audio_dir Path(./audio_files) output_dir Path(./output_files) output_dir.mkdir(exist_okTrue) audio_extensions {.m4a, .mp3, .wav, .flac, .m4b} audio_files [f for f in audio_dir.iterdir() if f.suffix.lower() in audio_extensions] failed_files [] for audio_file in audio_files: print(f正在处理: {audio_file.name}) try: # 直接传原文件Whisper 内部会自动加载 ffmpeg 解码 result model.transcribe( str(audio_file), languageChinese, fp16True, verboseFalse ) # 生成纯文本 txt_path output_dir / f{audio_file.stem}.txt with open(txt_path, w, encodingutf-8) as f: f.write(result[text]) # 生成带时间戳的 srt 字幕 srt_path output_dir / f{audio_file.stem}.srt write_srt(result[segments], srt_path) print(f完成: {audio_file.name} - {txt_path.name}) except Exception as e: print(f失败: {audio_file.name} - {e}) failed_files.append(str(audio_file)) with open(output_dir / failed_list.txt, w, encodingutf-8) as f: for item in failed_files: f.write(item \n)注意model.transcribe()里我显式传了languageChinese这是为了避免批量处理时每一条音频都让模型重新做语言检测。还有一个细节是fp16True前提是你的 GPU 支持如果你用的是 CPU这里一定要改成False否则会报错或者更慢。4.3 第三步从 segments 生成可读的 SRT 字幕上面的脚本里我调用了一个write_srt()函数这个函数需要自己实现。SRT 文件的格式是“序号 时间轴 文本”时间轴的格式是小时:分钟:秒,毫秒。从 Whisper 返回的segments列表里可以拿到每一句的start和end字段单位是秒需要转成 SRT 格式def format_timestamp(seconds): millis round(seconds * 1000) hours millis // 3600000 minutes (millis % 3600000) // 60000 secs (millis % 60000) // 1000 ms millis % 1000 return f{hours:02}:{minutes:02}:{secs:02},{ms:03} def write_srt(segments, output_path): with open(output_path, w, encodingutf-8) as f: for i, seg in enumerate(segments, start1): f.write(f{i}\n) f.write(f{format_timestamp(seg[start])} -- {format_timestamp(seg[end])}\n) f.write(f{seg[text].strip()}\n\n)这个函数生成的 srt 文件可以直接拖进剪映或 PR。我刚开始做字幕时踩过一个坑直接拿 Whisper 的 txt 输出当字幕发现时间轴完全对不上因为句子被自动合并了。后来才意识到必须用 segments 而不是 text 字段。这就是理解和会调用的区别。4.4 第四步给交付方看的文稿怎么生成客户的访谈成稿和字幕的需求不太一样。字幕要求句子短、口语化保留成稿要求尽量通顺、去掉口癖、分段清晰。所以我一般会从result[segments]里把每句话抽出再按说话场景拼成段落而不是直接使用 Whisper 输出的整段文字。比如把每次较长的停顿视为一个新段落开始def write_markdown(segments, output_path): with open(output_path, w, encodingutf-8) as f: current_paragraph [] last_end 0 for seg in segments: # 如果句间间隔超过 2 秒则另起一段 if current_paragraph and seg[start] - last_end 2.0: f.write(.join(current_paragraph) \n\n) current_paragraph [] current_paragraph.append(seg[text].strip()) last_end seg[end] if current_paragraph: f.write(.join(current_paragraph) \n\n)这个逻辑的目的是Whisper 本身不做段落划分但通过安静间隙判断能很自然地划分出说话人和话题切换比单纯输出一大坨文字要友好得多。你如果后面还要人工润色这种段落结构也省时间。4.5 批量跑的时候要不要并行脚本写好后很多人会问能不能多线程并行处理多个文件。我的建议是GPU 用户不要并行CPU 用户也不要并行。GPU 上并行处理多个文件并不会让模型吃掉更多显存去同时跑多个任务反而会因为任务切换造成资源浪费。CPU 上并行确实能快一些但 Whisper 的解码过程线程安全方面有坑多线程容易出诡异问题不值得。稳妥的办法是串行处理队列。我实测处理十条 40-60 分钟的音频large-v3 RTX 3060串行跑完大约耗 7-8 个小时晚上挂机跑早上起来收稿完全能接受。5. 实测三个月踩过的坑环境、中文口语和长音频5.1 安装期的三大坑每条都是真实翻车记录先说安装期。第一大坑是 Python 版本兼容性我用 Python 3.12 装了最新版 Whisper跑import whisper没问题但实际调用时报了TypeError一看是torch的兼容性问题当时最新的 PyTorch 还不支持 3.12只能退到 3.10 才消停。这个坑后来随着 PyTorch 更新逐渐少了但如果你遇到诡异的 error先怀疑 Python 版本。第二大坑是 ffmpeg 路径。我一度以为 Windows 上装了 ffmpeg 就行结果在 IDE 里跑脚本时一直报找不到 ffmpeg因为 IDE 自带的环境变量和命令行不共享。最后我在脚本里显式指定了 ffmpeg 路径才彻底解决import whisper whisper.load_model(base) # 如果 ffmpeg 不在 PATH 里可以用这个方式指定但 OpenAI 的 Whisper 包没有直接暴露设置 ffmpeg 路径的参数我的排查思路是确保 ffmpeg 全局可用同时在环境变量里单独加一份路径另外再检查一次 Python 进程加载的 PATH。这个方法比较绕但确实能解决 IDE 和命令行不一致的问题。第三大坑是第一次下载模型卡住。也就是前文说的模型文件太大默认从 OpenAI 的服务器下载网络条件不好的时候经常中断。后来我用国内镜像源或者手动把模型文件放到缓存目录才解决。我这里不展开讲具体的镜像地址因为镜像库变动频繁你只要明白原理先下载好模型文件然后在运行时设置环境变量指向本地缓存目录可以彻底避免下载失败的问题。5.2 中文口语的翻车现场不是 Whisper 不够强是你没喂对它我对中文识别的观察非常细。Whisper 对普通话的识别整体已经相当好但口语场景里还是有几个典型的毛病。第一个是专有名词和生僻词。人名、地名、公司名、产品名尤其是不常见的那种经常会被听成发音相近的常见词。比如“飞书”变成“非书”“飞猪”变成“飞猪”这种稍微好点但“还是那个 Keystone 项目”会变成“还是那个K型项目”。解决这个问题的办法就是前面说的--initial_prompt。我的做法是在处理每一批音频前根据当前项目的主题整理 50 到 100 字的关键词描述塞进 initial_prompt 里。实测下来对于包含领域专有名词的音频这种做法的准确率提升非常明显。第二个是语气词和口癖。Whisper 会把“嗯”“啊”“那个那个”这些词原原本本地转写出来。对字幕来说这是好事能保留说话人停顿的感觉但对交付给客户的成稿这就是噪音。我的处理方法是在成稿脚本里加一个语气词过滤import re noise_words [嗯, 啊, 那个, 就是说, 然后呢, 对吗] def clean_text(text): # 去掉开头和结尾的语气词 text text.strip() for w in [嗯, 啊]: text re.sub(rf^{w}[,.。]?, , text) return text别指望代码能完全清理干净但能把 70% 的明显口癖去掉剩下的交给人工润色。第三个是数字和英文混排。中文访谈里经常出现“我们 2019 年的时候”“Python 那个库”这种中英数字混排。Whisper 对这些内容的处理基本靠谱但偶尔会把英文单词转成中文音译比如“API”变成“A P I”或者“接口”“CPU”变成“中央处理器”这取决于上下文。如果你需要保留原始英文可以在 initial_prompt 里写上“请保留英文原文和技术缩写”会有一定缓解。5.3 长音频处理两小时会议录音的分配策略一条两小时的音频如果直接整个丢给 Whisper即使显存够也容易出现一个问题中途如果发生程序崩溃前面的转写结果全部丢失。我的处理方式非常明确大文件先按 30 分钟一段切分再逐段处理。虽然 Whisper 内部本来就有分段机制但从外部切分有额外的好处——每段独立处理避免了一段错误文本通过上下文条件传递给下一段而且万一某一段失败只需要重新转那一段就行不用整条重跑。切分也可以交给 ffmpegffmpeg -i 长音频.mp3 -f segment -segment_time 1800 -c copy 分段_%03d.mp3-segment_time 1800是每 1800 秒切一段。切分后按前面的批量脚本处理每段最后再用脚本把所有 txt 合并。这个方案的缺点是有可能在切分点处把一个句子拦腰截断Whisper 按整段理解的时候连贯性稍差。不过在实际处理中我很少遇到切分点正好落在语义关键位置的情况整体收益远大于损失。另外一个容易忽略的问题会话中不同说话人。Whisper 不区分说话人它只会一股脑把所有声音转成文字。如果你需要知道某句话是谁说的就得借助说话人分离工具比如 pyannote。但这属于进阶玩法两头同时跑会非常吃资源且配置复杂。我的做法是先用 Whisper 转出完整文字稿再在人工校对时根据音色和上下文手动标注说话人。对大多数场景来说这个成本已经可以接受。5.4 背景音乐、掌声和多人同时说话的干扰访谈里经常有背景音乐尤其播客的开头和结尾。Whisper 在音乐段落的表现是要么生成长长的空白片段要么输出乱写的“歌词”。解决方案不是调参数而是预处理用 ffmpeg 把音频里的音乐片段剪掉或者至少把音乐声压低。最省事的办法是在脚本里自动检测静音段静音段超过一定长度就从有效音频里剔除这样背景音乐处的无效转写会少很多。还有多人同时说话的情况这个目前所有自动转写工具都很难处理Whisper 也不例外。它会把两个人重叠的声音合并成一句输出结果是不可用的。我在处理这种素材时一般会在访谈开始前就和参与者约定“尽量别抢话”这是最有效也最便宜的解决办法。技术上我还没有找到特别好的办法也欢迎有经验的朋友留言交流。6. 从转录到可交付成稿的最终一步降噪、排版和字幕6.1 音频预处理转写之前先好好洗一遍声音质量直接决定了转写效果。同样一段语音用 iPhone 在安静房间录的和用会议室麦克风录的Whisper 的识别准确率可以差出十几个百分点。如果你能做一点预处理后续校对时间能省非常多。最常用的预处理是高通滤波。录音里常见的人声低频噪音、空调嗡嗡声、空调风声可以通过高通滤波把 80Hz 以下的声音切掉人声几乎不受影响。ffmpeg -i 原音频.wav -af highpassf80,lowpassf8000 处理后的音频.wav高通 80Hz 以下低通 8000Hz 以上这样能有效过滤掉大部分环境噪音同时保留人声主要频段。这个处理对转写效果的影响是正向的。如果录音里有明显的背景人声或电视声可以试用降噪工具。开源圈比较火的有 NVIDIA 的 Riva 和 RNNoise但需要单独安装。早期我用过一个简单的 DSDDeep Speech Denoiser方案效果不稳定后来放弃了。我的经验是先去物理环境里减少噪音源比任何软件降噪都管用。如果录音质量实在太差别指望 Whisper 能创造奇迹人工重录往往是最省时间的。6.2 文稿的排版让客户一眼看懂的逻辑转写完成后直接拿 Whisper 的 txt 去交付很多客户会不满意因为满屏语气词、半截句子、缺少分段会让阅读体验非常差。我给自己定了一个交付标准每一段文字至少经过一次润色去掉明显口癖按话题重新换行重要结论和行动项加粗标记。润色不是改写不要改变说话人原意只是把口语变成书面语。具体到排版我习惯把一段话控制在 3 到 5 行内每句话之间空行。如果是访谈稿件还会在每段前加“问/答”标记。对于有明确结构的会议录音我会加“议题 1”“议题 2”这样的标题方便领导快速定位。这些小改动看着不起眼但能显著提高稿件被阅读的可能性。6.3 字幕处理从 srt 到剪映的实用流程如果你做视频Whisper 的 srt 输出可以直接导入剪映。剪映支持直接导入 srt导入后字幕会自动落在时间轴上。导入前最好检查一下 srt 的编码建议 UTF-8 无 BOM有 BOM 的中文 srt 在某些版本的剪映里第一行字幕会变成乱码。万一遇到这种情况用文本编辑器另存为 UTF-8 无 BOM 即可。剪映导入 srt 后我还习惯统一字幕样式字体、描边、字号、位置。Whisper 输出的每条字幕可能长短不一短的只有一两个字长的可能是一整句话。剪映里有“批量修改样式”的功能可以一次性统一风格不用一条条改。6.4 一段完整流程的时间成本算给你看最后给你算一笔账。一条 60 分钟的访谈录音我的完整流程是预处理转 16kHz wav 大约 1 分钟Whisper large-v3 在 RTX 3060 上转写大约 60-70 分钟清洗语气词和排版大约 15 分钟人工校对关键内容大约 30 分钟总计约 2 小时左右。相比之下我手动整理时一条 60 分钟的访谈至少需要 4 到 5 小时。省下的时间不是一点点而且我不需要再付给在线转写服务按分钟计算的费用。这套流水线我已经稳定用了大半年期间也踩过不少坑但把坑都填平之后的收益非常可观。我个人的建议是不要一味追求模型最大、参数最全而是根据你自己的素材特点、机器性能、交付要求去组合一套最顺手的流程。先跑通一条最基本的链路再慢慢往里面加预处理、加排版、加说话人标注每加一个环节都要问自己“这个环节真的帮我省时间了吗”而不是“这个功能看起来很炫”。工具是拿来用的用起来顺、交付得起才是最重要的。