H4.02.2feature-specific purpose string设计研究
说明需具体到功能而非泛化
别名: 具体用途 · 功能级说明 · purpose specification · generic rationale
概念解释
权限说明要落到一项可观察的功能：「用位置显示你到店的步行路线」「用相机拍摄这张保单」，而不是「为了提供更好的体验」「用于运营与安全」。泛化用途不能让人检验必要性，也不能限制事后把同一授权拿去干别的。这条管的是说明的粒度，不是系统弹窗前要不要先出一层界面，也不是把可选能力写成「必须开启」。
机制
系统权限名只标明能力类别，同一枚「照片」开关既能选一张图，也能扫描整个图库并上传。人用来做「这合不合理」判断的，是功能级后果，不是能力名词。具体说明把当前任务接到能力上，使人可以对照：若我只是换头像，为什么要通讯录。泛化说明把授权边界留白，事后新增的用途看起来仍被旧文案覆盖，目的限定在交互上失效。短，但具体，比长而空更能被用来预测行为。
怎么研究
给同一权限写具体功能句与泛化体验句，在人做选择前或选择后测理解。
自变量：用途是否点名功能、是否写明数据是否离开设备、是否写明一次性还是持续。 因变量：对「会用在哪一步、会不会上传、能不能拒绝仍用应用」的预测准确度、允许后的事后惊讶、选择稳定性（隔日是否后悔）。
只看允许率会把「具体说明提高信任」和「具体说明吓退了不需要该功能的人」混在一起。后一种下降往往是健康的。理解测试必须在没有产品演示的条件下做，否则人是靠界面猜用途，不是靠说明。
边界
系统用途字符串有字数上限，具体到功能不等于写进实现细节或法律例外。多功能共用同一权限时，说明应写当前这次要做的那一项，并在设置页列出其他用途，而不是在弹窗里开清单。监管要求的完整告知可以放在可展开的详情里；弹窗和前置层仍应先给功能句。
怎么落地
- 每条权限准备一句「能力 + 当前功能 + 可选的范围」（会不会后台、会不会上传）；禁止单独使用「改善体验」「个性化」「安全防护」这类收不到功能的短语。
- 同一权限服务多项功能时，弹窗和前置层只写触发本次请求的那一项；其余写在权限设置的用途列表里。
- 把说明和实际 API 调用对一下：文案写「选一张照片」，就走系统选择器，而不是打开完整图库权限。
- 验证：找未参与设计的人只看说明、不看后面的界面，列出「应用接下来会做什么、哪些不会做」。出现「更好的体验」或与即将发生的功能对不上的猜测，说明就失败了。