写隐私政策时最常见的卡点不是不会写，而是不知道写全了没有：采集了什么、给谁看、存多久、用户怎么注销、出了事找谁，这些栏目漏一条就可能被应用市场打回或被审出问题。这篇给一份按章节拆开的内容清单，配套一份改版自查顺序和几类容易写错的边界说明，让你在写之前先把栏目补齐，再逐条填内容。
写隐私政策时最常见的卡点不是不会写，而是不知道写全了没有。采集了什么、给谁看、存多久、用户怎么注销、出了事找谁，这些栏目漏一条就可能被应用市场打回，或者在合规审查里被挑出来返工。所以更稳的顺序是先把栏目补齐，再逐条填内容，而不是打开一份模板从头往下填。
下面这份清单按章节拆开，可以直接当作逐项打勾的核对表。每条都说清判断标准和该做什么动作，也标了什么场景下不适用。需要注意的是，监管口径和渠道审核要求会变，具体表述以站内页面当时的内容为准，不要拿旧稿直接复用。
一、先对齐：哪些栏目属于必备，哪些属于看情况
必备和看情况要分开对待。必备栏目少了就是硬伤，看情况的栏目硬凑反而会让政策变长、重点被稀释，用户和审核都抓不到关键。判断标准很简单：有没有对应场景，有就写，没有就不写，别为了显得周全堆段落。
- 必备栏目一般绕不开这几块：处理者身份与联系方式、收集的个人信息种类与用途、共享与委托处理情况、存储期限与存放地点、用户权利与行使方式、未成年人条款、政策更新机制；
- 看情况的栏目：涉及跨境传输、自动化决策、敏感个人信息、第三方 SDK 时，要单独加段落说明，没有这些场景就别硬凑；
- 谁适用看业务实际：只要面向境内用户提供产品或服务、并且处理了能对应到自然人的信息，基本都落在范围内，具体口径可到 /safety 看当时的说明；
- 不适用的情况：纯内部工具、不采集任何可识别信息、也不接第三方统计的，可以只留一句极简声明，但要有证据说明确实没采集。
二、动笔顺序：按数据流走一遍，比按模板抄更省事
模板是从别人的业务里长出来的，栏目顺序未必匹配你的产品。按数据流走一遍，你会发现哪些字段其实早该删、哪些共享关系根本没写进旧稿。产出一份字段清单后，再回来写政策，返工次数会明显少。
- 画数据流从用户第一次打开、注册、下单到退出，标出每一步采集了什么字段、存在哪张表、谁会读到。动作产出是一张字段到用途的对照表。
- 定口径每个字段写清收集目的，比如「用于账号登录」而不是「用于优化体验」这种含糊说法；没有实际用途的字段先删掉，再动笔写政策。
- 填共享列出所有会接触数据的第三方，包括统计、推送、支付、客服系统，逐个写成一段，写清共享的信息类型和目的。
- 定更新与撤回机制写清政策改了怎么通知、用户怎么撤回同意、撤回之后哪些功能会受影响，别只写「可以撤回」却不写后果。
三、交稿前自查：一张逐项打勾表
交稿前最好换个人来核对，写的人容易对自己写的内容产生盲区。下面这张表可以按行打勾，任何一行对不上就先改产品或者改描述，不要留到上线后再补。
| 核对项 | 判断标准 | 不通过怎么处理 |
|---|---|---|
| 身份与联系方式 | 有没有能真正联系到人的邮箱或表单，而不是只有一个网页地址 | 补一个可用的联系渠道并说明响应方式 |
| 收集范围 | 政策里写的字段和产品实际采集的字段能否一一对上 | 对不上就先改产品，再改政策表述 |
| 用户权利 | 查询、更正、删除、注销、撤回同意、投诉六项有没有写清入口和响应时限 | 逐项补入口位置与处理时长 |
| 存储与删除 | 有没有写清存多久、到期怎么处理、注销后多久清干净 | 按实际流程写，别写模糊表述 |
| 未成年人 | 有没有年龄提示与监护人同意路径 | 做儿童向产品的要单独加一段 |
这张表里的「响应时限」这类数值不要照抄网上的说法，按你团队实际能做到的写。写不出来的项往往说明内部流程还没定，那就先定流程，政策只是流程的书面投影。
四、最容易写错的几处，改稿时重点盯
复审时按下面几条扫一遍，通常能捞出一半以上的问题。这几条不是文字润色问题，而是会让声明和实际功能对不上，属于实质性风险。
- 堆术语不落地：满篇「可能」「为了提供更好的服务」，用户看不出到底拿了他的什么数据；
- 一稿通吃：App、小程序、网页端采集范围不同却共用一份政策，声明和实际功能对不上；
- 更新只改日期：内容变了但没写变更说明，也没给用户重新确认的入口；
- 把安全和隐私混为一谈：两者关注点不同，政策里混着写会让读者找不到重点，条款怎么分工可看 /ai-nav/category/ai-legal 里的工具思路，概念差别可参照 /ai-dict/category/safety 的分类。
「一稿通吃」这条最常被忽略，尤其是多端产品。各端采集的字段、调用的第三方往往不一样，共用一份政策的代价是每一端都有一半内容对不上。真要共用，至少要在开头说明适用范围和差异点。
五、定稿后怎么和条款、模板配合
政策定稿不是终点，它还要和用户协议、渠道模板、版本记录配合。这几样东西各管一段，互相塞内容会让读者和审核都绕晕。配合关系理顺了，后续改版也更容易控制影响面。
- 隐私政策
- 管数据怎么被处理：收什么、为什么收、给谁、存多久、用户有什么权利
- 用户协议
- 管你我能做什么：账号规则、使用限制、责任边界，不要把数据条款塞进去
- 渠道模板
- 各应用市场或平台给的填写模板，栏目结构可能不同，以当时的页面要求为准
- 版本记录
- 改了什么、为什么改、哪天生效，出问题时这是最直接的证据链
用模板填内容之前，先确认模板的栏目结构和你所在渠道的审核要求是否一致，渠道要求会变，以当时页面为准。改版之后保留版本记录，改动越大越要写清变更说明和用户重新确认的方式。
政策写得再长，只要有一栏和产品实际对不上，这一栏就是无效的。下一步把这份清单转成你自己的核对表之前，先到站内把现行的合规模块和价格、模型资料一起看一遍，确认口径没有过时，再动笔改稿。→
常见问题
隐私政策必须写全所有栏目吗？
不是越多越好，而是你实际做了的事都得写清楚。写了不做的叫虚假告知，做了不写的叫未告知处理，两者都算问题。判断标准是政策和产品实际的数据处理动作能不能一一对上，对不上的先改产品再改文档，而不是靠加一段免责话绕过去。
只有几个人的小团队也要写吗？
只要对外提供产品或服务、处理了能对应到个人的信息，规模大小不影响要不要写这个结论，只影响你写多细。小团队最容易走的捷径是套模板，但模板里的采集字段往往和你实际用的对不上，建议先把自己的字段列一遍，再决定删哪些。
政策改了要重新让用户同意吗？
看改动幅度。改了收集范围、用途、共享对象这类实质内容，一般需要重新提示并取得同意；只改联系方式、错别字这类非实质内容，做好变更说明并公示即可。拿不准时按更严的一档处理，把重新确认入口做出来成本并不高。
