写隐私政策最容易卡在两个地方：一是不知道该收哪些条款，二是抄了模板却和自己的数据流对不上。这篇按「收集—使用—共享—留存—用户权利」的顺序，把一份能落地的隐私政策该包含的核心条款逐条拆开，附上自查动作和易漏项，适合产品、法务在版本更新或新功能上线前对照使用。
写隐私政策最容易卡在两个地方：一是不知道该收哪些条款，二是抄了模板却和自己的数据流对不上。模板能给你框架，但填不出你家产品到底收了多少字段、数据在链路上经过谁。所以更靠谱的顺序是先把数据流摊开，再逐条映射到条款。
下面按「收集—使用—共享—留存—用户权利」的顺序，把一份能落地的隐私政策该包含的核心条款逐条拆开，每节都给出写法要点和可执行的自查动作。适合产品、法务在版本更新或新功能上线前对照使用。注意这只是条款清单，不是法律意见；涉及跨境、特定行业的合规要求，仍需按当地法规单独确认。
先写清适用范围和收哪些数据
适用范围是第一段就要交代的边界：政策覆盖哪些产品、站点、App 与子服务，以及不覆盖哪些第三方跳转页面。很多人把这条当客套话跳过，结果后面所有承诺都会被追问「那这个页面算不算」。判断标准很简单：用户从你这条链路走出去之后的页面，原则上都不在你承诺范围内，但要在文里明确说出来。
收集清单建议按固定分组来列，不要东一句西一句。常见分组是账号信息、设备与日志、使用行为、位置、支付、客服沟通。每一组都要写清收集目的、是否必填，以及不提供的后果——比如不填手机号就注册不了，这种后果必须提前说明，不能等用户卡在流程里才发现。
- 主动填写
- 用户自己输入的手机号、邮箱、昵称等，通常可以拒绝但会导致部分功能不可用
- 自动采集
- 设备型号、系统版本、IP、日志等，一般在服务运行过程中被动产生
- 第三方接入
- 通过第三方登录、支付、统计 SDK 回流的数据，要单独列出来源
不适用的情形也要写清楚：纯内部部署、不对外提供服务、或完全不采集个人信息的工具类页面，只保留最小声明即可，不必硬套完整条款。把不该写的写进去，反而会让读者以为你收了实际没收的数据。
使用目的、共享对象与留存期限
使用目的要具体到「用来做什么」，而不是「提升体验」这类空话。特别是涉及模型训练、二次利用、用户画像的场景，必须单独说明，并给出退出或拒绝的方式。判断标准是：如果用户看完这段只能得到一个模糊的好印象，那这段就没写到位。
| 条款 | 要写清什么 | 什么情况下可简化 |
|---|---|---|
| 使用目的 | 具体用途、是否用于训练、是否二次利用 | 不涉及训练与画像时可合并说明 |
| 共享与委托 | 接收方类型、共享目的、是否跨境 | 纯自建、无第三方时可只写内部访问 |
| 留存期限 | 期限口径或到期处理方式 | 写不出固定天数就写最短必要期限 |
| 安全措施 | 加密、访问控制、脱敏等实际做法 | 做法确无差别时可归并描述 |
共享与委托处理是最容易含糊的一段。要列出接收方类型、共享目的、是否跨境；涉及中转或第三方接口的，还要说清数据在链路上经过哪些角色。如果你用的是中转站，链路上多了第三方，这一点要在政策里体现，具体链路信息可以到 /sites 看各家说明，再决定哪些写进条款。
留存与删除写不出固定天数时，用「为实现目的所需的最短期限」这种口径是常见做法，但后面最好补一句到期后的处理方式，比如匿名化或删除。安全措施部分，日志脱敏、访问控制的描述要跟实际做法一致，可以对照 /log-redaction-retention 的脱敏口径确认日志侧对不对得上，写一套做一套是这类条款最常见的坑。
用户权利、未成年人与联系方式
用户权利清单至少覆盖查阅、更正、删除、撤回同意、注销账号、获取副本这几项，每一项都要写明申请入口和响应时限。只写「您可以联系我们」是不够的，得给出具体渠道，以及大概多久会回复。判断标准：随便找个同事按条款走一遍，能不能找到入口。
- 确认入口从 App 或站内帮助中心找查阅、删除、注销的入口，找不到说明条款和实现脱节
- 走一遍流程用一份真实测试数据依次执行查阅、删除、注销，记录每步实际耗时
- 比对时限把实际耗时和条款里承诺的响应时限对照，对不上的改条款或改流程
- 留档把这次走查的结果和日期留档，方便下次版本更新时对照
未成年人条款要区分你面向的是不是未成年人、是否需要监护人同意、发现误收集后怎么处理。如果产品本身不面向未成年人，也要写一句明确的态度，而不是完全留白。联系方式部分同样要给出有效渠道，并说明政策更新怎么通知、重大变更是否重新取得同意。
上线前的核对顺序与常见坑
核对顺序建议固定下来：先拉数据流清单，再把清单逐项映射到政策条款，最后检查条款措辞与产品实际行为是否一致。顺序反过来——先改文字再找数据——几乎一定会漏。这个顺序看起来慢，但返工少。
- Cookie 与同类技术：是否用了、用来做什么、用户怎么关
- SDK 清单：引入了哪些第三方 SDK，各自收什么、传去哪
- 自动化决策与画像：有没有做、依据是什么、能不能拒绝
- 第三方登录的回传数据：登录时对方会把你哪些信息回传
- 版本管理：保留历次版本与生效时间，标出变更点
版本管理这条常被忽略。保留历次版本和生效时间，说明每次变更了什么，出现争议时才能回看当时的承诺。想横向比较同类产品的写法，可以到 /tools 的工具目录里找对照；如果涉及 API 或中转链路上的数据处理，具体哪家怎么标、当时的说明是什么，到 /price-watch 核对当时的记录更稳妥，别凭印象写。
最后提醒一句不适用的情况：这份清单针对的是对外提供服务、会采集个人信息的产品。如果你做的是纯静态展示页、没有任何表单和统计脚本，条款可以压缩到最小；反过来，一旦接了支付、登录或统计，就要回到本文的顺序重新过一遍。
隐私政策不是写给监管看的作文，是用户和你的实现之间的对账单。下一步拿这份清单当核对表，先把你的数据流列出来，再逐条映射到政策条款；需要对照同类产品和服务链路时，去站点导航看当时的记录。→
常见问题
隐私政策必须包含哪些条款才算完整？
没有一份通用模板能覆盖所有业务。判断标准是：政策里出现的每一项承诺，都能在你的数据流里找到对应动作。最低限度要覆盖适用范围、收集清单与目的、共享与委托对象、留存与删除、用户权利与联系方式这几块；如果还涉及跨境、画像、未成年人，就要各自补一节。
从哪抄一份隐私政策模板比较省事？
模板只能当骨架，直接抄容易写出与自己实际行为不符的承诺，反而增加风险。更稳的做法是先整理自家数据流清单，再拿模板逐条对照删改，最后让实际走一遍查阅与注销流程的人确认。数据流向本身可以对照站内 /data-boundary-audit 的方法梳理链路。
隐私政策写好了，是不是就安全了？
不是。政策是对外承诺，真正的问题多出在实现侧：日志里带着明文、SDK 偷偷回传、删除请求没落地。写完政策只是起点，后面要按固定节奏做一次实现核对，重点看采集范围、留存期限和删除动作是否与条款一致。
