语音编程的误区
提到「语音编程」，大多数开发者脑海中浮现的是这样的画面：有人逐字口述 Python 语法——「def space calculate underscore total open paren items close paren colon...」那根本不是语音编程，那是折磨。
真正的语音编程不是用声音替代键盘来输入语法，而是将声音用于软件开发中大量属于自然语言的部分：文档、注释、提交信息、拉取请求描述、任务拆解、Slack 更新和代码审查。
大多数开发者低估了开发工作中自然语言所占的比重。一个认真的开发者的时间大致分配如下：
- 20% 写代码
- 30% 写文档和注释
- 15% 写 Issue 描述和 PR 内容
- 20% 在 Slack、邮件和会议中沟通
- 15% 代码审查和规划
也就是说，80% 的工作场景中语音输入要么比键盘更快，要么同样高效。那 20% 真正需要键盘的，是语法本身。
开发者应该用语音输入什么
代码注释
注释是纯自然语言。口述一段清晰的注释——解释函数存在的原因、处理了哪些边界情况、调用者需要了解什么——比打字更轻松。
工作方式： 在编辑器中定位到注释位置，按下热键，口述说明内容，松开。清洁校正模式会去除填充词并输出整洁的散文。
示例： 按下热键，说「这个函数处理用户 token 已过期但 refresh token 仍然有效的边界情况，它会先尝试一次刷新，如果刷新也失败则强制登出，调用方应处理 AuthenticationError」，松开。注释随即出现，格式整洁。
文档和 README
README 文件、API 文档和内联 JSDoc/Docstring 注释，正是语音输入最擅长的场景。你在为人类读者写自然语言——和有人问你「解释一下这段代码」时你会说的话完全一样。
对着代码口述函数文档，往往比打字出来的更好。你自然地描述你看到的内容，省去了把想法翻译成按键动作的那层摩擦。
提交信息
好的提交信息是简短的散文：描述改动了什么、以及为什么改。口述提交信息比打字快，清洁校正模式保证措辞流畅。
拉取请求描述
PR 描述——问题背景、解决方案、测试计划、审查者备注——正是 Telvr 增强模式天然擅长的结构化内容。开发任务模式能直接输出这种格式。
示例： 按下热键，切换到开发任务模式，说「修复了支付处理流程中的竞争条件，问题在于两个并发请求可能都在扣款前通过了余额检查，针对这部分事务添加了数据库行级锁，并编写了一个同时发起两笔并发支付的测试用例」，松开。结果是一份包含问题描述、解决方案和测试说明的结构化 PR 描述。
Issue 和工单描述
用键盘一字一字敲出一份详尽的 Bug 报告或功能规范相当繁琐。对着问题自然地口述，往往更快，而且由于没有打字的机械负担，描述反而更全面。
Slack 和团队更新
进度汇报、阻塞问题、站会总结——这些本质上是对话性的内容。「我昨天完成了认证模块重构，今天在推进支付集成，目前卡在拿沙盒环境的测试凭据，准备去问 Sarah。」15 秒口述，一条完整的站会更新。
为开发工作流配置语音输入
热键配置
Telvr 默认热键（Mac 上的 Option+Space）对开发者很友好，因为它与大多数 IDE 快捷键不冲突。如有需要，热键可以自由配置。
开发者推荐配置：
- 双手保持在主键区，热键触手可及
- 使用两键组合，防止在终端中误触发
- 避开与 IDE 冲突的快捷键（建议对照 VS Code 或 JetBrains 的键位映射确认）
模式选择
针对开发工作流的模式建议：
- 清洁校正模式： 通用注释、散文文档、Slack 消息
- 开发任务模式： PR 描述、Issue 规范、技术需求摘要
- 会议记录模式： Sprint 回顾笔记、设计讨论摘要
- 邮件模式： 面向客户的技术沟通、对非技术干系人的进度汇报
IDE 集成
Telvr 使用系统级文本插入，因此在任何应用的任意文本字段中均可工作，包括：
- VS Code（代码编辑器、集成终端、搜索框、注释区域）
- JetBrains 系列 IDE（IntelliJ、WebStorm、PyCharm）
- Zed、Neovim（处于插入模式时）
- Linear、Jira、GitHub（浏览器中）
- 终端（输入非命令性文本，如 git 提交信息时）
无需安装任何插件。任何可编辑的文本字段都可以直接使用。
真实的开发工作流
以下是实际开发会话中语音输入的样子：
早晨在 Slack 发站会更新： 按下热键，口述昨天进展 + 今日计划 + 阻塞问题，松开。20 秒搞定。
写代码： 键盘。正常的开发节奏。
为复杂函数添加注释： 定位到对应行，按下热键，自然地口述说明，松开。
在 GitHub 上创建 Bug Issue： 打开新 Issue，按下热键并切换到开发任务模式，描述 Bug 现象和复现步骤，松开。给 Issue 命名，提交。
写提交信息：
在终端执行 git commit，在弹出的编辑器中按下热键（或重定向到文件），口述提交描述，松开。
写 PR 描述： 打开 PR 表单，按下热键并切换到开发任务模式，说明这个 PR 做了什么、为什么这样做，松开。根据需要补充审查者备注。
在 Slack 回答技术问题： 按下热键，大声解释技术决策或相关概念，松开。清洁校正模式会输出可读的解释，无需仔细斟酌每个词。
生产力的真实提升
语音输入在开发中带来的最大收益，不在于原始速度，而在于消除摩擦。文档经常被推迟甚至完全跳过，因为打字感觉像是在正式编码工作之外的额外负担。当写一段注释或 Docstring 只需 15 秒口述而非 2 分钟仔细打字时，愿意动手的门槛就大幅降低了。
更完善的代码注释、更全面的 PR 描述、更详尽的 Issue 报告——这些往往才是开发者使用语音输入的实际成果，而不仅仅是把同样的习惯执行得更快。
一周养成新习惯
将语音输入融入开发工作流的节奏：
第 1 天： 只用语音发 Slack 消息。其他什么都不做。
第 3 天： 加入提交信息。在终端编辑器里口述描述。
第 5 天： 加入内联注释。写完复杂函数后，直接开口描述它的逻辑。
第 7 天： 加入使用开发任务模式写 PR 描述。你会发现描述写得比以前更完整——因为说话比打字更轻松。
两周后，习惯自然建立，语音输入不再感觉刻意，而是随手就来。