@Founder们，我们开源了给OPC的隐私协议MVP生成器 skill

@Founder们，我们开源了给OPC的隐私协议MVP生成器 skill @Founder们，我们开源了给OPC的隐私协议MVP生成器 skill Modified June 1 第一步，先问事实，解决「你不知道有哪些」。 先给出一张产品事实清单。 产品叫什么，运营主体是谁，联系方式是什么，产品面向谁，核心功能是什么，收集哪些个人信息，哪些信息是功能必需，有没有用户上传内容，有没有第三方 SDK、API、插件、模型服务、云服务。 如果你的产品是 AI 或 AIGC 工具，它还会继续问：用户上传的图片、文件、提示词，会不会用于模型训练或模型优化；有没有第三方模型服务；有没有公开发布、社区展示、下载、二次创作或对外使用场景。 先把数据流转情况问清楚，后面才谈得上怎么写。 第二步，合规校验，解决「你不知道哪些对」。 这个 Skill 会根据《个人信息保护法》等法律法规、国家标准和合规实践，逐项检查一份 MVP 隐私协议该有的内容： • 主体有没有？ • 联系方式有没有？ • 产品范围有没有？ • 核心功能和个人信息类型有没有对应？ • 必要信息和非必要信息有没有区分？ • 拒绝提供的影响有没有说？ • 第三方 SDK 是否说明？ • 跨境传输或境外访问是否判断？ • 用户查询、更正、删除、撤回同意、注销、投诉路径是否清楚？ 如果涉及 AI 训练、自动化决策、敏感个人信息、未成年人、跨境传输这些高风险事项，MVP 版本也不能靠一句「相关信息」糊过去。 合规校验这一步，它守着两条原则。 事实不清，不硬写。 不知道有没有 SDK，就不会假装没有 SDK；不知道是否跨境，就不会直接写「不存在跨境传输」；不知道用户上传内容是否用于训练，就不会替你写「我们不会用于训练」。 不确定的，不替你拍板。 该留空、该标成待确认的，就让你来完成。 注意，是 MVP。 不是低标准。 MVP 的意思是正文可以短一点，结构可以轻一点，但核心告知不能空着。 第三步，MVP 协议生成与复查。 它会在最小范围内，生成一份可以继续迭代的隐私协议建议稿，同时输出个人信息收集简表、第三方 SDK / API / 插件 / 合作方简表、用户权利路径简表，以及本版忽略或简化的内容、后续完善事项和复查报告。 很多自动化工具填完空就收工了。 这个 Skill 生成完才算开始。它会回头扫一遍：哪些字段其实没问实，这一版简化了什么、跳过了什么，后面还要补什么，全都标出来，写进复查报告。 AI 在不知道产品真实数据流转的情况下写错隐私协议，可能会把 SDK、模型训练、跨境访问、未成年人、用户删除路径这些关键问题一起写没了。 所以它要先把产品事实问出来，再用法律法规和相关标准核对，最后在最小范围内生成一份能继续迭代的 MVP 隐私协议建议稿。 这个 Skill 在动笔之前，会把产品的数据事实一条条问清楚：收集了哪些个人信息，哪些是功能必需，有没有第三方 SDK，用户上传内容会不会用于训练，有没有跨境访问，有没有未成年人，有没有敏感个人信息。 这串问题，本身就是一份自查清单。 你完全可以不生成任何协议，只拿这串问题，对着自己的产品过一遍。 能一条条答上来，说明你对自己的数据流转是清楚的，协议怎么写都不会太离谱。 答不上来，那协议先别急着写，先把产品搞明白。 03 后续安排和能力边界 这个项目目前只是 1.0。 后面我会继续做两个方向。 v2.0 会面向完整深度版隐私协议，适合产品事实已经比较完整的团队。 到了这个阶段，隐私协议就不能只写基础信息了。SDK 清单、权限清单、第三方服务商清单、AI 训练规则、保存期限、跨境判断、委托处理、自动化决策，这些都要进一步展开。 v3.0 会面向基于 MVP 协议的持续扩充。 很多产品不是一次长成的。 今天只是网页工具，明天加登录，后天加支付，再过一阵子接入模型服务、内容审核、云存储、推荐算法、会员系统。 协议也应该跟着产品一起更新。 这也是我们想长期做的事：在 AI 合规、数据合规这些复杂、琐碎但高频场景里，一个个把能开源的工具做出来。隐私协议 MVP 生成器是第一个，后面还会有更多 Skill。 很多 AI 产品的服务条款里，都会写类似这样的免责声明：AI 输出可能不准确、不完整、过时或者具有误导性，不应被视为事实或专业建议；用户应当自行评估输出的准确性、合法性和适用性；不得把 AI 输出直接用于法律、金融、医疗等会对个人产生重大影响的决策。 这个 1.0 版本生成的是隐私协议 MVP 版本建议稿，仅供参考。 它适合帮 OPC、founder 和早期团队把最初版本先立起来，把个人信息处理者、产品范围、个人信息类型、第三方 SDK、AI 功能、模型训练、跨境访问、用户权利路径这些基础问题先说清楚。 但如果你的产品数据流转很复杂，比如涉及未成年人、敏感个人信息、跨境传输、AI 训练、自动化决策、金融、医疗、教育、大规模用户数据，或者已经进入平台审核、B 端客户采购、融资尽调、监管沟通这些场景，就不要只停留在工具生成。 这时候就需要找专业法律人士了。 也可以找我。 真正复杂的数据合规问题，最后还是要回到具体产品、具体数据、具体链路里解决。 再重复一下项目地址 https://github.com/youdianzhineng ailaw/privacy policy self service generator mvp 欢迎后台私信或添加微信获取skill 源文件。 也欢迎持续关注“有点智能事务所”。 我们会持续更新新的 Skill 发布，以及 AI 合规、隐私协议、数据合规相关的实务经验。 【END】 如果有GEO相关的问题 欢迎联系我们探讨！ 「新朋友招募计划」 我寄offer与明月 只待将才共和鸣 详情指路： 在继续成为的路上，我们想再找一位同行者 | 2026星也招聘律师助理 作者简介 北京星也律所高级顾问 于泽辉 法律行业的AI创业者 All in AI+legal，用法律帮助AI创业，用AI重塑法律服务 在继续成为的路上，我们想再找一位同行者 | 2026星也招聘律师助理 第一步，先问事实，解决「你不知道有哪些」。 先给出一张产品事实清单。 产品叫什么，运营主体是谁，联系方式是什么，产品面向谁，核心功能是什么，收集哪些个人信息，哪些信息是功能必需，有没有用户上传内容，有没有第三方 SDK、API、插件、模型服务、云服务。 如果你的产品是 AI 或 AIGC 工具，它还会继续问：用户上传的图片、文件、提示词，会不会用于模型训练或模型优化；有没有第三方模型服务；有没有公开发布、社区展示、下载、二次创作或对外使用场景。 先把数据流转情况问清楚，后面才谈得上怎么写。 第二步，合规校验，解决「你不知道哪些对」。 这个 Skill 会根据《个人信息保护法》等法律法规、国家标准和合规实践，逐项检查一份 MVP 隐私协议该有的内容： • 主体有没有？ • 联系方式有没有？ • 产品范围有没有？ • 核心功能和个人信息类型有没有对应？ • 必要信息和非必要信息有没有区分？ • 拒绝提供的影响有没有说？ • 第三方 SDK 是否说明？ • 跨境传输或境外访问是否判断？ • 用户查询、更正、删除、撤回同意、注销、投诉路径是否清楚？ 如果涉及 AI 训练、自动化决策、敏感个人信息、未成年人、跨境传输这些高风险事项，MVP 版本也不能靠一句「相关信息」糊过去。 合规校验这一步，它守着两条原则。 事实不清，不硬写。 不知道有没有 SDK，就不会假装没有 SDK；不知道是否跨境，就不会直接写「不存在跨境传输」；不知道用户上传内容是否用于训练，就不会替你写「我们不会用于训练」。 不确定的，不替你拍板。 该留空、该标成待确认的，就让你来完成。 注意，是 MVP。 不是低标准。 MVP 的意思是正文可以短一点，结构可以轻一点，但核心告知不能空着。 第三步，MVP 协议生成与复查。 它会在最小范围内，生成一份可以继续迭代的隐私协议建议稿，同时输出个人信息收集简表、第三方 SDK / API / 插件 / 合作方简表、用户权利路径简表，以及本版忽略或简化的内容、后续完善事项和复查报告。 很多自动化工具填完空就收工了。 这个 Skill 生成完才算开始。它会回头扫一遍：哪些字段其实没问实，这一版简化了什么、跳过了什么，后面还要补什么，全都标出来，写进复查报告。 AI 在不知道产品真实数据流转的情况下写错隐私协议，可能会把 SDK、模型训练、跨境访问、未成年人、用户删除路径这些关键问题一起写没了。 所以它要先把产品事实问出来，再用法律法规和相关标准核对，最后在最小范围内生成一份能继续迭代的 MVP 隐私协议建议稿。 这个 Skill 在动笔之前，会把产品的数据事实一条条问清楚：收集了哪些个人信息，哪些是功能必需，有没有第三方 SDK，用户上传内容会不会用于训练，有没有跨境访问，有没有未成年人，有没有敏感个人信息。 这串问题，本身就是一份自查清单。 你完全可以不生成任何协议，只拿这串问题，对着自己的产品过一遍。 能一条条答上来，说明你对自己的数据流转是清楚的，协议怎么写都不会太离谱。 答不上来，那协议先别急着写，先把产品搞明白。 03 后续安排和能力边界 这个项目目前只是 1.0。 后面我会继续做两个方向。 v2.0 会面向完整深度版隐私协议，适合产品事实已经比较完整的团队。 到了这个阶段，隐私协议就不能只写基础信息了。SDK 清单、权限清单、第三方服务商清单、AI 训练规则、保存期限、跨境判断、委托处理、自动化决策，这些都要进一步展开。 v3.0 会面向基于 MVP 协议的持续扩充。 很多产品不是一次长成的。 今天只是网页工具，明天加登录，后天加支付，再过一阵子接入模型服务、内容审核、云存储、推荐算法、会员系统。 协议也应该跟着产品一起更新。 这也是我们想长期做的事：在 AI 合规、数据合规这些复杂、琐碎但高频场景里，一个个把能开源的工具做出来。隐私协议 MVP 生成器是第一个，后面还会有更多 Skill。 很多 AI 产品的服务条款里，都会写类似这样的免责声明：AI 输出可能不准确、不完整、过时或者具有误导性，不应被视为事实或专业建议；用户应当自行评估输出的准确性、合法性和适用性；不得把 AI 输出直接用于法律、金融、医疗等会对个人产生重大影响的决策。 这个 1.0 版本生成的是隐私协议 MVP 版本建议稿，仅供参考。 它适合帮 OPC、founder 和早期团队把最初版本先立起来，把个人信息处理者、产品范围、个人信息类型、第三方 SDK、AI 功能、模型训练、跨境访问、用户权利路径这些基础问题先说清楚。 但如果你的产品数据流转很复杂，比如涉及未成年人、敏感个人信息、跨境传输、AI 训练、自动化决策、金融、医疗、教育、大规模用户数据，或者已经进入平台审核、B 端客户采购、融资尽调、监管沟通这些场景，就不要只停留在工具生成。 这时候就需要找专业法律人士了。 也可以找我。 真正复杂的数据合规问题，最后还是要回到具体产品、具体数据、具体链路里解决。 再重复一下项目地址 https://github.com/youdianzhineng ailaw/privacy policy self service generator mvp 欢迎后台私信或添加微信获取skill 源文件。 也欢迎持续关注“有点智能事务所”。 我们会持续更新新的 Skill 发布，以及 AI 合规、隐私协议、数据合规相关的实务经验。 【END】 如果有GEO相关的问题 欢迎联系我们探讨！ 「新朋友招募计划」 我寄offer与明月 只待将才共和鸣 详情指路： 在继续成为的路上，我们想再找一位同行者 | 2026星也招聘律师助理 在继续成为的路上，我们想再找一位同行者 | 2026星也招聘律师助理 作者简介 北京星也律所高级顾问 于泽辉 法律行业的AI创业者 All in AI+legal，用法律帮助AI创业，用AI重塑法律服务 🔗 原文链接： https://mp.weixin.qq.com/s/E38I1Bhq... https://mp.weixin.qq.com/s/E38I1Bhq... 原创 于泽辉 于泽辉 有点智能事务所2026年6月1日 18:00 北京 面向OPC、founder、个人开发者和早期团队 先把第一版隐私协议做出来 让 OPC 和 founder 没有难写的隐私协议 最近法律人开源的东西越来越多。 有人开源合同生成 Skill，有人开源审查工作流，也有人把自己在某个细分业务里踩过的坑，整理成可以复用的工具。 我们也把自己在 AI 合规和数据合规领域的经验，做成了第一个可以拿出来开源的产品： 隐私协议 MVP 生成器 https://github.com/youdianzhineng ailaw/privacy policy self service generator mvp 我们的口号很简单直白！ 让 OPC 和 founder 没有难写的隐私协议。 开源什么，其实是个选择题。 真正需要判断的活儿，比如一个功能有没有数据合规风险，在执法口径下站不站得住，依赖实务经验，还是律师的领域。 但还有一类活，本来就不太需要律师。客户自己也在用 AI 搞，只是搞得似是而非，风险埋在看不见的地方。 比如隐私协议。 一些功能简单的 App、小程序和早期网站，第一版隐私协议未必需要一开始就做成深度法律意见。微信小程序上线时也有官方隐私保护指引和模板入口。很多团队真正卡住的，不是复杂法律判断，而是压根不知道从哪里开始。 这种事，我甚至愿意直接让当事人先去问 AI。 先有个大概认知，再决定要不要找人。 问完还觉得需要律师，那也好，至少我们有了能往下聊的基础。 问完问题就解决了，那效率更高。 所以这次干脆把工具做好，直接交到他们手里。 很多 OPC、founder、独立开发者和早期团队，产品已经做出来了，甚至已经有用户开始进来了。 但隐私协议还没写，而且不知道怎么写。 于是市场上出现了几种经典做法。 第一种，复制一份大厂类似产品的隐私政策，把产品名和公司名换掉。 第二种，让 AI 生成一份看起来还行的。 第三种，先空着不上或者随便放一份。 主打一个产品先跑，合规在后面追。 这次开源的 Skill，就是来解决这个问题的。 01 为什么做 我做这个 Skill 的起因，是看过太多 AI 生成的隐私协议。 长，很长，非常长。可即便这么长，内容遗漏和硬伤照样一大堆。 • 产品到底收集哪些个人信息，说不清。 • 第三方 SDK 是谁，说不清。 • 用户上传的图片、文件、提示词会不会用于模型训练，说不清。 • 数据会不会被境外服务访问，说不清。 • 用户怎么删除账号、撤回授权、注销、投诉，说不清。 更离谱的是，我之前看过一份黑客松的隐私协议，差不多三万字，最初版本里居然完全没有提到「未成年人」。 这就很魔幻。 一个面向大量青少年参与者的活动，隐私协议写了三万字，却没有看见未成年人字样。 会让 AI 写出很长的隐私协议，不代表真的理解自己的数据流转。 很多 founder 对隐私协议的理解，还停留在一个非常朴素的阶段。 上线前找个模板，换个产品名，换个公司名，再加一句「我们高度重视您的隐私」，然后放到网页底部。 问题是，隐私协议不是网页装饰品。 它是真的要回答你的产品到底怎么处理用户数据。 《个人信息保护法》第十七条说得很清楚。处理个人信息前，要用显著方式、清晰易懂的语言，真实、准确、完整地告知处理者名称和联系方式、处理目的、处理方式、个人信息种类、保存期限，以及用户行使权利的方式和程序。 简单翻译一下就是： 你拿了什么数据，为什么拿，怎么用，给了谁，存多久，用户怎么找你删。 所以这次开源的 1.0 版本，只做一件事： 给 OPC 和 founder 生成最初版本的隐私协议 MVP 建议稿。 它主要面向 OPC、初创企业的 founder、个人开发者、独立开发者和早期创业团队，帮助他们在产品上线前，先形成一份符合中国数据合规和 AI 合规基本要求的隐私协议草案。 AI 合规和数据合规，首先是一种产品拆解能力。 你要知道产品在哪里收集数据，在哪里调用模型，在哪里接入 SDK，在哪里发生跨境访问，在哪里触发敏感个人信息，在哪里可能涉及未成年人，用户又在哪里退出。 02 怎么做的 整个流程就三步： 产品事实采集 → 合规校验 → MVP 协议生成与复查。