很多小团队第一次上线产品，把隐私政策和用户协议当成一份东西写，结果该说的没说、不该承诺的写了，审核和用户投诉都容易出问题。这篇按「谁管什么、各写什么、怎么自查」三段讲清两者定位，给你一份可以直接照着核对的对照表，也会说清哪些情况下这套常规写法不适用。
很多小团队第一次上线产品，把隐私政策和用户协议当成一份东西写：勾选框只有一个，文案也糊在一起。结果该告知的没告知，不该承诺的倒先写死了，审核不过、用户投诉都从这儿来。这篇按「谁管什么、各写什么、怎么自查」三段讲，给你一份能直接照着核对的对照表。
先说一句实话：法规文本很难一次写全，但结构是可以先搭对的。下面这套不是让你照抄模板，而是让你知道每一段该往哪个框里放。判断类内容都会说清什么情况下不适用，别硬套。
先分清：一份管信息，一份管关系
隐私政策管的是「信息」，读者是数据主体，核心是履行告知义务；用户协议管的是「关系」，读者是使用者，核心是写清双方权利义务。两份文件经常被塞进同一个注册勾选框下面，但法律定位不同，混着写最容易出的问题就是拿协议里的免责条款去挡隐私责任，这种错位在投诉和审核里都很扎眼。
一个实用的判断标准：把条款里的主语替换成「我们」和「你」，试着放进隐私政策的语境里读。读不通、读起来像在划分责任而不是在告知事实的，多半属于协议内容。反过来，纯告知性的信息处理说明，塞进协议里也会显得突兀。
| 维度 | 隐私政策 | 用户协议 |
|---|---|---|
| 回答的问题 | 你的信息怎么被处理 | 你和平台各自有什么权利义务 |
| 读者 | 数据主体（用户本人） | 使用者（签约方） |
| 核心动作 | 告知、取得同意、提供权利入口 | 界定服务范围、账号规则、责任边界 |
| 典型高频条款 | 收集范围、共享对象、留存期限、注销路径 | 服务可用性、付费退款、封号终止、争议解决 |
| 写串的后果 | 告知不充分，同意基础不牢 | 免责条款易被认定无效，纠纷时站不住 |
隐私政策必须落到的那几项
隐私政策最怕写成抽象列表。更稳的写法是按功能逐条对应：这个功能收集了哪些字段、从哪来、为什么需要、不用会怎样。用户看完能对上自己实际点过的按钮，这份政策才算合格。
- 收集范围与来源：按功能拆开写，别只写「可能收集相关信息」这种兜底句
- 对外共享与委托处理：说清合作方类型和目的，而不是笼统地写「可能共享给第三方」
- 存储位置与留存期限：跨境场景单独说明，留存期限给出口径而不是含糊的「合理期限」
- 用户权利入口：查询、更正、删除、撤回同意、注销账号，每条都写清从哪个页面操作
- 未成年人处理：如果产品可能被未成年人使用，这条不能省
具体政策口径和合规工具，可以到 /ai-nav/category/ai-legal 页面找可对照的条目。哪些写法在你的业务里适用、哪些不适用，要结合收集场景判断，别直接套别家的文本。
用户协议该写清的责任边界
用户协议的重点不是把话说得漂亮，而是把边界画清楚。写得太满、承诺太多，后面兑现不了反而更被动；写得太松、无限免责，这类条款本身也容易被认定无效。
- 服务内容与可用性
- 写清提供什么、不承诺什么，避免「永久可用」「绝不中断」这类绝对化措辞
- 账号规则
- 注册资格、一号一人还是一号多人、转借与共享怎么处理，都要有明确口径
- 付费与退款
- 计费口径、自动续订、退款条件写清规则，具体数字引导用户到当时页面看
- 责任限制与终止
- 什么情况停服或封号、怎么通知、争议怎么解决，注意别堆无限免责
涉及价格、额度、模型名称这类会变的内容，不要在协议正文里写死。改成指向当时可查的页面，比如到 /price-watch 核对当期的数字，到 /official-api 看模型与接口的现行说明。这样改版时不用每次都动协议正文。
- 列功能清单把产品当前所有会碰用户信息的功能列出来，逐条问「这条在协议里对应哪句」
- 标责任点把封号、退款、停服这些可能引发争议的动作单独标出来，确认协议里有对应口径
- 去绝对化措辞搜一遍「永久」「绝不」「任何情况下」这类词，逐条改成有条件表述
- 交叉检查拿隐私政策里的处理说明去对协议里的服务描述，两边对不上的地方就是需要改的地方
交稿前按这个顺序自查一遍
自查的核心思路是「先对行为、再对用词、后对版本」。顺序别反，否则容易在文字上打转，改了半天行为没对上，还是白费。
- 第一步：对产品实际行为拿功能清单逐条对照两份文件，多写的和漏写的都标出来，先改事实层面的偏差
- 第二步：对用词是否混用隐私政策里出现「同意本协议即视为同意隐私政策」这类写法是把两份文件混在一起，要拆开分别呈现
- 第三步：对会变的数字与版本价格、额度、模型名称不要写进正文，改成指向 /official-api 与 /price-watch 这类当时可查的页面
- 第四步：留痕与通知改版要记录版本号和生效时间，保留通知记录；出纠纷时的举证逻辑可参考 /guides/dispute-evidence-keep
还有一点：如果产品处在快速迭代期，功能一周一变，那就别指望一次写全。更现实的做法是先把结构和判断标准搭好，每次上线新功能时按上面四步跑一遍，比一次性写一份大而全的文本更管用。
下一步想对照不同产品的条款写法和合规工具，可以到 /ai-nav/category/ai-legal 按分类翻一遍，再结合自己产品的实际收集场景做取舍。→常见问题
隐私政策和用户协议能不能写成一份文件？
技术上可以放在一个页面里，但建议分成两个独立章节，各有各的生效与更新说明。合并成一份的最大风险是用户勾选一次就代表同意全部内容，责任边界说不清；一旦涉及个人信息处理争议，很难证明你单独告知过。小团队可以同页展示，但结构上要能拆开引用。
协议里写了「最终解释权归平台」是不是就万无一失？
不是。这类条款在多数场景下会被认定为不公平条款而不被支持，写了反而显得不专业。更稳的做法是把规则写具体：什么行为触发什么处理，处理前是否通知，用户如何申诉。规则越具体，执行时争议越小。
产品还没上线，这两份文档什么时候开始写合适？
建议在功能定稿、数据流向确定后就动笔，别等功能做完再补。因为条款里要写的收集项、共享方、留存期限，都要以实际链路为准；链路一改文档就得跟着改。可以先用 /guides/data-boundary-audit 的方法把数据链路梳理出来，再据此外包成条款文字。
