vibe 项目的隐私合规实战：从数据地图到删除按钮

先说结论：隐私合规不是法务部的事，是产品上线的前置条件

很多 vibe coder 的上线清单是这样的：功能跑通 → 买域名 → 部署 → 发 Product Hunt。隐私政策？「先上线再说，抄一份模板糊上去。」然后三个月后收到第一封用户邮件：「请删除我的账号和所有数据。」——这时候才发现，数据库里用户数据散落在七八张表，第三方分析工具里还有一份，备份里还有一份，根本删不干净。

隐私合规和 SOC2 那种企业审计认证是两回事（本站有专门的 SOC2 指南，那是拿来做 B2B 销售的）。这篇讲的是产品对外的隐私合规：你收集了用户什么数据、拿来干什么、用户有没有权利删掉。做 toC 产品的 vibe 团队，这套东西做不好，轻则被应用商店下架，重则吃罚单——而且和代码质量无关，纯粹是产品设计问题。

另外区分：本站另有一篇《上线前一天的法律三件套》，讲隐私政策/服务条款/Cookie 文本"写什么"——那篇是文书模板，这篇是产品动作（数据地图、删除 SOP、同意记录），两者配套不重复。

好消息是：隐私合规的大部分工作，是「在正确的时间做正确的产品决策」，不需要法务背景。这篇给你一套从第 1 天就能落地的实战框架。

第一步：画出你的数据地图（上线前必做）

在写第一行隐私政策之前，先回答这张表。拿张纸（或 Notion）列出来：

• 你收集什么？邮箱、用户名、IP、设备信息、支付信息、用户上传的内容、行为埋点……一项一项列。
• 为什么收集？每一项都要有一个「没有它功能就跑不起来」的理由。答不上来的，删掉。——这就是「数据最小化」，所有隐私法规的第一原则。
• 存哪儿？哪个数据库、哪个云厂商、哪个 region。用户在欧洲，数据却存在美国裸机上？这就是隐患。
• 谁还看得到？第三方 SDK 清单：统计（PostHog/Umami）、错误追踪（Sentry）、支付（Stripe）、邮件（Resend）、登录（Auth0/Clerk）。每一个第三方都是一次数据共享，必须在隐私政策里点名。
• 存多久？日志 30 天？埋点 13 个月？用户注销后呢？没有保留期限的数据，就是未来的负债。

这张表做完，你的隐私政策就有了 80% 的素材。更重要的是：上线后再想补这张表，成本是 10 倍——因为数据已经散出去了。

数据地图表示例：收集什么 / 为什么收集 / 存哪儿 / 谁还看得到 / 存多久

第二步：隐私政策里必须有的 8 个条款

别抄模板。模板的问题是它不知道你收集了什么。按你的数据地图，亲手写这 8 节（每节 2-3 句话就行，真诚比篇幅重要）：

• 1. 我们收集什么、为什么收集：按功能分组写（「账号功能需要邮箱」「分析功能收集匿名访问数据」），不要写「我们可能收集以下信息」这种正确的废话。
• 2. 第三方共享清单：点名每个第三方服务商 + 它拿到什么数据 + 它的隐私政策链接。这是用户最想看、开发者最常漏的一节。
• 3. Cookie 与跟踪技术：用了哪些 cookie、干什么用、有效期。欧洲用户还要单独的同意横幅（见下）。
• 4. 数据保留期限：每类数据存多久，注销后多久删除。写不出来？回去看第一步的表。
• 5. 用户权利：访问、更正、删除、导出、撤回同意。至少给一个能用的联系方式（别只留个 noreply 邮箱）。
• 6. 未成年人：你的产品允不允许 13/16 岁以下用户？不允许就写清楚，有年龄门；允许，就得做家长同意——绝大多数 vibe 项目应该选前者。
• 7. 数据跨境：服务器在哪几个 region，用户数据会不会出境。一句话就行，但不能没有。
• 8. 政策更新通知：重大变更怎么通知用户（邮件/站内信），生效前多少天。

写完找个懂行的朋友读一遍，问：「如果你是用户，看完敢注册吗？」不敢，就重写。

第三步：Cookie 横幅——欧洲流量的生死线

如果你的产品有欧洲用户（ePrivacy/GDPR 辖区），这条是硬性的：非必要的 cookie/tracker，必须在用户点「同意」之前就处于关闭状态。注意三个常见翻车点：

• 翻车 1：「继续使用即代表同意」。不行。必须是明确的肯定动作（点按钮），预勾选也不行。
• 翻车 2：拒绝按钮藏三层。「同意」一键，「拒绝」要进设置翻三页——监管机构明确说过这算违规。两个按钮必须同等显著。
• 翻车 3：先加载分析脚本，等用户同意了再说。顺序反了。正确做法：默认只加载「严格必要」的（登录态、安全），分析/广告类等同意后再动态注入。用 Google Tag Manager 的 Consent Mode 或自研一个 50 行的小模块都行。

中国用户为主的产品，看《个人信息保护法》：「单独同意」是关键词。App 首次启动时，别把 5 个权限 + 隐私政策打包成一个「我已阅读并同意」——重要的数据处理（人脸、位置、通讯录）要单独弹窗。应用商店审核现在会实测这个。

第四步：删除权——最被低估的工程需求

「删除我的账号」是用户权利里工程成本最高的一项，因为它在考验你的数据架构。vibe 项目常见的三种死法：

• 死法 1：删了 users 表，订单/日志/埋点里还留着邮箱。解法：用户表用内部 UUID 做主键，PII（邮箱、手机号）集中在一张表，删除=删 PII 表 + 匿名化关联表。
• 死法 2：第三方删不掉。Sentry 的 issue 里带着用户邮箱、PostHog 的事件带着 userId。解法：数据地图里标出每个第三方的删除 API，上线前就写好一个 DELETE /me/data 的内部脚本，按清单逐个调。
• 死法 3：备份里还有。备份保留 30 天是合理的，但要在隐私政策里写明「备份中的数据将在 X 天内随备份轮转自然清除」，这是监管认可的标准做法。

建议的产品形态：设置页放一个「导出我的数据」（JSON 打包下载）和「删除账号」按钮，删除走「30 天冷静期 + 真删」的两段式。做出来不难，但它是用户信任感最强的功能之一。

第五步：AI 功能的额外三条红线

vibe 项目大多带 AI 功能，隐私合规要多想三层：

• 1. 用户输入会不会进训练集？如果你调的是第三方 API（OpenAI/Anthropic），看清数据条款：API 模式默认不拿用户数据训练，但某些「数据共享换折扣」的选项会。把这个结论写进隐私政策，一句话的事。
• 2. Prompt 里别塞 PII。最常见的翻车：把整条用户记录（含邮箱、订单号）拼进 prompt 发给模型。解法：prompt 只传完成任务必需的字段，敏感字段先脱敏或用代号。
• 3. RAG 的权限继承。如果你的 AI 能搜用户文档，确保搜索结果遵守原文档的权限——A 用户的 agent 不能搜出 B 用户的文档。这是本站反克隆/权限类指南里反复强调的，隐私视角下同样致命。

上线前 48 小时检查清单

• ☐ 数据地图 v1 已建档（收集项/目的/存储/第三方/保留期）
• ☐ 隐私政策 8 条款已按数据地图亲手写完，页脚可访问
• ☐ 第三方 SDK 清单与政策里的点名一致（新增一个 SDK 就更新政策）
• ☐ Cookie 横幅：默认关闭非必要跟踪，同意/拒绝同等显著
• ☐ 设置页有「导出数据」和「删除账号」入口（或明确的上线后两周内补齐计划）
• ☐ AI 功能的 prompt 脱敏 + 第三方 API 数据条款已确认
• ☐ 团队每个人都知道：用户要删数据时，找谁、走什么流程

最后说句大实话：隐私合规做得好的 vibe 项目，转化率反而更高——注册页上那句「我们只收集让功能跑起来的数据，政策全文 800 字」本身，就是一种差异化。用户不是不愿意给数据，是不愿意给「不知道去哪了」的数据。

法规速览：四套规则，一张表

不需要背法条，但要知道你在跟哪套规则打交道：

• 欧盟 GDPR + ePrivacy：全球最严。核心是「同意」必须自愿、具体、明确；用户有删除权、导出权、撤回同意权；Cookie 横幅是 ePrivacy 的要求（非必要跟踪默认关闭）。罚则是全球营收的 4%。——有欧洲用户就必须按这套做；
• 中国《个人信息保护法》（PIPL）：关键词是「单独同意」和「最小必要」。敏感个人信息（人脸、位置、金融账户）要单独弹窗同意；App 违规收集会被应用商店下架、通报。——国内上架必修；
• 美国加州 CCPA/CPRA：核心是「选择退出权」——用户可以要求你「不要出售/共享我的个人信息」；网站要有显眼的 "Do Not Sell or Share" 入口。跟 GDPR 的「事先同意」逻辑不同，是「事后退出」逻辑；
• 其他：巴西 LGPD、加拿大 PIPEDA、新加坡 PDPA 大体是 GDPR 的变体。记住一个原则就行：按最严的那套做，全球通用。为欧盟/中国做好的合规，拿到别处基本够用。

特别提醒 vibe 团队：很多独立开发者觉得「我这么小，没人管」。现实是应用商店（Apple/Google）和云厂商才是第一执法者——App 隐私标签填错、首次启动多要权限，直接下架，不跟你讲「规模小」。合规的第一 audience 不是监管机构，是应用商店审核员。

数据地图模板：复制即用

第一步提到的「数据地图」，直接给一张可复制的表。每一行是一类数据：

• 数据项：用户邮箱 | 收集目的：账号登录与通知 | 存储位置：Postgres users 表（us-east-1）| 第三方可见：Resend（发邮件）| 保留期：注销后 30 天删除 | 删除方式：DELETE /me 脚本 + Resend suppression list
• 数据项：访问埋点（页面、点击） | 收集目的：产品优化 | 存储位置：PostHog Cloud（eu）| 第三方可见：PostHog | 保留期：13 个月 | 删除方式：PostHog deletion API
• 数据项：错误日志（含设备信息） | 收集目的：崩溃排查 | 存储位置：Sentry（us）| 第三方可见：Sentry | 保留期：90 天 | 删除方式：Sentry 数据删除 + 本地日志脱敏（见本站 log-redaction 指南）
• 数据项：用户上传的文件 | 收集目的：核心功能 | 存储位置：S3（us-east-1）| 第三方可见：无 | 保留期：用户删除即删 | 删除方式：S3 delete + CDN 缓存 purge

把这张表维护在团队 wiki 里，每新增一个 SDK 加一行。这张表有三个读者：写隐私政策的你、做删除功能的你、以及（万一）来问询的监管者。一张表，三种用途。

隐私政策的 6 个反模式

见过太多 vibe 项目的隐私政策长这样——每一条都是坑：

• 反模式 1：全文复制模板，一字不改。模板里写「我们可能使用 GPS 定位」，你的产品根本没定位功能。用户看了觉得你心虚，监管看了觉得你撒谎。
• 反模式 2：「我们可能收集以下信息」+ 20 项清单。「可能」是最糟的词——到底收没收？按数据地图写「我们收集 X，用于 Y」，确定的语气本身就是信任。
• 反模式 3：第三方一节写「详见各服务商政策」。等于没写。点名 + 说明拿了什么数据 + 给链接，三件套缺一不可。
• 反模式 4：没有更新日期。政策页连个 "Last updated" 都没有，用户默认它是三年前写的。每次更新都改日期，重大变更发通知。
• 反模式 5：联系方式是 noreply@。用户权利条款写了「您有权要求删除」，联系邮箱却是 noreply——行为艺术。给一个真人会回的邮箱（或工单入口）。
• 反模式 6：中英版本对不上。中文政策更新了，英文还是旧版。双语产品最容易在这里翻车：以外文版为准还是中文版为准？提前写清楚，以哪个版本为准。

第三方 SDK 审查：每次接入前的 5 分钟

数据地图里最容易腐烂的是「第三方可见」这一列，因为 SDK 是 agent 顺手接的。定一条团队规矩：接任何第三方 SDK/ API 之前，花 5 分钟填这 4 格：它拿走什么数据？数据存哪？它的删除 API 是什么？它的隐私政策链接？填完才合入。

几个高频踩坑的 SDK 类型：

• 分析工具（PostHog/Amplitude/Mixpanel）：默认可能收集 IP、设备指纹。开「匿名模式」、关掉不必要的自动捕获（如 heatmap 的文本采集）；
• 错误追踪（Sentry）：默认会带上 breadcrumbs 里的用户信息。开数据脱敏（beforeSend 里 scrub），把邮箱、token 替换掉；
• 广告/归因（AdMob/AppsFlyer）：这是数据共享的重灾区，能不接就不接；接了必须在政策里大写加粗；
• AI API：确认数据条款（训练集问题），prompt 脱敏（见第五步）。注意：有些「AI 客服」SDK 会把全量聊天记录存到它家服务器——等于你把用户数据又共享了一次。

收到删除请求时的 SOP

终于有一天，用户发邮件说「删我数据」。别慌，按这个 SOP 走：

• 1. 确认身份（24h 内回复）：从注册邮箱发来的？是就继续；不是，要求验证。别把 A 的数据删给 B 看了；
• 2. 跑删除脚本：按数据地图的「删除方式」列，逐个执行：主库 PII 删除 → 关联表匿名化 → 第三方 deletion API → S3/CDN 清理。脚本提前写好，别到时候现写；
• 3. 备份说明：告诉用户「在线数据已删除，备份中的副本将在 X 天内随轮转清除」——这是标准话术，监管认可；
• 4. 回执：72h 内给用户发确认邮件，列出删除了哪些、保留了哪些（如法律要求保留的交易记录）及原因；
• 5. 复盘：这次删除花了多久？有没有哪个第三方删不掉？更新数据地图。

把 SOP 写下来还有一个好处：应用商店审核/监管问询时，「我们有书面流程」本身就是加分项。合规的很多分，来自「看起来专业」。

特殊情况：未成年人与敏感行业

两类产品要把合规等级再调高一档。第一类是可能有未成年人用户的产品（教育、游戏、社交）：13 岁（美国 COPPA）/16 岁（GDPR 默认）以下是红线。最省事的方案是年龄门——注册时问一句，14 岁以下直接拒绝注册并给出家长联系通道。千万别做「收集了再说」，儿童数据的罚单是按「明知故犯」顶格算的。

第二类是处理健康/金融数据的产品（健康追踪、记账、AI 问诊）：这类数据在各国都是「敏感个人信息」，要求单独同意 + 加密存储 + 更短的保留期。如果你的 vibe 项目误入这个领域（比如一个「AI 营养师」开始存用户的体检报告），要么把合规做到医疗级，要么把功能砍掉。二选一，没有中间态。

判断自己是否踩线的方法很简单：看数据地图里有没有「身份证号、人脸、位置轨迹、健康、金融账户」这几类。有，就按敏感级处理；拿不准，就按敏感级处理。合规上「过度防护」的成本，远低于「防护不足」的成本。

最后：把合规变成产品特性

很多开发者把隐私合规当成「不得不交的税」。换个角度想：在 AI 生成内容满天飞、数据泄露每周上新闻的 2026 年，「我们不作恶」是最便宜的差异化。注册页上写「我们只收集让功能跑起来的数据，政策全文 800 字，删除一键完成」——这句话的转化率，可能比你调三个月的落地页文案还高。

合规不是法务部的事，是产品的事；不是上线后的事，是第 1 天的事。数据地图今天就建，30 分钟。剩下的，按这篇的清单一项项打勾。

Cookie 同意横幅：正确做法 vs 错误做法对比