I2.02.1monotonic progress设计
进度需单调且不倒退
别名: 进度不回跳 · 单调进度条 · no backward progress
概念解释
单调进度（monotonic progress）要求已完成量只增不减：条只往前走，百分比不回跳，步骤不从 4/5 退回 2/5。进度是人对「工作在积累」的外部记忆。倒退等于告诉他刚才那份积累作废了，等待模型要从头建。可预期的第一条件不是估得准，是已经走过的路不被收回。
机制
人把进度条当成一条不可逆的路径。看见 60%，就会把 60% 写进对这次任务的预测：至少已经做完这些。条往回拉，预测被证伪的方式很特别——不是「比我想的慢」，而是「我以为完成的那截其实没完成」。后一种证伪更伤，因为它拆的是工作本身的方向，不只是速度。速度可以更新；方向反了，人会怀疑计数单位、怀疑任务是不是被重启、怀疑界面在演戏。
倒退的常见工程来源是分母变了：压缩包里又找出文件、服务器追加了一批、重试把计数器清零、并行任务里某一个失败后总进度按失败分支重算。分子没少，分母变大，比例照样掉。对用户来说掉就是倒退，不会去区分「总量修正」和「工作被抹掉」。另一来源是用当前速率瞬时反推百分比，速率一抖，条就晃，晃过前高点就是一次小倒退。
边界
任务被用户自己取消再重开，进度从零开始不是倒退，是一次新任务；必须让人看见旧任务已经结束。校验失败后必须重做的步骤（上传完发现格式不对，要重新选文件）应当换成新的进度实例，而不是在同一条上把填满的段挖空。总量发现得更晚、必须修正分母时，宁可让条停住并改文案「发现了更多项」，也比无说明地往回跳更可预期——停住是停滞，要另给阶段；回跳是食言。游戏读档、视频缓冲允许在用户主动seek时重置，那是人在改任务范围，不是系统收回已走的路。
怎么落地
- 进度的内部表示用「已完成量 / 当前总量」，总量只许增大或保持；比例因此不会因为发现更多工作而掉到前高点以下。
- 重试、换文件、取消重开会新开一条进度，旧条标成已结束，不要在同一条上倒灌。
- 禁止用瞬时速率直接驱动百分比；要用已完成的真实单位（字节、记录、步骤）。
- 验证：在上传中途人为追加文件、或让服务端在 40% 时把总数翻倍。条不应往回走。若必须改总量，停在当前分子并出现一句说明，而不是从 40% 跳回 20%。