用 WorkBuddy 在纯 CPU 笔记本上跑本地语音转写：会议录音不出门 #WorkBuddy#

适用人群：经常要整理会议录音、访谈录音，但对数据出本地有硬要求的人（法务、财务、涉密项目、医院/学校内部会议）。 本文给出一条实测可跑通的路线：不买独显、不租云 GPU、不调用任何在线转写 API，用一台普通办公本把 1 小时录音转成带标点的中文文稿，并把整条链路封装成 WorkBuddy 可复用技能。

一、为什么要本地转写

在线转写服务便宜、准确率也高，但有两个绕不过去的坎：

1. 保密：会议里常有未公开的报价、人员、合同信息，音频上传等于把底牌交出去。
2. 成本与配额：长音频按分钟计费，团队一年下来并不便宜；免费额度还经常限时长。

本地转写的收益正好相反：一次装好，永久免费，数据不出机器。代价是要接受"慢一点"——而慢是可以靠流程消化的（后面讲）。

二、技术选型：CPU 上怎么做

核心结论先给：

• 引擎选 faster-whisper（CTranslate2 推理后端），比原版 whisper 在 CPU 上快数倍，内存占用也更低。
• 模型选 distil / small / medium 三档按需切换：日常口音标准的中文会议，small 够用；对外正式纪要，上 medium 或更大。
• 量化格式选 int8：CPU 上速度提升明显，精度损失在人耳可接受的范围内。
• 大模型不要硬上：在没有独立显卡的机器上，large 系列会让 1 小时录音跑到几小时，性价比崩掉。

一个经验数字：1 小时中文录音，small int8 在中端 CPU 上大约 15~30 分钟出稿。所以正确姿势是"丢进后台，干别的活，回来取稿"。

三、落地步骤（含命令）

步骤 1：准备隔离环境

不要把依赖装进系统 Python，装坏了很难收拾。建一个独立虚拟环境：

python -m venv .venv-stt
# 激活（Windows）
.venv-stt\Scripts\activate
# 激活（macOS / Linux）
source .venv-stt/bin/activate

步骤 2：安装引擎

pip install faster-whisper

首次运行会自动下载模型权重（几百 MB 到 1 GB 级，取决于档位）。模型缓存目录记得指到大容量盘，别塞满系统盘：

# 用环境变量指定缓存位置（示例目录，请替换成你自己的路径）
set HF_HOME=<你的模型缓存目录>

步骤 3：写一个转写脚本

新建 transcribe.py，核心就几行：

# transcribe.py —— 本地语音转写（CPU / int8）
import sys
from faster_whisper import WhisperModel

audio = sys.argv[1]                        # 输入音频路径
model_size = sys.argv[2] if len(sys.argv) > 2 else "small"

model = WhisperModel(model_size, device="cpu", compute_type="int8", cpu_threads=8)

segments, info = model.transcribe(
    audio,
    language="zh",
    vad_filter=True,                       # 静音切分，长录音必开
    vad_parameters=dict(min_silence_duration_ms=500),
    beam_size=5,
    initial_prompt="以下是普通话会议记录，请使用简体中文与正确标点。",
)

with open(audio + ".txt", "w", encoding="utf-8") as f:
    for seg in segments:
        f.write(f"[{seg.start:7.1f} → {seg.end:7.1f}] {seg.text.strip()}\n")
print("done ->", audio + ".txt")

三个参数值得解释：

• vad_filter=True：自动跳过静音段。会议录音里静音可能占到三四成，开了它等于白捡加速。
• initial_prompt：中文场景的准确率开关。它会让模型倾向输出简体中文和标点，显著减少"中英混排""全文无标点"的毛病。
• cpu_threads：设成物理核心数（不是超线程数）通常最快，设太大反而因调度开销变慢。

步骤 4：批处理整个目录

一条命令批量跑完：

for f in ./audio/*.m4a; do python transcribe.py "$f" small; done

如果是长会议，建议按录音文件并行度设为 1（一次跑一个），避免 CPU 抢占导致风扇狂转、单任务都变慢。

步骤 5：接进 WorkBuddy 做成可复用技能

把上面的流程写成一个 skill（技能），约定触发短语，例如"本地转写""音频转文字"。之后只要把音频丢进指定目录、说一句话，WorkBuddy 就会：

1. 检查环境是否就绪（虚拟环境、模型缓存是否在位）
2. 逐个文件调用转写脚本
3. 把产出按"日期+主题"命名归档
4. 失败时明确告诉你卡在哪一步（失败可见，不静默吞掉）

这一步是整条链路的关键：脚本负责稳定，技能负责编排。脚本只管"给定音频出文本"，技能负责排队、命名、异常上报，两者解耦，换项目不用重写。

四、踩坑清单

• 中文没标点、中英混杂：九成是没设 initial_prompt，加上就行。
• 长音频内存飙升：开 vad_filter，并且不要一次性把整个音频读进内存自己切分，交给引擎分段处理。
• 笔记本烫手 / 降频：限制 cpu_threads，并保证进风口不被遮挡；长时间批处理建议插电运行。
• 系统盘被模型撑满：模型缓存与输出文稿都指向大容量盘。
• 口音重、术语多：先把 initial_prompt 换成该领域的提示句（例如"以下是医疗病例讨论"），比换更大模型更划算。

五、成本与收益

真正省的不是那点转写费，而是不用再为一段录音纠结"该不该上传"。

六、一句话总结

对数据敏感的团队，本地转写的正确姿势不是"追求最快"，而是把慢的那部分丢进后台批处理：选 faster-whisper + int8 + vad_filter，把流程封装成 WorkBuddy 技能，一句话触发、结果自动归档。装一次，用很久。