夜雨聆风最近一段时间，我一直想做一件事：在自己的笔记本上跑一个能说话的 AI 助手，不联网，不上传录音，问它什么它本地回答，然后用语音念给我听。
这个想法不算新，但能真正跑起来的方案一直很分散。直到我把 Ollama、Whisper 和 Edge TTS 这三个东西串在一起，才算搞清楚思路。今天把整个链路写出来，也把我踩过的坑讲清楚。
为什么想要本地语音助手
先说动机，不然后面讲方案没有依托。
我用过几个云端语音助手。体验是流畅的，但有几个问题挥之不去。
第一，录音会离开本地。你说的每一句话，都走了一条你不太清楚的路。对大多数场景这没关系，但如果你习惯在 AI 面前讲一些工作里的敏感想法，或者你本来就对数据流向很在意，云端方案总是让你不放心。
第二，长期调用成本。如果真的每天用语音问几十条，调用成本会慢慢累积起来。本地方案一次性把模型下载好，后续基本没有边际成本。
第三，离线可用。家里网络出问题、出差在外、或者就是不想依赖服务稳定性的时候，本地方案能保证你手边总有一个能用的东西。
这三点加在一起，对重度 AI 用户和愿意折腾链路的人来说，本地语音助手是值得花时间的方向。
三个组件各管什么
这套方案的分工很清晰，分成三层：
Whisper 负责听。 你说的话，首先要变成文字，这件事交给 Whisper。它是一个 end-to-end 的 Transformer 模型，专门做语音识别。训练数据量大、来源多样，在真实录音环境里的鲁棒性比很多同类工具强。输入音频先转成 log-Mel spectrogram 再走 encoder，最后输出转写文本。它还能识别你说的是哪种语言，中文转写直接支持。
Ollama 负责想。 转写出来的文字，发给本地运行的大模型。Ollama 提供了一个本地 HTTP 接口，默认跑在 http://localhost:11434/api，调用方式非常直接。比如官方文档里这条命令：
curl http://localhost:11434/api/generate -d '{ "model": "gemma4", "prompt": "Why is the sky blue?"}'模型在本地跑，回复也在本地生成，数据不出机器。对开发者来说接口不复杂，后续想接脚本、做桌面端、甚至接进网页，都有扩展空间。官方还提供 Python 和 JavaScript 库，调用更方便。
Edge TTS 负责说。 模型给出的文字回复，最后要变成语音播出来。这里用的是基于 Microsoft Edge Read Aloud API 的方案，在服务端运行稳定，能调节语音的音色、语速、音调、音量。效果比很多本地纯离线 TTS 方案自然一些，工程成本也不高，能快速得到可用的播报质量。
三层串起来的逻辑就是：你说话 → Whisper 转文字 → 文字发给 Ollama → 模型回复 → Edge TTS 念出来。
最小可用流程怎么搭
我建议用最少的步骤先跑通一个"单轮问答器"——按住说话、松开得到语音回复的那种，不做唤醒词，不做持续对话，不做界面。
四步走：
录音：用 Python 的 sounddevice或pyaudio录一段语音，保存成音频文件。Whisper 转写：把音频文件喂给 Whisper，拿到转写文本。 发给 Ollama：把文本通过 /api/generate接口发给本地模型，拿到文字回复。Edge TTS 播报：把回复文本送进 Edge TTS，播放出来。
每一步都可以单独测通，再连起来。关键是：先证明这条链路能跑，再去想怎么让它好看、让它常驻、让它支持多轮对话。
这套方案是一个可控的本地原型，不是现成的消费级智能音箱。它没有语音活动检测，没有唤醒词，没有联网升级，但它让你在自己的机器上掌控整条链路——这件事本身就有价值。
适合什么人，不适合什么人
适合做这件事的人：
在意数据隐私，不想录音上传到云端的人。 重度 AI 用户，想把长期调用成本压下来的人。 有一定动手能力，愿意花时间把录音、转写、模型、播报几段串起来的人。 想在本地做语音交互原型、探索可能性的开发者或爱好者。
不适合的情况：
要求开箱即用，不想处理环境配置和链路调试。 期待像成熟智能音箱一样长期稳定待机、随叫随到。 对延迟要求极高——本地链路的总延迟取决于硬件，Whisper 跑模型和 Ollama 推理都需要时间，不是调参能完全解决的。 没有合适硬件的情况，低配设备跑起来体验会很差，先想清楚再入手。
最容易踩的几个坑
做完之后回头看，有几个弯路是很多人会走的：
一、一开始就想做完整智能音箱。 唤醒词、持续对话、漂亮界面、设备化部署，全想一次到位。结果每个环节都没跑通，最后什么都没做成。正确的顺序是先让单轮问答跑通，再一步步叠加功能。
二、忽略整条链路的延迟。 录音、Whisper 转写、Ollama 推理、TTS 合成，每一步都有延迟，加起来可能远超你的心理预期。如果你对延迟有强烈期待，最好在自己的机器上把每一步单独计时，再决定要不要继续做——而不是做完才发现慢到不能用。
三、以为 Whisper 拿来就准。 在干净录音环境下效果确实不错，但背景噪声、口音、连读、或者说话太快，都会影响转写质量。如果你的录音环境不理想，可能需要做一些前处理，或者调整自己的说话方式，而不是一味调 Whisper 的参数。
四、把 TTS 当随便补的一步。 很多人在前三步花了很多时间，最后 TTS 随手接一个，结果声音机械到难以接受，实际使用体验大打折扣。TTS 的自然度直接影响这个方案的可用性，Edge TTS 的 voice、rate、pitch、volume 都有调节空间，值得认真花时间测一下，找到你能接受的参数组合。
我的行动建议
如果你打算做，建议先做一个最小版本：
能录音 能用 Whisper 识别 能把文字发给 Ollama 拿到回复 能用 Edge TTS 把回复念出来
不求稳定，不求漂亮，不求常驻，只求这四件事在自己的机器上跑通。
跑通之后，你会对整条链路的真实情况有清晰认知：延迟在哪、质量怎么样、哪个环节是短板。这时候再决定要不要继续投入，或者在哪里做优化，是有依据的判断，不是凭空想象。
本地 AI 最难的从来不是找一个好模型，而是让整条链路稳定运行。先跑通，再谈其他。
