上线前一天的法律三件套：隐私政策、服务条款与 Cookie 最小合规指南

凌晨两点，你的 SaaS 终于能跑了：Stripe 的测试支付刚刚走通，Landing page 在 Vercel 上绿得发亮。只剩一个按钮——"发布"。然后你突然想起来：隐私政策呢？服务条款呢？那个欧盟用户一打开就该弹出来的 Cookie 横幅呢？

这就是 99% 一人项目的真实状态：法律三件套要么没有，要么是从某个模板站复制粘贴来的。没有，挡不住应用商店审核和 Stripe 风控；复制粘贴，则是另一种风险——一份和你实际数据流对不上的隐私政策，在法律上叫"虚假陈述"，比没有更贵。

这篇指南给"复制粘贴党"一条安全上岸的路径：半天时间，AI 起草 + 清单自查，把上线门槛跨过去。但我也会把 AI 生成文本的天花板说清楚——代码可以 vibe，法律文本不行。这是少数几个你必须"亲手"把关的环节。

复制粘贴为什么是颗雷

先说一个反直觉的结论：一份错的隐私政策，比没有隐私政策更危险。没有政策，别人看到的是"缺失"；有一份写着"我们不收集任何数据"、而你实际上接了 PostHog 做行为分析、接了 Sentry 收集崩溃日志、还用 Resend 发交易邮件的政策，别人看到的是"撒谎"。前者是合规缺口，后者是虚假陈述，罚则和信任成本完全不在一个量级。模板最大的问题从来不是写得不好，而是它描述的是别人的产品，不是你的。

一人产品最常见的三种翻车，几乎都长这个样子：

情形一：分析工具接了，政策里没写

某独立开发者给自己的 AI 写作工具接了行为分析工具做热力图，想看看用户在哪一步流失。隐私政策是从模板站复制的，里面写着"我们仅收集您主动提供的信息"。一位欧盟用户行使 GDPR 的"访问权"，发邮件要求导出"你们关于我的全部数据"。开发者一查分析后台：会话录像、点击热力、设备指纹全在。这封回复邮件怎么写都是错——承认吧，等于承认政策在撒谎；不承认吧，数据明摆着。最后他花了两周重写政策、补了 Cookie 横幅，还得给用户书面道歉。复盘时他说，最冤的是：分析工具是上线前一周才接的，政策是三个月前复制的，两边从来没对过账。

情形二：应用商店审核卡在"缺条款"

另一位开发者把 Web 应用套壳上架应用商店，审核被拒，理由是"含订阅/内购的应用必须提供可访问的隐私政策与服务条款链接"。他临时拼了一份英文政策塞进设置页，二次审核又被拒——审核指南要求政策必须真实描述数据实践，而模板里的"我们可能与广告合作伙伴共享数据"，和他"无广告、纯订阅"的实际模式自相矛盾，审核员直接判定为误导性陈述。来回折腾三周，发布窗口全错过。应用商店的审核员不关心你的政策写得是否优雅，只关心两件事：有没有，以及说的是不是真话。

情形三：支付风控要你"证明你是认真的"

还有一位做模板市场的开发者，Stripe 账户在收到第一笔稍大额的企业付款后被标记复核。风控邮件列了一串材料清单，其中一项就是"面向用户的服务条款与退款政策"。他当时只有一句写在 FAQ 里的"暂不支持退款"。Stripe 的逻辑很直接：没有明确退款条款的商家，争议率天然更高，风控模型会直接加权。补条款、补退款流程说明，前后十天，资金一直处于冻结状态。对一人产品来说，现金流被冻十天，可能就是生与死的区别。

三个故事的共同点：出事的都不是"坏人"，都是"先上线再说"的好人。法律三件套不是写给律师看的，是写给审核员、风控系统和较真用户看的——它是你产品的"成年人证明"。没有它，你连被认真对待的资格都没有。

签署隐私政策文件

最小合规三件套：照着清单填

忘掉那些 30 页的律所模板。一人产品的法律三件套，目标不是"滴水不漏"，而是"真实、完整、可执行"。下面这份清单，是"能上线"的最低标准——每一项都对应一个真实世界的检查点：审核员会看、风控会看、较真用户会看。

隐私政策：必须回答的 8 个问题

一份合格的隐私政策，本质上是对用户 8 个问题的诚实回答。写的时候别想着"我要写一份政策"，想着"我在回答用户最想知道的事"：

1. 你收集什么？列出数据清单，按类别写：账号数据（邮箱、用户名）、支付数据（注意：卡号一般由 Stripe 等支付商处理，你要写明自己不存储完整卡号）、行为数据（页面访问、点击）、设备数据（IP、设备型号）、用户内容（上传的文件、输入的提示词）。越具体越好，"我们可能收集某些信息"这种话等于没说。
2. 为什么收集？每个数据类别对应一个目的：邮箱用来发交易通知和密码重置，行为数据用来优化转化漏斗，崩溃日志用来修 bug。目的限定是 GDPR 的核心原则之一，写不出来目的的数据项，就别收集。
3. 凭什么收集？也就是法律依据：履行合同（提供你付费购买的服务）、用户同意（营销邮件）、正当利益（反欺诈）。即便你的用户主要在美国，写清依据也是专业度的体现。
4. 数据存在哪？写明服务器位置和云厂商："数据存储于 Vercel/Neon 位于美国的数据中心"。这直接决定你适用哪套跨境规则，也省掉用户发邮件来问。
5. 分享给谁？列出所有第三方处理者，一个都不能漏：Stripe（支付）、PostHog（分析）、Sentry（错误监控）、Resend（邮件）、Vercel（托管）。这是复制粘贴的政策最容易翻车的地方——模板不知道你接了谁。
6. 存多久？给出保留期限："账号注销后 30 天内删除个人数据，匿名化分析数据保留 13 个月"。没有期限的"永久存储"，在任何法域下都是红旗。
7. 用户有什么权利？访问、更正、删除、导出、撤回同意。至少给出一个能用的联系邮箱，并承诺响应时限（比如 30 天内）。权利条款没有执行入口，等于空头支票。
8. 政策变了怎么通知？写明版本号、生效日期，以及重大变更的通知方式（邮件或站内公告）。这既是合规要求，也是你日后改条款时的"程序正义"。

服务条款：5 个必备条款

服务条款是你和用户之间的"合同"。一人产品不需要 20 页，但下面 5 条缺一不可，缺一条就等于在对应场景下"裸奔"：

1. 服务描述与"按现状提供"。说清楚你提供的是什么（"AI 写作辅助工具"）、不承诺什么（"按现状提供，不保证输出内容的准确性"）。AI 产品尤其要写明：生成内容可能不准确、用户需自行判断。这条是你在"AI 胡说八道导致用户损失"时的第一道防线。
2. 付费、订阅与退款。定价、计费周期、如何取消、退款政策，一个都不能含糊。建议写得比你想的更慷慨一点——"7 天无理由退款"在 Stripe 争议里是你的护身符，在转化率上反而是加分项。含糊的退款条款，等于邀请用户去银行做 chargeback。
3. 责任限制。把赔偿上限锁死：通常写法是"以用户过去 12 个月实际支付的费用为限"，并排除间接损失。没有这条，理论上一次服务中断导致的"用户声称的业务损失"可以无限索赔。一人公司赔不起无限责任，这条是生存线。
4. 账号终止。你有权在什么情况下停掉账号（滥用、欠费、违法），以及终止后数据如何处理（保留多久、能否导出）。写清这条，你封禁羊毛党和恶意用户时才有依据；不写，封号就是"平台霸凌"。
5. 准据法与争议解决。约定适用哪国/哪州法律、争议去哪解决。一人出海产品常见的务实选择是约定 Delaware 或新加坡法律+仲裁，成本可控。别留空——留空意味着用户可以在他所在地的法院起诉你，那才是真正的噩梦。

另外建议顺手加一条"可接受使用政策"（禁止事项：垃圾邮件、攻击他人、违法内容），可以放在条款正文里，也可以单独一页。它是你用 Cloudflare 或服务商投诉流程处理滥用时的依据。

Cookie 横幅："能过审"的最低标准

Cookie 横幅是三件套里最容易"形式主义"的一个。很多站点的横幅只有一个"知道了"按钮——这在欧盟标准下等于没有。最低标准是这 5 条：

• 首次访问就告知。用户第一次打开站点就要看到横幅，而不是藏在页脚等用户自己发现。非欧盟用户可以简化，但告知动作不能省。
• 接受和拒绝同样容易。"接受"是一个大按钮，"拒绝"就不能是藏在三层弹窗里的小字链接。对称设计是监管机构检查的第一项， asymmetric 的横幅在多个欧盟国家已经被开过罚单。
• 默认关闭非必要 Cookie。分析、营销类脚本必须等用户点"接受"后再加载，这叫 opt-in。页面一打开就全量加载 Google Analytics 再弹横幅问"同不同意"，属于先斩后奏。
• 说清类别。横幅或二级面板里列出 Cookie 类别：必要（登录态、安全）、分析（PostHog）、营销（如有）。用户要能按类别开关，而不是只有"全接受/全拒绝"。
• 记录同意、可撤回。把用户的选择存下来（cookie 或 localStorage），并在页脚放一个"Cookie 设置"入口，随时可改。撤回同意和给予同意必须同样简单。

三地差异速查：一张表讲清"做到哪档"

一人出海产品绕不开三个法域：欧盟 GDPR、美国加州 CCPA/CPRA、中国《个人信息保护法》。它们的底层逻辑不同，但对小团队来说，可以收敛成一张速查表。先看差异，再说"做到哪档"：

维度	欧盟 GDPR	美国加州 CCPA/CPRA	中国《个人信息保护法》
管辖门槛	没有规模门槛：只要向欧盟用户提供服务就适用，一人产品也不例外	年营收超 2500 万美元，或处理 10 万以上加州居民数据，小团队早期多半够不上	向境内用户提供产品即适用；数据量达到一定规模需做安全评估
同意模式	最严：营销 Cookie 和非必要追踪必须事先 opt-in，预勾选无效	opt-out 为主：必须提供"拒绝出售/共享个人信息"入口，但默认可收集	接近 GDPR：单独同意 + 敏感个人信息需逐项同意，默认勾选无效
核心用户权利	访问、更正、删除、限制处理、数据可携带、反对自动化决策	知情、删除、更正、拒绝出售/共享、限制敏感信息使用	知情、查阅、复制、更正、删除、撤回同意，近似 GDPR 全套
数据出境	需 adequacy 决定或标准合同条款（SCC），一人产品靠云厂商的 DPA 覆盖	无专门出境限制	最严：达到阈值需申报安全评估；小体量也建议数据境内存储
处罚力度	最高 2000 万欧元或全球营收 4%，按高者计	按次计罚，集体诉讼风险高	最高 5000 万元或上年营收 5%，并可责令暂停业务

"做到哪档"的务实建议：如果你的用户主要是欧美，直接按 GDPR 基线做——它是三套里对产品形态要求最细的（opt-in 横幅、权利响应入口、第三方清单），做到了 GDPR，CCPA 基本顺带满足，只需补一个"Do Not Sell/Share"链接。

如果有中文版、有中国用户，单独按《个人信息保护法》补三件事：注册和授权弹窗里的"单独同意"（不能和一揽子协议绑在一起默认勾选）、敏感个人信息（人脸、定位、金融账号）的逐项告知、以及认真评估数据存哪里——跨境传输的合规成本对一人团队极不友好，早期能用境内云就用境内云。

一句话总结：GDPR 是"产品形态"要求，PIPL 是"架构"要求，CCPA 是"补充链接"要求。按这个顺序排优先级，半天时间花得最值。

隐私保护主题配图

AI 起草工作流：快，但别闭眼签字

法律文本是 AI 最擅长的文体之一：结构固定、术语标准、不需要创意。但 AI 起草的前提是你喂对材料——Agent 不知道你的技术栈，它只能编。我推荐的工作流分三步：喂材料、生成、人工核对。

第一步：喂给 Agent 的四份材料

在写 prompt 之前，先准备好这四份材料，缺一份，生成结果就有一处是编的：

• 技术栈清单：前端框架、托管平台、数据库、认证方案（比如 Next.js + Vercel + Neon + Auth.js）。这决定"数据存在哪"怎么写。
• 第三方服务清单：每一个外部服务：Stripe（支付）、PostHog（分析）、Sentry（错误监控）、Resend（邮件）。附上每个服务处理什么数据。这是"分享给谁"章节的原材料，也是复制粘贴党最容易漏掉的部分。
• 数据流清单：按用户旅程写：注册收集什么、登录收集什么、下单收集什么、用了哪些追踪脚本。不用很正式，bullet list 就行，但必须是你真实的代码行为。
• 目标市场与定价模式：做哪些国家/地区、订阅还是一次性付费、有没有免费 tier、退款政策打算怎么写。这决定条款里"付费与退款"和"准据法"章节的走向。

第二步：起草 prompt 模板

把下面这个 prompt 喂给你的 Agent，附上上面的四份材料。注意 prompt 里埋了三个约束：诚实优先（不知道的标出来而不是编）、引用真实服务名、输出双语：

你是一位熟悉 GDPR、CCPA 和中国《个人信息保护法》的合规顾问。
请基于以下材料，为我的一人 SaaS 产品起草三份文件：
1) 隐私政策 2) 服务条款 3) Cookie 政策。


- 技术栈：<粘贴技术栈清单>
- 第三方服务及处理的数据：<粘贴第三方清单>
- 用户数据流：<粘贴数据流清单>
- 目标市场：<如：全球，含欧盟和中国>；定价：<如：$12/月订阅，7 天无理由退款>


1. 只写材料中真实存在的服务和数据流；不确定的地方用 [待确认] 标出，绝不编造。
2. 隐私政策必须覆盖：收集什么、为什么、法律依据、存储位置、第三方清单、
保留期限、用户权利、联系方式、版本与变更通知。
3. 服务条款必须包含：服务描述（按现状提供）、付费与退款、可接受使用、
责任限制（以过去 12 个月实付费用为上限）、账号终止、准据法与争议解决。
4. 语言平实，避免堆砌术语；输出中文版和英文版。
5. 最后附一份"人工核对清单"，列出你认为我必须亲自确认的事实点。

第三步：生成后必须人工核对的 10 个点

AI 生成的文本，语言 95 分，事实部分必须你亲自过。这 10 个点是翻车高发区，一个一个打勾：

1. 第三方清单和你 package.json / 环境变量里实际接入的服务对得上吗？（最常见翻车点）
2. 写的数据存储位置和你的云厂商实际 region 一致吗？
3. 退款政策和你打算在 Stripe 里实际执行的规则一致吗？
4. 联系邮箱是真实有效、你会看的邮箱吗？
5. 生效日期填的是今天，而不是模板残留的 2023 年吗？
6. 公司/个人名称、注册地写的是你自己的真实信息吗？
7. 有没有出现你根本没做的事，比如"我们使用人脸识别""我们投放个性化广告"？
8. 用户权利的响应时限（30 天）和入口，在你一个人运维的前提下做得到吗？
9. 准据法是你真实能接受的法域吗？别选一个你一辈子没去过的州。
10. 英文版和中文版说的是同一件事吗？AI 翻译偶尔会"发挥"，关键数字和期限要逐项对。

什么时候必须找真律师：三条红线

AI + 清单能覆盖 90% 的一人产品场景，但下面三条红线，踩中任何一条都别省律师费：

• 红线一：碰敏感数据。医疗、金融、儿童、生物识别、人脸、精确地理位置——这些数据的合规要求是另一个量级，模板和 AI 都不够格。碰了就找律师，没商量。
• 红线二：体量触发了"大玩家"义务。比如欧盟用户多到需要指定欧盟代表、任命数据保护官（DPO），或中国侧数据量触发安全评估申报。这些义务的判断本身就需要专业意见。
• 红线三：已经出事了。收到监管问询、用户集体投诉、律师函、应用商店以"误导性陈述"下架——事后补救的每一句话都可能成为证据，这时候 AI 生成的回复函只会帮倒忙。

判断标准很简单：AI 负责"从 0 到 1 的合规骨架"，律师负责"从 1 到 N 的风险兜底"。别让 AI 替你做它没资格做的判断，也别为骨架阶段花冤枉钱。

工程落地：三件套在 Next.js 里的标准放法

文本写好了，剩下的是工程问题：放哪、怎么让用户看到、版本变了怎么办。这部分有标准答案，照抄就行。

路由与页面：三个静态页面

在 App Router 项目里，标准做法是三个静态路由，构建时生成，不占运行时成本：

app/[locale]/(legal)/privacy/page.tsx # 隐私政策
app/[locale]/(legal)/terms/page.tsx # 服务条款
app/[locale]/(legal)/cookies/page.tsx # Cookie 政策

用 (legal) 路由组是为了共享一个极简 layout（去导航、留页脚），让法律页面看起来干净正式。内容直接写 JSX/MDX，别从 CMS 动态拉——法律文本的版本稳定性比编辑方便重要得多。

三个必做的"露出点"

• 页脚链接。全站页脚放"隐私政策 / 服务条款 / Cookie 设置"三个链接。这是审核员和风控检查的第一个位置，找不到链接等于没有政策。
• 注册时勾选。注册表单下方放一个默认不勾选的 checkbox："我已阅读并同意《服务条款》与《隐私政策》"。预勾选在 GDPR 和 PIPL 下都无效，这个细节决定你的"同意"有没有法律效力。注意：条款链接要在 checkbox 旁边点得开。
• 版本变更通知。政策每次实质性变更：递增版本号、在页面顶部标注生效日期、重大变更发邮件或站内公告并保留历史版本。一个小技巧：把历史版本按日期归档在 /legal/archive/2026-10-10 这种路径下，出纠纷时这是你的时间线证据。

轻量 Cookie 同意方案：不用重型 CMP

OneTrust、Cookiebot 这类企业级 CMP 对一人产品是三重浪费：贵、重（动辄几百 KB 的 JS）、定制困难。自研一个 100 行左右的同意管理器完全够用，核心逻辑只有四步：

1. 首次访问弹横幅：说明类别（必要 / 分析 / 营销），"接受"和"拒绝"按钮同等显著，"自定义"展开按类别开关。
2. 把选择存进 localStorage（键如 cookie-consent，值含版本号和时间戳），下次访问直接读取，不再打扰。
3. 按同意状态动态加载脚本：分析类脚本（PostHog、GA）只在用户同意"分析"类别后才注入。用条件渲染或动态 import()，而不是页面加载时全量引入。这是 opt-in 的真正含义——横幅只是 UI，脚本 gate 才是合规。
4. 页脚常驻"Cookie 设置"入口，点击重新打开横幅，允许用户随时撤回。撤回后要实际停掉对应脚本并清掉已种的非必要 Cookie，光改个状态位不算数。

这套方案没有外部依赖、不增加账单、样式完全可控。唯一的成本是你得诚实：在代码里 gate 掉每一个第三方脚本。横幅弹得再漂亮，Network 面板里 GA 在用户点"拒绝"前就发了请求，等于白做——而这恰恰是监管机构技术检查时会看的东西。

结尾：代码可以 vibe，法律文本不行

vibe coding 的哲学是"先跑起来再说"，这对代码成立，因为代码错了可以回滚、可以热修复。法律文本错了，回滚不了——你发出去的每一个版本，都是你亲口承认的"事实陈述"，监管和用户都会拿着它来对照你的实际行为。

所以这件事的正确姿势是：用 AI 把 80% 的体力活干掉（起草、双语、格式），把 20% 的判断留给自己（事实核对、红线识别、版本管理）。半天时间，换来的是应用商店审核一次过、Stripe 风控不找你、较真用户挑不出毛病。这笔投入产出比，在你整个上线清单里是最高的。

最后再强调一遍那句反直觉的话：没有政策是缺口，错的政策是撒谎。上线前一天，花半天时间把三件套做对——这是你从"写 demo 的人"变成"做产品的人"最便宜的一课。