用户协议和隐私政策模板怎么写

自己做小程序或 App 的开发者，多半卡在同一个地方：协议从网上抄一版，业务逻辑却跟它写的不一样，用户来要求更正个人信息时又不知道怎么接。这篇不谈法律结论，只讲模板结构怎么搭、更正与删除条款怎么写才不空、提交审核前该逐条对什么，最后给一份可以照着打勾的清单。

自己做小程序或 App 的开发者，多半卡在同一个地方：协议从网上抄一版，业务逻辑却跟它写的不一样。用户来要求更正个人信息时，你不知道该让他提交什么、多久回复、回复不了怎么说。这篇不谈法律结论，只讲模板怎么搭、更正与删除条款怎么写才不空、提交审核前逐条对什么。

整篇按「先分两份文件 → 搭骨架 → 写收集清单 → 写更正删除 → 写更新与同意 → 补小程序场景 → 上线前自查」的顺序走。你可以把它当成一份写作流程单，一边写一边打勾。具体到价格、费率这类数字，本文一律不写，需要时去站内对应页面看当时的口径。

先分清两份文件各写什么，别混成一锅

用户协议管的是「你和我之间的交易与使用关系」，隐私政策管的是「我怎么处理你的个人信息」。这两件事的读者、审核路径、被追问的角度都不一样。混写最直接的后果是：用户找退款规则翻到了数据留存章节，审核方找收集清单翻到了责任限制条款，双方都找不到重点。

用户协议

账号规则、付费与退款、内容归属、责任边界、终止条件

隐私政策

收集哪些信息、为什么收、给谁看、存多久、用户怎么行使权利

两份文件可以互相引用，比如用户协议里写「个人信息处理详见隐私政策」，隐私政策里写「账号注销流程见用户协议第几节」。但引用只是指路，不能拿引用代替正文。判断标准很简单：把两份文件分别给一个陌生用户看，他能不能各找到自己关心的那件事。什么情况下不适用：如果你的产品完全不收集个人信息、也不做账号体系，重心就是用户协议；但隐私政策里仍要写清「不收集」这件事本身，而不是干脆不写。

• 写之前先列一张表，左边写「用户会关心的问题」，右边写「这个问题归哪份文件」，归错行的挪过去
• 个人信息处理事项一律只出现在隐私政策，用户协议里最多留一句指路
• 退款、发票、违约责任这类交易规则只出现在用户协议，别塞进隐私政策
• 两份文件里的产品名、公司名、联系方式保持完全一致，避免出现两个主体
• 协议类文章的整体分工可以去 站内 /safety 安全与合规 分区看，别自己重复造轮子

模板骨架：按这个顺序写，改起来最省事

骨架的价值不在于好看，而在于换产品、加功能时你知道该改哪一节。建议开头固定三段：生效说明与更新方式、适用范围（哪几个端、哪几个产品）、定义表。定义表先写，把「个人信息」「去标识化」「账号」「关联方」这类词定义死，后面全篇复用，能省掉大量重复解释。

把公司名、产品名、联系方式、生效方式抽成变量，换产品时只改变量。但有一类东西绝对不能做成变量：收集清单。它必须逐项对照真实代码里的埋点和依赖清单，写一次对一次。骨架里最容易被写虚的是「责任限制」和「你的权利」两节，前者容易写成大段免责声明，后者容易写成「您有权……」，两节都要按上面的三段句式重写一遍。

1. 第一步：先列目录把两份文件的章节标题先列出来，不写内容，只看顺序合不合理，有没有哪节其实该合并
2. 第二步：填定义把全篇会反复出现的名词抽出来定义，写完后通篇搜一遍，看还有没有没定义的词
3. 第三步：抽变量把主体信息、联系方式、生效方式抽成变量，标出哪些地方是每版必改的
4. 第四步：留骨架再填肉骨架定稿后再往里填业务细节，避免边写边改结构导致前后引用错乱

收集清单是审核最爱挑的地方，写法要对齐代码

收集清单不要写成一段话，写成表格最省事。每一行五列：信息类型、具体字段举例、收集时机、用途、能否拒绝及拒绝后的后果。缺任何一列都会留下追问空间。写完后拿真机把每个授权弹窗跑一遍，弹窗里出现的每一项，都要能在清单里找到对应行。

第三方依赖要单独列一节：名称、收集的信息类型、用途，并说明其隐私政策在你的协议里怎么被引用。不要笼统写「为提升服务体验可能会接入第三方」。最容易漏的三类：设备标识与日志、剪贴板读取、相册与位置权限。什么情况下不适用：纯服务端调用的 API 类产品没有客户端权限，但仍要写清楚请求内容和日志是否入库、存多久。

个人信息更正与删除条款：写成能执行的动作，不写成表态

更正条款最低限度要写四件事：入口在哪、要提交什么、多久内处理完毕、处理不了时怎么答复。只写「您有权要求更正」等于没写，因为用户看完还是不知道该点哪里。把入口写成具体路径，比如「个人中心 → 账号与安全 → 资料更正」，比写「可通过客服申请」有用得多。

• 更正（改错）：写清提交字段、身份核验方式、处理时限、答复渠道
• 补充（漏项）：说明哪些信息用户可自行补充，哪些需要人工核验后补充
• 删除（含撤回同意后的处理）：说明删除范围、执行时限、删除后是否有残留副本
• 例外情况：因法定义务需要保留的数据，要写保留范围、保留期内如何隔离、到期后怎么处理
• 账号注销单列一节，并与删除条款交叉引用，写清哪些删、哪些留存、能否恢复

更正申请模板（可直接放进协议附录）：
申请人：
账号标识（手机号/用户 ID）：
需要更正的字段：
当前显示值 / 更正后应为：
可证明该信息的材料（如有）：
联系邮箱或手机号：
期望答复时间：

给一个可复制的申请模板能明显减少来回沟通，用户一次给全，你也能判断该走哪条处理路径。判断标准是：把这份模板交给一个没接触过你产品的人，他能不能独立填完并提交。填不完说明字段设计有问题，回去改。

更新与同意提示：改了之后怎么让用户重新确认

先区分三种变更。错别字与格式调整不用通知；收集范围、共享对象、用途变化属于重大变更，必须重新取得同意；仅联系方式变化走公告即可。这个分类要先定义在协议里，否则每次更新你都要重新讨论一遍该不该弹窗。

1. 判断变更级别对照上面的三分类，落到哪一类就按哪一类的流程走，不要凭感觉
2. 重大变更的动作站内弹窗 + 显著位置公示 + 说明新旧差异；用户不接受时给出注销账号或停止使用的路径
3. 保留历史版本每次更新留一份带版本标识的存档，注明生效时间，用户有争议时能拿出他当时同意的那一版
4. 验证可回查随机抽几个账号，确认能查到其同意记录对应的是哪个版本

不要只写一句「继续使用视为同意」就完事。这种写法在用户不接受变更时没有出口，等于把矛盾推到后面。同意提示具体怎么写，可参考 站内 /guides/consent-notice-drafting 服务条款和隐私政策的同意提示怎么写，这里不重复。需要看同类协议更新节奏的，可以去 /guides 指南中心翻协议类文章。

微信小程序场景要额外补的几块

小程序有平台侧的用户隐私保护指引，和站内隐私政策是两套东西。指引里勾选的收集项必须与协议正文一致，不一致时按更严格的一方执行。写的时候把两份并排放在一起，逐项对勾，比凭记忆检查靠谱。

• 补一节说明平台内的信息如何流转：登录态、手机号授权、支付、订阅消息、客服会话，各自获取什么、存到哪
• 协议链接填到后台后，确认可公开访问、不需要登录、移动端能正常打开；链接失效是最常见的驳回理由
• 收集项在指引和协议里用词保持一致，避免一处写「手机号」一处写「联系方式」
• 平台侧权限变化后同步更新协议，别只改指引不改正文

这类条目怎么逐项补，可对照 站内 /guides/miniprogram-privacy-guide-checklist 小程序用户隐私保护指引怎么完善 的清单。如果你的小程序还接了第三方登录或支付，建议在「共享与委托」一节单列这些场景，写清共享的对象类型和用途，而不是笼统一句「为完成交易所必需」。

提交前自查清单：按这个顺序过一遍

自查的顺序有讲究：先对事实，再对可执行性，然后对措辞，最后对留证。反过来做的话，你会在措辞上花很多时间，最后发现收集清单里漏了一整个依赖。

• 删掉协议里写了但产品根本没做的功能承诺，这是审核和纠纷里最常见的问题
• 四条用户权利路径全部实跑一遍，走不通就先修产品再改协议
• 检查有没有把「可能收集」写进必然收集的章节，或反过来
• 确认协议链接、客服入口、投诉入口在小程序内都能点开
• 把这次自查的版本号和检查人记下来，下次更新有对照

留证这块，出事后的材料组织方式见 站内 /guides/dispute-evidence-keep 出事后的举证与维权。上线前整体风险再跑一遍 站内 /guides/prelaunch-security-checklist 上线前安全自查 15 项，协议只是其中一环，别指望靠协议兜住产品本身的问题。

协议写得再漂亮，也替代不了产品真的按它执行。用户来更正信息时你接不住，条文就是摆设。