I4.09.3slowing rate after a broken beat设计
节奏被外部延迟打断后，用户会降低操作频率以适应不可靠的响应
别名: 降低操作频率 · pacing down · 适应延迟 · cautious tapping
概念解释
连着点得很顺的时候，忽然有一拍迟迟不回来，人不会马上恢复原来的密度。节奏被外部延迟打断后，操作频率会降下来：人开始多等一拍再伸手，宁愿慢，也不愿再点上一次还没结束的。系统抖动让人难受，是另一条；这里谈的是人自己改拍子，用降低频率去适配一套不可靠的响应。
机制
预伸建立在「下一拍会按时到」上。外部延迟把这一承诺打破一次，工作记忆里留下的不是平均时延，是「刚才那次没到」。下一次伸手会插入一段自愿的等待，用来确认上一拍真的完了。等待一旦插进去，串的密度就掉下来，即使后面几拍已经恢复正常——人要连续几次准时，才会把自愿等待撤掉。这是在用自己的时间买确定，不是在用系统的平均速度工作。
降频还有一层保护：怕点重。上一拍还在飞，再点可能当成两次提交、跳过一项、或点到已经换掉的目标。慢下来是为了重新闭上环：看清楚再动。闭环一旦捡回来，开环的速度不会立刻回来，要一段「它又稳了」的证据。
边界
只发生一两次、中间隔得很开的操作，没有频率可降，延迟的代价是这一次的等待，不是串的密度。专业用户在必须赶工时可能不降反升——连点、刷新、开多个通道，那是在用过载换确定，会制造重复提交，需要另一套防重，而不是当成节奏恢复。延迟若伴随着明确的进行中反馈，人知道拍子还在、只是这一拍更长，降频会轻一些；完全无声的停顿才最容易把频率压死。实时控制里降频等于失控，人不会选择变慢，会选择放弃这套界面。
怎么落地
- 把串中间偶尔出现的长延迟当成会压低后续频率的事件，而不只是这一拍的体验问题：削尾部、把重活移出串。
- 延迟一旦发生，立刻给「还在处理」的占位，让人知道拍子没丢，只是这一拍变长，减少自愿等待。
- 恢复之后连续若干次稳住，再期望密度回来；不要用一次正常响应当成节奏已修复。
- 验证：在一串连续操作里注入一次明显的外部延迟。随后若干次的击发间隔应变长，即使系统已经恢复。加上进行中反馈再测一次，间隔拉长应减弱。把同一次延迟放在两个相隔很久的单次操作上，不应看到「频率」变化——那不是串。