用户协议与隐私政策模板区别

很多小团队上线前临时找模板，把用户协议和隐私政策当成一份东西，改个标题就贴上去，结果应用商店审核打回、隐私合规检查也过不了。这篇不讲法律定义，只讲实操：两份模板分别在什么场景下用、撰写时各自要交代哪些内容、哪些字段可以互相抄、哪些绝对不能混。看完你能判断手上的模板够不够用，缺的部分去哪里补。

很多小团队上线前临时找模板，把用户协议和隐私政策当成一份东西，改个标题就贴上去。结果应用商店审核打回，隐私合规检查也过不了，回头再补又是几天工。这两份文件面向的对象根本不同：一份约束用户行为，一份约束平台自己怎么处理个人信息。

这篇不讲法律定义，只讲实操。两份模板分别在什么场景下用、撰写时各自要交代哪些内容、哪些字段可以互相抄、哪些绝对不能混。看完你能判断手上的模板够不够用，缺的部分去哪里补，而不是拿着一份改标题的文档赌审核能过。

先分清两份模板各自解决什么问题

用户协议

管的是你和平台之间的规则：账号归属、使用限制、付费退款、违约处理、免责范围，核心是约束行为

隐私政策

管的是平台怎么处理你的个人信息：收集哪些字段、用途、共享给谁、存多久、怎么删除，核心是告知与授权

判断口径

内容是「你不能做什么」写进用户协议，内容是「我们拿你的数据做什么」写进隐私政策

实操里最好用的自测方法：把模板里每一条条款读一遍，心里问「这条是在管用户，还是在说平台自己」。管用户行为的归用户协议，讲平台数据动作的归隐私政策。两边都沾的条款，比如账号注销，通常要拆开写，用户协议写注销条件和后果，隐私政策写注销后数据怎么处理、多久清完。

• 只做内部工具、不收集任何个人信息的系统，往往只需要一份使用约定，但仍要确认是否触发其他告知义务
• 涉及未成年人、医疗、金融等场景时，通用模板通常不够，别硬套
• 同一份文档里既写行为约束又写数据用途，审核方一眼就会标记为混用
• 两份文件的生效日期可以不同，但主体名称和联系方式必须指向同一个法律主体

按场景对照：你的产品该上哪几份

拿不准的时候，先别急着选模板，先列三列：收集了什么、给了谁、留多久。三列里只要有一项填不出来，就说明现有模板不适配你的产品，需要补条款而不是换个标题。这三列同时也是后面自查清单的底稿，写隐私政策时直接按列展开成段落即可。

撰写差异对照表：同一件事两份怎么写

• 可以互相抄的：生效日期、主体名称、联系方式、争议解决口径，统一到一份源文件里维护
• 绝对不能混的：免责声明、责任限制、数据用途、共享对象、留存期限
• 两边都要出现的：账号注销入口、客服渠道、投诉方式
• 改完统一做一次交叉检查，确认两份之间没有互相矛盾的时间或口径

上线前自查清单与常见打回原因

1. 核对占位内容逐条检查主体名称、联系方式、更新日期是否与实际一致，模板里残留的占位文字是最常见的打回原因
2. 对齐实际调用检查隐私政策是否覆盖了实际调用的所有 SDK 和接口，多接一个统计或登录组件就要补一条
3. 确认同意动作同意要能追溯到具体版本，只留一句「我已阅读并同意」在争议时说明力很弱，可参考站内 /tos-privacy-consent-validity 的讨论
4. 归档发布版本每次修订留存版本号和生效时间，需要留证时按站内 /dispute-evidence-keep 的方法保存截图与页面快照

自查顺序建议从占位内容开始，再对齐实际调用，最后处理同意和归档。原因是占位内容最快能改完，但漏掉一条就等于全篇没改；而调用对齐需要开发和运营一起确认，往往最花时间，放前面容易卡住节奏。审核方看的是整体一致性，不是某一条写得漂亮。

如果手上模板已经用了一段时间，建议先别整篇推翻，按上面的清单逐条标注「已覆盖、部分覆盖、没有」，把没有的先补上。涉及特定行业或未成年人场景时，通用模板通常不够，需要单独评估后再上；具体到不同平台的审核口径，可以到站内 /sites 核对对应方向的资料再决定。