语音编码的神话
当开发人员听到"语音编码"时，大多数人想象有人听写Python语法："def space calculate underscore total open paren items close paren colon..."那不是语音编码。那是折磨。
真正的语音编码不是关于替换语法的键盘输入。它是关于使用你的声音处理软件开发中的大部分是自然语言：文档、评论、提交消息、PR描述、任务分解、Slack更新和代码审查。
大多数开发工作中自然语言与语法的比例比大多数开发者意识到的更高。彻底的开发者可能花费：
- 20%写代码
- 30%写文档和评论
- 15%写问题描述和PR内容
- 20%在Slack、电子邮件和会议中
- 15%关于代码审查和规划
那是80%的工作其中语音输入要么比输入更快，要么同样有效。20%保留在键盘上的确实是语法。
作为开发者要听写什么
代码评论
评论是纯自然语言。写一个清晰的评论解释函数为什么存在、它处理什么边界情况或调用者应该知道什么比输入更容易说。
工作流： 在你的编辑中导航到评论位置，按热键，说出解释，释放。清理模式删除填充词并产生干净散文。
示例： 按热键，说"这个函数处理用户令牌过期但刷新令牌仍然有效的边界情况，它尝试一个刷新然后强制登出如果那也失败，调用者应该处理AuthenticationError"，释放。评论出现格式化和干净。
文档和README
README文件、API文档和内联JSDoc/docstring评论是语音输入优秀的确切地方。你为人类读者写自然散文——与你会说的相同如有人要求你解释代码。
在看代码时说出函数的文档产生比输入它更好的文档。你自然描述你看到的，无需翻译想法到按键的摩擦。
提交消息
好的提交消息是短散文：什么改变了为什么。说出提交消息比输入它更快，清理模式确保它读起来很好。
拉取请求描述
PR描述——问题、解决方案、测试计划、审查者笔记——正是Telvr的增强模式本地处理的结构化内容类型。开发任务模式产生这个结构。
示例： 按热键，切换到开发任务模式，说"修复了支付处理流中的竞争条件，问题是两个并发请求可以在任何一个扣除前都检查余额，添加了数据库级行锁围绕事务，添加了产生两个并发支付尝试的测试"，释放。结果是带问题、解决方案和测试笔记的结构化PR描述。
问题和票据描述
写一个详细的bug报告或功能规范通过输入很繁琐。在看问题时自然说它更快，并经常产生更彻底的描述，因为你不是在与输入的机械开销对抗。
Slack和团队更新
进度更新、阻碍、站立总结——这些本质上是会话。"我昨天完成了认证重构，今天我在做支付集成，被阻碍在获取沙盒环境的测试凭据，会问Sarah。"那是一个完整的站立在15秒的语音中。
为开发人员工作流设置
热键配置
默认Telvr热键（Mac上的Option+Space）对开发人员工作效果很好，因为它不与大多数IDE快捷键冲突。如果你更喜欢其他，热键是可配置的。
开发人员推荐设置：
- 将手放在主行上
- 使用两键组合来防止在终端中意外激活
- 避免与你的IDE冲突的热键（检查VS Code或JetBrains键映射）
模式选择
对于开发人员工作流：
- 清理模式： 常规评论、散文文档、Slack消息
- 开发任务模式： PR描述、问题规范、技术需求摘要
- 会议记录模式： Post-sprint回顾笔记、设计讨论摘要
- 电子邮件模式： 面向客户的技术通信、对非技术利益相关者的状态更新
IDE集成
Telvr使用系统范围文本插入，这意味着它在任何应用的任何文本字段中有效。这包括：
- VS Code（代码编辑器、集成终端、搜索、评论）
- JetBrains IDE（IntelliJ、WebStorm、PyCharm）
- Zed、Neovim（在插入模式时）
- Linear、Jira、GitHub（在浏览器中）
- 终端（输入非命令文本如git提交消息）
没有插件要安装。任何可编辑的文本字段都是公平游戏。
真实开发人员工作流
这是在实践中使用语音输入的开发会话：
早上Slack中的站立： 按热键，说昨天进度+今天计划+阻碍，释放。在20秒内完成。
写代码： 键盘。正常开发工作流。
向复杂函数添加评论： 导航到正确的行，按热键，自然说出解释，释放。
为错误创建GitHub问题： 打开新问题，按热键加开发任务模式，描述bug和再现步骤，释放。给问题命名，提交。
写提交消息：
git commit在终端，按热键在打开的编辑中（或导到文件），说提交描述，释放。
写PR描述： 打开PR形式，按热键加开发任务模式，解释PR做什么和为什么，释放。如果需要添加审查者笔记。
在Slack中回答技术问题： 按热键，解释技术决定或概念大声，释放。清理模式产生可读解释而无需小心输入。
生产力现实
从开发中的语音输入获得的最大收益来自不是原始速度，而是摩擦减少。文档经常被延迟或完全跳过，因为输入它感觉像是在实际工作编码之上的开销。当写一个评论或文档字符串需要15秒的说话而不是2分钟的仔细输入，添加它的阈值大幅下降。
更好的文档代码、更完整的PR描述和更彻底的问题报告通常是开发人员语音输入的实际结果——不仅仅是相同习惯的更快执行。
一周到一个新习惯
将语音输入融入到你的开发工作流：
第1天： 仅为Slack消息使用语音。没有其他。
第3天： 添加提交消息。在终端编辑器中说出描述。
第5天： 添加内联评论。开始在你完成写它们时讲述复杂函数。
第7天： 添加带开发任务模式的PR描述。注意你写比之前更完整的描述，因为说话比输入更快。
在两周后，习惯建立了，语音输入感觉自然而不是费力。