Whisper+LLM本地搭建语音转文字清理工作流

先说一下我自己的使用背景。最近在整理录音笔记和口述草稿时，频繁在“语音转文字 → 内容清理”这两步之间来回折腾。腾讯会议导出的转写稿口语词太多，在线工具又总担心隐私问题，尤其涉及未公开方案和客户信息时，根本不敢往外传。于是我开始研究完全本地化的听写方案，核心思路是把 OpenAI 开源的 Whisper 语音识别模型和大语言模型（LLM）结合起来：先用 Whisper 把录音转成带口语词的原始文本，再用本地 LLM 做清理、断句、去口头禅，最终输出一份干净的 Markdown 笔记。这个思路英文社区里有一个叫 Dictata 的项目专门做了落地实现。

本文会围绕 Dictata 的核心理念展开，先梳理 Whisper 和 LLM “转录 + 清理”这套架构，然后给出一套可以直接照着跑起来的本地环境搭建方案，包含完整命令、提示词设计、Python 脚本示例以及高频报错排查。不管你是为了做会议纪要，还是想搭建私人语音笔记工作流，都能在这篇文章里找到可以复用的参考。

1. 背景与核心概念：为什么需要 Dictata 这种本地听写方案

1.1 传统语音转文字方案的痛点

先看一个常见场景。你开完一场 40 分钟的会议，拿到一份转写稿，结果发现：

• 通篇都是“然后”、“就是说”、“那个”这类口头禅；
• 标点符号乱得离谱，大量内容挤在一起；
• 一段话里穿插着好几个语气词，连 AI 都分不清谁是主语；
• 关键数字和专有名词错得比较离谱。

如果使用在线听写服务，比如讯飞、腾讯会议、Google Speech-to-Text，虽然识别率很高，但存在几个现实问题：

1. 隐私边界不清晰：音频和转写文本默认会经过云端，对于企业用户来说存在合规风险；
2. 成本随时长线性增长：按分钟计费，长期使用并不便宜，而且几乎不保留历史文本的清理能力；
3. 口语清理能力不足：大部分转写服务给出的是“一个人读到文字稿”，没有自动去掉冗余口语词的能力；
4. 离线场景无法使用：没有网络或者网络质量差时，识别体验会断崖式下降。

1.2 Whisper 是什么：语音识别的本地化基石

Whisper 是 OpenAI 开源的一个通用语音识别模型，它的核心特点是“通用”和“鲁棒性”。它支持多语言语音识别、翻译，并且对背景噪声、口音、专有名词有一定的容忍度。Whisper 提供了多个大小的模型，从tiny、base、small、medium到large，逐级提升识别精度，同时也逐步提升算力需求。

它解决的关键问题是：把“语音转文字”这一步变成可以完全本地运行的模块。你不需要把音频上传到任何服务器，用自己的 GPU 或者 CPU 就能完成转录。

1.3 LLM 清理：把转写稿变成干净文字

Whisper 输出的是识别文字，但实际使用中，它几乎不会帮你清理口语废词。当你说“然后呢，就是那个，我觉得应该要改一下”，Whisper 输出的文本大概率是“然后呢就是那个我觉得应该要改一下”，标点符号也可能不对。

LLM 清理（LLM Cleanup）要做的就是第二件事：让大语言模型基于提示词（Prompt）对 Whisper 的输出进行润色。它的任务包括：

• 删除“嗯”、“啊”、“然后就是”、“就是说”之类的语气填充词；
• 修正明显错误的标点符号；
• 对冗长片段做适度断句；
• 识别并修正常见同音错别字；
• 把口头语转成书面表达，但保留原始语义。

这一步如果使用本地 LLM，整个链路就完全离线了，既保护隐私，又不受网络限制。

1.4 Dictata 的组合思路

Dictata 这类工具本质上就是一套“Whisper 转录 + LLM 清理”的组合工作流，它的创新点不在于某个 AI 模型，而在于把开源模型串联成一条本地闭环：

录音/音频文件 ↓ Whisper 语音识别（本地转录，输出初稿文本） ↓ LLM 清理（Prompt 润色，去除口头禅、重排标点、格式化为 Markdown） ↓ 干净的笔记/会议纪要/待办事项

在这个架构里，Whisper 负责“听得懂”，LLM 负责“写得好”。两者缺一不可：没有 Whisper，音频无法变成文字；没有 LLM，转写稿无法被二次加工，阅读成本很高。

1.5 适用场景

这套方案比较适合以下场景：

• 记者、博主、学生党整理访谈录音或课堂录音；
• 开发者在不开 IDE 的情况下快速记录思路；
• 需要处理客户录音、内部会议录音但不愿意上传云端的职场人群；
• 对听写内容有格式要求（Markdown 输出）的笔记爱好者。

2. 环境准备与版本说明

在开始搭建之前，先梳理整体的工具链。为了让你能快速判断需要安装哪些东西，我列了一份“必须组件”和“可选组件”清单。

这里说明一点：版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。由于 Whisper 和 Ollama 的版本迭代速度都比较快，我不会把每个版本号写死，而是给出相对稳定的安装和配置方式。

2.1 操作系统建议

推荐在 Ubuntu 22.04、macOS 13+ 或 Windows 10/11 的 WSL2 环境中操作。如果你用的是 Windows 原生终端，建议优先启用 WSL2，因为后续编译音频处理库时 WSL2 比 Windows 原生环境省事很多。

2.2 Python 环境准备

建议使用venv创建独立的虚拟环境，避免和系统 Python 包冲突。

# 创建项目目录 mkdir -p ~/dictata-demo cd ~/dictata-demo # 创建虚拟环境 python3 -m venv venv # 激活虚拟环境 source venv/bin/activate # Windows WSL / Linux / macOS # 如果是 Windows CMD，使用 venv\Scripts\activate

激活虚拟环境后，后续所有 Python 包安装都在虚拟环境中完成。

2.3 安装 FFmpeg

FFmpeg 是一个处理音频和视频的开源工具，faster-whisper 依赖它来解码多种音频格式。

Ubuntu/Debian：

sudo apt update sudo apt install ffmpeg

macOS：

brew install ffmpeg

Windows（WSL 已覆盖），在 WSL 里执行上面的 Ubuntu 命令即可。

安装完成后验证：

ffmpeg -version

能打印出版本信息，说明安装成功。

2.4 安装 faster-whisper

faster-whisper 是 Whisper 模型在 CTranslate2 上的重新实现，推理速度比原始 Whisper 快很多，显存占用也更低。它已经成为社区里比较主流的 Whisper 使用方式。

pip install faster-whisper

这里不锁定版本号，因为 faster-whisper 会跟随 CTranslate2 随后端更新。如果安装过程中出现依赖冲突，可以优先尝试把 CUDA 相关库（如nvidia-cublas-cu12）升级到当前环境支持的版本。

2.5 安装 Ollama（本地 LLM 运行环境）

Ollama 是目前在本地跑大语言模型比较省事的工具，一条命令就能拉起一个支持 OpenAI API 兼容接口的服务。

macOS / Linux 安装：

curl -fsSL https://ollama.com/install.sh | sh

Windows 版本直接前往 Ollama 官网下载安装包即可。

安装完成后，拉取一个适合 CPU/GPU 运行的中文模型。以qwen2.5:7b为例：

ollama pull qwen2.5:7b

对于显存比较紧张的用户，也可以选择qwen2.5:3b或llama3.2:3b。这一步会下载几个 GB 的模型文件，建议安排在网速较好的时段执行。

启动 Ollama 服务：

ollama serve

验证服务状态：

curl http://localhost:11434/api/tags

如果返回一段 JSON，其中包含已经下载好的模型列表，就说明 Ollama 已经准备好了。

3. 核心原理拆解：Whisper 转录与 LLM 清理如何协同工作

在动手写代码之前，有必要先把两个核心模块的原理拆开讲清楚。理解了原理，之后遇到问题才知道该去哪一层排查。

3.1 Whisper 的转录流程

Whisper 模型的输入是音频，输出是文本。它内部经历了几个阶段：

1. 音频预处理：把音频切成 30 秒一段，并转换成梅尔频谱图（Mel Spectrogram），这是语音识别模型的标准输入。
2. 编码器（Encoder）处理：把梅尔频谱图编码成一组特征向量。
3. 解码器（Decoder）生成文本：基于特征向量逐 token 生成转录文本，同时可以输出时间戳。

使用 faster-whisper 时，我们主要关心几个关键参数：

一个最简单的转录代码只需求十几行：

# 文件路径：transcribe.py from faster_whisper import WhisperModel # 加载模型，这里以 small 为例 model = WhisperModel( "small", device="cuda", # 没有 GPU 改成 "cpu" compute_type="float16" # CPU 改成 "int8" ) segments, info = model.transcribe( "meeting.mp3", language="zh", beam_size=5 ) for segment in segments: print(f"[{segment.start:.2f}s -> {segment.end:.2f}s] {segment.text}")

这段代码的作用是：加载 Whisper small 模型，读取meeting.mp3，按中文识别，并逐段打印带时间戳的转录文本。

实际运行后你会发现，Whisper 输出的文本中口语词基本全部保留，比如“然后呢”、“就是”、“就是说”等等。这就是为什么需要 LLM 清理。

3.2 LLM 清理的核心：提示词设计

LLM 清理并不是简单地让大模型“帮我校对一下”，而是要通过提示词明确指定处理规则。如果提示词写得模糊，LLM 可能给你改写出一篇“思想正确但已经不是原话”的文字，完全失去转写稿作为原始记录的价值。

一个比较有效的清理提示词应该包含下面几点：

1. 角色定位：告诉 LLM 它是什么任务的角色；
2. 输入类型：说明输入是语音识别软件的原始输出，存在口语词和标点混乱；
3. 处理规则：明确可以删除什么、保留什么、修正什么；
4. 输出格式：指定输出为 Markdown 或纯文本；
5. 禁止事项：强调不要补充原文不存在的信息，不要改写成书面作文。

下面是一段可以直接用于 Ollama 调用的提示词示例：

你是一个专业的语音转写稿清理助手。 请对用户输入的语音识别原始文本进行清理，要求如下： 1. 删除“嗯”、“啊”、“然后”、“就是说”、“那个”等口语填充词； 2. 修正明显错误的标点符号和断句； 3. 保留原文的语义和信息，禁止添加原文中不存在的内容； 4. 保留专有名词、数字、英文缩写，不做修改； 5. 如果一段话太口语化，可以改写为更书面化的表达，但不要改变原本的意思； 6. 最终输出为 Markdown 格式，使用短段落和必要的列表。 禁止输出任何额外解释，直接输出清理后的文本。

这个提示词的关键在于“保留原文语义”和“禁止添加额外内容”，否则 LLM 很容易自由发挥。实际项目里，你可以把这段提示词写入一个单独的文件，方便反复调用。

3.3 选择合适的本地 LLM

本地 LLM 的模型选择会直接影响清理效果。

• 如果电脑有 8GB 以上显存，推荐qwen2.5:7b或llama3.1:8b；
• 如果只有 16GB 内存但无独显，可以尝试qwen2.5:3b，速度会慢一点，但清理口语词这类轻量任务完全够用；
• 如果显存达到 24GB，可以上更大的模型，效果更稳定。

对于清理任务，不需要代码生成能力，也不需要数学推理能力，所以不需要刻意追求超大模型。恰恰相反，小模型速度快、占用低，更适合做文本清理这种“轻量重活”。

3.4 完整的数据流拆解

把 Whisper 和 LLM 串联起来之后，整体数据流可以这样理解：

audio.mp3 ↓ faster-whisper 转录 raw_text.txt（口语词多，标点乱，无格式） ↓ Ollama + qwen2.5 清理（按提示词规则） clean_note.md（干净、有标点、Markdown 格式）

如果其中任何一步出了问题，定位方向很明确：转录错是 Whisper 的问题，清理错是 LLM 提示词或模型的问题。

4. 完整实战：搭建本地录音听写与清理流程

接下来从头搭建一个最小可运行的 Dictata 式工作流。整个项目只需要两个 Python 文件和一个音频文件就能跑通。

4.1 创建项目结构

dictata-demo/ ├── venv/ # Python 虚拟环境 ├── audio/ │ └── meeting.mp3 # 待转录音频 ├── transcribe.py # Whisper 转录脚本 ├── cleanup.py # LLM 清理脚本 ├── prompt.txt # 清理提示词 └── requirements.txt # 依赖清单

requirements.txt内容如下：

faster-whisper requests

在虚拟环境中安装依赖：

pip install -r requirements.txt

4.2 编写 Whisper 转录脚本

# 文件路径：transcribe.py from faster_whisper import WhisperModel def transcribe(audio_path: str, output_path: str) -> None: """ 使用 faster-whisper 将音频转写为文本并保存。 """ # 初始化模型，device 可按实际环境调整为 "cpu" model = WhisperModel( "medium", device="cuda", compute_type="float16" ) # 转录音频 segments, info = model.transcribe( audio_path, language="zh", beam_size=5, vad_filter=True # 打开 VAD 过滤，跳过静音段 ) # 拼接转录结果 lines = [] for segment in segments: text = segment.text.strip() if text: lines.append(f"[{segment.start:.2f}s] {text}") # 保存到文件 with open(output_path, "w", encoding="utf-8") as f: f.write("\n".join(lines)) print(f"转录完成，共 {len(lines)} 段，结果已保存至 {output_path}") if __name__ == "__main__": transcribe("audio/meeting.mp3", "output/raw_text.txt")

这里需要注意几个细节：

• vad_filter=True会过滤掉音频中的静音段，减少无效输出；
• language="zh"明确指定语言为中文，避免模型花时间在语种检测上；
• 输出格式带时间戳，后续如果需要回放定位内容会非常方便。

在运行之前，需要先创建输出目录：

mkdir -p output

然后运行：

python transcribe.py

如果一切正常，你会在output/raw_text.txt中看到类似下面的结果：

[0.00s] 好那我们现在开始讨论一下方案 [5.20s] 然后就是说这个项目的话目前主要有两个模块 [15.80s] 一个是数据接入一个是数据清洗

4.3 编写 LLM 清理脚本

清理脚本通过 HTTP 请求调用本地 Ollama 服务，把原始转录文本和提示词一起发送给模型，最终获得清理后的 Markdown 文本。

# 文件路径：cleanup.py import requests import json OLLAMA_URL = "http://localhost:11434/api/generate" MODEL_NAME = "qwen2.5:7b" def load_prompt(path: str) -> str: """读取提示词文件""" with open(path, "r", encoding="utf-8") as f: return f.read().strip() def cleanup_text(raw_text: str, prompt: str) -> str: """ 调用 Ollama 本地模型进行文本清理。 """ payload = { "model": MODEL_NAME, "prompt": f"{prompt}\n\n{raw_text}", "stream": False, # 非流式输出，直接拿到最终结果 "temperature": 0.2 # 降低温度，减少自由发挥 } response = requests.post( OLLAMA_URL, json=payload, timeout=600 ) response.raise_for_status() data = response.json() return data.get("response", "").strip() def main(): prompt = load_prompt("prompt.txt") with open("output/raw_text.txt", "r", encoding="utf-8") as f: raw_text = f.read() cleaned = cleanup_text(raw_text, prompt) with open("output/clean_note.md", "w", encoding="utf-8") as f: f.write(cleaned) print("清理完成，结果已保存至 output/clean_note.md") print("---预览---") print(cleaned) if __name__ == "__main__": main()

这段代码里有一个容易被忽略的点：temperature参数。温度越高，模型输出越有创造力，但同时越容易出现“改写过头”的风险。对于口语清理这类任务，建议把温度控制在0.2到0.3之间，保证模型输出稳定、忠于原文。

4.4 创建提示词文件

# 文件路径：prompt.txt 你是一个专业的语音转写稿清理助手。 请对用户输入的语音识别原始文本进行清理，要求如下： 1. 删除“嗯”、“啊”、“然后”、“就是说”、“那个”等口语填充词； 2. 修正明显错误的标点符号和断句； 3. 保留原文的语义和信息，禁止添加原文中不存在的内容； 4. 保留专有名词、数字、英文缩写，不做修改； 5. 如果一段话太口语化，可以改写为更书面化的表达，但不要改变原本的意思； 6. 最终输出为 Markdown 格式，使用短段落和必要的列表。 禁止输出任何额外解释，直接输出清理后的文本。

4.5 运行并验证

依次执行：

python transcribe.py python cleanup.py

清理后的clean_note.md大致会是这样：

好，我们现在开始讨论一下方案。 目前这个项目主要有两个模块： - 数据接入 - 数据清洗

对比原始的raw_text.txt，你会明显发现：

• 口语填充词被删除了；
• 句子被正确断句并加上标点；
• 内容被整理成带列表结构的 Markdown 格式；
• 原文语义没有缺失。

这就是 Whisper + LLM cleanup 这套组合的核心价值。

4.6 批量处理多个音频文件

如果你有多个音频文件，可以写一个批处理脚本，依次执行转录和清理：

# 文件路径：batch_process.py import os from transcribe import transcribe from cleanup import cleanup_text, load_prompt DATA_DIR = "audio" OUTPUT_DIR = "output" PROMPT = load_prompt("prompt.txt") for filename in os.listdir(DATA_DIR): if not filename.endswith((".mp3", ".wav", ".m4a")): continue base_name = os.path.splitext(filename)[0] audio_path = os.path.join(DATA_DIR, filename) raw_path = os.path.join(OUTPUT_DIR, f"{base_name}_raw.txt") clean_path = os.path.join(OUTPUT_DIR, f"{base_name}_clean.md") print(f"正在处理: {filename}") transcribe(audio_path, raw_path) with open(raw_path, "r", encoding="utf-8") as f: raw_text = f.read() cleaned = cleanup_text(raw_text, PROMPT) with open(clean_path, "w", encoding="utf-8") as f: f.write(cleaned) print("全部处理完成")

这个脚本会自动扫描audio目录下的所有音频，并生成对应的原始转录稿和清理后文稿。

5. 常见问题与排查思路

实际操作中，最容易踩坑的地方集中在环境依赖、模型加载、Ollama 调用和清理效果这四类。我整理了高频问题供你对照排查。

5.1 转录结果全是英文或中英混杂

这种情况基本是language参数没生效。faster-whisper 会自动检测语言，但检测结果有时不准。解决方案是强制指定语言：

segments, info = model.transcribe( audio_path, language="zh", task="transcribe" # 明确是转写任务，不是翻译任务 )

注意task="translate"会把中文翻译成英文，如果只需要转写，务必设置成transcribe。

5.2 LLM 清理时额外补充了原文没有的信息

这是最让人头疼的问题。大模型有“补全”的倾向，当提示词不够严格时，它可能自作主张地加入一些常识或解释。

我的做法是：

1. 在提示词里加一行 “如果原文信息不完整，请保留不完整状态，不要补充缺失内容”。
2. 降低温度，比如temperature=0.1。
3. 对输出结果做人工抽查，重点关注专有名词、数字和时间。

5.3 本地模型在处理长文本时速度明显下降

当转录文本超过几千字时，Ollama 的推理速度会明显变慢，甚至可能超出 API 超时时间。

解决方案有两个：

1. 按段落批次清理，而不是一次性把整篇文本都塞进去；
2. 先按时间戳切分文本，每 500 字左右清理一次，最后拼接结果。

5.4 faster-whisper 下载模型时被卡住

faster-whisper 模型默认从 Hugging Face 下载，部分地区网络连接不稳定。你可以在环境变量中指定镜像：

export HF_ENDPOINT=https://hf-mirror.com

然后再重新运行转录脚本。

6. 最佳实践与工程建议

一个能跑的 Demo 和一套能长期使用的本地听写工作流之间，还有不少工程层面的差距。下面是我实践下来觉得比较重要的几点。

6.1 模型选择要按机器配置“分层”

如果你的电脑只有 CPU，建议用small或base模型，LLM 选择qwen2.5:3b，这样能保证基本可用；如果有一张 6GB 以上显存的显卡，转录模型可以用medium，LLM 上qwen2.5:7b；显存超过 12GB，large-v3转录 +qwen2.5:14b清理的效果会比较理想。

有一点需要提醒：模型并不是越大越好。在录音环境比较嘈杂的时候，large-v3的识别质量提升明显；在录音质量已经很高的情况下，small和medium的差别没有想象中那么大，但速度差距却是成倍的。

6.2 用 VAD 过滤静音段，减少无效转写

在实际录音里，每个人说话之间都有停顿。faster-whisper 默认支持 VAD（语音活动检测），推荐开启：

segments, info = model.transcribe( audio_path, language="zh", vad_filter=True, vad_parameters={"min_silence_duration_ms": 500} )

这样做的好处是减少静音段被强制转录成无意义文字的概率，同时也能提升转录速度。

6.3 把提示词视为代码来维护

提示词是 LLM 清理效果的核心，但它很容易随着调试而变得混乱。建议把提示词单独抽成文件，纳入 Git 版本管理，每次改动都记录一下“为什么改”。例如：

• V1：基础清理，去掉口语词；
• V2：增加“禁止补充缺失信息”约束；
• V3：增加 Markdown 列表输出要求。

长期来看，这比在 Python 代码里硬编码提示词更容易维护。

6.4 保留原始转录稿

LLM 清理过程存在“改写过度”的风险，所以不要让清理后的文本覆盖原始转录稿。建议把两个文件都保存下来，方便后续核对。

推荐的目录结构：

output/ ├── 2025-01-15_meeting_raw.txt ├── 2025-01-15_meeting_clean.md ├── 2025-01-16_interview_raw.txt └── 2025-01-16_interview_clean.md

6.5 监控 Ollama 服务状态

如果清理脚本长时间没有响应，首先检查 Ollama 进程是否还活着：

ps aux | grep ollama curl http://localhost:11434/api/tags

如果 Ollama 服务正常但响应慢，看下系统内存和显存占用。Ollama 在加载大型模型时内存占用可能飙升，如果系统内存吃紧，换用更小的模型是性价比最高的选择。

6.6 考虑多级处理的扩展方案

当你有大量录音文件需要处理时，可以进一步升级这套架构：

1. 队列化：把音频文件放入消息队列，使用多个 worker 并行转录；
2. 增量处理：记录断点，录音文件新增时只处理增量部分；
3. 关键词标签：转录后用 LLM 提取关键词和待办事项，直接生成结构化文档；
4. 全文检索：把清理后的 Markdown 存入本地知识库，配合向量检索做语义搜索。

6.7 安全与隐私边界

虽然这套方案整体本地化，但仍要注意：

• 确保output目录权限正确，转录稿和清理稿可能包含敏感信息；
• Ollama 默认监听本机端口，不要直接暴露到公网；
• 如果部署在多人共享的开发机上，建议为 Ollama 增加访问控制；
• 涉及合规审计的项目，不要仅依赖 LLM 清理结果，原始录音文件也要按规定留存。

7. 实战经验小结

Whisper + LLM cleanup 的“转录 + 清理”工作流并不复杂，但使用体验和工具安装的完成度关系密切。在实践过程中，我有几个比较深的感受：

• 不要在一开始就追求最完美的模型和最好的清理效果，先跑通最小闭环，再逐步优化模型和提示词，这是最稳妥的路径。
• Whisper 转录的质量决定了 LLM 清理的上限。如果 Whisper 把关键人名和数字识别错了，LLM 很难从上下文里“猜”出正确内容。
• 把提示词当成策略文件来维护，比反复在代码里改字符串要靠谱得多。

如果你也经常需要处理大量录音，建议按本文的流程亲手搭建一遍，把transcribe.py、cleanup.py和prompt.txt调整为适合自己场景的版本。

下一步，你可以试着把这套工作流接入 Obsidian 或任意 Markdown 笔记工具，这样录音结束后，本机会自动生成一份格式干净的听写稿，省去从录音到成稿之间的大量手动整理时间。