ququ 语音转文字项目复盘：开源免费的中文语音工作流

发表于 2026-08-27 更新于 2026-09-10 分类于技术阅读次数： Changyan：

蛐蛐（ququ）是一个开源免费的桌面语音转文字工具，对标 Wispr Flow——你说话，文字直接上屏；语音识别在本地跑，数据不出本机。

适用岗位：运维工程师 / 技术支持工程师 / AI 运维工程师 / DevOps 工程师（AI运维岗重点）

一、项目速览

一句话定位：蛐蛐（ququ）是一个开源免费的桌面语音转文字工具，对标 Wispr Flow——你说话，文字直接上屏；语音识别在本地跑，数据不出本机。

“蛐蛐是我独立开发的开源桌面语音工作流，定位是 Wispr Flow 的开源免费中文替代。用户按下快捷键开始说话，说完文字直接打到正在输入的窗口里，解放双手。技术上分四段：麦克风采集语音 → FunASR 本地模型识别成文本 → 可配置的大语言模型做润色和格式化 → 把结果输出到当前输入框。核心卖点有两个：一是数据本地处理、音频不出机器，隐私安全；二是完全免费开源，中文场景专门优化。项目挂在 GitHub 上（lxp731/ququ），仓库语言字段是 JavaScript，识别推理用本地模型服务。”

一句话钩子（可选，抛给面试官）：”这个项目对我来说最大的价值，是让我把’模型服务化、本地部署、性能调优、跨平台打包’这一整套 AI 应用落地流程完整走了一遍。”

GitHub 描述：开源免费的 Wispr Flow 替代方案 | 集成 FunASR 本地模型和可配置大语言模型的下一代中文桌面语音工作流（language: JavaScript）
个人网站卡片：蛐蛐 | 语音转文字：解放双手，讲话完毕，直接上字。完全免费开源，数据本地处理，生产级别应用。标签：AI、LLM、F&B Separation
星标约 2（个人作品规模，别夸大）

二、项目背景（动机）

【背景事实】

对标对象：Wispr Flow —— 优秀的语音输入产品，但收费、闭源，数据走云端。
个人痛点：日常写代码、写文档、做会议记录打字效率低，想要”说话直接上字”的体验。
中文场景：Wispr Flow 等产品对中文支持一般，识别质量、标点、口语处理都不够好。
隐私诉求：语音是敏感数据，不希望所有音频上传云端。
学习驱动：想完整实践一次”AI 应用落地”——从模型选型、本地推理、前后端联动到打包发布。

【参考话术】
“做这个项目有两个原因。第一是真实需求：我写代码和文档打字很多，一直想要 Wispr Flow 那种’说完话字就出来’的体验，但它收费、闭源，而且中文支持一般。第二是学习：我想把’一个 AI 产品从模型选型到打包发布’的完整链路自己走一遍，FunASR 是阿里开源的本地中文识别工具，正好拿来用。另外，语音这种数据我不太放心全传云端，所以’数据本地处理’从一开始就是设计目标，不是事后补的卖点。”

“现成的免费方案各有各的问题：云 API（讯飞、百度这类）有免费额度但要注册计费、要联网，语音数据还会出境；Whisper 本地能跑，但中文场景和标点处理不如 FunASR 顺手；Vosk 够轻但识别率和断句弱一些。我需要的是’本地、中文、能集成进桌面流程’的方案，FunASR 最合适，而且它开源，我可以自己控制整条链路。”

三、完成情况（技术架构）

架构四段（流水线）：

语音采集层：桌面应用内录音（麦克风输入），快捷键启动/停止，可配置热键。
本地识别层：FunASR 本地模型把音频转成文本，VAD 断句、逐句输出（离线整句识别，视仓库实现可能支持流式）。
LLM 处理层：可配置的大语言模型对识别文本做二次处理——补标点、去口语词（”嗯””那个”）、纠错、分段、甚至转成 Markdown。
文字输出层：把处理结果写入当前焦点输入框（剪贴板模拟粘贴或直接插入），实现”讲话完毕，直接上字”。

关键设计——数据本地处理：音频采集后在本机完成识别，默认不离开机器；LLM 环节默认走本地（或可配置 API，见第七章第 4 条）。”数据本地”是架构选择，不是宣传话术。

【参考话术】
“整体是一条流水线：采集 → 识别 → 润色 → 上屏。音频从麦克风进来，先交给本地跑的 FunASR 识别成文本，中间接 VAD 做断句，避免一口气录完再识别；识别出来的中文口语文本通常没有标点、还带口头禅，所以再交给 LLM 补标点、去口语词、按意思分段；最后把结果输出到当前输入框，用户基本感觉不到中间过程。这个架构里每个环节都是独立、可替换的，这也是我后续做优化和扩展的基础。”

“直接用的体验很差——裸 ASR 文本没标点、口语词多、没有段落，上屏还要手动改。加一道 LLM 处理是’上屏即可用’的关键。为了速度可以用轻量模型和短提示词，为了隐私可以切本地模型，这一层可配置，用户也可以关掉。”

四、负责内容

独立完成项目从 0 到 1：需求定义、技术选型、架构设计、开发、测试、发布。
开源维护：README、使用文档、配置说明；处理 issue/反馈（如有）；持续迭代。

【参考话术】
“这个项目从立项到发布基本是我一个人完成的。需求是我自己的使用场景定的，选型我做了一圈对比，架构、开发、打包、文档都是我自己来。开源之后我还在持续迭代，把它当成一个长期维护的个人作品，而不是一次性 demo。对我来说，’独立把一件事从想法做成能天天用的产品’本身就是最大的收获。”

五、完成成效

功能达成：说话→上字全流程可用，本地处理，完全免费开源。
技术达成：完整落地”本地 ASR + LLM 后处理 + 桌面应用”链路。
个人价值：可作为技术名片——GitHub 开源项目、可被查看的代码、可持续迭代的作品。

【参考话术】
“从功能上讲，项目做到了’说完话文字直接上屏’的完整闭环，识别和润色都在本地完成，全程免费。从我个人角度，它让我把模型服务化、本地推理调优、桌面打包发布这套能力完整跑通，简历里’开源语音工作流’指的就是它，面试官可以直接去 GitHub 看代码。规模上我如实说：它目前还是个人项目，星标和用户都不多，但它是我每天都在用的工具，代码质量、文档和迭代节奏是我更看重的。”

六、面试官提问与参考回答

（共 15 题：基础 5 + 深入 6 + 刁钻/压力 4）

第一组：基础问题（5 题）

Q1. 简单介绍一下你的”蛐蛐”项目？

【面试官意图】考察表达与总结能力；判断你对项目是否熟悉、讲得是否清楚。
【参考回答】”蛐蛐是一个开源免费的桌面语音转文字工具，对标 Wispr Flow。核心体验是：按一下快捷键开始说话，说完文字直接打到正在输入的窗口，解放双手。技术上分成采集、FunASR 本地识别、LLM 润色、文字上屏四段，重点是识别和数据都在本地，音频不出本机。它是我独立开发并持续维护的开源项目，GitHub 上是 lxp731/ququ。”
【追问】”它和你简历里其他个人项目是什么关系？”——“简历里’开源语音工作流’指的就是它，是几个项目里技术含量最高、我投入时间最多的一个。”
【岗位侧重】通用

Q2. 为什么选择 FunASR 做本地识别？对比过其他方案吗？

【面试官意图】考察技术选型思路和调研能力，是不是”随手选了一个库”。
【参考回答】”选 FunASR 我做过一轮对比。云 API（讯飞、百度这类）识别效果好，但要联网、要注册计费，语音数据还会出境；Whisper 本地能跑，但中文场景和标点处理不如 FunASR 顺手；Vosk 太轻，识别率和断句一般。FunASR 是阿里达摩院开源的，中文识别是它的强项，支持 CPU/GPU、支持断句和标点模型，还提供官方运行时可以直接部署成服务，非常适合做本地中文语音工具。”
【追问】”如果用户要识别英文怎么办？”——“FunASR 也支持中英混说和多语种模型（比如 SenseVoice），我的设计里识别引擎是可替换的，真有需要可以切换模型。”
【岗位侧重】通用 / AI运维

Q3. 你项目的整体架构是怎么设计的？

【面试官意图】考察架构思维和模块划分能力。
【参考回答】”一条四段流水线：第一段是采集，桌面应用里录音，热键控制开始和结束；第二段是识别，音频交给本地 FunASR 模型转成文本，中间用 VAD 做断句；第三段是处理，可配置的 LLM 给文本补标点、去口语词、分段；第四段是输出，把结果写进当前输入框。设计上每个环节都是独立、可替换的，这让我后续做优化和扩展都很方便。”
【追问】”哪一段是性能瓶颈？”——“通常是本地 ASR 推理，这也是我优先做断句识别优化的原因：说完一句立刻出结果，体验提升最明显。”
【岗位侧重】通用 / 运维

Q4. “数据本地处理”具体是怎么做到的？

【面试官意图】验证隐私卖点是不是真实现，而不是宣传话术；AI运维岗考察数据流理解。
【参考回答】”核心是识别这条链路完全在本地：音频从麦克风采集后，在本机完成 VAD 和 FunASR 推理，文本在本地生成，这个过程中音频不离开本机。LLM 润色环节是唯一可能联网的部分，但它是可配置的——隐私敏感时切到本地模型（比如 Ollama），就做到全程不出机器。也就是说，’数据本地’不是口号，是架构选择：能本地跑的坚决不联网。”
【追问】”本地跑 LLM 会不会太慢？”——“会，所以默认配置里 LLM 环节用轻量模型和短提示词，速度优先；用户可以在’隐私’和’速度’之间自己权衡，这正是可配置的价值。”
【岗位侧重】运维 / AI运维

Q5. 这个项目用到了哪些技术栈？和你的岗位有什么关联？

【面试官意图】把项目和岗位要求串起来，考察技术栈的真实掌握程度。
【参考回答】”项目本身是桌面应用，主程序以 JavaScript 为主；识别推理用到了 Python 生态的 FunASR 和它的模型服务；LLM 环节对接 OpenAI 兼容接口或本地 Ollama；还涉及录音、热键、剪贴板这类系统级能力，以及应用的打包发布流程。对我来说，这个项目把’前端壳 + 本地模型服务 + 外部/本地 LLM’三种形态串在了一起，跟 AI 应用落地场景的运维部署逻辑是相通的。”
【追问】”如果让你把它部署到服务器上给团队用，你会怎么做？”——“识别服务可以容器化跑起来，只暴露内部接口；LLM 走公司自建网关或本地模型；音频数据留在内网。这套部署思路和我理解的 AI 应用上线流程是通的。”
【岗位侧重】运维 / DevOps / AI运维

第二组：深入问题（6 题）

Q6. “可配置大语言模型”是怎么实现的？支持哪些配置方式？

【面试官意图】考察配置化设计能力与工程落地；AI运维岗考察对 LLM 接入方式的熟悉度。
【参考回答】”设计上走的是’标准接口 + 配置化’：LLM 这一层抽象成 OpenAI 兼容的接口，用户填 base URL、API Key、模型名就能接任意兼容服务，比如 DeepSeek、通义、本地 Ollama（填 localhost 地址就行）。配置放在设置界面或配置文件里，不用改代码。选这个设计是因为不同用户情况差别很大——有人在意隐私要本地模型，有人要速度和质量用云 API，可配置才能覆盖所有人。”
【追问】”默认推荐哪个？为什么？”——“默认走性价比高的国内 API（比如 DeepSeek 这类），因为识别文本润色不需要顶级模型，便宜快的就够；隐私敏感场景再切 Ollama 本地模型。”
【岗位侧重】AI运维 / DevOps

Q7. 讲讲你用的 ASR 模型的细节：模型多大、CPU 还是 GPU、延迟、显存占用？

【面试官意图】考察是否真的跑过模型、对推理资源有没有概念；AI运维岗必问。
【岗位侧重】AI运维 / 运维

Q8. 桌面应用（JavaScript）和 FunASR（Python）是怎么联动的？

【面试官意图】考察跨语言/跨进程集成能力，是不是真把两个生态接起来了。
【参考回答】”应用主体是 JavaScript 的桌面壳，FunASR 是 Python 生态，我的做法是把识别做成本地模型服务（sidecar 形式）：应用启动时拉起识别进程，两者通过本地接口通信，应用侧发音频、收文本。这样拆的好处是：识别引擎可以独立启动、独立升级，模型换版本不用动主程序；出了问题也好定位是哪一层的故障。”
【追问】”识别进程挂了怎么处理？”——“做了拉起和重连：识别进程异常退出时主程序能检测到并重启它，同时给用户一个状态提示，不会静默失败。”
【岗位侧重】运维 / DevOps / 技术支持

Q9. 从说话到文字上屏，延迟瓶颈在哪？你做过哪些优化？

【面试官意图】考察性能分析与优化能力；AI运维岗考察对推理管线的理解。
【参考回答】”瓶颈几乎都在本地 ASR 推理，LLM 和上屏都很快。我的优化思路有两条：一是改识别节奏，VAD 检测到一句话说完就立刻识别输出，而不是整段录完再处理，用户感知的延迟大幅下降；二是把 LLM 提示词做短、模型选轻量的，让润色环节尽量不拖后腿。另外识别进程保持常驻、避免每次冷启动加载模型，这本身就能省掉好几秒。”
【追问】”如果用户要实时字幕式输出，你的架构支持吗？”——“FunASR 有流式模型，理论上可以边说边出字；我当前实现偏’整句出字’，流式是明确的演进方向。具体支持程度以仓库为准。”
【岗位侧重】AI运维 / DevOps

Q10. 桌面应用怎么打包和分发的？跨平台吗？

【面试官意图】考察工程化完整度：能不能把项目交付出去，而不只是本地能跑。
【追问】”打包时遇到过什么坑？”——“典型的是原生依赖的跨平台编译，以及不同平台的系统权限适配（比如 macOS 的麦克风权限弹窗）。这些是我实际踩过的点，具体以你的打包记录为准。”
【岗位侧重】运维 / DevOps

Q11. 你网站项目卡片上有”F&B Separation”标签，这是做什么的？

【面试官意图】考察对项目功能边界的诚实度，以及是否了解音频分离的概念。
【追问】”分离用什么方案实现的？”——“有专门的分离模型可以做（比如 Demucs 这类）。如果我在仓库里集成了具体方案，以仓库实现为准；如果这块还处于规划阶段，我也会如实说是 roadmap 里的能力。”
【岗位侧重】通用 / AI运维

第三组：刁钻 / 压力问题（4 题）

Q12. 你写”生产级别应用”，但仓库只有 2 个 star、几乎没有用户，凭什么？

【面试官意图】压力测试：看你会不会心虚、夸大或恼羞成怒。
【参考回答】”我说’生产级’指的是稳定性和完成度标准，不是用户量标准——它是我每天在用的工具，经历了多轮迭代、修过真实使用中暴露的 bug，有配置化、有错误处理、有打包发布流程，这个标准是’我自己当产品用’的标准。星标少我如实承认：开源时间不长、没做推广，个人项目而已。但如果代码经得起看、能持续迭代，用户量只是时间问题。”
【追问】”那你怎么证明它’稳定’？”——“我可以讲真实使用中修过的问题和当前的已知边界，也可以现场演示。空口说’稳定’没用，经得起追问才是证明。”
【岗位侧重】通用

Q13. 完全开源免费，你的商业模式是什么？会不会做着做着就不维护了？

【面试官意图】考察长期承诺与思考深度，压力测试对个人项目的投入态度。
【参考回答】”这个项目的定位就是个人作品和技术名片，不是商业项目，所以没有商业模式，也不需要靠它盈利——这反而是它能持续维护的原因：我自己天天用，dogfooding，修 bug 是给自己修。开源免费也是刻意的，对标品收费闭源，我的差异化就是免费开放。至于维护，只要我还在用它、它还在我的简历上，我就会持续迭代，它对我个人是有长期价值的。”
【追问】”如果大公司做了同样的免费产品呢？”——“那用户有更好的选择是好事；对我来说项目价值本来就不只在用户量，而在于我完整做成了一个产品，这个能力是带得走的。”
【岗位侧重】通用 / 技术支持

Q14. 你这个项目技术上有什么难的？是不是就是调 API、调库？

【面试官意图】考察是否真的做过工程，还是只会”组装”。
【参考回答】”调库是事实，但把库调通和做成产品是两回事。难的点在于工程集成：桌面应用和 Python 识别服务两个生态怎么稳定通信、识别进程怎么管理、出错怎么恢复；在于体验调优：断句节奏、延迟、输出时机这些细节决定好不好用；在于打包分发和跨平台适配。这些没有现成答案，都是实际踩坑踩出来的。如果你愿意，我可以现场讲其中一个模块的实现细节。”
【追问】”那你觉得你和直接照着教程做的人差别在哪？”——“差别在取舍：我知道每个环节为什么这么设计、换一个方案会损失什么，这需要自己完整走一遍才会有。”
【岗位侧重】通用 / 运维

Q15. 本地跑 ASR + LLM，普通用户电脑跑得动吗？这算不算伪需求？

【面试官意图】压力测试产品判断力：会不会为技术而技术，忽视真实用户场景。
【参考回答】”两个问题分开答。配置门槛我承认：本地 ASR 需要一定算力，所以我在设计上留了降级路径——LLM 环节默认走便宜的云 API，识别环节也在模型选择上做过权衡，让中低配机器也能用；真跑不动的人可以选纯云方案，但那不是我这个项目的定位。伪需求不成立：语音输入是真实存在的需求，Wispr Flow 收费不便宜还有大量用户就是证明；我做的是把价格打下来、把中文做好、把数据留在本地，需求本身没有争议。”
【追问】”你觉得这个项目最大的失败风险是什么？”——“用户规模上不去的风险——它可能永远是个小而美的个人工具。但我接受这个结果，因为我的目标本来就不是做独角兽。”
【岗位侧重】通用 / AI运维 / 技术支持