Z2.04.3Default handling of unknown persons设计研究
访客与临时人员需有默认处置
别名: 未知者默认策略 · fallback identity policy
概念解释
身份识别系统必然遇到认不出的人：访客、保洁、快递、新室友、还没注册的家人。系统必须预先定义「未知者在场」时的默认处置——当作没人、当作主人、还是当作入侵者。三种默认都有真实产品在用，失败面各不相同；而没有任何默认（即兴反应、行为未定义）是其中最糟的一种，因为它把错误留给运气。
默认处置的本质：识别系统遇到不可判定输入时，把「不知道是谁」映射为行为后果。这个映射定义错了，整个系统的可信度跟着塌——朋友进门警报大作，或者客人被无声录像，都比「没有智能功能」更糟。
机制
三种默认各自的失败面：
- 当作没人：访客活动不触发任何东西。安全类功能（安防、跌倒看护）漏报；节能类功能误动作（有客人在客厅，系统判定无人关灯关暖气）。
- 当作主人：未知者继承全部权限与个性化。识别错误被放大为权限开放与数据串显——这是最危险的默认，对访客场景几乎必然出错。
- 当作入侵者：触发告警。家人朋友进门警报大作；重复误告警触发警报疲劳，把系统的安全价值打光。
临时性加重问题：访客停留短、没有注册窗口（不能为住两天的姑姑录人脸），系统长期处于「未知者在场」状态——默认处置不是边缘情形的处理，而是访客场景的主路径。时段进一步耦合：白天的未知者与深夜的未知者、有人在家时的与全家外出时的，最优默认不同——单一全局默认必然在某些组合下错误。
怎么研究
- 多用户访问控制研究：智能家居的用户研究（Zeng 等 2017）发现，用户希望对「谁能触发什么」有明确控制，并担忧未预期的他人使用设备——访客处置是用户已表述的需求，不是设计师发明的问题。
- 剧本化访客场景：部署研究用标准剧本（客人到访、保洁上门、快递进门）测各默认下的系统行为，逐功能记录「当作没人/主人/入侵者」各产生什么，是评估默认矩阵的直接方法。
- 误告警研究：安防类产品的告警行为研究发现，用户对「朋友触发警报」的尴尬与对漏报的恐惧并存，处置策略需要同时压两端（泛写）。
方法论注意点：默认处置的评估必须覆盖时段×在家状态的组合矩阵——只测单一场景（白天有人的访客）会漏掉最危险的组合（夜间无人的陌生进入）。
边界
- 默认因功能类别而异，不存在全系统统一默认。 安全类偏向告警（低强度：通知而非刺耳警报）、便利类偏向忽略、权限类一律不继承——按功能类别分默认，比按系统统一默认正确。
- 「主人现场批准」不是万能解。 它依赖主人在场、被通知到且愿意响应——独居、睡眠、离家场景全部失效；批准机制只能作为默认矩阵之上的一层，不能替代矩阵。
- 不可识别本身可以是设计目标。 有些场景应主动放弃识别（客房的摄像头只做运动检测不做身份）——「不认出是谁」是一种隐私保护默认，不是能力缺陷。
怎么落地
- 写下未知者默认行为矩阵：时段（白天/夜间）× 在家状态（有人/无人）× 功能类别（安全/便利/权限），每格填一个明确行为，全团队评审——让每个格子有主人。
- 安全类：未知者触发低强度告警（手机通知「检测到活动」而非现场警报），主人可升级；便利类：忽略，保持现状；权限类：一律不继承，需要独立认证。
- 给主人一个轻量的访客预告入口：一次点击临时授权「今晚有客人」，系统进入访客模式（暂停个性化、调低告警敏感）——把「为客人费心」的成本压到一次点击。
- 验证办法：让一位从未登记的人进入空间，按默认矩阵逐项核对每个功能的实际行为与声明是否一致；特别核对夜间无人组合。任何未定义或与矩阵不符的行为都是缺陷。