本地实时录音转写，我终于跑通了

Qsianuo — Mon, 19 Oct 2026 11:19:38 +0000

我用 AI 做了一款本地录音实时转写工具，做完才发现：最难的从来不是写代码。

最开始只是想解决一个日常痛点：开会、采访结束后，整理录音转文字，总要额外耗上一小时。在线转写工具需要把音频上传云端，隐私不放心；现成本地软件又收费不便宜。干脆自己动手，定下核心目标：完全本地运行、边录音边出文字、项目开源。

整个项目全程借助 AI 辅助落地。技术栈很快敲定：浏览器采集音频，FastAPI 搭建 WebSocket 服务，后端用 faster-whisper 做本地语音识别，所有音频数据全程只在 127.0.0.1 内网流转，不会上传到任何外部服务器。

第一版代码跑通的那一刻特别激动，可测试中文识别结果直接翻车：测试句「实时语音识别测试」，被识别成了「实实与因时别特势」。我第一反应是模型能力不够，打算直接换更大的模型。但 AI 陪着我逐层拆解问题，最后定位到，是 4 个问题叠加导致识别拉胯：tiny 基础模型容量不足、提示词过长干扰模型选词、文本解码没有开启 beam search、推理速度慢造成音频队列堆积。

最出乎我意料的，是提示词带来的影响。原本写了一句看着很合理的提示词：「请使用简体中文输出并添加标点符号」，可实测它会稳定把「实时」识别成「时时」。换成一句中性描述：「这是一段普通话的录音。」之后，同一个模型，识别结果立刻恢复正常。前后对比了 6 组提示词、3 种 beam 参数，最终 8.9 秒的两段录音，全部识别准确。

下载模型也踩了坑：Python 下载器卡在 Hugging Face Xet 协议，进度一直卡在 0。换镜像 + curl 直连的方式，几分钟就成功拉取 483MB 的 small 模型。

目前整套链路可以纯本地运行，不需要任何 API Key，代码已经推送到 GitHub 修复分支。

这次项目最深的感悟：AI 写代码的速度很快，但它真正的价值在于辅助排查问题。它可以帮你把「模型不行」这种笼统模糊的猜想，拆解成一个个可以单独验证的原因。代码工具只是起点，学会把模糊的大问题拆清楚、问明白，才是整个项目里最有价值的部分。

https://github.com/Qsianuo/echonote

DEV Community: Qsianuo

本地实时录音转写，我终于跑通了