I1.02.3status confirmation without progress bar设计
该区间无需进度条但需状态确认
别名: 秒级确认 · 不定进度即可 · indeterminate acknowledgement
概念解释
从刚过 1 秒到还没到十秒，人需要知道「系统还在」，但不需要知道「还剩百分之几」。这个区间的正确反馈是状态确认（status confirmation）：按钮上的加载态、一行「正在打开」、骨架的呼吸，证明活着就够了。进度条在这里是错配——总量往往还估不准，一条会动的百分比会逼人去读一个没有信息的数。
把进度条省掉不是因为偷懒，是因为这个时间尺度上，进度条提供的分辨率高过人所需要的，也高过系统所能诚实给出的。
机制
秒级等待里，人问的是二元问题：还在进行 / 已经死了。状态确认回答二元问题，成本低，也不会假装精度。进度条回答的是连续问题：走了多远、还要多久。连续问题只在等待长到人开始做时间预算时才出现——那是十秒级、注意力可能离开的尺度。提前给出连续答案，系统多半在编：百分比来自猜测的总量，卡住时条子不动，人反而用「进度冻结」来判决死。
确认还要轻。重的反馈（全屏遮罩、大转圈、模态）会把 2 秒的等待做成一次正式的中断，连续性思维刚要靠确认续上，又被模态切断。
边界
下载、导入、模型推理这类从一开始就知道会到分钟、并且有可测字节或步数的任务，不要因为「还在秒级」就拒绝进度条——它们很快会跨出这个区间，开局就该用确定进度。相反，打开一张详情、切一个视图、提交一个短表单，即使偶发到 3 秒，也仍是确认区间。不确定进度若转得太久（接近十秒仍无阶段变化），确认会失效，人会把「还在转」读成卡死；那已经越出这条的舒适区。
怎么落地
- 1 到数秒的操作：在原控件上做加载态或一句状态文案，不要上百分比条，也不要上预估剩余时间。
- 确认要能被一眼扫到，但不要抢走正在看的内容。优先按钮内指示、行内标记、局部骨架，而不是模态。
- 若等待可能滑向十秒以上，预先准备从确认升级到阶段说明或进度，而不是一直转圈到人离开。
- 验证：把一次打开详情固定在 2.5 秒。用状态确认的版本，人应能指出「它还在开」且说不出百分比。若他们开始找进度条或把转圈判成卡死，确认的分量或时长已经错了。