本文约 5,161 字，预计阅读 13 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：一键生成的三页政策里，写着别人家的公司名
“装个插件，三分钟生成隐私政策、服务条款、退货政策。”这类插件对新手站长极其友好，确实解决了”白纸不知如何下手”的问题。但我在给几个外贸客户做合规复核时，反复看到同样的问题：生成器不知道你的真实业务，它只会填预设的变量。
最典型的两类硬伤：一是责任主体不符——模板里写着”本协议由 XYZ Inc. 与您签订”，而变量没替换干净，站点已经上线半年还带着占位公司名；二是数据流向描述缺失——正文写了”我们可能向第三方共享数据”，但第三方是谁（支付网关？物流？广告平台？）、数据存哪国、保留多久，生成器一无所知，只能给一句含糊的模糊表述。而 GDPR 第 13 条明确要求披露接收方类别与跨境传输情况，模板的那句话在监管眼中等于没说。
WordPress 核心其实自带了一个更靠谱的工具：「设置 → 隐私」里的隐私政策向导，它会读取你站点实际注册的插件推荐文本，拼出贴合实际情况的草案。本文把两条路都讲清楚，并给一份必须人工修改的检查清单。
原理分析：模板生成器的六个结构性局限
| 局限 | 具体表现 | 后果 |
|---|---|---|
| 变量替换不全 | 公司名、邮箱、地址、司法管辖地留占位符 | 形同虚设，被投诉时直接认定无政策 |
| 与实际数据处理不符 | 说”不向第三方共享”，但实际用了 Stripe + PayPal + Google Ads | 虚假陈述，性质比没写更严重 |
| 缺乏具体服务清单 | 未列出实际使用的 cookie、SDK、SDK 收集项 | 与 Cookie banner 的实际清单不一致 |
| 区域适配错误 | 面向欧盟却用了加州风格的措辞：Missing “legal basis” | 不符合 GDPR art.13/14 |
| 不会自动更新 | 插件一年没更新，里面的法规引用已过期 | 引用已废止法规，例如 Privacy Shield 已失效 |
| 未成年人 / 特殊条款缺失 | 面向儿童、金融、医疗的产品有特殊要求 | 行业强制条款缺失 |
需要明确区分两类工具：
一类是 WordPress 核心自带的隐私向导（「设置 → 隐私 → 创建页面」）。它的机制是：每个合规的插件/主题可以通过 wp_add_privacy_policy_content() 钩子把自己的数据处理说明贡献出来，核心把这些片段拼成一份草案。这个机制的长处是实际、动态、与站点实际情况挂钩——你装了 WooCommerce、Contact Form 7，它们的处理说明才会出现。
另一类是第三方模板生成器：
- WP Legal Pages（WPEka，安装量 10 万+）：模板库丰富，覆盖 affiliate disclosure、GDPR cookie policy 等，但需仔细核对。
- Terms Feed / Iubenda / Termageddon：SaaS 形态的法律文本服务，质量最好、会随法规自动更新，但需要付费或按年订阅。
- Auto Terms of Service and Privacy Policy：免费，可实现一次性生成，更新维护比较冷淡。
理解区别之后，选型标准就清楚了：单页往往不够，最终的那份文档一定要人工核一遍。
保姆级实操
步骤 1：先用核心隐私向导生成基线
后台「设置 → 隐私」，把隐私政策页选为新建或已有页。然后「工具 → 站点健康 → 信息 → 隐私」可以看到后台有哪些插件注册了推荐文本。核心 API 长这样（插件开发者应实现它）：
/**
* 插件侧：向 WordPress 隐私政策向导贡献本插件的数据处理说明
*/
function mf_plugin_privacy_policy_content() {
if ( ! function_exists( 'wp_add_privacy_policy_content' ) ) {
return;
}
$content = sprintf(
'<h3>%s</h3><p class="privacy-policy-tutorial">%s</p>',
__( '我们收集的评论数据', 'mf' ),
__( '当您在本站发表评论时，我们会收集评论表单中显示的数据，以及您的 IP 地址和浏览器 User-Agent 字符串，用于垃圾评论检测。', 'mf' )
);
wp_add_privacy_policy_content( 'MF 评论增强', $content );
}
add_action( 'admin_init', 'mf_plugin_privacy_policy_content' );
生成后，核心会在该草案变更时提示「需要更新隐私政策」，这是第三方生成器不具备的能力。
步骤 2：对照实际第三方服务，手工补齐清单
这是生成器永远做不到的部分。列一张表，逐项核对：
| 服务 | 类型 | 收集内容 | 传输地 | 政策链接 |
|---|---|---|---|---|
| Google Analytics 4 | 分析 | 匿名 ID、事件 | 美国 | policies.google.com/privacy |
| Stripe | 支付 | 卡号（经 PCI 渠道）、账单地址 | 美国/爱尔兰 | stripe.com/privacy |
| PayPal | 支付 | 交易信息 | 美国 | paypal.com/privacy |
| 阿里云短信 | 通知 | 手机号 | 中国境内 | 自有政策 |
这张表既要体现到隐私政策正文里，也要和 Cookie banner 的分类清单、以及 Feedback、SDK 一致。三者不一致是审计时最容易被挑出的问题。
步骤 3：WordPress 内置的数据导出 / 删除功能要保证可用
这是「工具 → 导出个人数据」与「工具 → 清除个人数据」，它依赖注册的 exporter/eraser。隐私政策里承诺了用户可以导出数据，就必须真的能导出。检查一下：
# 查看站点已注册的个人数据导出器与擦除器（需安装 WP-CLI）
wp eval "print_r( array_keys( apply_filters( 'wp_privacy_personal_data_exporters', array() ) ) );"
wp eval "print_r( array_keys( apply_filters( 'wp_privacy_personal_data_erasers', array() ) ) );"
如果站点上装了自定义插件，需要为它注册导出/擦除器：
// 注册自定义表的数据导出器
add_filter( 'wp_privacy_personal_data_exporters', function( $exporters ) {
$exporters['mf-consent-log'] = array(
'exporter_friendly_name' => __( 'Cookie 同意记录' ),
'callback' => 'mf_consent_exporter',
);
return $exporters;
} );
function mf_consent_exporter( $email, $page = 1 ) {
// 注意：同意日志按 IP hash 存储，通常无法关联到具体邮箱
return array(
'data' => array(),
'done' => true,
);
}
步骤 4：修改现有模板点位（必改清单）
不管用哪个生成器，以下八处必须人工核对过：
// 用 WP-CLI 批量查找政策页里的占位符残留
wp post list --post_type=page --field=ID | while read id; do
body=$(wp post get "$id" --field=post_content)
echo "$body" | grep -oE '(\[company[ _-]?name\]|\{company\}|XYZ Inc\.|123 Main St|your@email\.com|\[address\]|\[state\])' | sort -u | sed "s/^/post $id 占位残留: /"
done
这个脚本把常见的占位符（公司名、地址、邮箱、州/省）一次性扫出来，输出为空才算干净。
步骤 5：版本管理与变更留痕
政策更新后必须保留旧版本并记录生效时间。简单做法是用 revisions + 一行 meta：
// 在政策页保存时记录版本号与生效时间
add_action( 'save_post_page', function( $post_id, $post ) {
if ( wp_is_post_revision( $post_id ) || ! in_array( $post_id, array( 3, 5 ), true ) ) {
return; // 换成你实际的政策页 ID
}
update_post_meta( $post_id, '_mf_policy_version', gmdate( 'Ymd-His' ) );
}, 10, 2 );
版本号同时要同步到 Cookie 同意插件里的政策版本字段（详见上一篇），否则老用户不会被重新征求同意。
常见踩坑
- 退款政策写得太”模板”： blindly 套 Shopify 或欧美 SaaS 模板，写”30 天无理由”，但自己站其实是中国发货、物流周期长，实际无法履行，属于自设违约。
- 一家站点两套政策互相矛盾：Cookie 政策说”永久保存”，隐私政策说”最多 12 个月”，被挑这时候两套说法都不算数。
- 案例：某精品外贸站用某生成器生成了 Terms & Conditions，默认管辖法律写的是 “State of California”。而站点实际运营主体在深圳，从未在美国注册。后来遇到一笔 PayPal 纠纷（买家主张退款），买家律师直接指出：政策里声明适用加州法，站点却无在美实体，涉嫌误导性商业陈述，PayPal 调解时站方处于明显被动。教训：管辖地与适用法律的条款必须与真实主体一致，模板默认值照抄即为自创风险。
- 引用了已废止的法规：很多生成器还在写 “Privacy Shield”（欧美隐私盾已于 2020 年被欧盟法院 Schrems II 判决废止），或引用已被替代的条款编号。现在应写 SCCs（标准合同条款）。
- 儿童相关数据没处理：面向未成年用户的产品要符合 COPPA / GDPR age of consent（各国 13~16 岁不等）的要求，模板一般不会提示。
- 政策页被 robots.txt 屏蔽或 noindex：政策都写了，却在 Yoast/Rank Math 里误设为 noindex，或被缓存插件压缩掉了，等于没有。
- 把 ZIP 时的测试数据、例字一起发布：生成器往往自带大量示例文本，比如 “We may share data with third-party advertising partners”，如果实际没接广告平台，这属于无须有的自我曝光。
- 用[mf]这种短代码渲染的 T&C 被主题 raw 输出：换个主题之后短代码失效。稳妥做法是用 WordPress 内置区块渲染，而不是插件专属短代码。
延伸阅读：Cookie 同意与脚本阻断、WordPress 数据导出与删除
总结
一句话：生成器给的是草稿，不是成品。 落地三步：①用 WordPress 核心隐私向导做基线（它是唯一能反映你实际装了哪些插件的机制）；②把第三方服务清单手工写出来，与 Cookie banner、SDK 三方对齐；③扫描占位符残留并确认管辖主体、退款期限、数据保留期、保留地与 CHANGELOG 版本。若你说某种服务根本删不了数据，那就别在政策里承诺删除——比起写得漂亮，写得准确才是免责的前提。
