Z4.09.3Communicating degraded-mode capabilities设计
降级模式下的基本功能范围需要预先告知用户
别名: 降级预告 · 降级范围告知 · graceful degradation 的沟通面
概念解释
设备或系统进入降级模式（degraded mode）——断云、断网、失联之后仍保留的受限功能集——时，用户需要在进入之前（或至少进入的当下）知道：降级后哪些还能用，哪些不能用。这是优雅降级（graceful degradation）的沟通面：架构把哪些功能留在了本地是设计决定，用户知不知道这个清单是另一件事，后者独立地决定降级体验的好坏。
这条讲的是预期管理，不是架构本身。功能怎么设计成本地可用、降级行为要不要每次一致，是断网与降级那一组的主题；这里只管一件事：范围要提前说。
机制
伤害的来源是预期落差。用户对系统的预期建立在完整模式上——能远程看、能联动、会报警；降级发生后，预期与实际能力之间出现一段差值，差值里的每个动作都会失败。更危险的形态是安全错觉：用户以为摄像头还在录像、报警还会推送，实际降级后只剩本地一盏指示灯在闪——用户基于假能力做的安全决策，比单纯「功能不可用」严重得多。
预先告知之所以有效，是它把落差从「发生时才暴露」改为「发生前已折价」：用户可以提前安排替代物——备用钥匙、机械定时器、临时多留意——事后解释只能止损，换不回已经错过的行动窗口。降级窗口还常与外部事件重叠（雷雨断网正是安防最需要的时刻），那时用户没精力现学系统能力，预告的价值被进一步放大。
边界
- 「预先」不等于「写进说明书」。 没有人为了一次断网去翻手册；装完即忘是常态。有效的预告知是轻量、场景化、可被动看到的：设备详情页的常驻标注、安装完成时的一次性清单，都优于长文档。
- 降级范围会随固件演进变化。 静态文档必然过时，绑定当前固件版本动态生成的能力清单比印刷品可靠。
- 部分降级难以完整枚举。 云端服务单类接口故障时，「能用/不能用」不是干净的二分；此时诚实标注「未知」好过勉强给一张假装完整的清单。
怎么落地
- 安装完成时展示一次「离线时这些功能仍可用」清单，按用户视角措辞（「断网后门仍可用钥匙开、室内报警仍会响、不会推送通知」），不用技术术语。
- 设备详情页常驻降级能力标注，随固件版本更新。
- 降级发生当下的提示分两栏：「现在不能用的」「仍然可以用的」——后者比前者更重要，它直接回答用户此刻最急的问题。
- 安全关键设备（门锁、烟感、安防）的降级行为写在机身或就近的物理说明上，不依赖应用——降级时应用可能正是不可用的那一个。
- 验证办法：随机抽用户问「断网后你家的门锁/摄像头还能干什么」，答对率就是预告知的真实效果；把「答对率」而非「文档存在」当验收指标。