仅用半天时间，手搓超火的「Typeless 」同款智能语音输入法
仅用半天时间，手搓超火的「Typeless 」同款智能语音输入法从0开始，半天时间，做了一个完全可用的智能语音转文字智能输入法（MAC版本）取名：Voicetype Mac
最近我一直在使用 Typeless。它最吸引我的地方，并不只是“语音转文字”，而是它能听完一整段表达，再帮我把内容重新梳理一遍。
口述时出现的停顿、重复、语气词、前后颠倒，甚至一段话讲了两三遍，都没有太大关系。结束录音后，AI 会理解整段内容，删除废话、修正表达，并把多个观点整理成清晰的段落或编号列表。
但 Typeless 有会员和使用量限制（会员是12美金/月），于是我产生了一个想法：
能不能参考 Typeless 的核心体验，自己做一款只供个人和几个朋友使用的 Mac 智能语音转文字的输入法？
结果是：我们用了大约半天时间，完成了一个能够实际运行的 macOS 版本。
目前开发完成的MVP，功能测试几乎可以替代原版Typeless了。但是还不能说达到了 Typeless 商业产品的完整度。从录音、转写、AI 整理到自动写入输入框，核心流程已经完整跑通。
一、我真正想做的，不是实时听写
最初，我们也尝试过“边说边出字”。
但测试之后发现，这并不是我真正想要的体验。
因为人在口述时经常会出现这些情况：
“嗯、呃、那个、就是说”等语气词；
同一句话重复两三遍；
说到一半推翻前面的表达；
先说结论，后面又补充原因；
明明讲了几个观点，却没有明确说“第一、第二、第三”；
一句话很长，语序和结构比较混乱。
如果一边说、一边把文字写进输入框，这些问题也会被原样保留下来。它只是把键盘输入换成了语音输入，并没有真正发挥 AI 的价值。
所以，我们重新定义了产品逻辑：
第一次触发快捷键开始录音，录音期间只保存和转写内容，不向输入框写入文字。第二次触发快捷键结束录音，然后让 AI 通读全文、理解原意、重新整理，最后一次性写入终稿。
完整流程是：
开始录音 → 持续收集语音 → 停止录音 → 获得完整转写 → AI 通读整理 → 一次性写入当前输入框
这也是整个产品最核心的设计。
二、产品的整体设计思路
我们把应用暂定名为 VoiceTypeMac，第一版只开发 Mac，不考虑 iPhone、会员、支付、云同步和用户系统。
产品被拆成了几个相互独立的部分。
1. 录音模块
使用 macOS 原生的 AVAudioEngine 采集麦克风音频。
用户第一次按下快捷键后开始录音，第二次触发时停止。它不是长按式对讲，松开快捷键后仍然会继续录音。
这样用户可以连续讲一分钟、两分钟甚至五分钟，中间可以停顿、修改和重复。
2. 语音转文字模块
语音识别和文字整理被设计成两个独立模块。
语音识别只负责尽可能准确地还原用户说了什么，不负责重写内容。
在用户说话过程中，音频会持续发送给转写服务，但转写结果只保存在应用内部，不会实时写进当前输入框。
3. AI 文字整理模块
停止录音后，完整转写才会交给文字模型。
AI 需要完成：
删除无意义的语气词和口头禅；
删除明显重复的内容；
修正语病、语序和前后颠倒；
保留人名、数字、时间、金额和专业术语；
根据语义合理分段；
发现多个并列观点时，自动整理成 1、2、3、4；
有层级关系时，整理出清晰的篇章结构；
不编造用户没有表达过的信息。
我们还提供了“中文转英文”模式。用户可以直接说中文，最终得到一段自然、适合实际沟通的英文，而不是机械的逐字翻译。
4. 自动写入模块
AI 整理完成后，应用需要把终稿自动写入用户当前正在使用的输入框。
这里使用了 macOS 的 Accessibility API：
开始录音时记录当前应用和光标位置；
AI 处理完成后重新激活原来的应用；
尝试直接写入当前输入框；
如果某些应用不支持直接写入，就自动模拟 Command + V；
如果仍然失败，至少把结果保留在剪贴板中，避免内容丢失。
三、我们调用了哪些接口
第一版采用“云端转写＋大模型整理”的方案，因为它开发速度快，也更容易先验证核心体验。
AI 文字整理
文字整理支持两个 Provider。
第一种是 OpenAI Responses API：
它负责通读完整转写，根据“智能口述”或“中文转英文”的提示词生成最终内容。
第二种是 DeepSeek Chat Completions API：
DeepSeek 使用非思考模式和较低温度，主要目的是减少等待时间和调用成本。
两个模型并不是同时调用，而是可以在设置中切换。这样既方便比较速度和效果，也避免应用和某一家模型供应商强绑定。
所有模型名称和接口地址都放在独立配置层中，后续可以继续更换模型。
四、我们如何参考 Typeless
我参考的是 Typeless 的产品逻辑和交互方式，没有复制它的品牌、Logo、代码或具体界面资源。
主要参考了以下几个方面。
1. 两段式处理逻辑
不是边说边输出，而是先收集完整表达，再由 AI 统一理解和整理。
这是我们认为 Typeless 最有价值的地方。
2. 全局快捷键
用户不需要先打开 VoiceTypeMac。
只要把光标放在任意应用的输入框中，通过全局快捷键即可开始和停止录音。
目前支持轻触 Control + Command，同时保留 Control + Command + Space 作为兼容性更好的备用组合。
3. 录音悬浮条
录音时会显示一个圆角悬浮条，包括：
取消按钮；
动态声音波形；
完成按钮。
结束录音后，悬浮条会切换成“正在识别”“正在整理”“正在写入”等状态，让用户知道应用正在做什么。
4. 设置、词典和历史记录
我们也参考了 Typeless 的设置结构，加入了：
API Key 设置；
输入模式；
全局快捷键；
麦克风选择；
个人词典；
本地历史记录；
开机启动；
Mock 测试模式。
个人词典可以保存人名、品牌名、产品名和专业术语。同一份词典会同时提供给语音识别、文字整理和中译英模块。
五、半天开发过程中遇到的几个问题
真正花时间的地方，并不是把界面画出来，而是让整个流程在 macOS 上稳定工作。
1. 全局快捷键没有反应
纯修饰键组合很容易被系统辅助功能或其他软件拦截。
我们最后增加了两套机制：
轻触 Control + Command；
Control + Command + Space 作为备用。
应用还会检测快捷键注册失败，并给出明确提示。
2. 辅助功能权限
没有 Accessibility 权限时，应用虽然能生成文字，却无法自动写入其他应用，只能退回剪贴板，让用户手动按 Control + V。
授权后，我们增加了：
记录原目标应用；
恢复目标应用焦点；
Accessibility 直接写入；
模拟粘贴回退。
最终实现了整理完成后自动把文字填入输入框。
3. API 和网络问题
测试过程中遇到过网络连接、VPN 路由以及模型配置错误。
因此我们增加了：
OpenAI 和 DeepSeek 连接测试；
请求超时；
网络错误重试；
明确的错误提示；
Mock Provider。
没有 API Key 时，也可以通过 Mock Provider 测试录音、状态机、悬浮窗和粘贴流程。
4. 悬浮窗外面的灰色矩形
最初虽然把 SwiftUI 背景设成了透明，但悬浮条外面依然有一块矩形灰色底板。
原因不是胶囊颜色，而是 AppKit 窗口和 SwiftUI Hosting View 仍然保留了矩形画布。
最后我们让窗口尺寸直接贴合胶囊内容，并在窗口层做透明和圆角裁切，才真正去掉了外层矩形背景。
六、最终做出了什么
目前 VoiceTypeMac 已经可以完成：
在任意 Mac 应用中触发全局快捷键；
开始整段录音；
录音期间允许停顿、重复和自我修正；
第二次触发后停止录音；
调用 OpenAI 获得完整转写；
使用 OpenAI 或 DeepSeek 整理全文；
删除语气词、重复内容和明显口误；
根据语义自动分段或生成编号列表；
支持中文直接转成自然英文；
将终稿一次性自动写入原输入框；
写入失败时自动保留到剪贴板；
将 API Key 安全保存在 macOS Keychain；
保存本地历史记录和个人词典。
七、半天能做出来，意味着什么
这次最有意思的地方，不是“半天做出了一个 Typeless”，而是一个人借助 AI 编程工具，已经可以在很短时间内完成过去需要多个角色协作的产品原型，关键是自用完全够用，几乎可以替代一个成熟的商业产品。
全程 Codex 5.6sol模型，快速模式，总共消耗 200刀Pro会员周量的8%Token量。
整个过程中，我们通过自然语言不断完成：
产品需求梳理；
技术架构设计；
Swift 项目创建；
API 接入；
权限调试；
快捷键调试；
UI 优化；
自动粘贴；
编译和测试；
应用安装。
这是一次全新的尝试，竟然完全跑通了，希望能够给大家期待借鉴意义。
这篇对我最大的启发是：不要把收藏当进步。 非常好，顶一下！
页:
[1]