L5.10.2domain-failure generalisation设计研究
用户会把单一领域的失败泛化到系统的全部能力
别名: 失败泛化 · 一个领域毁掉全部 · one miss all capabilities
概念解释
日历助手把时区搞错，会议进了错误的上午。用户随后连邮件草稿也不再交给它——邮件功能这次并没有出错。单一领域的失败会被泛化成系统的全部能力（domain-failure generalisation）。人更新的是「这个东西靠不住」，不是「它不会算时区」。
泛化是范围错误。失败是局部的，信任惩罚被花到了未出错的功能上。
机制
能力在用户心里往往是一个主体，不是一张功能表。一个主体错了一次，主体的标签被改写，标签跟着走遍所有入口。产品名、头像、同一对话框把多个技能焊成一个「谁」。焊得越紧，泛化越便宜。
界面很少在失败时切开范围：「这次错的是时区换算，写信不受影响。」没有这句，用户只能用主体级更新。不对称的单位更新再叠加上去，一处失败就够让相邻技能一起停用。这与「没有全局正确信任、应按任务校准」是同一事实的失败面：人没有按任务更新。
怎么研究
系统做成两个可分的技能（时区 / 草稿），只在其中一个注入失败，测另一技能上的交托是否下降。自变量：两个技能是否共享名称与对话框、失败时是否声明范围、技能表面相似度。因变量：未失败技能上的交托掉幅、主体级评价（「它不行了」）出现率。
共享表面是关键操纵。拆成两个应用若泛化消失，焊在一起就是原因。
边界
两个技能在用户任务里本就不可分（「安排会议」同时需要时区和邀请函）时，泛化部分是理性的。品牌级事故（隐私泄漏）本来就是跨能力的，不应被说成误泛化。连胜过冲发生在同一任务内；这里是跨任务传染。一次重创抽空的是整段关系，泛化只是其中一种表现。
怎么落地
- 失败文案锁定技能：「时区换算出错，已关闭自动换算；写信草稿未受影响。」不要写「我这次搞砸了」。
- 高独立的技能用可分开的开关和日志，避免一个失败键关掉整座产品。
- 在未受影响的技能入口给一句范围隔离，直到用户下一次成功看见它仍在工作。
- 验证：一处失败后，相邻功能的使用是否一起掉。一起掉而你们的可靠度只在一处破，泛化已经发生；看失败文案有没有给出可切开的范围。