背景
6536160(record-next queue)引入了「排队接力」:识别中(Processing)按下听写热键,该 Pressed 被缓在 hotkey channel 里,会话收尾后立即取出,用 120ms grace 窗口和 #545 的防误触冷却区分开,然后自动开录下一条。设计意图是连续听写的用户不用等上一条识别完。
先说明:这个 issue 不是质疑当时的实现质量——grace 窗口和 #545 冷却的区分做得很干净。想讨论的是这个交互本身的默认值。
交互问题
1. 按下时刻零反馈。 转写中按热键,当下没有任何视觉/听觉响应。用户无法区分「排队成功」和「没按上」——要么再按一次,要么忘了按过。一个没有回执的输入,却又悄悄生效了。
2. 延迟生效的惊吓成本高于收益。 几秒后转写完成,胶囊突然重新弹出开始录音。此刻用户可能已经在打字、在和别人说话——而听写的产物是自动插入光标处的文本。一次意外录音的代价是往当前应用塞进一段垃圾文字;省下的只是 1-2 秒等待。收益/风险不对称。
3. 与 Esc 取消的组合是客观缺陷。 #853 修好转写中 Esc 取消后,出现这样的序列:转写中用户按了热键(排队)→ 又按 Esc 取消 → 当前会话取消、收尾回 Idle → 排队的 Pressed 被取出、落在 grace 窗口内 → 又开一个新录音。用户明明在「全部停下」,却弹出一个新会话。排队机制里没有「取消时清空队列」的概念,因为队列本身是 channel 缓冲的副产品,没有可清空的实体。
提议
默认丢弃:Processing 期间的热键按下直接忽略(处理时刻距 Idle < grace 的 Pressed 不再放行开录,直接丢弃)。行为变得完全可预测:转写中按热键 = 无事发生。
如果连续听写场景确有需求,两个方向可以讨论:
- 做成设置项(默认关),开启的用户自己承担心智负担;
- 保留排队但补齐反馈:按下瞬间胶囊显式提示「已预约下一条」,且 Esc 取消时同步清空预约。
个人倾向第一步先默认丢弃——反馈补齐的工作量不小,而当前无反馈的排队比没有排队更伤体验。
相关:#545(冷却)、#853(Esc 取消通路)、#855(Esc 独占消费)。
🤖 Generated with Claude Code
背景
6536160(record-next queue)引入了「排队接力」:识别中(Processing)按下听写热键,该 Pressed 被缓在 hotkey channel 里,会话收尾后立即取出,用 120ms grace 窗口和 #545 的防误触冷却区分开,然后自动开录下一条。设计意图是连续听写的用户不用等上一条识别完。先说明:这个 issue 不是质疑当时的实现质量——grace 窗口和 #545 冷却的区分做得很干净。想讨论的是这个交互本身的默认值。
交互问题
1. 按下时刻零反馈。 转写中按热键,当下没有任何视觉/听觉响应。用户无法区分「排队成功」和「没按上」——要么再按一次,要么忘了按过。一个没有回执的输入,却又悄悄生效了。
2. 延迟生效的惊吓成本高于收益。 几秒后转写完成,胶囊突然重新弹出开始录音。此刻用户可能已经在打字、在和别人说话——而听写的产物是自动插入光标处的文本。一次意外录音的代价是往当前应用塞进一段垃圾文字;省下的只是 1-2 秒等待。收益/风险不对称。
3. 与 Esc 取消的组合是客观缺陷。 #853 修好转写中 Esc 取消后,出现这样的序列:转写中用户按了热键(排队)→ 又按 Esc 取消 → 当前会话取消、收尾回 Idle → 排队的 Pressed 被取出、落在 grace 窗口内 → 又开一个新录音。用户明明在「全部停下」,却弹出一个新会话。排队机制里没有「取消时清空队列」的概念,因为队列本身是 channel 缓冲的副产品,没有可清空的实体。
提议
默认丢弃:Processing 期间的热键按下直接忽略(处理时刻距 Idle < grace 的 Pressed 不再放行开录,直接丢弃)。行为变得完全可预测:转写中按热键 = 无事发生。
如果连续听写场景确有需求,两个方向可以讨论:
个人倾向第一步先默认丢弃——反馈补齐的工作量不小,而当前无反馈的排队比没有排队更伤体验。
相关:#545(冷却)、#853(Esc 取消通路)、#855(Esc 独占消费)。
🤖 Generated with Claude Code