做产品的人常被这两份文档绕晕：法务发来一份隐私政策要挂链接，应用商店又要求补一份权限说明，两边内容还被指「重复」「对不上」。这篇不讲法条，只讲实操：先分清两份文档各自回答什么问题，再给一份分工对照表和上线前自查顺序，让你知道哪句话该写在哪一份里，什么情况下这套分法不适用。
做产品的人常被这两份文档绕晕：法务发来一份隐私政策要挂链接，应用商店又要求补一份权限说明，两边内容还被指「重复」「对不上」。其实这不是文档写错了，而是两份东西本来就在回答两个不同的问题，硬凑成一份或者互相抄，才会看起来别扭。
这篇不讲法条，只讲实操：先分清两份文档各自回答什么、写什么，再给一份分工对照表和上线前的自查顺序，让你知道哪句话该写在哪一份里。最后也会说清什么情况下这套分法不适用，避免照搬。涉及合规口径和申报要求的具体数字与说法，别凭记忆答，去站内安全与合规分区核对当时的页面。
先分清两份文档各自回答哪一个问题
把两份文档放在一起看，最容易犯的错是当成「一份写数据、一份写权限」然后各写一半。实际上它们面向的对象不同：一份面向你收集的信息，一份面向你调用的设备能力。想清楚这一点，后面所有内容归位都顺。
- 隐私政策回答「你拿我的数据去做什么」：收集范围、用途、共享对象、留存与删除路径、联系方式。
- 权限政策回答「你为什么动我的设备能力」：相机、麦克风、相册、定位、通讯录、剪贴板等，每一项的调用时机与拒绝后的后果。
- 一句话记法：隐私政策面向「数据」，权限政策面向「设备入口」；同一个功能可能在两份里都出现，但说法完全不同。
- 别把两份当备份：一份详写、一份只放摘要的做法，被审核问到时会两边都对不上。
这里有个判断标准：如果一个条目描述的是「信息流向了哪里」，它属于隐私政策；如果描述的是「系统弹了哪个授权框」，它属于权限政策。拿不准时，问自己一句:用户看到这句话，是更想关掉数据收集，还是更想去系统设置里关权限。
内容对照：同一件事在两份文档里的不同写法
同一个功能，比如「拍照上传头像」，在两份文档里的表述重点不一样。下面这张对照表可以直接拿去改自己家的文档，看哪一列写空了、哪一列写串了。
| 维度 | 隐私政策里的写法 | 权限政策里的写法 |
|---|---|---|
| 收集什么 | 数据项：账号、设备标识、日志 | 系统能力：相机、定位、剪贴板 |
| 什么时候触发 | 场景：注册、下单、客服会话 | 时点：点拍照按钮才申请，不是一进首页就弹 |
| 不给会怎样 | 功能降级与退出方式 | 逐条写清拒绝后哪些功能不可用 |
| 能不能关 | 撤回同意、注销、删除入口 | 系统设置里的关闭路径 |
| 共享给谁 | 第三方 SDK、合作方与用途 | 一般不涉及，第三方调用要单独说明 |
注意最后一行的差异：共享对象通常只写在隐私政策里，权限政策一般只讲设备能力。但如果某个第三方 SDK 会在后台调权限，两边都要提到，且说法要能对上。
- 不要互抄：把数据项清单复制进权限说明，读起来像没写完。
- 不要互相省略：两份都写「详见另一份」，用户和审核都不会满意。
- 交集的写引用关系：比如权限说明里提到采集位置，就写「用途见隐私政策相关章节」。
- 改一份就要想另一份：任何一句承诺性表述，先看另一份有没有相反说法。
最容易踩的坑：两份文档互相矛盾
被指出「对不上」的场景，绝大多数不是谁写错了，而是功能改了、SDK 换了，只更新了一份。下面按排查顺序来，从最容易被抓到的矛盾开始查。
- 第一步 并排列清单把两份文档里提到的功能清单并排列出，逐项核对「是否收集 / 何时调用 / 能否关闭」三列是否一致。
- 第二步 查反向承诺重点找这类句子：隐私政策写「不收集定位」，权限政策却给定位写了用途说明。这类反向承诺最容易被审核挑出。
- 第三步 查范围宽窄权限说明里承诺的用途，不能比隐私政策里写的更窄，也不能凭空多出数据流向描述。
- 第四步 查时间线功能上线、SDK 更换、权限新增时，两份要一起改。只改一份是最常见的翻车原因，版本表能帮你快速回溯是哪一次漏改。
判断标准很简单:把两份文档当成同一份产品的两个侧面，任何一次改动都要问「另一个侧面有没有受影响」。如果两份的更新记录长期不一致，说明你们的流程缺一个共同负责人。
写作顺序：先定清单，再写文本
很多团队一上来就动笔，写到最后发现两份内容互相打架。比较省事的做法是先拉清单、再定归属、最后写句子。顺序对了，返工少很多。
- 第一步拉功能清单：每个功能需要哪些数据、哪些系统权限，谁申请、什么时候申请。
- 第二步判归属：数据项进隐私政策，系统能力进权限政策，交集的写清引用关系而不是各写一套。
- 第三步写拒绝路径：每个权限都要有一句「用户拒绝后产品怎么走」，写不出来说明这个权限可能不必要。
- 第四步留版本表：文档版本、生效时间、本次改动点，方便被问到时快速回溯。
这里最值得花时间的是第三步。权限政策的价值不在于把系统能力列一遍，而在于说清「不授权也能用哪些功能」。一个连拒绝路径都写不出来的权限，大概率是可以砍掉或延后申请的。
上线前自查清单
上线前把下面这几条过一遍，比事后被问到再补要省事。每条都能落到具体动作，不用靠感觉判断。
- 两份文档里出现的功能名称与实际产品一致，没有已下线的旧功能残留。
- 每个申请的系统权限都能在权限政策里找到对应条目，反之亦然。
- 首次弹窗与文档描述一致：什么时机申请、拒绝后是否还能继续用主流程。
- 注销、撤回同意、数据删除的入口真实可达，不是只写在文档里。
- 若走应用商店或政企采购，按对方要求补齐材料，具体口径到站内安全与合规分区核对当时要求。
最后一条特别提醒：不同渠道对文档的要求有差异，同一份东西投不同商店可能都需要调整。这类要求会变，所以别抄旧版本，去站内相关页面核对当时的说明。
被用户、审核或同事问到时怎么答
上线后总有人问这两份文档的事。回答时别绕法条，直接说清各自管什么，大多数疑问当场就能解决。
| 被问到 | 怎么答 |
|---|---|
| 两份是不是重复 | 用途不同：一份管数据流向，一份管设备调用，交集处做引用不做复制 |
| 为什么这个权限没写 | 先查清单再看文档，确认是漏写还是该权限已不申请 |
| 政策什么时候更新的 | 给版本表与生效时间，别用口头印象回答 |
| 用户只想关掉某个能力 | 告诉他在系统设置里的关闭路径，以及关掉后哪些功能会降级 |
什么情况下这套分法不适用
上面这套分工不是万能模板，以下几种情况直接照搬会出问题，需要另做调整。
- 纯内部系统、不面向外部用户的产品，重点往往在权限最小化与日志审计，不是对外文档。
- 行业监管另有强模板要求的场景，按监管口径走，本文只作整理思路。
- 多端产品（App、小程序、网页）同一份隐私政策可能不够用，需要按端说明差异，别硬合并。
- 文档只是表象：真实调用与文档不一致时，先改代码或改流程，改文档不能替代整改。
还有个常见误区：以为两份文档写全了就等于合规。实际审核和用户投诉往往针对的是「实际行为和文档不一致」，所以核对真实调用路径比打磨措辞更重要。涉及具体标准时，到站内安全与合规专区看当时的说明。
下一步把你家两份文档按上面的对照表过一遍，重点查反向承诺和拒绝路径；想对照第三方工具与中转站的采集口径，可以去站内工具目录和安全合规分区看当时的页面说明再动手改。→常见问题
隐私政策和权限政策区别大吗，能不能合成一份？
区别不小，但可以放在同一个入口下分两段或两个标签页。核心是分工：隐私政策讲数据怎么收集和使用，权限政策讲为什么调用系统能力。合成一份不是不行，但要把两套逻辑分清楚，否则容易出现「文档说不用定位、实际却申请了」这类矛盾。
我们的产品没有 App，还需要权限政策吗？
主要看有没有调用浏览器或系统的敏感能力，比如摄像头、麦克风、定位、通知推送。如果全程不碰这些，只写隐私政策通常够用；一旦有调用，就需要给用户一个能查到的说明，写在哪、写多细按你的发布渠道要求定。
权限政策里要不要写清楚拒绝后的后果？
要写，而且这是最实用的一段。用户拒绝相机权限后还能不能发图文、拒绝定位后附近功能是否隐藏，都该有明确说法。写不出来的权限，通常可以重新评估是否真的需要申请，或者是否可以改成用到时才问。
隐私政策更新了，权限政策要跟着改吗？
看改动是否涉及设备能力。新增数据项、换 SDK、加共享对象，一般要动隐私政策；新增或取消系统权限调用，两份都可能要动。稳妥做法是每次版本变更都把两份的功能清单对一遍，确认没有一边改一边没改。
运营侧最容易被问到什么，怎么准备？
最常被问「你们收集了我的什么」和「这个权限为什么申请」。准备一张功能—数据—权限对应表，客服和运营能照着答；涉及具体条款、地区要求或申报口径的，别自己判断，到站内安全与合规分区的对应页面核对当时说明。
