别让进度条骗人：用 AI + SwiftUI ProgressView 区分真实进度 (2026)

加载中的百分比，真的有依据吗？

导出文件、上传照片、同步数据时，界面常见两种写法：一直转圈，或者显示「37%」。前者没有告诉用户还要等多久，后者如果没有可靠的总量，就会变成一条会乱跳的假消息。

SwiftUI 的 ProgressView 用来显示任务向完成推进的进度。Apple 的文档把它分成两种情况：默认初始化器用于不确定进度，带 value 和 total 的初始化器用于确定进度。1 2

PM 先判断「现在有没有可信的总量」，再决定界面显示哪一种。下载文件时拿到了文件总大小，可以显示百分比；等待服务器生成报告时没有可靠的完成比例，就只表达「正在处理」。

先把进度规则写清楚

让 AI 改 SwiftUI 代码前，先拿一个具体流程做判断。不要从「把转圈改成进度条」开始，而要先确认进度数字从哪里来。

业务情况	应显示什么	PM 要先确认的规则
已知总文件大小、已完成字节数	确定进度	总量是否稳定，完成值是否只会向前走
已知总步骤数，例如 4 个导入步骤	确定进度	每一步何时算完成，失败后是否回退
服务端没有返回可靠的完成比例	不确定进度	文案是否说明当前动作，多久没有响应算异常
进度被取消或失败	结束状态	是否显示取消、失败或重试，而不是继续转圈

这张表解决一个常见误区：进度条不是「让等待看起来更专业」的装饰。它向用户暗示了完成比例，比例必须来自真实的已完成量和总量。拿不到总量时，使用不确定进度反而更诚实。

把状态和数据交给 AI

在 Xcode 中找到当前页面的加载视图，把下面信息一并交给 AI：

任务是什么，例如上传一张图片、导出一份文件，还是等待服务端生成内容。
当前能拿到哪些进度数据，完成值和总量的单位分别是什么。
取消、失败、重试和完成后，页面应该怎么变化。

可以直接这样下指令：

请只修改当前 SwiftUI 页面里的进度反馈，不要改网络请求、数据模型和业务流程。
先判断当前任务是否有可靠的 completed 和 total。有可靠总量时使用 ProgressView(value:total:)；没有可靠总量时使用不确定进度，不要编造百分比，也不要用时间估算冒充完成比例。
保留现有的取消、失败、重试和完成逻辑。请先列出空闲、进行中、取消、失败、完成五种状态，再给出最小改动代码。进度数值不能小于 0，不能大于 total，完成后要停止进度显示。最后列出 Xcode 验收步骤，覆盖慢请求、进度不变、失败重试和 VoiceOver。

Apple 也提供了带自定义标签和当前值标签的确定进度初始化器，适合把任务名称和当前值分开表达。3

用最小代码区分两种状态

假设导出任务能返回已完成字节数和总字节数，AI 可以先把确定进度接到现有状态上：

if isExporting {
    if let totalBytes, totalBytes > 0 {
        let progress = min(
            max(Double(completedBytes) / Double(totalBytes), 0),
            1
        )

ProgressView(value: progress, total: 1) {
            Text("正在导出")
        } currentValueLabel: {
            Text("已完成 \(Int(progress * 100))%")
        }
    } else {
        ProgressView()
        Text("正在准备导出")
    }
}

这里的判断顺序比代码样式更重要：

有可信的 totalBytes，才显示百分比。completedBytes 和 totalBytes 必须来自同一个任务，不能把上一次导出的总量留在页面里继续使用。
总量暂时未知时，回到 ProgressView() 的不确定进度。不要先显示一个估算百分比，等接口返回后再悄悄改掉。
任务结束后移除进度视图，改用完成提示或结果页面。失败和取消也要离开「进行中」状态，否则用户会以为任务还在跑。
currentValueLabel 是给读者看的当前值，不是给 AI 调试用的变量名。文案可以是「已完成 37%」，也可以是「12 MB / 30 MB」，选哪一种要看用户能理解什么。

如果任务只有 4 个明确步骤，也可以把完成步骤数作为 value，把 4 作为 total。但要提前写清「上传完成」和「服务端处理完成」是不是同一个步骤，不能为了让进度条动起来，把等待时间平均切成几段。

在 Xcode 里按状态验收

运行模拟器或真机，不要只看进度条能不能出现。用可控的假数据或慢请求逐项检查：

确定进度：总量为 100，完成值从 0、25、80 到 100 变化，显示比例与数据一致，没有突然倒退。
总量未知：让接口暂时不返回总量，页面显示不确定进度和当前动作文案，不出现猜出来的百分比。
进度不变：故意让任务一段时间没有新进度，界面仍能说明正在处理；如果超过产品设定的等待时间，要显示超时、取消或重试入口。
失败重试：中途失败后停止进度显示，显示具体失败提示；点击重试会重新进入进行中状态，不沿用上一轮的完成值。
取消任务：点击取消后进度立即停止，页面回到可继续操作的状态；不要只隐藏条而保留一个仍在运行的请求。
完成收尾：进度到达总量后切换到完成反馈，避免 100% 之后还继续转圈，也不要让完成提示一闪就消失到用户看不见。
大字号和窄屏：增大文字并切换窄屏，检查任务名称、当前值标签和取消按钮都能完整阅读，不被进度条挤掉。
VoiceOver：确认读屏用户能知道当前任务名称、当前状态和失败后的下一步；不要把颜色或动画当成唯一反馈。

ProgressView 只负责呈现进度，不会替你决定总量从哪里来，也不会自动处理取消、重试、超时或服务端任务状态。产品规则先写清楚，AI 才不会为了让界面「有变化」而编一个看似精确的数字。

PM 今天可以独立完成的清单

选一个当前只有转圈或假百分比的上传、导出或同步流程。
写出任务的完成值、总量、取消、失败、重试和完成条件。
判断总量是否可靠，可靠才使用确定进度。
没有可靠总量时，改用不确定进度和明确动作文案。
让 AI 先列五种状态，再只修改进度反馈区域。
用 0%、25%、80%、100% 和进度不变的假数据跑一遍。
验收失败重试、取消、超时、大字号、窄屏和 VoiceOver。
检查页面里没有用上一次任务的数据继续显示当前百分比。

先把「这个数字从哪里来」问清楚，再决定要不要显示百分比。用户不需要一条看起来精确的进度条，他需要知道当前任务是否还在进行，以及下一步该等、取消还是重试。

别让进度条骗人：用 AI + SwiftUI ProgressView 区分真实进度