说明具体用途而非泛化理由
别名: 权限用途说明 · 即时权限解释 · permission rationale · purpose disclosure
概念解释
即时权限用途说明（just-in-time permission purpose disclosure）在权限请求发生时，说明系统将访问哪类数据或设备能力、用于用户正在进行的哪项任务，以及访问的范围和方式。若决定需要，说明还应交代谁会接收或处理数据、访问由用户动作触发还是在后台持续发生、是否会重复。与“改善体验”相比，“使用麦克风录制这段语音并上传给本次通话的参与者”给出了可核对的对象、用途和接收者。
产品内解释与操作系统或浏览器的权限提示承担不同职责。产品文案把申请接回当前任务并补足产品知道的用途；平台提示展示平台定义的权限范围、选择和控制。产品不能改写平台授权结果，也不能用仿制系统弹窗掩盖平台实际选项。
机制
权限名称通常描述技术能力，却不自动解释产品行为。“照片”“定位”“通知”可能支持多种任务、接收者和调用频率；用户若只看到能力名，只能猜测这次访问会做什么。即时说明把数据或能力、当前功能与处理方式连成一条可验证承诺，使用户能比较所请求范围与任务是否相称。请求时机也提供证据：在用户主动扫描二维码后请求相机，比在启动页预先索取更容易理解，但时机本身不能替代文字。
说明必须由真实的数据流和权限调用生成约束。若文案称“仅用于这次上传”，实现却后台重复访问或将数据交给其他接收者，具体措辞反而留下更清晰的承诺落差。接收者、频率或后台行为只有与当前决定相关且产品能准确说明时才写；无法安全披露的反滥用细节可以收敛，但不能把可披露用途改成泛化收益。
怎么研究
以真实任务触发权限请求，在参与者选择前询问：将访问什么、为了完成什么、谁会收到、何时或多频繁访问，以及允许后平台提供什么范围。记录用途与范围理解、决定用时、求助、拒绝原因、任务完成和后续撤销；不要把授权率单独当成文案质量。比较无产品解释、简短就地说明和分层详情时，保持权限范围、任务价值、平台提示及触发时机相同。
覆盖首次请求、平台已决定、仅选定内容、一次性或使用期间访问、后台访问等真实状态，并在不同设备上验证文案与平台提示是否一致。用键盘、读屏、放大和动态字体检查说明能否在做决定前被获得；若预提示增加一步却没有提高理解，应考虑由任务语境和平台提示直接承担，而不是默认每次都加一屏。
边界
并非每次请求都需要自定义预提示。用途从当前动作已经唯一可推断、平台提示足够清楚时，重复说明可能只增加打断；平台禁止预提示、限制措辞或要求特定顺序时，应遵守平台交互。相反，后台访问、外部接收、跨功能复用或范围容易误解时，一句用途往往不够，需要分层提供决定所需细节。
即时说明不是隐私政策、数据最小化判断、处理合法性或法定同意机制的替代品，也不会因为写得具体就使访问自动正当。字段采集点要解释字段为何需要、必要性、受众和后果；设备或账户权限请求则聚焦本次能力授权与平台控制，两者在同一流程出现时应一致但不互相替代。
怎么落地
- 为每个权限入口维护 permission/data、task/purpose、scope、recipient、trigger/frequency、background behavior、owner 和版本；发布前与实际 API 调用、数据流及平台配置核对。
- 在紧邻平台请求且仍可返回的位置给出最短可决策摘要：访问什么、为哪项当前任务、关键范围；只有会改变决定时才展开接收者、频率和后台行为。按钮应描述继续请求或暂不决定，不能伪装成系统授权按钮。
- 读取平台可用范围并据此改写说明，例如仅选定内容、精确或近似位置、使用期间或一次性访问；产品文案不得承诺平台不提供的控制。平台已给出决定时，不重复展示像首次申请一样的提示。
- 用权限调用审计和版本化快照检查“文案—平台配置—实现”一致性；以理解测试、任务完成、撤销和错配投诉验证，而非只优化授权转化。