I2.10.3revise ETA continuously设计
估计值应随进度推进持续修正而非一次性给出后固定不变
别名: 持续修正剩余时间 · 不要一次估死 · updating remaining time
概念解释
外推的原料是「到目前为止」的速率。每多完成一截，原料就多一截，估计应当跟着改。开场时用前两秒算出「还剩 12 分钟」然后把这 12 分钟冻到结束，是在用信息最少的时刻锁定信息最多的时刻。持续修正不是出尔反尔，是估计作为活着的量：窗口在更新，数字或区间就更新。冻住才是把一次早期猜测打扮成承诺。
机制
信息随完成量增加。开始时窗口短、工作是否同质还不清楚，外推的方差大。走完一半，传输段的速率已经有一段够长的历史，方差应收窄。冻住等于拒绝后半段的证据。若早期偏快（缓冲打满、开头的小文件），冻住的剩余会在后半段显得过于乐观；若早期偏慢（握手、排队），冻住的剩余会在工作已经顺了之后还吓人。修正让表示跟着证据走。
修正的节奏要配表示的粒度。点估计每秒改会像跳动；区间可以在带内不改、出带再改。持续修正说的是估计对内每个新样本都进窗口，不是对外每个新样本都刷新文案。对内冻住和对文案抽搐是两种相反的病。
边界
倒计时截止（考试结束、验证码）不是估计，必须按墙上的钟减，不能因「加载变快了」而修正截止。用户已经按当前数字做了离开计划时，大幅向下修正（突然变成马上好）可能让人错过到达；可以修正，但该让到达通知承担「提前好了」，而不是指望人还盯着。修正若只能往更长改、禁止往更短改，会系统性偏悲观，有时是有意的保守，但要把「不会提前报短」说成策略，并接受有人会觉得被多报了。窗口要有下限：完成量太少时修正没有新证据，这时不更新是对的，与冻住开场的 12 分钟不是一回事。
怎么落地
- 估计对内随每个完成样本更新窗口；对外按表示粒度发布：点估计节流，区间出带才改。
- 禁止「第一次算出的剩余锁到 100%」。开场数字只是当时窗口的输出。
- 进入新工作段时重置该段窗口，不要把上一段的速率冻进下一段。
- 验证：看一次从慢握手进入稳传输的任务。开场剩余若一直显示到结束，中段的真实速率完全没进文案，就是冻住了。再看发布频率：若每秒改秒数，把对内更新和对文案刷新拆开。