为什么 AI Coding 时代，语音输入会变成新的 Prompt 入口？

用户79420320746
2 阅读8分钟

1. 以前语音输入解决的是“少打字”

传统语音输入的目标很简单：把说的话转成字。

这个目标对短消息、搜索、聊天很有用，但对开发者来说经常不够。因为开发者口述的内容不是一句普通自然语言，而是：

  • “帮我检查登录页验证码按钮的状态恢复逻辑”；
  • “这个接口报错以后要恢复 loading，并把错误信息展示出来”；
  • “帮我把这段逻辑拆成 hook，注意不要改变现有 props 结构”；
  • “这个 PR 里需要说明为什么把缓存 key 从 userId 改成 tenantId + userId”。

这些内容表面上是语音，实际上是 prompt、issue、PR review、bug 复现和技术方案。

所以 AI Coding 时代的语音输入，不应该只看“识别准不准”，还要看它能不能把口语变成可用的 prompt。

2. 开发者需要的是 Prompt Buffer，不是自动发送

很多语音输入产品会追求“说完直接输入”。这个体验在聊天里很爽，但在 AI Coding 场景里反而危险。

开发者真正需要的是一个中间层：

按住说话
→ 转写
→ 补标点 / 轻量纠错 / 去口语冗余
→ 进入可编辑文本框
→ 用户 review
→ 再提交给 Codex / Claude Code / Cursor / ChatGPT

也就是说，语音输入最好不要直接替你按回车。

原因很现实：

  • prompt 里可能有文件名、变量名、接口名；
  • 中文和英文、代码术语经常混在一起；
  • 语音识别会把技术词识别错；
  • 用户可能临时改口；
  • AI Coding 工具收到 prompt 后往往会立刻执行推理或修改代码。

如果语音输入直接发送，错一个术语就可能让 AI 往错误方向跑。
所以“review-before-send”应该是开发者语音输入的底线。

3. Typeless / OpenTypeless / 豆包这类产品正在教育市场

过去一年，语音输入明显从“输入法附属功能”变成了独立产品方向。

Typeless 这类商业产品证明了一件事：用户要的不是原始转录，而是“说完之后像写出来的文字”。它强调跨应用、润写、上下文、个人词典和速度。

OpenTypeless 这类开源项目则在另一个方向上做得很清楚：跨平台、多 STT / LLM provider、免费开源、可配置。

豆包、搜狗、讯飞、微信语音输入也在不断强化大模型改写和语音输入能力。

这些路线都说明：语音输入正在从“听写”变成“表达层”。

但开发者场景还有几个特殊问题：

  1. 技术词、项目名、变量名比普通输入更难识别；
  2. prompt / issue / PR 描述往往包含半结构化信息；
  3. 公司需求、客户信息、代码上下文经常比较敏感；
  4. 用户需要先检查，再决定是否发给 AI；
  5. 中文开发者经常是中文 + 英文术语混说。

这就是为什么我觉得“开发者语音输入”会成为一个独立的小方向。

4. 本地优先不是玄学，是开发者场景的现实需求

语音输入里最容易被忽略的是数据边界。

普通聊天内容上云，很多人可能无所谓。
但开发者口述的内容经常是：

  • 公司需求；
  • bug 复现；
  • 客户反馈；
  • 技术方案；
  • PR review；
  • 内部系统名；
  • 接口路径；
  • 甚至某些还没公开的产品设计。

这类内容不一定是“绝密”，但确实不适合默认到处流转。

所以本地优先路线的价值不是说“云端一定不安全”，而是给用户多一个选择：

  • 能本地处理的尽量本地处理；
  • 历史记录默认留在本机；
  • 用户可以审查代码、模型和数据；
  • 涉及训练或共享时必须明确 opt-in；
  • 不把用户改写历史默认上传或自动变成公开数据集。

成熟商业产品通常体验更好，本地开源项目通常更可控。两者不是谁完全替代谁，而是取舍不同。

5. 我做 MyVoiceTyping 的思路

我最近在维护一个开源项目：MyVoiceTyping。

它不是想立刻“打败 Typeless”，也不是一个成熟商业产品。它更像一个面向中文开发者的实验：把语音输入做成 macOS 上的本地优先 prompt 输入层。

当前重点是：

  • macOS 中文 / 中英混合语音输入；
  • 按住快捷键说话，松开后转写；
  • 补标点、轻量纠错、轻量润写；
  • 粘贴到当前输入框前可以 review；
  • App、文本润写模型、数据集都公开；
  • 0 费用、MIT License；
  • 尽量把音频、文本历史和改写样本留在本机。

相关资产：

6. Self-Evolution：让本地模型越用越懂你

语音输入还有一个很有意思的问题：每个人说话习惯都不一样。

有人经常说项目名；
有人经常说英文库名；
有人写 prompt 喜欢“帮我检查一下”；
有人喜欢非常结构化地说“背景、问题、期望输出”；
有人需要把口语整理成 PR 描述；
有人需要把口语整理成给 AI Coding 工具的任务。

通用模型很难一开始就懂这些习惯。

所以 MyVoiceTyping 新增了 Self-Evolution / 本地自进化方向：基于本机 voice_history.jsonl 中的原始转写、用户最终修正文本和输入场景，在用户确认后，用本机 MLX LoRA 调优本地文本改写模型，再转换为 GGUF Q4 替换本地模型。

简单说就是：

原始转写
→ 用户修正后的最终文本
→ 本机偏好样本
→ 用户确认后本地调优
→ 本地润写模型更贴近你的技术词和表达习惯

这里有几个边界必须说清楚：

  • 不默认上传云端；
  • 不自动进入公开数据集；
  • 不声称已经是成熟自动闭环；
  • 本地训练 / 调优应由用户确认后执行；
  • 敏感文本应该先用虚构样例测试，不要一上来就输入公司机密。

我更愿意把它称为“本地偏好学习”或“本地自进化入口”，而不是夸张地说它已经完全懂你。

7. 一个理想的 30 秒 Demo 应该长什么样

我认为开发者语音输入的 Demo 不应该拍成“识别率炫技”，而应该拍成一个真实任务：

帮我检查一下登录页面，用户点击发送验证码以后按钮应该进入倒计时，如果接口报错需要恢复按钮并显示错误信息。

理想链路是：

  1. 打开 Cursor / Codex / GitHub Issue 输入框；
  2. 按住快捷键说这段需求；
  3. 松开后得到一段可读 prompt；
  4. 系统补好标点、断句和少量润写；
  5. 用户检查；
  6. 再决定是否发送。

这比展示“语音转文字准确率 98%”更能说明问题。
因为开发者真正关心的是：这段话能不能变成 AI 能理解、我也敢发出去的 prompt。

8. 这个方向还早，但值得做

今天的语音输入产品已经很多了。

如果你要成熟体验、跨平台、商业支持，Typeless 这类产品可能更合适。
如果你要跨平台、多 provider、开源配置，OpenTypeless 这类项目很值得看。
如果你主要用大厂输入法，豆包、搜狗、讯飞也会越来越强。

MyVoiceTyping 选择的是更窄的一条路：

macOS
中文 / 中英混合
AI Coding prompt
本地优先
0 费用
App + 模型 + 数据集公开
Self-Evolution 本地偏好调优

它现在还早期，但我觉得这个方向值得有人做。

因为 AI Coding 让 prompt 变得越来越长，越来越像“口述任务”。
而人脑组织需求的速度，很多时候确实比手打更快。

如果语音输入能把“想法 → 可 review 的 prompt”这段链路做好，它就不只是输入法，而是 AI Coding 的基础设施之一。

9. 如果你想试

可以先看 30 秒介绍页：

botaruibo.github.io/MyVoiceTypi…

或者直接看 GitHub：

github.com/botaruibo/M…

建议先用虚构内容测试，比如：

帮我检查一下登录页面，用户点击发送验证码以后按钮应该进入倒计时，如果接口报错需要恢复按钮并显示错误信息。

如果你觉得这个方向有价值，欢迎 Star、提 issue，或者反馈：

  • 安装和权限哪里卡；
  • 中文 / 中英混合是否自然；
  • 技术词有没有被改坏；
  • 润写是否过度；
  • 是否需要 raw transcript 和 polished prompt 对照；
  • 你会不会把它用于 AI Coding prompt。

这些反馈比泛泛的点赞更有用。
因为一个本地优先的语音输入工具，最终应该长成用户真的敢在工作流里使用的样子。

avatar
文章
阅读
粉丝