不会写代码 做语音输入法 — 一个广告人的完整产品思路

前几期我演示用语音操纵 Claude Code，评论区一堆朋友追着问——「这个语音输入法哪买的？」

我才反应过来。我用的这个东西，市面上其实没见过同款。

那这期，我把怎么做出来的从头讲一遍。

我是个广告人。代码基本不会，Windows 客户端开发更没碰过。但我还是想要一款顺手的输入法——快、准、中英混排、热词可以自己管。

不会写代码？那就让 Claude Code 当我的手，我只负责把整个产品想清楚。

一段时间打磨下来，从 POC 跑到可商用，朋友们已经在用。

一、需求拆解 — 市面输入法为什么我都不顺手

想清楚自己要什么之前，先想清楚现有的东西哪里不对。

讯飞输入法——多年没更新，识别引擎停留在第二梯队。小艺输入法——华为鸿蒙上特别准（我猜它拿到了系统级权限拿到上下文），但只有鸿蒙版，没 Windows。豆包输入法——Windows 版还在研发。微信 PC 端自带的语音输入——其实非常好用。国外 typeless——一个月十几美金，还有一堆我用不到的奇怪功能。国内闪电书——做得不错，但热词库和自定义不能自己管。

调研完发现，没一个完全符合我。那要么忍，要么自己做。

二、技术选型 — 不会编程的人最大的盲区

「我不知道我不知道」——这是不会编程的人最大的盲区。

同样实现一个功能，背后的开发语言和框架完全不一样。Python 简单但软件臃肿；Rust 极小极快但生态门槛高。

我把需求明确告诉 Claude Code：「我的应用场景是这个，需求是这个。什么样的选型可以选，给我多维度评估汇报。」

调研下来——Rust + Tauri：软件体积小、内存占用小、单文件极简运行、识别稳定、跨平台。HTML/CSS 写浮窗，将来 Mac、Android 都能部署。

我选了 Rust。

但我也得说一句：这不是说每个人都该选 Rust。Python 在 AI 编程里更容易，社区经验更多，可以参考的代码到处都有。只有当模型能力足够强，才有可能把软件体积压得很小。这个过程对大模型能力的要求是高的。

三、ASR 引擎实测 — 5 家流式 ASR 横向比

POC 阶段我先用 Gemini 3 Flash 跑通了「按键录音 → 模型识别 → 粘贴到光标位置」整个链条。

但每次说完话要等几秒才看到第一个字。整段录音传到 Google 海外服务器再回来，体感很糟，时间长的录音还容易断。

我去问 Claude Code「怎么降延迟」，它告诉我——「用流式 ASR」。每说一小段就识别一小段，不用等整段。流式还分本地和云端。

这就是「我不知道我不知道」的瞬间。我有需求，Claude Code 帮我调研，才发现原来有这个选择。

接下来：让 Claude Code 把市面 5 家流式 ASR 全部部署到我电脑上做真实测试。

我用手机录了一段中英混杂的音频，跑下来——

• 本地模型：毫秒级出字，但技术词错到离谱，修都修不回来。快但不能用。
• Gemini 2.5/3 Flash：效果非常好，但非流式，得等几秒。
• 豆包流式云输入：首字毫秒级、云端流式、整段错误率有限。

又让 Claude Code 生成一段长音频做稳定性测试，完全没中断，速度也很快。

最终选了豆包。

四、Polish 层 — 修字音字形错

豆包不是没问题。比如我说「Claude Code」，它经常识别成「cloud」。同音词、发音不准、专业术语，是流式 ASR 的系统性盲区。

行业里有解决方案，叫 Polish 层——豆包出文本之后，快速发给一个校正模型，根据上下文和语义把出错的词修掉。

Polish 我也测了几个模型。最终在千问 Flash 和 Claude Haiku 之间选。

Haiku 质量稍好，但成本高，跨境传输还有一些不可忽视的延迟。

千问 Flash——又快又便宜，质量也够好，国内服务器没跨境延迟。我选了千问。

注意啊，到现在为止我一行代码都没写。就只是在调研决策、调研决策。

Polish 不是魔法，是提示词工程。我还设计了一个流程：每输入一定数量的内容触发一次 Claude 做精细排查，把高频出现的词、识别错误的语境提取出来，作为下一轮 Polish 的提示词修复方案。热词自动学习。

五、100 件不起眼的交互细节

最后是交互。极简浮窗，跟着光标走，不抢屏幕。

用户给我反馈「切换麦克风识别不了」。我跟 Claude Code 说：某用户在什么场景下出现了什么问题，我判断是切换麦克风之后跟踪的设备不见了，可以自动识别音频设备变化，外置麦克风优先。Claude Code 自动改 Rust 代码上线。

绑定鼠标中键——因为我经常用遥控器远程遥控电脑，不碰键盘。

识别完自动发送——大模型本来就会校正错字，没必要再手动按回车。

付费模式从月费切到按字付费——后台日志发现重度用户每月会用超亏本，按字付费永远有利润。

微信扫码登录——注册微信开发者平台，全程截图给 Claude Code，让它教我配回调。

每一件小事我都跟 Claude Code 描述清楚，它去改，我去测。

收尾

放在以前是想都不敢想——一个广告人，没碰过代码，做出一款已商用的 Windows 软件，用的还是最顶尖的 Rust。

现在真的就是——只要你能表达清楚需求，你就可以做到。

不会写代码不是借口。Claude Code 已经把执行这部分接管了。剩下的，永远在「想清楚」这一边。

来源：EP0011_audio.mp3 · ASR 模型 gemini-2.5-pro · 19 分钟原片完整文字版

[00:00] 来吧朋友们又见面了。前几期我已经给大家展示了我是如何用语音去操纵 Claude Code 去完成一些调研的工作啊、做 PPT 啊，或者是去开发产品。那结果评论区一大堆的朋友追着我在问，说这个语音输入法这么好用，能不能也给他们用一下。以及我回复说这个语音输入法是我开发的，他们其实都蛮惊讶的，都在说到底是怎么开发的，他们能不能也能自己去开发一个。

[00:21] 那今天我就来给大家讲一下，作为一个搞营销的广告人对吧，代码基本上是不会的，更别提是做一个 Windows 的一个软件了对吧。那我是如何从零开始去想清楚，然后一步一步地跟着 Claude Code 一起去完成了这样一个已经在商用的产品的开发了。对我的很多朋友都已经在用我的这套输入法了啊。那今天我也是让 Claude Code 整理了一份我的整个的一个开发过程啊，给大家去进行一个详细的讲解。

[00:50] 那最重要的并不是说我这里面用了什么提示词啊，而是说整体的我的开发的思路大家一定要看清楚。那说到这个输入法呢我也给大家展示一下，就是——从零打造一款中英混排的输入法，那一个人一个月 52 个 commit，从 POC 到 V0.6.1。这样的一个输入法它是怎么样去做到一个快速的反应，然后并且很精准的去识别这个中英文的内容，做出一个这样的一个输出的。

[01:16] 那大家可以看到说我这边输完了之后，它很快的就输入进去了，而且刚才的这段话中英混排的嘛，完全没有任何一个错误。那这个服务呢我已经上线到这个网站上可以去下载了。它是用的 Rust 的编码，然后整个的一个输入法的安装包就只有 8 兆。那这样我是从怎样的一个角度去开始做这个输入法的呢？

[01:36] 首先，我其实会在各种各样的这个平台上去使用嘛。那我最早去用到的输入法其实是讯飞的输入法，那它的输入法也是蛮好用的，但其实已经是很多年没有更新了。而且它的这个识别的引擎啊，它的准确率其实是停留在第二梯队的这么一个水平的。那我最近也是用到了华为的鸿蒙系统的这个小平板嘛，那知道的人都都知道说华为鸿蒙系统上有一个小艺输入法，识别的非常准确，但是它只有鸿蒙的版本，它并没有这个 Windows 的版本。那我其实也去考虑过说它为什么这么去做，我猜它一定程度上是拿到了系统级的权限，以至于它能够有这个用户输入的上下文能够做一个很精准的匹配。

[02:18] 那小艺输入法确实很好用但是它只有鸿蒙系统才有。那另外就是豆包输入法，很多的朋友们反映说豆包输入法效果很好，但是豆包的输入法大家打开它的官网也可以看到说，它的 Windows 的版本其实还没有上线，还在研发当中。那最近我其实也有体验说我的老东家鹅厂腾讯出的这个输入法嘛，那我其实发现它的输入法分了几个部门在做的。那其中一个部门呢就是 PC 端的微信客户端，它里面自带的语音输入法也是非常好用的，那大家也可以去用微信的输入法。

[02:47] 那在这样的一种情况下呢，我其实先用 Claude Code 做了一个全面的调研。我就问他说在 Windows 的平台上现在的输入法都有哪些比较好用的选择，以及大家都是怎么样去做这样的一个技术的嘛。它首先就做了一轮这样的一个调研，包括国外的 typeless，还有国内的闪电书，其实都是比较不错的这样的一个产品。

[03:08] 但是呢这些产品多多少少都没有符合我的需求。那比如说国外的那款 typeless 嘛，它的会员是 12 美金一个月，确实是太贵了。然后还有一些奇奇怪怪的可能我用不到的功能。那我需要的就是非常快、非常准的把这个文字能够快速的打出来对吧，就是省我的事，而且它要比较准。而且因为经常用到一些软件嘛，它里面可能会有中英混排的一些情况，所以在这种情况下需要它准。那国内的闪电说其实做的也不错，那也推荐大家去尝试一下这样的产品，但是它也有一些痛点。比如说它是需要自己去连接模型的，虽然可以选择模型啊，但是它的这个热词库也是不能够自己去管理的，包括一些自定义的一些内容，它其实用起来我觉得可能没有那么的方便吧。

[03:50] 然后那在这样的一种情况下的话，我又去想说我既然投入时间做这件事情，那我就不是一个自己玩的一个 demo 对吧，我要把它做成一个能卖钱的一个产品对吧，就别说赚多少钱，但是最起码它不能亏钱对吧。那在这个研发的过程中，因为它是有大模型的参与的嘛，那用量越多它的成本就越高，所以我一定是要做到一个多租户，就是用户可以登录，然后去充值使用的这样的一个产品。所以一开始就需要把我的这个体验、核心的一些需求和它的一个产品化的基础设施去想好。

[04:22] 比如说我需要它是一个极简的状态，就是没有复杂的设置、没有复杂的界面，然后中英混排能够不卡非常流畅的去准确的输出。同样它会有一个付费的一个方式，也可以完成自动更新，比如说我这边修复了一个 bug，那用户都可以收到一个推送，说我需要去自动更新，去完成这样的一个版本的升级。那这都是会提前想好的一些东西。

[04:47] 紧接着就是叫做选型。就是大部分的人在做 vibe coding 的时候，都会没有这个意识，就是不会编程的人这就是他们的盲区，叫做我不知道我不知道的部分。它根本不清楚说同样是实现了这样的一个功能，但是它背后所用的开发的语言、它用的框架是不一样的。那在这个时候，我也是不懂的对吧。那我就把我的需求明确的告诉 Claude Code 之后呢，我就跟他说：那在这样的一种应用场景下、我的这样的一个需求，那什么样的选型可以供我选择，并且它的优劣势，包括它的具体的区别，按照多维度进行给我一个评估的汇报。

[05:23] 那在这样的一轮调研下来之后，它就会告诉我说 Rust 这样的一种方式，它的软件的体积和它占用的内存都非常的小，它同样可以单文件的去进行极简的这个运行，然后它的识别都可以稳定的进行。同时这样的一种开发的方式它还可以跨平台，就将来我如果想要做 Mac 端的或者是做安卓端的，都可以用这个 HTML 和 CSS 去写这个浮窗，它可以去快速的部署到多端上。那同样也去符合了现代的这样的一个录音以及注入的这样的一个流程。所以在评估完之后呢，我就选择了 Rust 这样的开发的方式。

[05:57] 当然了，并不是说一定要去选择一个这样极端的一个配置的一个方案。这里面为什么这么说呢？因为你看它上面写出的这些语言嘛，比如说用 Python，那可能在 AI 编程的时候，尤其大家可能没有办法用到这个 Anthropic Opus 4.7 这样好的模型的情况下，那可能还是选择一些常见的语言会比较容易开发，因为会有很多的社区的经验供你参考，那也会有很多别人实现过的代码可以直接拿过来去参考或者使用。只有真的是模型能力很强的时候，才有可能去把这个软件的体积从你看从 200 兆去压缩到我最终实现的是只有 8 兆对吧。那但是这个过程就需要这个大模型是有更强的一个能力的。

[06:40] 那我一上来之后呢，我先选择了一个最直接的方式把整个的链条跑通嘛，就叫做 POC。就是我的这个产品，我先验证它能不能实现我的需求。所以我就在选好了开发语言之后，我先用的 Gemini 3 Flash 的这样的一个模型去跑通了一个按键录音、到模型识别、再到这个粘贴到当前光标位置出来的这样的一个方式。但是我就会发现说我实现完了之后，会发现说这样的一个方式是非常慢的，是因为什么？

[07:10] 我每次说的话之后都会等四秒进行识别，它会把我的整段录音传给 Google 的那个 Gemini 的模型去进行 ASR 的一个转译，就把语音转变成文本了。那这个过程呢就要发送到海外的服务器再回来，再识别再回来。所以整个的过程需要四秒的时间，我才能看到第一个我讲出去的字。这个在用户体验的体感上来是非常不好的，那就会觉得这个系统是不是没有在听我说话。而且时间长的录音呢，它就会容易断掉。虽然它的识别的准确度非常的高啊。

[07:43] 那经过这样的一个测试之后，我就有问到说 Claude Code 说：有什么样的方式能够降低我这个语音输入法的延迟，就是当我输出去字的时候，它就能很快地反馈。那这时候 CC 就 Claude Code 给我的一个调研反馈是说，诶还真实有解决办法，那就是用流式的 ASR 识别，就是不是全部的语音念完之后再识别，而是把语音切成一个一个的小块，随时在识别的方式。而且这样的方式它还告诉我说会分为本地的流式识别和线上的流式识别，就是可以用我们本地电脑的这个算力去完成这样的一个工作。

[08:18] 那我就恍然大悟嘛对吧，就我原来不知道这个事情，但是我有这个需求让 Claude Code 帮我调研之后，我发现说有这样的选择。那我发现了之后呢，我就让他去这个社区去找这些模型的口碑嘛，但其实发现这些口碑有很多是公关稿，就是它吹牛说准确度很高、然后响应很快，但是这个实际模型测下来是不对的。

[08:38] 所以这个时候我就用我的手机录制了一段中英文混杂的一个音频，我让 CC 帮我做测试，我说：你帮我，你先教我如何把这些大模型的全部都部署到我的电脑上，不管是用 API key 还是说我去创建一个环境去把模型下载下来。那我要把我们刚才调研过的所有的这些模型，全部真实的去测试，看它的效果如何。

[09:00] 那这样测下来之后我就会发现是说，虽然有一个本地的大模型它可以毫秒级的就基本上是无延迟的去往外蹦字，但是它的技术的词是经常错的，错到离谱到我可能再去修复它都修复不了，所以这也不能用，虽然快但是质量差也不能用。那有的是好的就像我刚才说的 Gemini 2.5 Flash 或者 Gemini 3 Flash 的这个预览版，它们效果是非常好的，但是它非流式的，就是我得说完这句话等几秒它才能把整个文本给到我，所以这个体验也是不好的。

[09:31] 那最终评估下来之后，发现豆包的流式云输入法是非常赞的一个效果。那它的首字的反馈是毫秒级的，那它又是一个云端流式的一个方式，而且它整段的一个错误率基本上是控制在 10% 到 5% 左右吧。那我就在这个时候我就选择了用一个流式的引擎，基本上选定了用豆包做这个引擎。

[09:55] 对你看它的完成率也很强。那我再选定豆包之后我还做了一件事，就是我让 Claude Code 去生成了一段 60 分钟的一个长的音频，去让他测试说我能不能稳定的使用豆包的这个流式的输入法的这个识别。那这 60 分钟我测试下来之后是完全没有中断的，而且它的字是连续出现的，总字符数达到了 15000 多个，每分钟是 258 个字的这样的一个速率，已经是飞速的快了。而且它所说的零错误啊，是因为我给到它的这个长时间识别的文本可能没有那么的复杂，而且存在一定的重复，所以它在这次测试当中是零错误的一个非常好的一个成绩。

[10:35] 本地模型刚才也说了它的事足够快，但是它的精度不够。所以我最终还是选择了这个豆包作为这个模型。但我们也可以看到说，豆包的这个模型在一些复杂的语境下，遇到同音词比如说，或者是说一些发音不准确，比如说我说 Claude Code 对吧，它可能就会识别成这个 cloud 对吧，就是云朵的那样的一个词，就是很容易同音词因为发音不准而去识别错误。那这个时候怎么办呢？

[11:03] 这个时候其实我就让 CC 调研了整个行业当中的最佳实践，发现了一个解决方案叫做 Polish。就是说它会进行第二轮的校正，就是当豆包流式语音输出的这个文字已经生成之后，它会快速的发给一个校正的模型，根据上下文和这段的语义去把当中可能出错的这个词进行快速的修正。那同样就是刚才我说的像这个千问对吧，Q问或者是 cloud 的这个识别或者是点或者是 dot，那每个人的习惯不一样，它就会出现这样的 ASR 的系统性的盲区。

[11:37] 刚才提到的这个 Polish 的这个阶段，我也测了好几个模型，那最终做了一个最终的抉择，就是从千问的 Flash 模型和这个 Anthropic 的 Haiku 去进行了一个选择。那最后其实也是发现嘛，虽然 Claude Haiku 这边它的质量稍微好一些，但是它的成本也高，而且还是那个问题——因为跨境传输，所以它一来一回多少会有大概 500 毫秒到一秒的这样的一个延迟。所以整个来讲的话，虽然它的质量更好，但是它的识别的体验还是不如我们自己家的这个千问 Flash，而且就是又快又便宜对吧。那我就最终选择了用千问做这样的一个输出的校验。

[12:18] 注意啊，到现在为止我是没写一行代码的，就只是在调研决策、调研决策。那这个 Polish 它不是一个魔法，它是一个提示词的工程。就是我们在用一些语音识别的会议机也好、还是识别的、或者是一些语音输入法的时候，会发现系统会让我们输入一些热词对吧，那就是我经常用的场景当中经常使用到的一些词。那像这些热词、还有上下文的一些学习，包括我的热词怎么样去形成一个场景的库，让这个输入法能够识别说有同样类型的用户，它可以调取这个库去增强其他人的这样的一个输入的方式。

[12:58] 那我就设计了一个流程，就这个流程是说每当我输入完大概 50 条内容的时候，那系统就会调用 Claude 的模型做一个精细的排查，就是在我最终输出的这 50 条当中，有哪些词是高频出现，或者是说它很明显的是在识别过程中出现错误的。那就会把这些热词提取出来，然后把那些在语境中识别错误的场景去把它归纳出来，作为一个再一次做 Polish 的这个提示词工程的一个修复的方案。那这个其实是稍微麻烦一点的，这里面会有一些工程上的一些逻辑在。

[13:34] 那最后就是这个交互的风格了。那我现在也是给大家打开一下我的这个小窗啊，大家可以看到说整个就是这样的一个窗口。那系统启动之后它就会自动的开机运行，会自动隐藏在右下角的托盘。那点击之后就可以进行一个微信的登录，可以显示今天说了多少字，然后我的语速是怎样的，202 字每分钟。还不算快啊，因为我认识的朋友用我的输入法其实有能达到 220 多个字每分钟的这样一个速度啊。还可以看到说我累计输入的字数。

[14:01] 以及我设计了一个可以去修改快捷键的，因为大部分时候可能在键盘上按 alt 或者是说按 control 加问之类的，这样的组合键去激活这个语音输入法嘛。但我发现我很多时候是不碰键盘的，或者是说就像我前几期分享的，就是我拿遥控器去远程遥控电脑的。那在这种情况下的话我就需要一个跟鼠标一体的一个方式，所以我就会把它绑定在鼠标中键上。

[14:24] 然后以及还有很多的输入法是输入完了之后，我可以去删除一些字或者是改一些字对吧，自动再去手动按回车。但是我发现因为我的输入法已经识别率很准了，再加上我平时是在 Claude 里面用，大模型也会校正我输出错误的地方，所以我就设计了一个功能是说当它识别完成之后可以自动发送。那这个也是可选的功能。那同样这个付费的环节，付费功能的开发，我也是做了一定的思考，那再往下我会给大家去讲啊。

[14:55] 就是把它这个界面做得极简，就是在输入框的右侧有一个能够显示当前识别了什么样的一个内容、以及识别出来之后它会有一个快速的展示以及自动的发送。你看这些小的点，都是一点一点一个一个小版本，从 0.5.0 开始，每一个小版本我都会做一个迭代。那包括最早我做测试的时候，这个 API key 是存在本地的，那现在也是存在云端，做了一些这个凭证的保护工作，包括一些这个安全性和这个稳健度的提升对吧。

[15:29] 或者说有些用户给我反馈说，他在用这个语音输入法的时候，切换了一个麦克风，他就发现识别不了了。那像这些小的体验，我只需要跟 Claude Code 说：某一个用户在什么样的使用场景下出现了一个怎么样的问题，那我判断可能是因为切换麦克风之后之前跟踪的那个设备不见掉了，我觉得可以在这种情况下自动识别音频设备的变化去选取一个更好的设备，比如说外置的麦克风优先选取外置的麦克风做采集去完成这样的功能。那我只需要把我的需求描述清楚，那 Claude Code 就会自动去改这个 Rust 的代码并且去完成一个上线。

[16:07] 然后我还去做了一定的更新啊。最早的时候我是没有这个登录的这个系统的，那后来也是注册了微信的开发者平台，然后全程截图给 Claude Code 去看，让它去教我如何去配置了这样的一个微信扫码登录并且做回调的这样的一个过程。这也是一个非常棒的一个学习的体验。所以我所有的用户目前都是微信扫码登录的。

[16:32] 同样最早的这个付费的方案是月费，我定了一个 19 元每个月的方案。但是呢其实在跑后台日志的时候发现，有的用户每个月是用超的，它的用量其实可能三四十块钱都能到，就是重度的使用的用户，他拿语音输入法去写文章的这样的一种情况。那还有一些用户呢一天只有可能 1000 字 2000 字，那这样的一些用户它其实是用不满这个额度的。所以其实付月费的这个模式呢，有可能导致我亏。而且会有一个点是说，当用户越喜欢越用它我是越亏本的。

[17:05] 所以我后来就会切换到一个，就是按字数付费的一个方式。那我让 CC 帮我算了一下，就是目前的几个测试用户当中，他们的用量消耗了多少算力的成本，那我再考虑到说将来我能拿到算力的优惠，最终定到了一个每千字五毛钱的这样的一个成本，就是我永远是有一个利润在里面的这样的一个方式。

[17:25] 所以那现在整个的一个过程就是：按键、然后录音、然后豆包做流式的输出给客户展示说我开始识别了、我识别的还不错，那再经过千问的一套这个校准的系统把它最终的进行改稿校准，才发送出去。那这样的一个前端的这个系统，包括我微信扫码登录、然后按照字数去扣费、余额的提醒，就是想到的这些功能全部都是叫做口喷给这个 Claude Code 去进行这个编程的。

[17:54] 所以在 23 天的时间内，我 52 次的这个提交代码。但其实弄这个输入法花费我的时间，大概是十几个小时左右的时间吧，就是整个的一个开发。因为它开发的过程是一来一回嘛，我有可能还在做别的事情，可能整个的时间都远远没有这个时间长。

[18:11] 就大家可想而知，一个开发完成度已经这么高的一个软件已经可以给别人用、可以去赚钱的这样一个产品，我只用了十个小时一个人开发，而且还是用的最顶尖的这个 Rust 的代码这样的一个框架去做的一个方式。以前是完全不能想的对吧。我还去做了一个官网，去做了一个官网去让这个消费者去看到我的这个更新的一个情况啊，包括未来的不同客户端版本的上线。

[18:41] 放在以前是想都不敢想的事情。现在真的就是只要你能表达清楚需求，你就可以做到。那还有什么想问的问题的话，大家可以去我的评论区去留言，那我们下期再见。想用输入法的朋友呢，也可以去我的输入法的网站上去下载使用。目前只有 Windows 版本，其实 Mac 的版本已经开发好了正在测试当中，那大家也敬请期待，拜拜。