做产品改功能、接第三方 SDK、上架审核时，经常被问「这两份文本先改哪份、哪份出了事更麻烦」。多数人把它们当成同一份法律文件的两个名字，结果该写的没写，不该承诺的写死了。这篇不教你套模板，只讲两者的定位差别、判断优先级的标准，以及一份能直接照着走的自查清单。
做产品改功能、接第三方 SDK、上架审核时，最常被问到的一句话就是：这两份文本先改哪份，哪份出了事更麻烦。多数人下意识把它们当成同一份法律文件的两个名字，结果该写的没写，不该承诺的写死了，改完一轮还是过不了审。这篇不教套模板，只讲两者的定位差别、判断优先级的标准，以及一份能直接照着走的自查清单。
先说结论方向：没有哪一份永远更重要，优先级会随产品阶段和触发事件切换。但判断依据是稳定的，搞清两份文本各自回答什么问题，你就能在两分钟内定下先动哪份。下面从分工、卡点、判断标准、监管视角一路讲到自查顺序。
先把两份文本的分工弄清楚
隐私政策面向的是个人信息处理这一整条链路：收集什么、为什么收、给谁看、留多久、用户怎么撤回同意。它回答的是数据处理合法性问题。用户协议面向的是你和我之间的关系：账号归谁、能不能转卖、内容版权怎么算、出了纠纷怎么解决，回答的是权利义务边界问题。两条线交叉但不重合。
- 隐私政策
- 解释数据怎么被处理，读者是监管和用户，看的是处理链条是否说清、是否与埋点一致
- 用户协议
- 界定双方责任，读者是用户和法院，看的是责任划分是否合理、有没有明显不公的条款
- 常见误区
- 放在同一个页面展示，就以为可以互相引用着省事，结果改一份另一份就前后矛盾
一份写得好不能替代另一份。你可以在隐私政策里把数据流向写得很细，但用户封号后能不能申诉、内容版权归谁，这些它管不到；反过来，用户协议写得再完整，也不能拿它当采集行为的说明。两份文本各司其职，缺一块就是缺一块。
为什么大家会纠结哪个更重要
这个纠结不是空想出来的，它来自三种真实卡点。这三种场景各自盯的是不同那份文本，所以问先改哪份，实际上是在问当前处在哪个场景里。
- 上架审核被拒时，平台多数先看隐私政策是否覆盖了实际采集行为，用户协议反而查得宽松
- 用户投诉或纠纷时，判定依据往往是用户协议里的责任条款，隐私政策帮不上责任划分的忙
- 监管问询或合规审计时，重点落在个人信息处理链路，用户协议基本不在问询范围内
- 同一个产品在不同阶段优先级会切换：上线前偏隐私政策，运营纠纷期偏用户协议
还有一类情况是两份都得动：产品同时改了采集行为和商业模式，比如从免费工具改成会员制并新增了定位功能。这时候不要按「哪个更重要」排序，而是按「哪个改动风险更高」排序，先把动了数据采集那份处理掉。
判断标准：什么情况下哪份更紧急
与其记结论，不如记触发条件。下面这张表可以直接对照产品当前的改动类型，快速定位该先动哪份文本。
| 改动类型 | 先动哪份 | 理由 |
|---|---|---|
| 新增采集行为（定位、通讯录、剪贴板、人脸） | 隐私政策 | 审核和监管首先核对采集与说明是否一致 |
| 改商业模式（收费、退款、账号转让、内容归属） | 用户协议 | 纠纷判定依赖责任与权益条款 |
| 面向境外用户 | 两份都要重写 | 别拿中文版本机翻顶上，处理说明和责任条款都要本地化 |
| 纯内部工具、不采集个人信息 | 用户协议可极简 | 但隐私政策仍要说明日志留存与访问控制 |
顺便说清楚什么情况下这套判断不适用：涉及未成年人、医疗健康、金融等特殊领域时，两份文本都有额外的强制条目，不能只按上面的顺序排优先级。这类产品建议两份一起过一遍，别挑着改。
从监管视角看：谁在盯隐私政策，谁在盯用户协议
监管盯两份文本的抓手不一样。隐私政策的检查点是「说的和做的是否一致」，也就是文本与埋点、SDK、第三方共享清单能不能对得上；用户协议的检查点是「有没有明显不公条款」，比如单方免责、随意封号、禁止用户投诉。
内审或外部审计出问题时，隐私政策的差距通常更难补齐，因为它牵涉技术侧改造，不是改几行文字就完事。用户协议的问题多数能在法务层面消化。所以如果你手上只有一个排期窗口，优先补隐私政策的技术对齐，往往收益更稳。
具体审查项与口径可以先看 app合规:用户协议及隐私政策审查要点（/app-compliance-policy-review），再结合本站安全与合规分区的其他文章对照自己的产品。
落地自查顺序：一份可以直接照着走的清单
- 第一步：对齐采集清单列出产品当前实际采集的数据项，与隐私政策逐条比对，多出来的补写，写了但没做的删掉。验证方式是让技术同学把埋点表和文本并排放，逐行打勾。
- 第二步：核对第三方共享确认第三方 SDK 与共享清单是否在隐私政策里点名，共享目的与字段是否写清。验证方式是拉出 SDK 清单，跟文本里的列举对照。
- 第三步：检查用户协议四类条款确认账号、内容、退款、争议解决四类条款是否与当前业务一致。验证方式是拿一份真实客服工单走一遍，看条款能不能回答用户的问题。
- 第四步：确认更新机制可执行确认两份文本的生效时间、更新机制、通知方式是否真的能做到。验证方式是模拟一次改版，看通知流程能不能跑通。
- 第五步：留档版本记录把两份文本的版本号与生效记录存档，方便出问题时证明当时用的是哪一版。验证方式是让任何一位同事都能在三十秒内说出当前生效的是哪版。
最常见的三类写错
下面这些错法跟具体条款文本无关，只关心「说的是不是真做的」。写的时候以实际情况为准，别照着感觉走。
- 把用户协议里的条款当隐私政策用，典型是拿「我们重视您的隐私」这类口号代替具体处理说明
- 两份文本互相引用关键条款，一旦其中一份改版就会前后矛盾
- 隐私政策里承诺绝不共享给第三方，但业务上接了统计与推送 SDK，属于典型自相矛盾
- 用户协议里写最终解释权归我方，这类条款在很多场景下不被认可
- 只改文本不改行为，比如删掉了某条共享说明但 SDK 还在跑
第三条和第五条是同一类问题：文本承诺和实际行为脱节。判断方法很简单，让技术同学把 SDK 调用清单导出来，逐项在隐私政策里找对应说明，找不到的就是缺口。
什么时候该动哪份：更新触发条件对照
更新触发条件可以直接做成对照表，挂在需求评审环节里，谁提的需求先对一遍。
- 新增或更换数据采集项
- 隐私政策必须更新，用户协议通常不需要
- 更换云服务商或调整日志留存策略
- 隐私政策更新，涉及数据出境还要另外走评估
- 调整收费、退款、账号规则
- 用户协议更新
- 两份文本变更后
- 都要重新取得同意或以显著方式通知，具体做法参照本站隐私保护与同意相关的文章
记不清当前用哪一版的，先到 检测口径与数据来源（/about） 看本站的说明方式，再回来整理自己的版本表。版本管理这件事看起来琐碎，出事时是唯一能自证的东西。
团队怎么分工：谁写、谁审、谁签字
两份文本不是法务一个人的事。产品、法务、技术各自负责一块，缺哪块都会在审核或纠纷时暴露出来。
- 产品负责列出实际数据流与业务规则，不能只丢一句按模板写
- 法务负责判断条款是否站得住，尤其是免责与争议解决部分
- 技术负责核对文本与埋点、SDK、日志实际行为是否一致
- 建议至少留一份版本记录，写明谁在什么时候改了什么，出事时能对上
如果是五个人左右的小团队，没有专职法务，那就把这三块职责按人分掉，哪怕是同一个人兼任，也要在版本记录里写清当时谁确认的。责任落到具体人头上，文本质量才会稳。
常见问题
隐私政策和用户协议可以合并成一份吗？
不建议。两者面向的问题不同，合并后容易出现条款互相稀释，监管与用户都难找到关键信息。可以放在同一展示层级、同一入口，但内容分开写，各自有独立的更新记录。
用户不同意隐私政策，还能不能用产品？
取决于该处理行为是否属于提供服务所必需。核心功能必需的通常无法拒绝，非必需的（如个性化推荐、营销推送）应当允许单独关闭。具体判断要结合业务类型，拿不准时先看审查要点页面里的口径。
两份文本里哪份出了问题更容易被追责？
看问题性质。文本与实际采集行为不符、隐瞒共享对象，属于隐私政策侧的问题；随意封号、单方免责、限制用户投诉，属于用户协议侧的问题。前者通常涉及个人信息处理合法性，处理链条更长。
小团队没专职法务，两份文本怎么办？
先把实际数据流写清楚，再对照站内的审查要点逐条核对，重点盯共享清单和留存期限两项。模板只能解决格式问题，填不填得对还是看你自己的业务事实。
改了功能但没改文本，会有什么后果？
属于文本与事实不符，一旦被用户投诉或被检查，很难解释。建议把「功能上线前同步检查两份文本」写进发布清单，作为固定动作，而不是等出问题再补。
