语音优先工作流：我们一天的 voice-first 工作方式

我是 Shuran，Loqua.ai 的创始人。这里写的是我们语音优先工作流的真实版本：它在哪里省时间，在哪里会失败，以及我会怎样处理。目标不是表演生产力，而是缩短一个想法到一份能推动工作的产物之间的距离。在这样的一天结束时，打字还是说话这个问题基本已经隐形；我注意到的是工作本身。

早上 8 点收件箱

我从 Spark Mail 和 Slack 开始。语音在这里很好用，因为回复大多是在表达意图和语气。我口述粗略答复，Loqua 去掉填充词，理解 app 的层会让 Slack 里的输出比邮件更短。

收件箱这段通常需要十五到二十分钟。大约三分之二的回复会用口述完成；剩下的我会打字，因为它们需要精确措辞、一串链接，或者更谨慎的解释。这个比例不是规则，而是当我不再强迫一种工具去做另一种工具的事之后，早晨自然呈现出来的样子。

语音失效的地方：公共空间里的保密线程。如果我在咖啡馆，而消息里包含敏感上下文，我会打字。语音优先不意味着隐私退后。

站会

站会时，我会说三个槽位：已交付、今天、阻塞。这是回报最高的日常语音输入工作流之一，因为结构每天重复，变化的是内容。

诀窍是不要散讲。我会把槽位名称说出来，Loqua 会用它们组织结构。站会内容本身可能三十秒就能写完，再花一分钟读团队其他人的更新。语音在单次站会上省下的时间并不多；它真正省掉的是拖延站会更新的成本，而这过去才是一天里更大的阻力。

代码审查

代码审查是混合模式。语音很适合解释担忧，键盘更适合行级精确操作。我会口述审查总结和高层评论，然后用鼠标和键盘做精确的文件导航。

一条好的语音审查评论会说明为什么这个问题重要，而不只是指出哪一行错了。比如：“This cache key ignores locale, so Chinese and English results can collide. Can we include locale in the key and add a regression test?” 这种评论一边读代码一边说出来，要比打出来容易得多。

规格草稿

写规格文档时，语音优先工作流最接近思考本身。我会口述目标、非目标、用户流程、边界情况和验收标准，然后用键盘调整标题。更大的规格文档我会从 Obsidian 开始；实现任务则会把清理后的版本移到 Claude Code 或 Cursor。

第一版口述草稿很少就是最终发出去的规格文档。它更像脚手架，让之后的键盘编辑变得显而易见。我反复学到的一点是：口述版本比手打大纲更快暴露缺失分区，因为一旦你把 “acceptance” 说出口，就必须至少跟上一条标准。

Slack 线程

Slack 最在意语气。如果清理模型只是转写，语音可能显得太生硬。Loqua 的目标位置格式化会让回复保持简短，但不冷淡。我仍然会在发送前读一遍；语音应该加速判断，而不是替代判断。

有个模式我花了一段时间才学会：口述温和版本，而不是最高效版本。Slack 里的回复通常第一句先回应对方，第二句再进入重点，会读起来更好。手打回复容易跳过第一句；口述通常会保留下来，线程也因此更健康。

语音失效的地方：需要仔细引用或插入多个链接的线程。这些我会打字。混合规则很简单：用语音表达论点，用键盘处理引用。

日终日志

一天结束时，我会口述今天让我意外的事。这不是状态更新，而是记忆捕捉：什么改变了我的想法，什么比预期更难，以及明天不该忘记什么。目的地是 Obsidian，因为它可搜索，也方便链接。

一篇典型日志有三小段，大约五分钟写完。有意思的是，最有价值的条目往往是小意外，而不是重大决策。重大决策总会被写下来，甚至会被写好几次。小意外才容易在第二天早上消失，比如某个 API 返回的形状和文档暗示的不一样，或某条用户评论推翻了我原来的模型。

今天语音不好用的时候

同一天里有两个例子。第一，一个繁忙文件里的密集代码重构。我试着把重命名计划口述进编辑器，但模型一直把一个 identifier 写错，因为可见上下文滚动得太快，listener 来不及稳定捕捉。我切回了打字。语音在这里是错误工具，因为光标移动太快，上下文无法稳定。

第二，一个紧张的 Slack 线程，正确回复应该是三句话、零形容词。我口述后，清理过程加了一个礼貌缓冲，结果消息读起来比我想要的更软。我手动重写了它。经验是：语音适合表达温度，不适合刻意冷处理；当你需要一条平直的信息时，就打字。

更完整的工具栈细节见我们的 语音生产力栈。关于这个习惯背后的论证，见 为什么键盘不是与 AI 一起思考的正确工具。影响我们 Mac 工作流的外部参考包括 Apple Dictation 和 Linear docs。