Z7.02.2Missing diagnostic tools设计研究
用户缺少定位工具
别名: 诊断工具缺位 · 分层自检 · troubleshooting affordance
概念解释
知道故障可能出在设备、网络或规则的任一层是一回事，手里有没有工具把层分开是另一回事。消费级智能环境产品的普遍现实是：设备在线状态藏在应用深处、网络诊断只有一句「无法连接」、规则触发日志多数产品根本没有。诊断工具不是用户不会用，是产品没有给。
这是分层诊断链条上断了的那一环：排查是假设检验（「是不是网断了？」），假设检验需要观测手段；没有观测手段，用户只能跳过检验直接行动。这条讲的是工具的缺位本身——它为什么缺、缺了会发生什么、最少要补哪些。
机制
没有工具时，用户的排查退化为暴力遍历：重启设备、重装应用、重新配网、恢复出厂。这些动作同时扰动多层，问题「偶尔」被解决——但解决是偶然的，与原因无关。
偶然成功有一个致命的副作用：它形成强化。重启三次里有一次管用，「重启」就被确认为该症状的解法，用户从此停在暴力层，永远不会走到归层那一步——不是不想，是路径上没有出口。长期后果是排查行为与系统理解脱钩：家里哪样东西不好使了，第一反应是拔电源，最后一反应是退货。
缺位有结构性原因，不全是疏忽：其一，厂商的诊断信息面向客服而不面向用户——数据存在（客服后台能看到离线记录），但默认不暴露；其二，链路跨厂商——网关、设备、规则平台各属一家，没有任何一方拥有全链路视图，每家只愿意展示自己那一层的正常。两层原因都指向：工具缺位是生态激励问题，单个环节的努力补不全。
怎么研究
- 排查策略访谈：智能家居实地研究里请用户复盘「上次坏的时候你做了什么」，可稳定编码出策略序列（重启→重装→绕开→弃用），归层步骤几乎不出现——工具缺位的行为学证据。
- 工具有无的对照：同一套故障在有自检入口与无自检入口的两个版本下注入，比较定位正确层的比例、耗时与求助率。这是直接检验「工具缺位造成归层失败」的范式。
- 支持渠道数据：分析客服工单的解决路径（多少靠「请重启后再试」结案），可以从供给侧反推用户侧工具的缺位程度。
方法论注意点：访谈里用户报告的排查策略受回忆美化影响——「我重启了一下就好了」会压缩掉中间的多次失败；辅以设备端日志或经验取样可以校准。
边界
- 工具不必专业化。 能分层的不是 ping 与日志流，而是两三条用户能理解的问句：设备指示灯什么颜色、手机连同一网络能否控制、这条规则最近触发是什么时候。把运维工具原样搬给家庭用户，只是把不可诊断换成了不可理解。
- 单侧工具有天花板。 一个厂商只能覆盖自家的设备与网关；跨厂商的全链路视图需要生态协议或网关侧的开放接口，这不是产品内设计能独立解决的——设计目标应定为「把我这一层的观测给足」，而不是许诺整体诊断。
- 工具给多了是噪声。 诊断入口在正常时段应当不可见，故障被怀疑时才出现；常驻的「健康」页面会训练用户无视它。
怎么落地
- 内置分诊向导：按设备→网络→规则的顺序问三个问题，每问附带自动检测的结果（在线状态、本地连通、最近触发时间戳），用户只需确认与继续。
- 暴露每条规则的最近触发时间——它是规则层唯一低成本、高信息量的观测点，一行字就把静默层打开了一条缝。
- 网关侧保留离线事件历史（何时离线、持续多久），并在设备详情页展示——把「间歇性网络故障」从感觉变成记录。
- 验证办法：故障注入三层各一次，比较提供分诊向导前后用户定位正确层的比例与从发现到定位的耗时；同时跟踪「直接重启率」的下降。重启率不降，说明工具没有进入用户的排查路径。