做产品评审时经常出现这种场面：开发说要加个定位权限，运营顺手把「权限说明」塞进隐私政策里，法务一看就问「这两件事是一份文件吗」。本文把隐私政策与权限政策各自的读者、内容范围、发布位置和更新触发条件拆开讲，给出一张对照表、一份自查清单，以及两者冲突时先改谁的处理顺序，适合产品经理、法务和负责合规文档的同学对着排查。
做产品评审时经常出现这种场面：开发说要加个定位权限，运营顺手把「权限说明」塞进隐私政策里，法务一看就问「这两件事是一份文件吗」。其实大多数团队不是不懂合规，而是把两份文档混成一份在写，结果用户看不懂、审核打回、内部改起来还互相牵扯。这篇把两份文件拆开讲，给你对照表和排查顺序，适合产品经理、法务和负责合规文档的同学对着动手。
先记住一个粗糙但好用的分法：隐私政策回答「你拿我的信息干了什么」，权限政策回答「你为什么要用我手机的这个能力」。一个面向信息处理，一个面向系统能力调用。两者有交叉区域，但读者、语气、发布位置和更新触发条件都不一样。下面逐节拆开，每节都会给出可执行的判断动作，而不是只讲定义。
两份文件到底写给谁看
隐私政策的读者是用户本人和监管方，用户翻开它想知道的是：你收集了我哪些信息、拿去做什么、存多久、会不会给别人。所以它得写成普通人能读懂的句子，不能全是法律术语堆叠。权限政策的读者更偏应用商店审核人员和系统层，他们关心的是：这个权限为什么非要不可、用户拒绝之后应用会怎样。它更像一份逐条对应的技术说明。
| 对比项 | 隐私政策 | 权限政策 |
|---|---|---|
| 主要读者 | 用户本人、监管方 | 应用商店审核、系统层、用户查看弹窗时 |
| 核心问题 | 收集什么、怎么用、存多久、给谁 | 为什么需要这个权限、不给会怎样 |
| 语气要求 | 通俗可读、少术语 | 逐条对应系统权限清单，说明用途和降级行为 |
| 典型位置 | 独立页面、应用商店提交材料 | 应用内权限说明弹窗、商店权限说明栏、开发者文档 |
| 典型不适用场景 | 内部工具、不对外分发的系统可不做对外版本 | 仍建议留档，至少写清权限用途和拒绝后果 |
这里有个容易忽略的点：读者不同，同一件事的写法就不同。比如相册权限，隐私政策里要写「用于上传你选择的图片」，权限政策里要写「仅在你主动选择图片时调用，拒绝后仍可手动输入文字」。两句话说的是同一条链路，但侧重点完全不一样。写的时候先问自己：这句话是给用户理解数据流向的，还是给审核人员核对系统调用的。
内容重叠与不重叠的地方分别在哪
两份文件的重叠区集中在涉及个人信息的系统权限上：定位、通讯录、相册、麦克风、相机这些。两边都会提到，但角度不同——隐私政策讲数据用途和流向，权限政策讲调用时机和降级表现。不重叠的区域也很清楚：隐私政策还要覆盖账号体系、日志、第三方共享、注销与数据导出；权限政策只管系统能力的调用，不涉及账号怎么注销。
- 重叠区：涉及个人信息的系统权限，两边都要提，但隐私政策写用途和流向，权限政策写调用时机和拒绝后的表现
- 隐私政策独有：账号注册与注销、日志留存、第三方共享清单、数据导出与删除路径
- 权限政策独有：权限名称与系统对应关系、申请时机、拒绝后的功能降级方案、再次申请的引导方式
- 常见错误一：隐私政策里堆了权限清单却没写每条权限用来干什么
- 常见错误二：权限政策只写用途不写拒绝后果，用户点「不允许」后体验断崖式下跌
判断标准之外还要注意一个边界：很多团队把「权限说明」当成隐私政策的一个章节来写，这在信息架构上没错，但会导致权限政策缺少独立可核对的结构。更稳的做法是内部维护一份权限清单表，隐私政策引用它的用途描述，权限政策引用它的调用与降级描述，两边同源但表述分开。
发布位置与更新触发条件
隐私政策通常需要一个稳定可访问的链接，随应用商店提交一并给审核，改版时旧链接不能直接失效。权限政策更多落在三个地方：应用内的权限说明弹窗、应用商店的权限说明栏、开发者文档。发布位置不同，决定了更新节奏也不同。隐私政策的更新往往跟着数据实践走，权限政策的更新跟着功能调用走。
| 触发事件 | 该动隐私政策 | 该动权限政策 |
|---|---|---|
| 新增数据用途或第三方共享 | 是 | 看是否涉及新权限，涉及则同步 |
| 新增或收回一项系统权限 | 看是否采集个人信息 | 是 |
| 留存期、注销路径变化 | 是 | 否 |
| 权限被拒绝后的行为变化 | 否 | 是 |
| 数据导出或删除方式调整 | 是 | 否 |
- 第一步：列出本次改动的原始事实写清楚新增了什么能力、调用了什么系统权限、是否产生了新的个人信息处理。这一步只记事实，不做判断。
- 第二步：判断是否新增个人信息处理如果新增的处理动作会产生或扩大个人信息收集范围，隐私政策要动；如果只是调用系统能力但不新增信息收集，优先动权限政策。
- 第三步：对照两份文档逐条核对拿权限清单表对照隐私政策的用途描述和权限政策的降级描述，看有没有哪条只在一份里出现。缺的那份补齐。
- 第四步：留下版本与审批记录每次改动记下版本号、改动点和审批人。出事时这些记录比任何截图都管用。
拿不准更新范围时，先按「是否新增个人信息处理」判断，再决定是否动另一份。这样能避免每次小改动都把两份文档翻一遍，也能防止该改的那份被漏掉。
两份说法打架时先改哪个
对外解释数据实践时以隐私政策为准，解释系统弹窗时以权限政策为准，不要用一份去盖另一份。冲突通常出现在三种地方：权限清单对不上、数据用途描述不一致、文案措辞一方写了另一方没写。排查顺序建议先对齐权限清单，再对齐数据用途，最后才抠措辞。
- 先对齐权限清单：系统里实际申请了哪些权限，两份文档是否都覆盖，有没有多写或漏写
- 再对齐数据用途：同一条权限在两份文档里的用途描述是否一致，不能一份说「用于推荐」另一份说「用于统计」
- 后对齐文案措辞：前两步对齐后，再统一术语和表述风格，避免用户读到矛盾说法
- 优先修权限说明：它直接对应系统弹窗，用户点「不允许」时的实际行为必须和文档写的一致
- 存档版本与审批记录：每次改动留下改动点和审批人，比事后截图更有说服力
有一个不适用的情况要提前说清：如果产品还处在原型或内部测试阶段，权限可能频繁增删，这时候不必追求两份文档完全同步，但要在内部记录里标注「待稳定后补齐」。等进入提审或对外发布前，再按上面的顺序做一次完整对齐。
下一步想对照实际产品的权限申请清单和文档组织方式，可以到站内工具目录看同类产品的合规文档结构，再到价格与资料库页面核对当时的数据口径，避免凭印象做判断。→常见问题
小团队只有一份文档，能不能把权限说明并进隐私政策？
可以合并成一份文件，但内容不能混。建议在同一份文档里分成两个明确小节，一个小节讲个人信息处理，另一个小节逐条讲系统权限和拒绝后的降级表现。这样应用商店审核和用户都找得到。前提是你确实不打算单独维护权限说明，一旦权限清单变长，拆开更省事。
隐私政策里写了某权限，但代码里其实没调用，会有问题吗？
会有。文档写了却实际调用，属于告知不实；文档写了但没调用，通常被认定为冗余描述，审核侧可能要求你删掉或说明。稳妥做法是让文档权限清单和代码里的实际调用点定期比对，删掉已下线权限的描述，补上新增权限的目的说明。
应用商店被打回说权限说明不清，通常缺什么？
多数情况缺三样：这个权限具体用来做什么功能、用户拒绝后哪些功能不可用或降级成什么、有没有更小范围的替代方案。补的时候别写「为提升体验」这种话，写成「用于XX功能，拒绝后该功能不可用，其余功能不受影响」更容易过。
