现状（2026-09-04 实测）
打开设置里的「节奏诊断日志」，用真实语音跑了多轮，最后一轮 99 秒 34 句：
changesPerSegment avg=1.29 max=5
normalizedErasure=1.13 （re-translation 论文的朴素基线 2.11）
displayLag avg=1.56s p90=3.96s
firstToken avg=168ms
displayLag 量的是「字幕落后语音多少秒」。正常语速一句话 2-4 秒，所以中位数
约落后半句，p90 就是整整一句。按窗口长度分组能看到差距集中在长句：
5-9 词：18 句，平均变 0.78 次，lag 0.78s
10-14 词：12 句，平均变 1.92 次，lag 1.48s
15+ 词：25 句，平均变 3.24 次，lag 2.54s （占 41%，那轮 max 7.84s）
短句体感可接受，长句落后一整句。
与原问题的关系
原标题记的是「访谈场景约 2 秒端到端时差」。那一版的实际情况比 2 秒更差，
而且主要痛点不是延迟而是字幕反复重写（changesPerSegment 曾达 29.67、
rewriteRatio 94%）。那部分已经解决：
|
之前 |
现在 |
| 一句话在屏幕上变几次 |
29.67（max 76） |
1.29（max 5） |
| 译文改写占比 |
94% |
59% |
| 完整句子上字幕条 |
从不 |
每句 |
剩下的就是本 issue 现在记录的这一条：长句的端到端延迟。
为什么它是结构性的
延迟由串起来的几段构成，长句每一段都更长：
- ASR 把 volatile 转成 finalized 要等；
- planner 攒够 6-12 词才切一个翻译单元；
- 长句要切成多个窗口，主行要等最后一个窗口定稿才翻页；
- 翻译时间随源文本长度增加；
- 展示层的阅读门槛按「这次改写要重读多少字」算，长译文门槛更高。
调参数已经到头——前几轮每次调整都是「这边好一点那边差一点」。真要往下压
需要改结构，方向大致有：
- 让主行在 volatile 上就开始翻译，不等 finalized；
- 按从句边界提前出译文，不等整个窗口定稿；
- preview 与整句定稿共用一次请求，省掉一次往返。
验收边界（沿用）
- 不得重新出现重复/错序源转录、stale 覆盖或 committed 字幕回写；
changesPerSegment 与 normalizedErasure 不得因为降延迟而回升；- 有可复现的前后对照数据（诊断日志的会话总表）；
- 用户实机体验验收为最终门槛。
现状（2026-09-04 实测）
打开设置里的「节奏诊断日志」，用真实语音跑了多轮，最后一轮 99 秒 34 句：
displayLag量的是「字幕落后语音多少秒」。正常语速一句话 2-4 秒，所以中位数约落后半句，p90 就是整整一句。按窗口长度分组能看到差距集中在长句：
短句体感可接受，长句落后一整句。
与原问题的关系
原标题记的是「访谈场景约 2 秒端到端时差」。那一版的实际情况比 2 秒更差，
而且主要痛点不是延迟而是字幕反复重写（
changesPerSegment曾达 29.67、rewriteRatio94%）。那部分已经解决：剩下的就是本 issue 现在记录的这一条：长句的端到端延迟。
为什么它是结构性的
延迟由串起来的几段构成，长句每一段都更长：
调参数已经到头——前几轮每次调整都是「这边好一点那边差一点」。真要往下压
需要改结构，方向大致有：
验收边界（沿用）
changesPerSegment与normalizedErasure不得因为降延迟而回升；