A11.04.7The tradeoff when expert efficiency needs conflict with novice safety needs设计
专家的效率诉求与新手的安全诉求冲突时的取舍
别名: 效率与安全的取舍 · 确认对话框争议 · efficiency safety tradeoff
概念解释
加速器与基础路径可以并存，是因为它们是两条各走各的路、通向同一个结果的平行方案，谁也不挡谁的路。但有一类冲突没法用"并行"解决：同一个操作点上，让它对专家更快，往往意味着去掉一道新手需要的安全网（确认弹窗、分步展示、延迟执行）——这道安全网的价值恰恰来自它出现在唯一那条被走的路上，一旦为了提速把它拿掉，不管走这条路的是谁，这道网都同时消失了。
机制
加速器之所以能和基础路径和平共存，是因为二者是并行结构，一个人选哪条都不影响另一条对其他人依然可用；而效率与安全的冲突发生在同一个交互点上，是串行结构——这个点要么有安全网，要么没有，不存在"专家版走这条、新手版走另一条"的物理并行，因为如果真的拆成两条路，专家很快也会走那条没有安全网的路（本群前一条已经说明，专家的自动化行为恰恰是这类差错的高发状态），安全网对谁都不再起作用。
边界
这个冲突不是在所有操作上都存在——对后果可逆、代价低的操作，把确认步骤去掉对新手也几乎没有额外风险，因为犯错的成本本身就低，这类场景根本谈不上"取舍"，直接按效率优化即可。冲突只出现在后果不可逆或代价高的操作上，这时候是否保留安全网，才真正是一个需要权衡的决定。
怎么落地
- 把是否保留安全网的判断依据从"用户熟练与否"换成"这个操作的后果是否可逆、代价是否够高"：可逆、低代价的操作，无条件给所有用户提供快速执行路径；不可逆或高代价的操作，无条件保留安全网，即便对最资深的用户也不例外——专家的熟练程度不会降低这次犯错的客观代价，反而会提高滑入这次犯错的概率。
- 对不可逆高代价操作，不要靠"专家可以在设置里关掉确认"这类选项来解决冲突——这等于把安全网的存废交给用户自己此刻的判断，而这类差错恰恰发生在用户没有主动判断的那一刻，选项本身不会在那个瞬间起作用。
- 验证办法：把产品里所有跳过确认、直接执行的操作列出来，逐一核对其后果是否真正可逆、代价是否真正够低；任何一项后果不可逆却因为"面向专家用户"而跳过了安全网的操作，都是把效率诉求错误地凌驾在了安全诉求之上，需要恢复安全网而不是保留跳过选项。