Z1.07.4Over-aggregation risk设计
过度聚合到单一入口会造成单点故障风险
别名: 单点故障 · single point of failure · 聚合权衡
概念解释
聚合的诱惑很大：一个入口管一切，学习成本低、体验统一，产品叙事也干净（「一个应用控制全屋」）。但把全部交互能力收拢到单一入口，等于把系统的全部可达性押在一个组件的可用性上——入口挂了，一切挂。这是设计层面的单点故障（single point of failure）：不是因为做错了什么，而是「只有一个」这个结构本身就携带着风险。
这条与「聚合点失效的后果」构成一对：一边讲失效发生时损失什么，这边讲为什么会在设计时主动制造这个风险——因为聚合的收益真实可感（统一、简洁、好卖），风险遥远抽象（出事才知），权衡天然偏向聚合。
机制
为什么单点风险在智能环境里被放大，而不像传统单机那样可容忍：
- 入口承载的不只是操作。 单一入口通常同时是状态视图、配置界面、规则编辑器与通知中心——它失效时同时切断了控制、观察、修改与被告知四条通路，用户对系统彻底失明失声。
- 单一入口多是云端入口。 「一个应用」背后几乎总是「一个账号 + 一个云服务」，单点不止是手机上那个图标，而是图标-账号-云-网络四层串联，任何一层（含运营商级断网）都触发全量失效。串联链越长，可用性越低。
- 组织激励偏向聚合。 产品侧的指标（日活、停留时长、账号绑定）全部奖励入口集中，可用性冗余没有对应的指标 traction——过度聚合常是指标结构的产物，不是工程判断的产物。
还有一条慢性风险：能力迁移的单向性。功能一旦聚进单一入口，用户习惯随之迁移，物理入口荒废；此后想再分散回去，要同时对抗产品激励（入口指标）与用户习惯（已经不想用别的方式了）——聚合容易、再分散难，风险随时间固化。
边界
- 聚合本身不是错，错的是无冗余的聚合。 单一主入口 + 平行的保底通道，聚合的收益照拿、风险有兜底——批判的靶点是「唯一」，不是「主」。
- 低后果系统可以接受单点。 全屋只有三盏灯的宿舍场景，单入口失效的代价是走两步路按开关——单点风险的严重度要与系统的后果量级匹配，不必为玩具规模付冗余的复杂度。
- 冗余通道要能覆盖关键少数。 不要求冗余入口复制主入口的全部功能，只要求在主入口失效时能完成「停得下来」的操作（关掉、锁上、停机）——冗余的目标是止损可达，不是功能对等。
怎么落地
- 做聚合设计时同时设计第二条路：每个有后果的动作，问一句「主入口挂了用户怎么停掉它」，答不上来的地方就是单点裸露处——评审清单里加这一问，比事后补冗余便宜一个量级。
- 保底通道与主通道同步上线，不作为「后续优化」——第二条路晚三个月上线，意味着三个月里用户习惯已把主入口变成事实唯一。
- 对后果分级配置冗余：安防与电器控制必须有物理或本地保底；氛围类功能（灯光场景）可接受单入口。冗余预算按失效后果排，不按功能数量摊。
- 验证办法：列出主入口失效后仍需完成的操作清单（至少包括：全屋断电级停止、安防启停、开门），逐一在主入口禁用状态下实测完成路径。清单上有任何一条走不通，单点就是活的。