H4.02.3inflated permission necessity设计研究
说明不得夸大必要性
别名: 夸大必要 · 伪必需权限 · overstating necessity · false required permission
概念解释
用途说明若把一项可选能力写成「必须开启才能使用」，就是在夸大必要性。通知、模糊位置、通讯录匹配好友，常常不是核心任务的物理前提；相机对「拍这张证件」才是。夸大把拒绝框成产品不可用，人无法按真实依赖做取舍。这条只谈说明与真实依赖是否对齐，不谈拒绝之后其余功能如何继续、也不谈具体功能句该怎么写。
机制
「必须」是很强的情态：它取消了拒绝作为合法选项的地位。当文案说必须、实现上却能降级时，人是在被不实信息推动授权，允许率不再表示知情同意。反过来，真必需的能力（没有麦克风就无法通话）应当直说，隐瞒依赖会在拒绝后造成故障错觉。夸大还会污染以后的说明：人一旦发现「不给位置也能搜附近」，会把后续所有「必须」读成推销。
怎么研究
把每条权限标成「无此则任务失败」或「无此则降级」，再比较诚实文案与「必须开启」文案。
自变量：文案是否声称必需、拒绝后产品是否真的不可用、前置层是否隐藏跳过。 因变量：允许率、拒绝后的任务完成率、对「不给还能不能用」的判断准确度、发现不实后的信任评分。
允许率升高若伴随着「拒绝其实仍可用」，测到的是胁迫，不是说明有效。理解题要单独问「如果点不允许，下一步还能做什么」。不要在实验室里用必须完成任务的指导语，那会把夸大必要性变成实验者的要求。
边界
支付、医疗、门禁等场景里，某项能力是合规或物理前提，说明应当写清「没有它，这一步无法完成」，这不是夸大。平台审核规则若要求用途字符串声明功能，不等于允许把可选分析或营销写成核心功能。A/B 测试里「必须」话术提高了允许率，只能说明话术有效，不能说明依赖为真。
怎么落地
- 为每条权限写一句内部判定：「关掉它，当前任务是失败、降级，还是几乎不变」。只有「失败」才能在对用户的说明里使用「需要 / 必须」。
- 降级类权限改成「开启后可以……；不开启则……」，两种后果都写，不要只写开启的好处。
- 禁止用全屏拦截把可选权限伪装成启动门槛，尤其是通知和通讯录。
- 验证：在测试包里强制拒绝该权限，走完主路径。若主路径仍通，对外说明里却出现「必须」，文案不合格。再问拒绝组「你以为不给会怎样」——若答案比实际后果更严重，就是夸大。