用Claude Code搓了一个MacOS语音输入tool
这个博客搭建之初，我是想多写一些技术内容的，让自己看起来更像个专业的程序员。但写着写着就偏题了，净是些观后感和随想。这回却要来写点技术的事情，着实让自己都有些感到不可思议。
2024 年以后，我就很少写技术相关的内容了，因为 AI 出来之后，我能分享的技术心得实在有限。遇到什么问题直接问 AI，它给出的结论比我自己摸索的要准确得多。既然如此，把这些内容分享出来的意义也就不大了。但这回想专门写一写，是因为我意识到，2026 年的 AI 开发能力又迈上了一个新台阶，我理解技术的方式正在发生新的变革。
起因
大模型出来以后，我经常跟各种大模型和 Agent 对话，不管是日常聊天、计划梳理、随想分享，还是工作中的代码编写、任务完成、原因分析，AI 工具几乎渗透了我日常的方方面面。AI 的效率很高，帮我解决了不少生活和工作中的难题。
但与此同时，我使用 AI 的瓶颈不再是 AI 本身，而是我跟它对话交流的速度。很多时候脑子里有很多想法，但还没来得及转化为文字让 AI 去分析，就已经消失了。所以在过去半年里，我一直在尝试各种语音输入工具来提升效率。
调研下来，比较好用的主要有两款。一是移动端的豆包输入法，这篇文章也是用它口述输入的。它的名词识别准确率很高，说完话后还会对内容进行二次润色和整理，我在手机上已经用它替代了默认输入法。美中不足的是，它目前只在移动端表现出色，Mac 端只有豆包 APP 内的语音输入功能，麦克风唤醒需要 2 到 3 秒，识别准确率也不够理想。另一款是 TypeLess，在 Mac 和 Windows 上都支持很好的语音输入和大模型润色功能，按下 FN 键即可开始口述，它会自动把口癖、说错的字以及可以书面化的内容都整理好，特别适合在大模型对话场景中使用。不过它的大模型润色有点过于强劲，人机味偏重，而且免费试用一个月后，每个月至少需要 12 美元，否则每周只能说 4000 字。
于是那段时间我的 workflow 相当笨拙：先在手机上用豆包输入法口述好需求，再通过 Mac 和 iPhone 之间的跨设备剪贴板复制过去，在电脑上执行。效率上勉强还行，但总有一种割裂感。我习惯工作时把手机放远一点，不然很容易就刷起来了。
跟朋友聊起这个事情时，有人说：”那你为什么不自己写一个呢？”想想也对，我本质上是个开发，虽然是个菜菜的开发。TypeLess 和豆包输入法的实现原理无非是接语音输入 API，再用大模型润色一下，没有想象中那么难。于是在一个平凡的周末，我打开 Claude Code，开始了这次折腾。
开发过程
顺带提一句，我目前比较推崇 Claude Code 和 CodeX，模型质量带来的输出上限差异是真实存在的。我在开发时主要使用 packycode 作为中转站，表现还不错。
我先和 Claude Code 梳理了需求，写了一份简单的 PRD，确认好要开发的功能，然后让它进行调研。调研结束后，我们选定第一版方案：用 Python 实现基础功能，语音输入支持本地 Whisper 和远端讯飞大模型，同时接入 DeepSeek 进行大模型润色。AI 思考了很久，在网上做了各种 fetch 和搜索，为我生成了详细的 plan，Plan mode 在这个过程中真的很重要。我 review 之后感觉没什么问题，就让它开始开发，没过多久便写好了，简单测试后发现功能确实能跑通。
不过有些功能与预期存在出入。比如我想设置 FN 键按下后开始说话，FN 加 Space 同时按下则是语音转文字加大模型整理，但实际使用时发现 FN 加 Space 会不断地输入空格，效果很抽象。于是和 AI 讨论迭代后，最终改为：用右 Option 键进行语音输入，右 Command 键则是语音输入加大模型整理，这两个键在日常使用中都很少用到，不容易误触。
接下来是速度问题。我让 AI 调研豆包输入法为什么这么快，它给出的答案是豆包底层用的是火山引擎的语音输入 API，性能更好。于是我让它阅读火山引擎的 API 文档，debug 了一会就跑通了，识别速度比讯飞快很多，和豆包输入法的效果非常接近。火山引擎还给新用户送 20 小时的免费额度，完全够用。我立刻让 AI 把底层换掉，本地 Whisper 太慢不要，讯飞也有点慢只保留火山引擎。
它甚至会自己打开浏览器查询我喂给他的文档。
在用户体验上，我发现按下按键说完话后，并没有明确的反馈来告知语音是否成功转换。于是让 AI 用 Rops 把工具做成常驻菜单栏：按下右 Option 键时显示麦克风图标，转换中显示 loading 图标，完成后显示完成图标，让整个过程更加可视化。第一版方案里 emoji 的显示会跑到下面去，后来改成简单字符图标规避了这个问题。
做到这里，对我个人使用来说已经足够了。但一个需要懂技术才能跑起来的工具，终究不够完善。于是我又做了两件事：一是完善菜单栏，让用户可以在设置页面填写各种 API key、测试连接，并检测辅助功能等权限；二是尝试把 Python 工具打包成可以在 Mac 上直接安装的应用。
然而在打包这一步，我栽了不少跟头。Python 通过 Py2APP 打包时踩了很多坑，打包时频繁报错，而打包后的 APP 又出现了权限问题，无法插入文字，也无法保存到剪贴板，和命令行里跑的效果完全不一样。开发到这里有点卡，就先去忙别的事情了。
第二天晚上再来看这个问题，我先和另一个 AI 从架构层面聊了一下。它给了我一个更激进的建议：把 Python 重写为 Swift，原生支持肯定更好，打包成的 APP 也更轻量。于是我做了这个决定，让 AI 把之前所有 Python 代码重写为 Swift 的 Xcode 项目。顺带一提，所有的 git 提交也是让 AI 做的，我全程没有参与。甚至一开始代码没有跑通，我把截图直接贴给 Claude code 看，他分析了一会跟我说，我找到你的问题了，这段代码没有跑通的原因是你把 API key 和 API Token 贴反了，把它们交换回来就可以了。感觉自己笨笨的。
我本身不会用 Xcode，还让 AI 教了我怎么把项目 build 出来。最后发现这个项目真跑通了，用 Swift 编写非常好地解决了 Python 打包的各种兼容性问题，文字插入、菜单栏、剪贴板功能全部正常。我的第一个像模像样的 Vibe Coding 项目，就这样完成了。
整个开发过程，我基本都是一心二用的状态：先输入好提示词让 AI 生成计划，它调研的时候我去忙别的事情，需要批准了就 approve，完成后 review 一下再让它继续开发，开发期间继续做其他事，等完成了再回来验收。我完全没有 review 过代码，就是一个纯黑盒开发的过程。
最终效果
工具运行后，用户需要先填写火山引擎的 API key，如果需要大模型整理功能，还需要提供 DeepSeek 的 API key。菜单栏支持检测辅助功能、语音输入和麦克风等权限，并支持直接跳转到对应设置页面添加权限。设置完成后，按右 Option 键进行语音输入，按右 Command 键则会在语音输入的基础上，通过指定的 Prompt 对内容进行润色和整理。
有填写API的菜单。
还有一些可以改进的地方：没有按 TDD 模式开发，每次测试都是手动回归；只支持火山引擎和 DeepSeek，可以改成工厂模式适配更多 API；大模型整理的系统提示词是固定的，其实可以让用户自己编辑，比如选择是否保留句号、是否进行分点等。
项目地址：https://github.com/Baokker/PressTalk
不过我大概不会再继续更新这个工具了，因为没多久在小红书上刷到了一款叫”闪电说”的语音输入工具，相当于我做的这个小 tool 的 Pro Max 版。它支持本地加联网多种语音输入方式，推荐使用火山引擎，同时支持 DeepSeek、Kimi、GPT 等多种大模型进行润色，还支持自定义整理功能和快捷键，配置教程也很详细，有需要的朋友可以直接去试试。
一些感悟
这段经历给了我几点比较真实的感受。
第一，现在的 AI 开发工具已经很成熟了。整个开发过程中，我没有使用任何额外的skills（例如很火的superpowers），光凭模型和 Agent 本身的能力，就帮我完成了以前因成本太大而不愿去做的事情。
第二，在 AI 大模型时代，智力不再是高不可攀的资产。随着大模型能力不断进步，信息差在持续缩小，想做什么、学什么，都可以通过大模型快速上手。
第三是一种越来越强烈的职业危机感。学了六七年计算机，从入门时就有人喊着”要凉”，喊到现在也没真凉。但 AI 能力的进步让我感到真实的焦虑：以前花了大量时间积累的 CSS 样式、前后端通信方式、后端架构等知识，它们的价值在迅速缩水。当然，一些开发上的 sense 可能会让我更流畅地使用这些 AI coding 工具，但这个差距确实在越来越小。
更重要的是，我觉得现在用 AI coding，代码能力本身反而不是最关键的，更重要的是如何清晰地捕捉需求，并把它转化为 AI 能理解的文字。从这点来说，程序员的边界确实在逐渐模糊，纯粹靠写代码立身的空间也在被逐渐挤压。在这次开发过程中，我更多时候扮演的是 PM 的角色，用 PM 的思维去思考产品该怎么做，具体怎么实现则交给 AI。我在开发层面只有一小部分宏观架构上的思考，并没有深入参与具体的编码工作。
也许这就是 2026 年开发的新常态。等一个马斯克的脑机接口。