1. 为什么我放弃了“白嫖”，选择自己动手

几年前，我接到一个任务，需要把公司过去几年积累的上百个小时的会议录音、访谈音频整理成文字稿。第一反应和大家一样：上网搜“语音转文字 免费 在线”。结果呢？真是踩了一路的坑。

那些不知名的小网站，确实能让你传个一两分钟的音频试试，感觉挺友好。但真要把几十兆、上百兆的文件传上去，页面要么直接卡死，要么弹出一个大大的付费窗口。更让人心里打鼓的是，这些来路不明的平台，你怎么敢把可能涉及内部讨论的音频文件传上去？隐私和数据安全根本无从谈起。这就像为了省几块钱，把自家钥匙交给路边不认识的人保管一样不靠谱。

于是我把目光转向了大厂。某飞、某讯、某为，这些名字听起来就可靠多了。我一个个试过去，体验却是一言难尽。有的网站，用巨大的“免费”字样把你吸引过去，等你吭哧吭哧上传完几个G的文件，点击“开始转换”的瞬间，弹窗告诉你“试用已结束，请购买套餐”。那种感觉，就像排了半天队，终于轮到你时，窗口关了。不是说它们骗人，商业服务收费天经地义，只是这种“诱导上传再收费”的体验，实在让人不太舒服。

有的国际大厂服务确实规范，明确给出了每月500分钟的免费额度，这很良心。但门槛是必须绑定信用卡。对于很多国内开发者或者没有外币信用卡的朋友来说，这堵墙直接就过不去了。还有的云服务商，提供10小时免费时长，对于轻度用户足够，但对我这种需要处理历史存档的“重度用户”，连塞牙缝都不够。算了一下，如果全部用它们的付费服务，这上百小时的音频处理完，费用得上千元。

最关键的是，那种“受制于人”的感觉很不好。今天有免费额度，明天政策可能就变了；这个月项目紧，处理量暴增，立刻就得为超额部分买单；更不用说，所有音频数据都要流经别人的服务器，尽管大厂承诺安全，但对于一些敏感内容，心里总有个疙瘩。我意识到，当需求变得稳定、量大且对隐私有要求时，继续到处寻找和拼接“白嫖”资源，效率低下且不可持续。是时候把主动权拿回自己手里了。

2. whisper.cpp：没有GPU的电脑也能跑的语音识别引擎

当我决定自建方案时，GitHub上“speech-to-text”主题下，星星最多的项目就是 whisper.cpp。它不是另一个全新的轮子，而是OpenAI那个大名鼎鼎的Whisper模型的纯C++实现。为什么是它？简单说就是三个字：高效率、零依赖、真本地。

Whisper模型本身很强，支持多种语言，识别准确率高，还能区分说话人。但原版是Python写的，依赖PyTorch等一堆库，对硬件要求也高，想跑得快最好有GPU。而whisper.cpp的作者Georgi Gerganov做了一件很棒的事：他用C++重写了核心推理代码，并进行了极致的优化。最大的魅力在于，它不需要GPU，在普通的CPU上就能流畅运行，而且通过量化技术，将庞大的模型压缩到更小，速度更快，内存占用更低。

这意味着什么？意味着你手头那台用了三五年的旧笔记本，或者一台轻量级的云服务器，就能变身成一个靠谱的语音转文字工作站。你不用再去折腾复杂的CUDA驱动、PyTorch版本冲突，也不用担心云端API调用的网络延迟和费用。一切都在你的机器内部完成，数据不出门，隐私有保障，一次部署，无限次使用。

它的工作流程非常清晰。你准备好音频文件（支持wav, mp3, m4a等常见格式），选择好一个下载好的模型文件，运行一个编译好的可执行程序，文字结果就出来了。你可以通过命令行参数灵活控制，比如指定语言（-l zh就是中文），输出带时间戳的文本，或者直接保存成srt字幕文件。对于开发者来说，这种简洁、可控、可脚本化的工具，用起来非常顺手。

我自己的主力机是一台MacBook Pro（Intel芯片），还有一台Windows台式机。我在这两台设备上都成功部署并稳定运行了whisper.cpp。在Mac上直接编译，在Windows上我选择了WSL2（Windows Subsystem for Linux）来创建一个Ubuntu环境，整个过程和纯Linux下几乎一样。下面，我就带你一步步走通这条路。

3. 从零开始：在普通电脑上部署whisper.cpp

别被“C++”、“编译”这些词吓到，整个过程其实比想象中简单。我们一步步来，我以在Windows 10/11上使用WSL2为例，因为这是很多人的主要环境。如果你用macOS或原生Linux，步骤会更简单。

3.1 搭建基础环境：安装WSL2和编译工具

首先，确保你的Windows系统已经开启了WSL2。如果还没安装，打开PowerShell（管理员身份），运行一条命令就行：

wsl --install

这条命令会默认安装Ubuntu发行版。安装完成后，从开始菜单打开“Ubuntu”，它会完成初始化设置，让你创建用户名和密码。

进入Ubuntu终端后，第一件事是更新软件包列表并安装必要的编译工具：

sudo apt update
sudo apt upgrade -y
sudo apt install build-essential cmake git -y

build-essential 包含了GCC编译器、make等核心工具；cmake 和 git 则是获取和构建项目所必需的。这几步是标准操作，就像给新房子通水电一样，是后面一切工作的基础。

3.2 获取代码与“灵魂”：下载模型

环境准备好，就可以把whisper.cpp的源码“克隆”到本地了：

git clone https://github.com/ggerganov/whisper.cpp.git
cd whisper.cpp

接下来是最关键的一步——选择并下载模型。模型是AI的“大脑”，不同的模型在大小、速度和精度上差异巨大。whisper.cpp支持多种规模的模型，从tiny到large，甚至还有更专业的large-v2、large-v3。

模型名称	磁盘大小	内存需求	速度	精度	适用场景
tiny	~75 MB	约400 MB	极快	一般	实时预览、对精度要求极低的场景
base	~142 MB	约500 MB	很快	尚可	日常简单录音、清晰语音快速转录
small	~466 MB	~1.5 GB	快	良好	综合性价比最优，推荐大多数场景
medium	~1.5 GB	~3.5 GB	中等	优秀	会议录音、访谈等复杂音频，追求更高准确率
large	~2.9 GB	~6.5 GB	慢	最佳	学术研究、重要档案转录、多语言混杂音频

怎么选？我个人的经验是：从 small 模型开始。tiny和base在中文识别上，尤其是带有口音或背景噪音时，错误率会明显升高。small模型在精度和资源消耗上取得了很好的平衡，我的老MacBook处理一小时音频，用small模型大概需要15-20分钟，效果已经相当可用。如果你的电脑内存有16G或以上，并且音频内容很重要，直接上 medium 模型，准确度会有可感知的提升。large模型则对硬件要求较高，适合不差时间、追求极致效果的场景。

下载模型也简单，项目提供了脚本。在whisper.cpp目录下运行：

bash ./models/download-ggml-model.sh small

这个脚本会从Hugging Face平台下载对应的模型文件（ggml-small.bin）到 models/ 目录下。如果网络连接不畅，你可能需要多试几次，或者寻找可靠的网络环境。模型只需要下载一次，以后就可以反复使用了。

3.3 编译与第一次运行

模型就位，接下来把源代码变成可以运行的程序。编译过程非常简单：

make

如果一切顺利，几分钟后你就会在目录下看到生成的可执行文件 main。现在，激动人心的时刻来了。找一个测试用的音频文件（比如test.wav），把它放在whisper.cpp目录的同级或任何方便的位置，然后运行：

./main -m models/ggml-small.bin -l zh -f ../test.wav

解释一下这几个参数：

• -m models/ggml-small.bin：指定我们使用的模型文件路径。
• -l zh：告诉模型，音频语言是中文（Chinese）。这能显著提升识别准确率。
• -f ../test.wav：指定要转换的音频文件路径。

回车之后，终端会开始输出识别过程，最后将转写的文字结果显示在屏幕上。看到自己机器“吐出”的第一段文字，那种“自力更生”的成就感，是调用任何API都无法比拟的。

4. 进阶玩法：批量处理与效率提升技巧

单文件测试成功只是第一步。我们面对的更可能是成百上千个音频文件。手动一个个操作不现实，这就需要用到脚本和更多参数技巧。

4.1 编写批量处理脚本

假设我们有一个文件夹 audio_files，里面装满了需要转换的 .mp3 或 .wav 文件。我们可以写一个简单的Bash脚本来搞定它们。在whisper.cpp目录下创建一个新文件，比如叫 batch_convert.sh：

#!/bin/bash

# 定义模型和语言
MODEL_PATH="./models/ggml-small.bin"
LANGUAGE="zh"

# 定义输入音频文件夹和输出文本文件夹
INPUT_DIR="../audio_files"
OUTPUT_DIR="../text_outputs"

# 创建输出目录
mkdir -p "$OUTPUT_DIR"

# 遍历输入文件夹中的所有音频文件
for audio_file in "$INPUT_DIR"/*.{wav,mp3,m4a}; do
  # 检查文件是否存在（避免通配符匹配不到时的错误）
  if [ -f "$audio_file" ]; then
    # 提取文件名（不含路径和扩展名）
    filename=$(basename "$audio_file")
    basename="${filename%.*}"

    echo "正在处理: $filename"

    # 运行whisper.cpp，并将结果输出到文本文件
    ./main -m "$MODEL_PATH" -l "$LANGUAGE" -f "$audio_file" -otxt -of "$OUTPUT_DIR/$basename"

    echo "已完成: $basename.txt"
  fi
done

echo "批量转换全部完成！"

给脚本加上执行权限并运行：

chmod +x batch_convert.sh
./batch_convert.sh

这个脚本会自动为每个音频文件生成一个同名的 .txt 文本文件，保存在 text_outputs 文件夹里。参数 -otxt 表示输出纯文本格式，-of 则指定输出文件的前缀名。

4.2 实用参数详解：让输出更符合你的需求

whisper.cpp提供了丰富的参数，让结果更贴合你的使用场景。这里介绍几个我最常用的：

• 输出带时间戳：-ots 参数可以输出每个词段（segment）的起始时间。这对于制作字幕或者需要对照音频位置的情况非常有用。

  ./main -m models/ggml-small.bin -l zh -f test.wav -ots
  

  输出格式类似：[00:00.000 --> 00:04.000] 大家好，欢迎收看今天的节目。

• 直接生成字幕文件：-osrt 参数可以直接生成标准的 .srt 字幕文件，能被各种视频播放器和剪辑软件识别。

  ./main -m models/ggml-small.bin -l zh -f test.wav -osrt
  

• 控制处理线程：如果你的CPU核心数多，可以用 -t 参数指定使用的线程数，加快处理速度。例如，8核CPU可以设为6或8。

  ./main -m models/ggml-small.bin -l zh -f test.wav -t 6
  

• 处理超长音频：默认情况下，模型对超长音频的上下文理解有限。使用 -c 参数可以增加上下文长度（单位是token），有助于提升长文本文档的连贯性，但也会增加内存消耗。

  ./main -m models/ggml-small.bin -l zh -f long_lecture.wav -c 2048
  

把这些参数组合进你的批量脚本，就能打造一个完全适应你工作流的自动化转录流水线。我通常会用 -osrt 生成字幕文件，再用文本编辑器打开 .txt 文件进行最终校对和整理，效率比手动听打高了不止一个数量级。

5. 结果不是终点：后处理与“AI幻觉”应对

当你兴冲冲地打开转换好的文本，可能会发现两个问题：一是有些小错误，比如同音别字、专业术语识别不准；二是偶尔会出现一些完全无关的、奇怪的句子，比如我原文里提到的“【请不吝点赞 订阅 转发...】”，这就是所谓的 “AI幻觉”。别担心，这是正常现象，我们有办法应对。

5.1 必要的校对与润色

首先必须明确，目前没有任何一个全自动语音转文字方案能达到100%准确，尤其是面对口音、专业词汇、多人交谈或嘈杂环境。whisper.cpp的输出是一个优秀的“初稿”，能帮你完成90%甚至95%的工作，但最后的5%-10%需要人工介入。

我的校对流程一般是：

1. 快速通读：先不看音频，快速浏览一遍文本，修改那些明显的错别字和语序不通的地方。很多错误凭上下文就能判断。
2. 重点聆听校对：对于专业名词密集、或者听起来逻辑不顺的段落，回头去听原音频，进行精确校正。这时候，之前生成的带时间戳的文本或SRT文件就派上大用场了，可以快速定位到音频的具体位置。
3. 格式整理：去除识别中可能产生的多余空格、奇怪的断句，按照最终文档要求（如段落划分、发言人标记等）进行排版。

这个过程听起来繁琐，但相比从零开始听写，已经节省了巨量的时间和精力。你可以把它看作是与AI协作：AI负责繁重的听记初稿，你负责发挥人类在语义理解和上下文判断上的优势，进行最终的质量把关。

5.2 理解与规避“AI幻觉”

“AI幻觉”是生成式AI模型的一个已知特性，它可能会“脑补”出一些训练数据中常见、但当前音频中并不存在的内容。在语音识别中，这通常表现为插入一些广告语、节目口播、网络常用句等。

如何减少它的影响？

1. 使用更大的模型：medium或large模型由于训练更充分、参数更多，产生幻觉的概率通常比small或tiny模型要低。
2. 提供语言提示：-l zh参数已经是一种很强的提示。确保音频语言设置正确。
3. 保持音频质量：清晰、噪音少的音频能让模型更专注于真实内容，减少“猜”的空间。如果原始录音质量差，可以先用一些音频降噪工具（如开源工具Audacity）进行预处理。
4. 后处理过滤：对于批量处理的结果，可以写一个简单的脚本，查找并标记或删除那些包含常见幻觉短语（如“点赞”、“订阅”、“关注我们”等）的句子，提醒人工重点检查。

坦然接受AI的不完美，把它当作一个能力超强但偶尔会“走神”的助手。通过模型选择、参数优化和人工校对这个组合拳，我们完全能获得一份高质量、可用的转录文本。

6. 方案对比与长期维护

自建方案听起来美好，但它适合所有人吗？我们来和云端API服务做个直观的对比。

对比维度	云端API服务（如某讯、某飞）	本地whisper.cpp方案
启动成本	低。注册账号，有时有免费额度。	中。需要基础技术知识，部署约需1小时。
边际成本	高。按使用量（时长/次数）付费，用量越大成本越高。	近乎为零。一次性部署后，电费是主要成本。
隐私安全	依赖服务商承诺，数据需上传至外部服务器。	极高。数据全程在本地处理，不出设备。
定制灵活性	低。受限于API提供的功能和参数。	高。可任意修改代码、调整参数、集成到自有系统。
网络依赖	必须。断网或服务不稳定则无法使用。	无。完全离线运行。
处理速度	快（依赖网络和服务端性能）。	取决于本地CPU性能，可接受至较快。
长期可用性	存在服务变更、涨价、停服风险。	完全自主控制，可持续使用。

从这个对比可以清晰看出，whisper.cpp本地方案的核心优势在于隐私、成本和长期可控性。它特别适合：

• 处理敏感或机密音频内容的个人或团队。
• 有长期、大批量转录需求的用户，能摊薄初始部署成本。
• 开发者或技术爱好者，希望将语音识别能力深度集成到自己的应用中。
• 在网络条件不稳定或无法连接外网的环境下工作。

关于长期维护，其实非常简单。whisper.cpp项目非常稳定，一次部署，基本可以一直用下去。主要关注两点：一是模型更新，Whisper官方可能会发布更强大的新模型（如large-v3），你可以关注社区，下载新模型文件替换旧的，可能获得准确率提升；二是项目更新，偶尔用 git pull 拉取一下whisper.cpp的最新代码，重新执行 make 编译，可以获取一些性能优化和Bug修复。

从到处寻找免费额度，到被各种付费墙和隐私顾虑困扰，最终在自己的电脑上搭建起一个完全受控、高效可用的语音转录环境，这个过程带给我的不仅仅是完成了任务。它更是一种思维转变：从单纯的“消费者”转向“建设者”。你获得的不仅仅是一个工具，而是一种将前沿AI能力内化、私有化的能力。当你的机器开始为你“聆听”并“记录”时，那种自由和踏实感，是任何云端服务都无法给予的。如果你也有类似的批量转录需求，并且对数据隐私和长期成本有所考量，那么投入一个下午的时间，搭建属于你自己的whisper.cpp，绝对是一笔值得的投资。