做产品文档时最常见的卡点：一份协议里既写了「你怎么用我的服务」，又写了「我收集你哪些信息」，结果两边都不合格。审批被法务打回、应用商店上架被卡、用户投诉找不到依据，多半是这两份文档的边界没划清。这篇给一套功能对照、拆分手顺和自查清单，让产品先写对、法务再改得动。
做产品文档最常见的卡点：一份协议里既写了「你怎么用我的服务」，又写了「我收集你哪些信息」，结果两边都不合格。审批被法务打回、应用商店上架被卡、用户投诉找不到依据，多半是这两份文档的边界没划清。这篇给一套功能对照、拆分手顺和自查清单，让产品先写对、法务再改得动。
要解决的核心不是「写多长」，而是「每句话该进哪份文档」。下面按功能归属、法律定位、拆分手顺、评审顺序四块讲，每块都尽量给可勾选的动作，而不是概念解释。
两份文档各自管什么
用户协议（服务条款）管的是双方的权利义务：能不能用、怎么用、禁止什么、违约怎么处理、争议去哪解决。它的对象是「使用行为」，主语通常是用户「不得」「应当」「同意」。隐私政策管的是个人信息处理：收哪些、为什么收、存多久、给不给第三方、用户怎么查改删，对象是「信息本身」，主语通常是平台「会收集」「会共享」「保留多久」。
判断归属可以用一个土办法：读这句话，是在约束人的动作，还是在描述数据怎么流动。约束动作的进用户协议，描述数据流动的进隐私政策。两份文档都可能被同一件事触发，比如风控封号会同时涉及行为约束和数据留存，但叙述角度不同：用户协议讲「什么情况会被封」，隐私政策讲「封号时相关数据会保留多久、是否用于申诉」。不要为了省事把同一段话同时抄进两份。
- 使用行为约束：账号注册规则、禁止行为、内容规范、费用与续费、终止与解约——归用户协议
- 责任与救济：免责范围、责任限制、违约处理、管辖与争议解决——归用户协议
- 个人信息处理：收集字段、使用目的、共享对象、跨境传输、留存期限——归隐私政策
- 用户权利：查询、更正、删除、注销、撤回同意、投诉渠道——归隐私政策
- 交叉内容：安全措施、未成年人保护、变更通知——两份都要提，但表述角度分开，且互相引用
为什么法律定位不一样
用户协议本质是合同，核心是双方意思表示和违约责任，出问题通常走合同纠纷路径；所以它可以约定管辖法院、责任上限、免责条件。隐私政策本质是告知与同意机制，核心是处理个人信息的合法性基础，重点在「有没有讲清楚、有没有真的这么做」。这意味着隐私政策的义务不能靠「最终解释权归我方」这类条款免掉，写了做不到反而更容易被认定为不实告知。
这也决定了改稿时的分工：用户协议里法务的裁量空间更大，可以谈商业条款；隐私政策里产品必须先给出事实，法务才能写表述。事实错了，措辞再严谨也没用。适用的例外要说清楚：如果产品或服务完全不接触个人信息，也不涉及账号体系，隐私政策可以极其简略甚至只剩一句引导；但只要碰了个人信息，无论规模多小都不能省。纯内部工具、不对外提供服务的场景，用户协议仍需要，隐私政策视是否处理个人信息而定。
| 对比维度 | 用户协议 | 隐私政策 |
|---|---|---|
| 管什么 | 使用行为与双方权利义务 | 个人信息的收集与处理 |
| 法律属性 | 合同，靠约定生效 | 告知与同意，靠事实与合法性基础生效 |
| 典型条款 | 禁止行为、费用、终止、责任、管辖 | 收集范围、用途、共享、留存、用户权利 |
| 写不实的后果 | 条款可能被认定无效 | 可能构成不实告知或违规处理 |
| 改稿主导方 | 法务主导，产品补充事实 | 产品先给事实，法务再定表述 |
涉及具体合规口径的边界，比如某类信息算不算敏感、第三方共享要披露到什么颗粒度，到站内安全与合规相关分区核对当期说明，不要拿旧版本或别家文档直接套用。
拆分手顺与分工清单
如果手上已经有一份混在一起的旧文档，先别急着删，按下面顺序拆。每一步都要有可验证的产出物，不然只是把文字搬来搬去。
- 第一步：逐段打标把现有文档每段标成 A 类（使用规则、费用、终止、责任）或 B 类（收集范围、用途、共享、留存、用户权利）。标完统计一下，哪类占比明显偏低，通常就是被另一份吃掉的内容。
- 第二步：找交叉点做互引用户协议里写「数据处理方式见隐私政策」，隐私政策里写「服务使用规则见用户协议」。两边重复抄同一段是返工的主要来源，互相引用能直接消掉。
- 第三步：产品列事实，法务写表述产品出一张「功能—数据」映射表：功能名、涉及哪些字段、存哪、给谁、留多久、用户怎么删。法务基于这张表写隐私政策，不要反过来让法务猜系统里有什么。
- 第四步：上线前跑一致性核对文档里写了的功能，系统里是否真的有对应开关、删除入口和日志留存。写了「可随时注销」但产品没做入口，就是承诺无法履行，这是最常见的被打回原因。
- 第五步：归档版本与生效时间每份文档留一份版本记录：改了哪几个功能、对应哪次发版、旧版本存哪。出问题时能拿出「当时生效的是哪一版」，比事后解释有用得多。
分工建议：产品出「功能—数据」映射表，法务出条款，运营负责版本与生效时间记录。三方各管一段，别让一个人从头写到尾，否则事实和表述必然互相将就。
评审顺序与常见返工点
推荐顺序是：先定数据事实，再写隐私政策骨架，然后写用户协议条款，再做双向互引，最后归档版本与生效时间。这个顺序的原因是隐私政策依赖系统事实，而用户协议依赖商业规则，先做依赖外部事实的那份，返工最少。
- 隐私政策里写了「可随时注销」，但产品没做注销入口——承诺无法履行，评审必打回
- 用户协议里塞了大段信息收集说明，导致隐私政策被认定不完整——该拆走的内容没拆走
- 改了功能没改文档，版本号没更新——出问题时拿不出对应版本，责任说不清
- 两份文档对同一件事的表述不一致，比如留存期限一处写一套——用户投诉时会成为把柄
- 只改一份没同步另一份的互引链接——点了跳不到对应段落，等于没引
其中第一、二、四条是返工最多的。排查时建议让非文档作者的人拿真实账号走一遍：能不能找到注销入口、能不能导出数据、能不能联系到投诉渠道。走不通的地方，就是文档和系统对不上的地方。
涉及第三方服务的计价与额度口径这类数字，不要凭记忆写进文档，到 /official-api 核对当时的数字再引用。涉及具体合规表述的边界，参考 /safety 分区的其它文档，不要跨区抄结论。
下一步把手上两份文档按上面的对照表过一遍，找出被放错位置的内容。还可以到工具目录里找文档管理和版本记录相关的工具，顺手把归档流程固定下来。→常见问题
能不能把隐私政策和用户协议写成一份？
技术上可以合并成一个页面，但内容必须分块且标题清晰，分别回答「使用规则」和「信息处理」两类问题。真正的风险不在合不合并，而在有没有把个人信息处理讲清楚。如果合并后信息处理部分被使用条款淹没、用户找不到，反而更容易被认定为告知不充分。
两份文档哪个必须先给用户看？
顺序上通常先展示用户协议再展示隐私政策，因为同意使用服务是前提。但隐私政策的同意必须是独立、主动的动作，不能靠「继续使用即视为同意」一笔带过，尤其是涉及敏感信息或第三方共享时。注册页把两个勾选框分开，是最省事的做法。
改了功能之后，两份文档谁先改？
先改隐私政策，因为信息处理范围变化是实质性的，晚改会造成「实际做法与告知不一致」。改完再同步用户协议里的相关引用。每次改动留版本号和生效时间，旧版本留存备查，不要直接覆盖线上文本。
