用了这么多年语音转文字你会发现一个很反直觉的事实决定一个听写工具好不好用的根本不是“转得准不准”而是“转完之后你还需不需要自己重写一遍”。Whisper 这类本地语音识别模型已经把准确率提到了一个很可用的水平但它输出的文本通常是没有标点、布满“嗯”“然后”“就是说”的原始转写稿。换句话说它完成了“听见”这一步却没有完成“成稿”这一步。而这两步之间正是 Dictata 这个项目想要填平的 gap先用本地 Whisper 做听写再用 LLM 做清理让录音直接变成可用的文字。本文不打算只做概念科普。我会从实际工作流出发讲清楚这类工具解决什么问题、内部由哪几个环节组成、适合谁用、又有哪些坑同时提供一个最小可复现的本地听写清理流水线示例方便你在自己的电脑上先跑通一个简化版本再去决定要不要把它接入日常工作。1. 这篇文章真正要解决的问题先看一个非常常见的场景你打开语音备忘录对着手机讲了五分钟想法或者参加了一场线上会议录了一段讨论。经过 Whisper 转写后你得到的是这样的文本然后呢我觉得就是说这个功能嗯其实可以再优化一下然后我们再讨论一下看看这段文字“转写”是成功的因为每个词都听清了但作为“文字产出”是失败的——没有标点缺少分段语气词连篇发送给同事之前你必须重新整理一遍。整理一遍的时间往往比当时讲话的时间还长。这是语音输入的经典痛点识别环节和编辑环节之间缺少一座桥。云端语音输入法比如手机自带的语音转文字、各类会议转写软件能解决一部分问题因为它们在服务端做了智能标点和口语过滤。但代价是你的音频要上传到第三方服务器。对于一些涉及客户信息、未公开产品方案、医疗法律内容的录音很多开发者、产品经理和律师根本不敢往云端传。于是出现了两条路线路线 A使用本地 Whisper先解决隐私和准确率但输出还是粗稿。路线 B使用云端转写服务解决体验和格式但放弃数据边界。Dictata 的价值在于它把 Whisper 的本地转录和 LLM 的文本清理组合成一条完整流水线让人不用在“隐私”和“可用性”之间二选一。所以这篇文章不只是讲一个具体软件。我更想通过 Dictata 这个切入点和读者一起梳理“本地语音听写 LLM 清理”这个组合背后的技术思路、实现方式和工程陷阱。如果你属于下面三类人这篇文章会比较有帮助经常用语音写文档、写会议纪要、发长消息但受不了原始转写稿质量的人。对音频隐私敏感希望语音数据尽量不出本机的人。想用 Whisper LLM 搭建本地自动化工作流但不知道从哪里下手的开发者。2. 三个核心概念先搞清楚在进入实操之前有几个概念需要先明确边界因为很多人把它们混为一谈。2.1 Whisper 是什么Whisper 是 OpenAI 开源的语音识别模型支持多语言可以完成语音转写和翻译。它最突出的特点是“本地可运行”你可以把模型下载到自己的电脑上完全离线使用不依赖任何云端接口。Whisper 有多个尺寸的模型常见的有tiny、base、small、medium、large。模型越大识别准确率通常越高但需要的显存/内存也越多推理耗时也会明显增加。对于中文语音small或medium往往是比较常见的起步选择但具体选哪个取决于你的电脑配置和录音质量。这里要强调一个判断Whisper 解决的是“听到并写出文字”不是“帮你把文字整理好”。它输出的是口语音频的忠实转写包括语气词、重复、打断、没说完的话。这在转写会议时是优点但在“听写一篇文章”的场景里就是负担。2.2 本地听写与传统语音输入的区别传统语音输入比如手机输入法的语音键一般会上传音频到云端服务端完成识别再把文字返回给你。优点是准确率高、标点全缺点是依赖网络、有隐私风险而且很难自定义后处理逻辑。本地听写则是在设备本地完成声学处理和推理。它的核心优点不是“免费”而是数据不出设备。对于录音内容敏感的行业这几乎是刚需。但本地听写也有代价模型下载占空间转录速度依赖本机性能而且很多现成工具只给你“原始转写文本”省略了标点和分段等后处理。2.3 LLM cleanup 到底在清理什么LLM cleanup 是这条流水线里最容易被低估的环节。它用大语言模型对 Whisper 的转写结果做二次处理通常包括添加标点符号和分段。去掉“嗯”“啊”“就是说”“然后”等口头语。把重复、颠倒的话改成通顺的书面表达。识别说话人角色或为文本生成标题、要点工具允许时。统一术语、修复同音字错误。从项目角度看Whisper 负责“耳朵”LLM 负责“大脑”。前者保证每个词大概率正确后者保证最终文本适合直接阅读或发布。这里有一个很多人忽略的技术风险LLM 做 cleanup 时有可能“过度发挥”。它会根据自己的语言习惯补全句子甚至加进原话里没有的信息。因此cleanup 提示词设计非常关键后面我会专门展开。3. 为什么“本地 Whisper LLM 清理”是合理组合3.1 对比传统方案方案识别方式文本可用性隐私边界额外成本适合场景云端语音输入云端服务较高自带标点音频上传通常按量付费日常快速输入本地 Whisper 原始转写本地模型低无标点无分段音频不出设备电费硬件折旧追求隐私的粗转写本地 Whisper LLM cleanup本地识别 本地或 API 后处理高可直接使用取决于 LLM 是否本地模型推理耗时隐私敏感且追求成稿质量云端转写 人工整理云端服务高音频上传按量付费 人力成本对准确率极端敏感的场景从这个对比可以看出本地 Whisper LLM 清理并不是要完全替代云端方案而是补上“隐私敏感 希望直接得到可用文本”这个空档。如果你每天只是发语音消息转文字手机输入法已经够好但如果你需要处理的是会议录音、灵感和写作素材并且不想让音频离开电脑那这条组合路线显然更合适。3.2 这个组合真正降低了什么成本它降低的不是“识别成本”而是“整理成本”。识别成本在 Whisper 出现之前已经被云端服务压得很低了。真正的成本在识别之后的整理环节。一条 10 分钟的语音人工整理可能在 15 到 30 分钟而 LLM 清理可以把整理时间压缩到“只看一遍确认没有错”。从工程角度看这个组合的另一个好处是可编排。Whisper 转录和 LLM 清理是两个独立环节你可以单独替换任何一个。今天用本地 Ollama 上的小模型明天改成更强大的云端模型甚至录音后先粗转写、再用另一套 prompt 做摘要都不需要动整体架构。3.3 也得泼一盆冷水并不是所有人都适合这个组合。原因有三点硬件门槛。Whisper 的medium和large模型在无 GPU 的电脑上跑得很慢一条 1 分钟的音频可能要等好几分钟。配置复杂度。要让“录音→转录→清理→输出”全流程顺畅你需要做不少脚本和快捷键工作这对非技术用户并不友好。LLM 的不确定性。本地小参数模型在中文口语整理方面效果可能不够稳定有时会改出不像人话的句子。所以更稳妥的判断是Dictata 这类工具适合的不是所有语音输入用户而是愿意投入一点配置时间、把隐私和成稿质量看得比较重的人。4. Dictata 类工具的核心工作流拆解从项目标题来看Dictata 的定位是“Local Whisper dictation with LLM cleanup”也就是围绕“听写”而不是“批量转写历史录音”来设计的。这意味着它的工作流应该是低延迟、可交互的而不是上传一堆音频文件后等待队列处理。拆开来看一条完整的本地听写清理流水线由五个环节组成。4.1 音频捕获这是起点也是最容易做得粗糙的环节。你不可能每次听写前都打开终端敲一遍录音命令所以工具一般会提供全局快捷键或在菜单栏常驻一个小窗口。音频输入可能是系统麦克风实时录音。系统音频输出用于把正在播放的会议录音直接转录。已有音频文件拖入。对开发者来说这个环节涉及音频格式统一Whisper 要求音频是 WAV、MP3、M4A 等常见格式如果是其他格式需要先用 FFmpeg 转换。很多后续问题都出在音频格式不规范上而不是识别模型本身。4.2 本地 Whisper 转录捕获到一段音频后工具会把它交给本地 Whisper 模型进行转录。这一步的关键参数包括模型尺寸。语言设置中文场景建议指定zh避免自动检测浪费时间。是否启用 VAD语音活动检测也就是忽略录音开头和结尾的静音。输出是否保留时间戳通常听写场景不需要但会议纪要可能需要。从技术角度看这个环节最核心的优化点是“减少等待”如果用户刚说完一句话就点击停止系统应该能基于较短音频快速转录而不是坚持等整个文件处理完。4.3 LLM 清理Whisper 输出原始文本后LLM 清理环节开始工作。这里有两种常见设计直接把system prompt 转写文本发给 LLM要求返回清理后的版本。先做后处理正则去掉语气词再用 LLM 做标点和段落整理。第二种更省 token也更可控。第一种更灵活但提示词必须写得很仔细否则模型容易自由发挥。4.4 输出与回填清理完的文本如何交给用户决定了这个工具好不好用。常见方式有写入系统剪贴板用户直接CtrlV粘贴到编辑器。模拟键盘输入逐字输出到当前焦点窗口。写入指定 Markdown 文件。显示预览窗口允许用户确认后再复制。从实际使用体验看写入剪贴板 手动粘贴是最稳妥的方案。自动模拟键盘输入虽然看起来更“无缝”但很容易在密码框、无焦点窗口、中文输入法等场景下出现丢失字符的问题。4.5 异常处理和回退这是工程上最容易被忽视的一环。LLM 调用可能超时、报错模型可能加载失败麦克风可能没权限。好的工具设计应该保证LLM 清理失败时至少把 Whisper 的原始转写文本返回给用户而不是直接报错什么都不给。下面是一个简化的流水线伪代码用于说明各环节的衔接def dictation_flow(audio_file): raw_text whisper_transcribe(audio_file) # 本地 Whisper if raw_text is None: return 转录失败请检查音频 try: cleaned_text llm_cleanup(raw_text) # LLM 清理 except Exception as e: cleaned_text raw_text # 出错时回退原始文本 copy_to_clipboard(cleaned_text)这个流程逻辑简单但已经涵盖了“核心流程 失败兜底”两个关键点。5. 环境准备与前置条件如果你只是想使用 Dictata 的成品功能请以项目官方文档为准关注它的安装包和系统要求即可。但如果你也想理解原理或希望自己搭一个最小的“本地 Whisper LLM cleanup”流水线那下面的环境准备可以照着做。需要提前说明的是版本请以各个工具的实际官方要求为准本文重点演示通用思路不会写死某个具体版本号。5.1 硬件建议内存建议 16GB 以上。medium和large模型在推理时占用内存较高8GB 的机器会比较吃力。GPU有 NVIDIA 显卡CUDA会大幅提升速度没有 GPU 也能跑只是慢。麦克风即使是普通耳机麦克风也够用关键是录音环境不要太吵。5.2 软件依赖主要需要三部分Python 3.9 以上环境用于运行 Whisper。ffmpegWhisper 依赖它做音频解码。一个 LLM 服务。如果你想完全本地化推荐安装 Ollama并下载一个适合中文的模型如果你不介意部分数据上云也可以使用 OpenAI 等厂商提供的兼容 API。下面是安装依赖的命令示例这是行业通用的做法兼容大多数 Linux 和 macOS 环境# 创建虚拟环境可选但推荐 python3 -m venv dictata-demo source dictata-demo/bin/activate # 安装 openai-whisper pip install openai-whisper # 安装 FFmpegWindows 用户请到官网下载安装包 # macOS: brew install ffmpeg # Debian/Ubuntu: sudo apt update sudo apt install ffmpegOllama 的安装这里就不展开命令了它的官方文档写得比较清楚。安装完成后你需要拉取一个 LLM 模型例如ollama pull qwen2.5:7bqwen2.5:7b只是示例具体模型名称和版本请以 Ollama 仓库为准。如果你的电脑配置不高也可以选择更小的参数版本。6. 最小实现示例自己搭一条“录音转成稿”流水线下面这些代码不是 Dictata 的官方源码而是我按同类工具的工作流原理写出的最小示例。它的作用是帮助你理解“本地 Whisper LLM cleanup”到底是怎么串起来的。如果你后续要深度使用 Dictata仍然应该以官方文档为准但你理解了原理之后排查问题和二次开发都会容易很多。6.1 Whisper 转写脚本首先写一个最简单的转写脚本验证 Whisper 环境没问题。# 文件路径transcribe.py import sys import whisper def transcribe(audio_path, model_sizebase): # 加载本地模型如果本地没有缓存会自动下载 model whisper.load_model(model_size) # 中文场景可以指定 languagezh避免模型先做语言检测 result model.transcribe(audio_path, languagezh) return result[text] if __name__ __main__: audio_file sys.argv[1] text transcribe(audio_file, model_sizebase) print( 原始 Whisper 转写 ) print(text)运行方式python transcribe.py demo.wav如果这一行能正确输出文字说明 Whisper 已经能用。这里的model_size可以从tiny、base、small、medium中选建议先从小模型跑通再逐步增大。6.2 用 LLM 做文本清理接下来写一个调用 LLM 做清理的脚本。这里我以“OpenAI 兼容接口”为例因为这是目前比较通用的方式。如果你用的是 Ollama启动本地服务后很多配置也支持这种兼容调用。# 文件路径cleanup.py import requests import json OLLAMA_BASE_URL http://localhost:11434 # 以你的 Ollama 配置为准 MODEL_NAME qwen2.5:7b cleanup_prompt 你是一个文本整理助手。你会收到一段语音识别软件转写出来的原始文本。 这段文本可能包含口语词、重复表达、缺少标点等问题。 请你把它整理成通顺、可读的中文书面文本要求如下 1. 不要添加原话中不存在的事实、数字、观点。 2. 保留专有名词和术语不要改写它们。 3. 去掉“嗯”“啊”“就是说”“然后”等语气词和口头语。 4. 合理添加标点符号并按语义分成若干段落。 5. 如果原文本身语义不完整保留不完整状态不要强行脑补。 请直接输出整理后的文本不要输出任何解释。 def llm_cleanup(raw_text: str) - str: url f{OLLAMA_BASE_URL}/v1/chat/completions payload { model: MODEL_NAME, messages: [ {role: system, content: cleanup_prompt}, {role: user, content: f原始文本\n{raw_text}} ], temperature: 0.2, stream: False, } resp requests.post(url, jsonpayload, timeout60) resp.raise_for_status() data resp.json() return data[choices][0][message][content].strip()这个脚本最关键的是提示词设计。注意我明确加了“不要添加原话中不存在的事实”“保留专有名词和术语”“如果语义不完整就保留不完整状态”这三条约束。它们的作用是限制 LLM 的自由发挥空间而这个限制恰恰是 cleanup 和“创作”的本质区别。6.3 串联完整流程现在把转录和清理串起来再加一个剪贴板输出。# 文件路径dictate.py import sys import subprocess import transcribe from cleanup import llm_cleanup def copy_to_clipboard(text: str) - None: # macOS try: subprocess.run([pbcopy], inputtext.encode(utf-8), checkTrue) return except FileNotFoundError: pass # Linux try: subprocess.run([xclip, -selection, clipboard], inputtext.encode(utf-8), checkTrue) except FileNotFoundError: print(未找到剪贴板工具请手动复制文本。) def main(): audio_file sys.argv[1] model_size sys.argv[2] if len(sys.argv) 2 else base print([1/2] 正在使用 Whisper 转写...) raw_text transcribe.transcribe(audio_file, model_sizemodel_size) print(raw_text) print(\n[2/2] 正在使用 LLM 清理...) cleaned_text llm_cleanup(raw_text) print(cleaned_text) copy_to_clipboard(cleaned_text) print(\n清理后的文本已复制到剪贴板。) if __name__ __main__: main()运行方式python dictate.py demo.wav base在这个组合脚本里你看到的已经是一个完整的 Dictata 式最小工作流输入音频 → Whisper 转写 → LLM 清理 → 复制到剪贴板。剩下的工作就是把这个流程绑定到快捷键上让“录音→粘贴”变成一步操作。6.4 让麦克风录音也能直接进入流程上面的示例需要你提前准备好音频文件。如果要用麦克风实时录音还需要一个录音工具。这里给一个 Linux/macOS 上常用命令的示意# 录制 30 秒音频到 temp.wavmacOS 常见写法 ffmpeg -f avfoundation -i :0 -t 30 temp.wav # 录制 30 秒音频Linux 常见写法 arecord -d 30 -f cd temp.wav录制完成后再把temp.wav交给dictate.pypython dictate.py temp.wav small这个方式的体验还不够顺畅因为要先手动录完再运行脚本。实际 Dictata 这类工具一般会把“开始录音”“停止录音”“自动转录”“自动清理”合并到一组快捷键里那是产品化之后的事情。对于学习原理来说当前的最小流程已经足够说明问题。7. 运行结果与效果验证先准备一段测试音频。你可以随便录一段 1 到 2 分钟的语音内容可以是工作计划、学习总结或者是读一段短文尽量包含口语词。下面是一个预期输出对比示例。假设你对着麦克风说了这样一段话“嗯然后呢我觉得这个项目可以分成三个阶段然后第一阶段先做基础功能然后第二阶段再做优化然后第三阶段看看用户反馈怎么调整”运行python dictate.py demo.wav small后预期你会看到两类输出。Whisper 原始输出大致是嗯然后呢我觉得这个项目可以分成三个阶段然后第一阶段先做基础功能然后第二阶段再做优化然后第三阶段看看用户反馈怎么调整LLM 清理后的输出大致是这个项目可以分成三个阶段。第一阶段先做基础功能第二阶段再做优化第三阶段看看用户反馈怎么调整。判断成功与否可以从三个维度来看可读性清理后的文本是否分句、分段合理有没有明显的标点错误。忠实度数字、项目名、人名等关键信息是否与原始录音一致有没有多出原话里不存在的内容。稳定性同一段音频反复跑几次LLM 清理结果是否基本一致会不会每次输出都不一样。如果第二点出问题比如 LLM 给文本塞进了你没说过的话优先检查提示词约束是否生效可以把温度参数再调低一些或者换一个小一点的模型。如果第一点出问题比如清理后的句子还是乱七八糟那可能是原始 Whisper 转写错误太多你需要升级 Whisper 模型尺寸或者检查录音质量。8. 常见问题与排查思路我在实际搭建这类流水线时遇到的大多数问题都集中在下面几个地方这里整理成表格供你排查问题现象可能原因排查方式解决方案麦克风录音为空或杂音大录音权限未开启或输入设备选择错误先录一段 wav用播放器检查是否有有效声音在系统设置中授权麦克风检查默认输入设备Whisper 转写结果为空音频静音段太长或格式不支持用 FFmpeg 转换格式查看音频波形使用 VAD 裁剪静音转换标准 WAV/MP3转录速度非常慢模型过大、CPU 内存不足观察 CPU/GPU 占用率改用small或base模型增加内存中文识别错别字多录音方言口音重或模型过小试听录音确认人耳能否听清换medium模型或提高录音质量LLM 清理后加了原文没有的内容提示词约束不够温度参数偏高对比原始转写和清理文本强化提示词把 temperature 降到 0.2 以下剪贴板复制失败系统未安装pbcopy/xclip运行命令确认工具是否存在安装对应工具或改用文件输出LLM 调用超时本地模型加载慢或 API 网络问题查看 LLM 服务日志拉长超时时间或先启动模型预热输出乱码或字符错乱终端编码不是 UTF-8检查终端 locale 设置设置PYTHONIOENCODINGutf-8环境变量如果你第一次运行就失败千万不要直接去调 LLM 提示词先按这个顺序排查单独跑transcribe.py确认 Whisper 本身能不能输出正常文字。单独跑cleanup.py用一段手写文本替代 Whisper 输出确认 LLM 清理环节正常。最后再跑串联脚本。这一步拆开验证的思路能帮你快速定位问题出在哪个环节而不是在整条流水线上盲目猜测。9. 最佳实践与工程建议把本地 Whisper LLM 清理做成一个日常可用的工具不只是“写一个脚本”这么简单。下面几条是我认为对实际项目帮助最大的实践经验。9.1 提示词要“禁止”而不是“允许”做 LLM cleanup 时最重要的不是告诉模型“你可以做标点、可以做分段”而是明确告诉它“不要做什么”。因为模型的自由发挥能力远远超过我们的预期。一份能用的 cleanup 提示词至少应该包含这几条禁用规则不要添加原文不存在的事实、数字、观点。不要臆测说话人的意图。不要删改专有名词、品牌名、人名。不要为了通顺而改变原意。把这些规则放在system消息里并且让模型只输出清理后的文本不要输出解释。这样能显著降低“AI 自由创作”的风险。9.2 把两个环节解耦Whisper 转录和 LLM 清理之间建议保留“中间产物”。也就是说每次录音结束后先自动保存一份原始转写文本再生成清理文本。这样做有三个好处如果 LLM 清理效果不好随时可以回到原始转写而不是重新转录一遍。可以批量调优 LLM 提示词同一组原始转写喂给不同提示词对比效果。审计方便最终成稿和原始录音的差异是可追溯的。实际项目中我会建议至少把raw_text和cleaned_text存成两个文件文件名带上时间戳。这看起来是多了一步但长期使用节省的时间远超成本。9.3 模型选择要分层不要一上来就追求最大模型。我的建议是首次验证流程用 Whisperbase 任何能跑起来的本地 LLM先跑通全链路。日常使用根据电脑配置选择small或mediumLLM 选择 7B 到 14B 级别的中文友好模型。批处理长音频如果时间不急再用large模型提升准确率。“分层”的意思是把转录模型的选型和清理模型的选型分开考虑不要因为硬件配置不够就放弃整条流水线。转录不准可以换模型清理效果差也可以换模型两者互不干扰。9.4 注意数据边界和权限即使 Whisper 是本地运行你也必须清楚数据流向了哪里LLM 如果使用云端 API音频文本内容仍然会离开本机。如果使用 Ollama 等本地模型数据不出设备但输出结果可能受模型本身的知识影响。涉及他人声音的录音转写前应当确认你有处理该录音的合法授权。另外录音文件本身可能包含比文本更敏感的信息。实际项目中建议设置自动清理临时音频文件或者至少按日期归档避免大量 WAV 文件散落在系统临时目录。9.5 做好回退和人工确认LLM cleanup 的不确定性决定了它不能完全替代人工确认。比较稳妥的交互设计是清理完成后先把文本显示在预览窗口。用户按CtrlC复制或按回车确认。如果用户想用原始转写文本再按一个快捷键切换。这比“一键直接写入剪贴板”多一步但能防止 AI 修改的结果被无意识发送出去。对于正式邮件、对外文档这类场景多一步确认非常值得。9.6 用快捷键和工作流绑定提升使用频率即便工具做得再好如果每次都要打开终端敲命令你很快就会放弃。解决思路是把它绑定到系统级快捷键macOS 可以用快捷指令Automator/Shortcuts调用脚本。Windows 可以用AutoHotkey绑定脚本。输入法或启动器如 Raycast、Alfred也可以作为入口。绑定快捷键后你的使用流程就变成了按快捷键开始录音 - 再按一下停止 - 几秒钟后文本已经在剪贴板 - 粘贴这个流程足够快才可能成为“日常工具”而不是“偶尔跑一次的实验脚本”。10. 总结与后续学习方向Dictata 这个项目给开发者带来的启发不只是“又一个 Whisper 工具”。它把一个很朴素的痛点讲清楚了语音转文字不能停在转写要停在成稿。转写是技术问题成稿是工程问题。本地 Whisper 降低了隐私门槛LLM cleanup 降低了整理成本两者组合起来才构成一个完整的本地听写解决方案。如果你打算继续深入可以从三个方向入手提示词工程针对不同的语音场景会议、写作、头脑风暴、客户访谈设计不同的 cleanup 提示词这是投入产出比最高的提升点。音频处理细节学习 VAD、静音检测、音频压缩、按句号切分这些技术能让长录音的处理提升一个档次也能降低 Whisper 的误转概率。工具工程化把脚本封装成带快捷键、状态栏、预览窗口的桌面小工具甚至加入 RAG 能力让模型在清理时能参考你的术语表或历史文档而不是每次凭感觉发挥。最后提醒一句先跑通最小的用例再升级模型。不要在一开始就追求large模型 14B LLM 的“顶配方案”那只会让你卡在环境配置上连一次完整的听写都没跑完。把整条链路用最简配置走通一遍你会发现真正决定这个工具好不好用的不是模型大小而是你能不能掌控从录音到成稿的每一个环节。