使用方法
- 先填三个身份字段：名称、运营主体全称、隐私联系邮箱。运营主体须与备案或营业执照一致，不能写品牌简称。
- 选业务类型：网站、App、电商三选一，它决定第二节末尾追加哪段专属说明——网站写访问日志与第一方 Cookie，App 写系统权限与第三方 SDK，电商写订单、支付与物流配送。
- 选适用法域：中国大陆引用三法，欧盟引用 GDPR 与第 15 至 22 条权利清单，全球通用同时参照两套要求。
- 在信息类型里勾你真在收集的项，共 5 类，默认勾前 3 类。全部不勾时第二节会降级成「不主动收集」声明。
- 拨动条款开关：用不用 Cookie、会不会与第三方共享。关掉后对应章节改写成否定声明，而不是整节消失。
- 填生效日期；它出现在正文头部，也是日后改版时唯一要同步更新的时间戳。
- 点「生成隐私政策」或在单行输入框里按 Enter；结果写入下方文本框，同时刷新统计条与必含条款自检。
- 「复制全文」带走正文，「下载 .txt」存成 UTF-8 文件，「重置为默认示例」恢复全部字段。
这个隐私政策生成器能解决什么问题
一是解决「不知道写哪几条」的起步问题。隐私政策有一份事实上的骨架：收集范围、使用目的、Cookie、第三方共享、存储与保护、用户权利、未成年人、更新机制、联系方式。这个隐私政策生成器把十个章节一次铺开，你只需回答「我收集了什么、共享给谁」。
二是把业务形态的差异落到文字上。三种形态差别很具体：App 会申请系统权限、集成推送与统计 SDK；电商要把收货信息交给物流、把支付交给持牌机构。工具按业务类型追加对应的 44～71 个汉字说明段，避免拿一份通用模板套三种形态。
三是用自检挡住最常见的遗漏。实务中被点名最多的是「没有告知第三方共享」和「没提供联系方式与权利行使渠道」。工具固定检查五类必含条款，缺哪条直接标出。
四是给法务评审一个能改的底稿。示例默认口径输出 652 个汉字、10 个章节，结构完整、条款位置正确，律师只需删改与业务不符的句子。
本页不做这些事：不判断你的数据处理活动是否合法、不生成用户协议与 Cookie 弹窗文案、不做多语言版本、不代替律师出具意见。要单独起草 Cookie 声明请用页面底部的「Cookie政策生成器」，要写服务条款与退款规则请分别用「服务条款服务生成器」和「退款政策生成器」。
生成原理：三段式拼接、条款开关与汉字计数
整个生成过程是一条字符串流水线，没有模板引擎。正文分三部分：头部四行（名称、运营主体、生效日期、业务类型）、十个章节、尾部声明。章节由字符串累加拼出，每节之间统一插入一个空行，所以段落结构与章节数固定，不会多也不会少。
业务类型走查表，不堆条件分支。三种业务各对应一段专属说明，存在以 website / app / ecommerce 为键的对象里，生成时按键取值追加到第二节末尾。查表的好处是新增业务形态只加一个键，不改拼装逻辑。实测网站版 652 个汉字、App 版 677 个、电商版 666 个——三版只差那一段，其余九节逐字相同。
条款开关改写整节措辞，而不是隐藏整节。关掉 Cookie 开关后第四节仍然存在，但正文从「必要 Cookie 无法关闭」改成「本服务不使用 Cookie 或同类追踪技术」。理由是：「不使用 Cookie」本身也是必须告知的信息，直接删掉整节，读者无法区分「你没收集」和「你忘了写」。第五节的第三方共享同理，关闭时输出正向的否定声明。
勾选直接决定第二节的列举。5 类信息各对应一句，按固定顺序（账号、联系方式、设备、位置、支付）用中文分号连接。顺序固定是有意的：同一家公司不同时期生成的版本条款顺序一致，便于法务做版本比对。实测勾 0 到 5 类时全文汉字依次为 600、616、632、652、670、689。
法域只替换一句话。差异集中在头部「依据某某法规制定」那句：中国大陆版 31 个汉字，欧盟版 29 个，全球通用版 37 个。整篇因此分别落在 652、650、658 个汉字——差距不到 1.5%，换法域只改依据措辞，不改变条款结构。
统计口径。汉字数用 /[\u4e00-\u9fff]/g 匹配 CJK 基本区，标点、数字与英文字母不计（HTTPS/TLS、15 都不算）；总字符数按 String.length 的 UTF-16 码元计，含换行；行数按 \n 切分。这就是默认结果 854 个字符里只有 652 个汉字的原因。
完整示例（数值仅作演示）
示例条件与页面默认值完全一致：柳泉商城 / 网站 / 中国大陆 / 勾账号+联系+设备三类 / 开 Cookie / 开第三方共享 / 生效日期 2026-10-01。实测：汉字数 652、总字符数 854、行数 38、章节数 10，五类必含条款自检 5/5 全部命中。
切换业务类型时，网站 652、App 677、电商 666 个汉字；切换法域时，中国大陆 652、欧盟 GDPR 650、全球通用 658 个汉字。把信息类型从 0 类勾到 5 类，正文长度单调增加，章节数始终是 10：
| 勾选的信息类型 | 第二节写法 | 全文汉字数 |
|---|---|---|
| 一类都不勾 | 降级为「不主动收集可识别身份的信息」 | 600 |
| 仅账号信息 | 列举 1 句 | 616 |
| 账号 + 联系方式 | 列举 2 句 | 632 |
| 账号 + 联系 + 设备（默认） | 列举 3 句 | 652 |
| 再加位置信息 | 列举 4 句 | 670 |
| 五类全勾 | 列举 5 句 | 689 |
默认口径生成的完整正文就在上方输出框里，共 10 节；尾部固定带这句声明：「本政策由模板拼接生成，仅供起草参考，不构成法律意见，也不替代专业律师出具的合规文件。」
输入范围与条款对照表
每个控件的范围与越界动作如下：
| 控件 | 允许范围 | 越界/填错的动作 |
|---|---|---|
| 名称 | 1～30 字符，必填 | 拒绝生成，提示填备案全称或产品全名 |
| 运营主体 | 1～50 字符，必填 | 拒绝生成，提示须与营业执照一致 |
| 联系邮箱 | 须形如 name@example.com | 拒绝生成，回显你填错的内容 |
| 业务类型 / 法域 | 各三个固定选项 | 下拉选择，不存在非法值 |
| 生效日期 | 2020-01-01 ～ 2099-12-31 | 拒绝生成，提示年份需在区间内 |
| 信息类型 | 5 类可任意多选，可全不选 | 全不选不报错，第二节降级 |
| Cookie / 第三方共享 | 开关二值 | 关闭时改写整节措辞，不删章节 |
下表列出隐私政策最常见的 16 类条款、本工具把它们放在第几节、是否必含，以及缺失时的典型风险。点「加载更多」逐条展开，点「复制对照表」以 TSV 格式带走。
| 条款 | 本工具章节 | 是否必含 | 缺失时的典型风险 |
|---|---|---|---|
| 政策适用范围 | 一、适用范围 | 必含 | 读者无法判断是否适用自己 |
| 收集信息类型 | 二、我们收集的信息 | 必含 | 被认定为超范围收集 |
| 业务专属说明 | 二（按业务类型追加） | 必含 | App 权限、电商配送信息未告知 |
| 使用目的 | 三、使用目的 | 必含 | 无法证明目的正当性 |
| Cookie 与同类技术 | 四、Cookie 与同类技术 | 必含 | 未提供同意与拒绝入口 |
| SDK 与第三方共享 | 五、共享、转让与公开披露 | 必含 | 最常见被点名项 |
| 跨境传输 | 六、信息的存储与保护 | 按需 | 有海外服务器却未声明 |
| 存储期限 | 六、信息的存储与保护 | 必含 | 被认定过度留存 |
| 安全措施 | 六、信息的存储与保护 | 必含 | 泄露事件中难以自证已尽责 |
| 访问与复制权 | 七、您的权利 | 必含 | 权利行使渠道缺失 |
| 更正与删除权 | 七、您的权利 | 必含 | 权利行使渠道缺失 |
| 撤回同意与注销 | 七、您的权利 | 必含 | 无法退出，用户投诉集中 |
| 投诉与申诉渠道 | 七、您的权利 / 十、联系我们 | 必含 | 缺少救济途径说明 |
| 未成年人保护 | 八、未成年人保护 | 必含 | 14 周岁以下用户无专门规则 |
| 政策更新机制 | 九、本政策的更新 | 必含 | 改版后无留痕、无提示 |
| 联系方式与生效日期 | 十、联系我们 / 头部 | 必含 | 监管无法联系到运营方 |
结果边界、免责声明与使用须知
- 生成的是草稿，不是合规结论。工具只做文字拼装，不检查你的实际数据处理活动，也不判断某条款在你所在司法辖区是否成立。正式发布前必须经过法律审核，这句声明写在结果末尾，也写在控件上方。
- 章节数固定为 10，不因少填字段而减少。缺字段只让对应章节降级措辞，不会整节消失——空章节会让读者误以为漏写。
- 全文长度落在 600～689 个汉字之间（默认组合 652），区间外的差异只可能来自你替换名称、主体、邮箱三个自由字段。长度不代表合规质量——短不等于漏，长也不等于全。
- 「15 个工作日」是写死的答复时限。《个人信息保护法》第五十条要求及时处理但未规定天数，15 个工作日是业界通行的承诺口径；若你所在地区的监管指引另有要求，请在评审时替换。
- 「不满 14 周岁」阈值取自《个人信息保护法》第三十一条：不满十四周岁未成年人的个人信息属敏感个人信息，须取得监护人同意。GDPR 默认门槛是 16 岁、成员国可下调至 13 岁。
- 法域选择只改依据措辞。选「全球通用」不会自动生成双语版本，也不代表同时满足两套法规的全部要求，只是把两套依据都写进开头那句。
- 不支持撤销。生成过程不写浏览器存储、不发任何请求，刷新后选项回到默认值；改完字段请先复制或下载再刷新。
常见问题
生成的隐私政策能直接发布上线吗？
不能直接发。它是结构完整、条款位置正确的草稿，用来降低你和律师从零起草的成本。发布前至少核对三件事：列举的信息类型与你实际收集的是否一一对应；第五节写的合作方类型是否覆盖真实接入的服务；15 个工作日的答复时限与你内部流程是否匹配。
网站、App、电商三套模板到底差在哪？
只差第二节末尾那段业务专属说明，网站版 44 个汉字、App 版 71 个、电商版 58 个。网站版写访问日志与第一方 Cookie；App 版写相机、相册、麦克风、位置等系统权限与推送统计 SDK；电商版写收货信息共享给物流、支付由持牌机构处理。其余九节三版逐字相同。
为什么关掉 Cookie 开关，第四节还在？
因为「不使用 Cookie」也是一条必须告知的信息。直接删掉整节，读者无法分辨你是真的没收集，还是忘了写。保留章节并改写措辞，能让这份政策在不使用 Cookie 的场景下依然完整——这也是开关被设计成「改写」而不是「删除」的原因。
选了「欧盟 GDPR」和「中国大陆」有什么实际区别？
目前只差开头那句依据。中国大陆版引用《个人信息保护法》《网络安全法》《数据安全法》，欧盟版引用 GDPR 并点名第 15 至 22 条的数据主体权利。全文分别是 652 与 650 个汉字，结构完全一致。真正的差异（数据出境机制、数据保护官任命、未成年人门槛）需要律师按具体业务补写。
五条必含条款里的「用户权利」具体指哪些权利？
第七节列出访问、更正、复制、删除、撤回同意、注销账号和投诉七类请求。对应《个人信息保护法》第四章赋予个人的权利，以及 GDPR 第 15 至 22 条的查阅、更正、删除、限制处理、数据可携、反对等权利。勾选欧盟法域时，开头依据句会把这些条号一并点明。
生效日期填错或以后政策改版了怎么办？
生效日期只影响正文头部那一行，改完重新生成、重新发布即可。改版还要额外做两件事：保留「历史版本」入口，以及在涉及重大变更时单独提示用户——这两项工具不做，属于你的上线流程，第九节的更新条款已经写明了这类提示义务。
不勾任何信息收集项，政策会变成什么样？
第二节会从列举式降级成「我们目前不主动收集可识别到您个人身份的信息」，后面仍接业务专属说明，全文缩短到 600 个汉字，十个章节一个不少。但只要用了统计脚本、接了客服系统，就几乎不可能真的「不收集」，勾选时请按实际情况来。
为什么政策里反复出现「15 个工作日」？
它出现在第七节（权利请求答复）和第十节（联系方式答复）两处，是同一套承诺时限。《个人信息保护法》第五十条要求建立便捷的个人权利申请受理机制并及时处理，但没有规定具体天数；15 个工作日是行业习惯写法。做不到就请改成能兑现的数字。
相关工具
- Cookie政策生成器：单独起草 Cookie 与同类技术的告知声明，可与本页第四节配合使用。
- 服务条款服务生成器：生成用户协议与服务条款，与隐私政策一起构成站点的基础法律文本。
- 退款政策生成器：电商站点常与隐私政策同时发布，退款规则单独成文更清楚。
- Disclaimer生成器：生成免责声明，用于内容站的专业建议免责条款。
- 保密协议生成器：与合作方签署时使用的保密条款文本。
- 租赁合同协议生成器：结构化字段拼装合同条款，录入思路与本页一致。
- SEO与营销：查看全部 SEO 与营销工具。