做产品的人常碰到这种场面：模板从网上抄下来，用户协议和隐私政策塞进同一个文档，改个公司名就上线了。结果审稿时被问一句「这条为什么写在协议里而不是政策里」就答不上来，返工重写。这篇不讲法律条文，只讲两类模板的结构差别和核对顺序，让你在拿到模板的第一时间就知道哪段该留、哪段该挪、哪段必须自己填。
做产品的人常碰到这种场面：模板从网上抄下来，用户协议和隐私政策塞进同一个文档，改个公司名就上线了。结果审稿时被问一句「这条为什么写在协议里而不是政策里」就答不上来，只能返工重写。这篇不讲法律条文，只讲两类模板的结构差别和核对顺序，让你拿到模板第一时间就知道哪段该留、哪段该挪、哪段必须自己填。
先记住一个最省事的判断起点：这两份文档不是「一份正式版、一份补充版」的关系，它们是两条平行线，管的事情几乎不重叠。重叠的地方只有变更通知、联系方式这类程序性内容，而恰恰是这几处最容易被复制粘贴成同一套说法，也最容易被审稿人抓出来。
两类模板管的是两件事
用户协议约束的是「你怎么用我的服务」，落点在账号、付费、内容发布、封号与责任划分。隐私政策交代的是「我怎么处理你的个人信息」，落点在收集哪些信息、用来干什么、给谁看、留多久、你怎么撤回。把这两句话贴在文档标题下面，写每一段时先问自己属于哪一半，绝大多数归类争议当场就没了。
什么情况下不适用：如果产品根本不收集任何个人信息，比如一个纯离线的小工具，政策可以写得极简，但协议不能省，因为付费、免责、知识产权这些条款跟收不收个人信息没关系。反过来，如果产品是强账号体系，用户协议再简也不能省掉账号规则和禁止行为这两块。
- 先在文档开头写一句「本文件管什么」，逼自己选边，选不出来说明这段该拆
- 涉及付费、退款、封号、责任上限的，一律归协议
- 涉及收集字段、用途、共享对象、存储期限、用户撤回方式的，一律归政策
- 两边都涉及的（变更通知、联系方式、生效日期），指定一处详述、另一处引用
- 拿不准时看条款的落点是人还是数据：约束人的行为放协议，描述数据的流转放政策
模板结构对照：段落顺序和必备块
两类模板的骨架差别很大，拿到手先看目录就能判断这份模板是不是「拼出来」的。协议模板的段落顺序通常围绕用户生命周期展开，政策模板的顺序通常围绕数据生命周期展开。顺序错乱不一定是法律问题，但会让读者找不到自己关心的那一条。
| 对比项 | 用户协议模板 | 隐私政策模板 |
|---|---|---|
| 展开线索 | 用户从注册到注销的行为路径 | 数据从收集到删除的处理路径 |
| 典型必备块 | 定义、账号与注册、使用规则与禁止行为 | 收集范围、收集方式、使用目的 |
| 商业相关块 | 付费与退款、自动续费、知识产权 | 一般不承担商业条款，只做提及和跳转 |
| 责任相关块 | 免责与责任限制、争议解决 | 安全措施、泄露处置、未成年人条款 |
| 变更口径 | 继续使用视为接受 | 重大变更需重新征得同意 |
| 用户权利块 | 申诉与封号复议 | 查阅、更正、删除、撤回同意、注销 |
两边都有的块，措辞不能共用一套套话。最典型的是变更通知：协议讲「继续使用视为接受」，政策要讲「重大变更重新征得同意」。这两句话写反了，或者干脆两边都写成同一句，审稿时一定被挑出来。另一个是联系方式，建议两份文档指向同一个入口，但不要在政策里塞客服话术，那属于协议或帮助中心的内容。
带「视情况填写」标记的段落
模板里凡是标着「此处填写」「视情况修改」「示例」的段落，都属于必须替换项，直接留原样等于没写。判断方法是把文档里的占位符全部搜一遍，包括方括号、示例公司名、示例域名、示例邮箱，一个都别放过。搜完还剩空的地方，说明你漏了一块该补的内容。
照抄模板最容易踩的几处
模板能省事，但有几处是抄了不如不抄。下面这几条按返工概率从高到低排，审稿时优先处理。注意这里说的都是结构性问题，具体条款是否合规，最终还是要请法务或有资质的人看过。
- 把 SDK 清单、第三方共享名单原样留着：模板里的示例合作方不是你的合作方，写错等于虚假告知
- 收集字段写成「包括但不限于」这种开放表述，实际只收手机号，属于过度声明，反而是风险
- 协议里写「最终解释权归本公司」这类表述，属于无效条款，审稿时优先删
- 把退款、自动续费规则只写进政策：这类商业条款应放协议，政策里提一句并链过去即可
- 把未成年人的条款两边写得一模一样，实际两份文档对这个群体的处理逻辑并不相同
给一个通用的排查顺序：先比对模板字段与产品实际收集项，再比对条款与产品实际功能，最后统一两边对同一件事的说法。这三步做完，绝大多数「抄出来的坑」就堵住了。什么情况下不用这么细？如果产品还在原型阶段、没有真实用户，可以先按这三步粗筛一遍，等上线前再走完整流程。
给产品与法务的核对顺序
产品和法务经常卡在「谁先动」上。建议产品先出事实，法务再改措辞，顺序反过来会浪费大量沟通时间。下面这套顺序对小程序、App、网页端同样适用，差别只在权限声明的篇幅，核心动作是一致的。
- 拉一份产品实际行为清单注册要什么、埋点收什么、第三方 SDK 有哪些、数据存哪。产品同学负责填，不确定的字段标问号，不要猜。
- 用清单反向标注模板逐段标成「适用」「不适用」「需要改写」三档。标「不适用」的段落直接删，别留着占位置。
- 统一两份文档的口径找出重复但不一致的表述，只留一处详述、另一处引用，避免同一件事在两份文档里说法不同。
- 确认程序性内容对得上变更通知方式和生效日期在两份文档里要能对上，避免一个说重新同意、一个说继续使用即接受。
- 上线前再走一遍产品加新功能、接新 SDK 后，回到第一步重跑一遍。建议把这份清单存档，不要求每次从零开始。
如果你在做中转站或聚合类产品，第三方接口、日志留存、计费数据这几块尤其容易在协议和政策之间放错位置，建议单独列一栏对照。相关的模板字段和第三方清单，可以到站内的工具目录里找现成的核对表，比对着改效率更高。
下一步把上面那张结构对照表和四步核对顺序存下来，下次拿到模板先按这个顺序过一遍；站内还有中转站可信度检测和价格追踪页面，涉及第三方接口和数据留存的部分可以交叉核对。→常见问题
两份文档能不能合成一份？
技术上能，实务上不建议。合成后用户很难分清哪部分是自己的义务、哪部分是你在处理他的信息，变更时也没法只改其中一边。更稳的做法是保持两份独立，在关键位置上互相引用，比如协议里提一句「个人信息处理见隐私政策」并给出链接。
模板里那些「包括但不限于」的表述，能不能留着？
要看在哪。风险与免责类条款用这种兜底表述相对常见，但涉及收集信息范围、共享对象时必须写成具体清单，否则等于给自己留了一个说不清的口子。判断标准很简单：这句话如果被人追问「具体指什么」，你能当场答出来就留，答不出来就改成具体项。
小团队没有法务，怎么判断模板改得够不够？
按可用性核对：每一段能不能对应到产品的真实动作，能不能说清触发条件和后果。做不到就先标出来，别硬写。拿不准的条款可以去站内安全与合规模块对照同类产品的写法，再决定保留还是删掉。
