防护强度与后果分级对应
别名: 风险比例防护 · graded safeguard
概念解释
防护强度按后果分级，是安全工程的通用原则；这里要说的是这条原则在界面实现层面最容易失效的地方——不是设计者不认同分级，而是分级方案一旦落进具体的界面组件库，很容易被组件复用本身悄悄拉平。判断一套界面是不是真的做到了分级，不能只看文档上写的分级方案，要看屏幕上实际渲染出来的摩擦差异。
机制
界面团队通常会做一个通用的"确认弹窗"或"二次核实"组件，供全系统所有需要确认的场景调用——这是工程上最省事的做法，一次实现，处处复用。问题是，组件一旦做成一个样子，接入新功能时最方便的选择就是直接调用现成组件，而不是回头评估这个新场景到底该配几级摩擦；久而久之，一个只用于低风险调整的入口，和一个用于不可逆操作的入口，弹出的是同一个组件、同样的文案模板、同样的一次点击，分级在纸面的规范里存在，在实际渲染出来的界面里已经不存在了。这个失效路径是界面工程特有的：它不需要任何人主动决定"降低这里的防护"，只需要复用一个现成组件这个最自然的工程选择,分级就已经被悄悄拉平。
边界
组件复用本身不是问题，是低成本复用和"未经评估直接复用"两者的差别——如果调用方在接入时被强制填写这个场景的后果等级，系统据此渲染出不同的摩擦程度（不同的按钮数量、是否需要输入而非点击、是否需要停顿），复用同一套底层机制反而是好事，省的是重复造轮子的成本，不是省评估这一步。另外，纯粹的视觉强度（弹窗颜色更红、字号更大）不能替代真实的操作摩擦——操作者很快会学会无视更红的弹窗，就像无视更朴素的弹窗一样快，除非红色的弹窗真的伴随着更多步骤或更长的强制停顿。
怎么落地
在确认组件库层面强制要求：任何新场景接入确认组件时，必须显式声明这次操作的后果等级，由等级决定渲染出的摩擦形式（点击次数、是否要求输入关键值、是否有强制停顿），而不是让调用方自己决定要不要传这个参数——参数可选，就意味着大概率会被跳过。
- 验证办法：定期抽取生产界面里全部确认类弹窗的实际渲染结果，按后果等级分组统计每一组实际的点击次数和平均停留时间，检查是否存在"不同后果等级但摩擦完全相同"的组，这类组通常就是组件复用把分级拉平的位置，而不是分级方案本身写错了的位置。