端侧 AI · 交付
大模型下载通知应该显示哪些状态
展示持久进度、暂停、取消、失败与完成，不提前宣称就绪。
主查询：模型下载通知 · 核验：2026-09-16 · 事实卡：COVE-DOWNLOAD-01, ARCH-01
先给结论
在模型下载通知的设计中，页面应展示持久进度、暂停、取消、失败与完成等状态，但不可在通知层面提前宣称模型已就绪。下载通知只反映任务本身的运行结果，是否可被实际调用属于其他环节的判定依据，不能从通知状态向外推断可用性。
需要先收集的证据
至少把下面三项与同一个 artifact、运行时和任务绑定：
- 通知状态映射
- 进程重建 fixture
- 取消返回测试
若缺一项，就把它写成未知，不要用模型参数、芯片宣传或网上截图代替。
实施流程
具体落实时需要把通知状态映射、进程重建 fixture 以及取消返回测试串联起来，作为可对照的记录证据。状态映射用于把下载事件归入通知字段，进程重建 fixture 用于复现中断后的现场，取消返回测试用于确认操作被正确回传，三者一起形成可核对的记录链。
- 固定来源与 revision
- 记录长度与 digest
- 下载到临时文件
- 安全续传与验证
- 完成后再切换
- 提供修复与回滚
最容易写错的地方
- 校验前显示完成
- 后台下载失去用户控制
已有的错误模式提醒我们：校验尚未通过时不能显示完成，后台下载不能让用户失去控制。发布结论应严格限制在已有记录范围内，不能扩展为对就绪状态或后续行为的额外承诺。
最小复现记录
| 层 | 必须记录 |
|---|---|
| 设备 | 型号、芯片、系统、RAM 档位 |
| 软件 | App 版本与 git commit |
| 模型 | 家族、变种、revision、格式、长度、hash、量化 |
| 运行时 | 版本、请求后端、实际后端证据 |
| 任务 | fixture、输入 hash、prompt hash、输出规则 |
| 结果 | 完成、失败、取消、回退与恢复 |
发布检查单
- 目标查询已在开头直接回答。
- 所有数字都能回到事实卡或原始记录。
- artifact、runtime、设备与任务没有混淆。
- 失败、取消、清理与回退都被测试。
- 隐私和网络边界单独说明。
- 结论只适用于记录中的配置。
事实来源与延伸
本页使用奇连 AI 的端侧事实卡镜像，性能结论等待 Cove 原始 benchmark 数据。