用了几个月 Typeoff 后，我把语音和键盘重新分了工

我经常遇到一种情况：脑子里已经把事情想得差不多了，手放到键盘上，最后却只写出“这个可以做，我再看看”。

接口要不要改、哪些场景要测、哪里还有风险，其实都想到了。但打字时我会下意识地压缩内容，先把结论发出去，后面再靠几轮消息补上细节。

几个月前，我开始把 Typeoff 放进日常工作流。最初看中的是语音输入速度，真正让我持续使用的，是它让“把话说完整”变得没那么累。

我现在不会什么都用语音

刚开始时，我连“收到”都想用语音输入。用了一段时间后，使用范围反而变窄了。

简短回复、数字、文件路径、函数名和命令仍然用键盘。这些内容容错率很低，错一个字符反而更麻烦。

语音主要用在另一类任务上：需求分析、长消息、会后复述，以及给 AI 交代复杂任务。这些场景先要保住完整上下文，句子可以在发送前再精修。

场景一：回复需求时，把“不做什么”一起说出来

企微里经常会收到一大段需求，最后跟着一句“这个能不能做”。

以前我往往只回结论。现在会直接说：

这个需求逻辑上可以做，但这一版只改结算页的优惠券展示和选择状态。后端接口、会员价和价格计算先不动。测试要覆盖老用户有券、新用户无券、券过期和手动取消选择。支付回调是否受影响还需要确认，确认前不要对外承诺。

这段话用键盘也能写，但我很少愿意一次性敲得这么完整。口述时可以连续把范围、测试点和待确认项说完，再由 Typeoff 清理重复词和标点。

发送前我会再看一遍，尤其是产品名、数字和承诺类内容。语音可以减少整理成本，不能替我承担决策责任。

场景二：给 AI 补齐背景和限制条件

我每天都会用 ChatGPT、Claude 或 Cursor。以前用键盘提问，常常写到一半就觉得“差不多了”：

帮我看看订单并发导致库存错乱的问题。

模型不知道技术栈，也不知道我已经查过哪些位置。这样的对话往往要补好几轮上下文。

换成语音后，我会把 Next.js、Prisma、事务范围、死锁现象、连接数限制和输出要求一口气讲完。然后回到键盘，检查函数名、文件路径和报错代码。

我也会根据使用场景调整文字风格和整理强度。技术问题不需要被修饰成一封正式邮件，保留术语和因果关系更重要。

场景三：会后先复述，再整理成 Markdown

会议结束后，空白文档往往比会议本身更让人头疼。结论散落在几十分钟的讨论里，拖到第二天再写，很容易把被否决的方案和待确认事项一起忘掉。

我现在会趁记忆还在，对着 Typeoff 说三五分钟。顺序不用很完美，只要尽量把决定事项、不做范围、负责人和未确认风险都讲出来。整理后再补上链接和时间点，一份 Markdown 纪要就有了可继续修改的底稿。

哪些情况我还是会用键盘

语音输入并不适合所有环境。

开放办公区里，对着电脑连续说几分钟会影响别人，内部项目和客户信息也不适合直接念出来。数字、版本号、路径和代码参数则是另一个问题，错一个字符就可能增加排查时间。

另外，整理强度不是越高越好。企微里的一句简短回复，如果被处理得像正式公文，原来的口气会被磨平。我会按场景选择风格，发送前仍然会快速读一遍。

我现在的分工

用到现在，我对 Typeoff 的定位已经很简单了。

需要精确落字的事情交给键盘，例如代码、数字、路径和最后一轮修改。需要完整上下文的事情先用语音，例如需求分析、AI 提问、长消息和会议复述。

语音并没有让我放弃键盘。它只是把“我已经想清楚，但懒得完整写出来”的那部分内容，更完整地送到了输入框里。