这个动作很像专业工作本身。很多答案不是一开始就完整出现的，而是在一次次真实使用里发现偏差，把偏差说清楚，再把修正写回系统。

做 DPA 审核 Skill 的过程里，我对这件事的感受更深。

法律工作里的“不对劲”，通常没有 PPT 排版那么直观。PPT 样式错了，打开文件一眼就能看到。DPA 审核错了，输出可能仍然很完整：风险等级有，修改建议有，谈判清单也有，语气甚至很像一个成熟律师。真正的问题往往藏在更前面。

它有没有先梳理数据处理活动？有没有判断双方到底是委托处理、共同处理、两个独立个人信息处理者之间的数据提供，还是跨境传输？有没有先确认是否发生个人信息出境，再讨论 SCC 或个人信息出境标准合同？有没有把合同条款、数据处理事实、PIA/DPIA、隐私政策承诺和内部升级机制对应起来？

这些问题如果没有被问出来，一份 DPA 审核意见看起来再完整，也可能只是格式完整。

这也是我开发 DPA 审核 Skill 后最强烈的体会：好的法律 Skill，不靠把提示词写长，也不靠把法条堆满。它真正有价值的地方，是把专家真实工作里的判断顺序、风险分层、业务感知和交付习惯，变成 AI 可以执行的流程。

换句话说，Skill 是专家经验的 AI 化呈现。

本文仅用于学习、测试和工作流讨论，不构成法律意见，也不能替代律师审查。

一、为什么是 DPA：它逼你把数据处理活动说清楚

很多人看到 DPA，会把它理解成主合同后面的一个隐私附件。这个理解太轻了。

DPA 通常指 Data Processing Agreement 或 Data Processing Addendum，可以翻译为数据处理协议或数据处理附录。它常见于 SaaS 采购、云服务、营销工具、客服外包、数据分析、AI 工具接入和跨境业务。主协议解决商业合作本身，DPA 解决合作过程中个人信息如何被处理。

在数据合规实务里，DPA 的真正价值不只是“合规文件”。它贴着业务合同发生，贴着项目推进发生，贴着第三方合作发生。业务要签合同、采购服务、接入系统、向对方提供数据，这个时候 DPA 会逼着我们把一个平时看不清的数据处理活动说清楚。

数据从哪里来？原始数据在哪个系统？给对方是为了什么目的？给出去的是不是最小必要？对方拿到数据后怎么用？会不会再给子处理者？会不会传到境外？对方反馈的数据又会落回哪里？项目结束后数据怎么删除、返还或保留？

这些问题，单靠一份隐私政策不一定问得出来。隐私政策常常是产品上线时的一次性披露，DPA 则是业务合作里真实发生的数据接口。它能把分散在系统、合同、供应商、业务流程里的数据流串起来。

所以，DPA 不能被当成普通合同附件。它更像数据处理活动和法定义务之间的落实接口。

在中国个人信息保护法下，公司和合作方之间可能存在不同的数据关系：委托处理、共同处理、两个独立个人信息处理者之间的数据提供，或者个人信息出境。不同关系下，合同要落实的义务完全不同。

如果是委托处理，合同要写清委托处理目的、期限、方式、个人信息种类、保护措施、双方权利义务、监督机制、转委托限制，以及终止后的返还或删除。

如果是共同处理，合同要分配告知、同意、个人权利响应、安全保护、责任承担和内部追偿。共同处理不能简单写成“双方各自负责”，因为个人仍然可以向任何一个共同处理者行使权利。

如果是两个独立个人信息处理者之间的数据提供，重点是提供方是否履行告知和单独同意，接收方是否只能在被告知和同意的范围内处理，不能拿到数据后任意改变目的和方式。

如果存在跨境传输，还要再往前判断：是否真的存在个人信息出境？谁是境内个人信息处理者？谁是境外接收方？适用的是安全评估、认证，还是标准合同？如果依赖中国个人信息出境标准合同，官方标准合同就不能只是“参考文本”，而应当作为合同安排的一部分纳入，并且其他商业条款、DPA 条款不能与标准合同冲突。欧盟 SCC 也是同理，先判断是否存在向第三国传输，再判断适用哪个 SCC 模块，不能把 SCC 当成普通数据保护条款随手引用。

所以，DPA 审核的顺序，应该从还原数据处理活动开始，再进入合同条款。先厘清角色、义务和跨境机制，再谈文字怎么改。它要问的也不只是“条款有没有写”，还包括“这份合同有没有把法定义务落实到真实业务里”。

这就是为什么 DPA 很适合做成 Skill。它高频、专业、复杂，但有稳定的实务顺序。也正因为如此，它能很明显地暴露一个法律 AI 工具到底有没有理解任务。

二、DPA 审核 Skill 的使用过程，本身就是专家经验

我开发这个 DPA 审核 Skill 时，最想保留的是一条真实的数据合规律师审 DPA 的工作顺序，而不是一份漂亮的输出模板。

用户最常见的输入可能只有一句话：

“帮我审一下这份 DPA。”

但这个 Skill 不会马上开始逐条审查。因为一份 DPA 不能盲审。

它第一步会先做冷启动画像，问清几个前提：我方是谁？协议里我方被写成什么角色？这次重点看哪个法域？业务场景是什么？数据传输了哪些内容？谈判地位是强、中、弱还是未知？有没有公司绝对不能接受的硬性底线？

这一步看起来像问答，实际是在固定审查坐标。

同一份 DPA，放在不同公司、不同交易、不同数据场景下，审查结论可能完全不同。采购云服务，最关心的可能是数据丢失、备份恢复、SLA 和安全责任；接入智能体平台，最关心的可能是平台能不能把客户数据用于模型训练、产品优化、模型评估；如果合同适用 GDPR，就要看 controller、processor、subprocessor、SCC、72 小时通知和 GDPR 第 28 条要求；如果适用中国法，就要看个人信息处理者、受托方、转委托、等保、安全措施、个人权利协助、个人信息出境标准合同等问题。

画像固定后，Skill 会先读取并确认审查对象。这一步是为了防止 AI 看不到附件、读错附件，甚至凭空补出一个审查对象。

接下来是材料完整性检查。DPA 经常会有很多附录：数据处理活动附录、安全保障措施附录、子处理者清单、跨境传输 SCC 或个人信息出境标准合同、区域条款、主协议、订单、SLA、隐私政策、PIA/DPIA。缺哪一部分，会直接影响能不能形成签署判断。

然后，Skill 会先输出数据处理概况，而不是直接给风险意见。

这一步是整个 DPA 审核里最重要的实务动作之一。它先把角色、数据主体、数据类别、处理目的、处理操作、处理地点、传输路径、子接收方、保存删除、缺失事实列出来。这个阶段就是在固定事实：我到底基于什么业务场景、什么数据流、什么法律要求、什么客户诉求来审这份 DPA。

事实固定之后，才进入逐条审查。

这也是 DPA 和普通合同审核的差别。普通合同审核太泛，标准条款很难穷尽。但 DPA 不一样，各国法律都会规定它应该覆盖哪些事项，只是写到什么程度、是否可执行、是否和业务事实匹配的问题。所以 DPA 可以做成更结构化的逐条审查：处理目的、处理范围、子处理者、跨境传输、安全事件、删除返还、审计权、个人权利协助、协议优先级、单方更新机制，每一项都可以和审查基准对应起来。

逐条识别风险后，Skill 才进入法律人真正要解决的问题：怎么改。

它会给出首选修改文本，也会给出对方不接受时的退让方案。这一点很重要，因为真实谈判不是把所有问题都写成红线。不同谈判地位下，策略不一样。强势客户可以要求直接修改；中等地位可以提出首选方案和备选方案；弱势一方可能更需要补料、澄清、合理实施期、内部风险接受条件和升级留痕。

最后，Skill 会生成两类材料：对外谈判清单和内部升级说明。

这不是单纯的格式设计，而是实务交付边界。对外谈判清单要给商务拿出去和对方沟通，语言必须克制、可发送，不能把内部底线暴露给对方。内部升级说明要说清卡点、风险影响、签署前条件和需要谁来决策。安全问题可能要安全或 IT 确认，采购问题可能要采购负责人推动，隐私合规问题可能要 DPO 或隐私负责人判断。

所以，这个 Skill 的使用过程不是“产品功能展示”。它本身就是数据合规专家的工作方法：先识别数据处理活动，再厘清角色和义务分配，再检查材料和跨境机制，再进入条款审核，再拆成可谈判、可升级、可落地的交付物。

三、我是怎么做出来的：先找支柱，再磨成自己的东西

我不是从一条空白提示词开始写这个 Skill 的。

最稳的方式，是先找一个好的开源 Skill 作为支柱。这个支柱的价值，不在于可以照搬，而在于它已经把任务拆过一遍：什么时候冷启动，什么时候判断角色，什么时候加载不同审查手册，什么时候停止，什么时候输出下一阶段。

我参考的 DPA Review 结构给了一个很重要的提醒：DPA 审核不能放进普通合同审核里粗暴处理。普通合同审核更多看资金流、货物流、交付、责任、违约、争议解决；DPA 审核看的是数据流，以及数据流背后的隐私合规动作。隐私政策披露了哪些第三方，DPA 有没有覆盖；DPA 签了，PIA/DPIA 的风险缓解措施有没有落进去；跨境传输发生了，SCC 或个人信息出境标准合同有没有；这些材料之间能不能对得上。

但开源结构也不能直接拿来用。

第一，它对普通用户来说太重。成熟隐私团队可能有隐私政策、PIA/DPIA、DSAR、use-case triage、历史审查、组织升级路径。一个开源体验包不能默认用户已经准备好这些材料。所以我把边界收回到 DPA 专项审查：隐私政策、PIA/DPIA、既往审查和标准模板，如果用户提供，就作为增强材料做一致性检查；如果没有提供，就明确说明没有检查，不能假装做了完整隐私合规评估。

第二，它需要中国法化。只把字段翻译成中文是不够的。中国法下的委托处理、共同处理、向其他个人信息处理者提供、个人信息出境、个人信息保护影响评估、个人信息出境标准合同、等保、安全措施、转委托，都要重新写进审查逻辑。

第三，它还要贴近真实交付。我希望这个 Skill 不要上来就给一堆风险，而是先固定数据处理概况；不要只给一份审查意见，而是同时支持修改建议、对外谈判清单和内部升级说明；不要让谈判地位停留在用户画像里，而是让它真正影响后续修改策略。

所以这个 Skill 的开发过程，其实是三步。

先借用成熟开源 Skill 的工程结构。再把中国法和本土实务规则补进去。最后拿真实样本反复测试，直到它越来越像一个数据合规专家会审出来的东西。

四、真正花时间的，是测试和纠偏

这个 Skill 真正花时间的地方，不在生成第一版，而在测试、纠偏、再测试。

一开始，AI 生成的测试样本太干净。短短两三页，条款简单，还会故意埋一些它自己能审出来的点。这种样本用来演示很好看，但不是真实合同。真实 DPA 往往有主协议、附录、外链区域条款、安全措施、子处理者清单、跨境传输文件，条款质量还不低。只有用真实合同去标识化后测试，才能看出它到底会不会审。

后来我要求测试样本必须来自真实合同的去标识化版本。这样才会出现真实工作里的问题：材料缺失、角色不确定、区域条款外链、适用法不同、谈判地位不同、模型训练用途过宽、受托处理者角色和自主目的混同、跨境传输判断过早拉高风险。

第二个问题，是谈判地位问了，但没有真正进入策略。

冷启动里已经问用户谈判地位是强、中、弱，但测试时我发现，如果用户说自己谈判地位偏弱，Skill 后面仍然给出一套强势修改意见。它只是多问了一个问题，并没有让这个问题改变后续输出。

这就是专家才能看出来的问题。不了解真实谈判的人，会觉得“问到了谈判地位”就够了。但真正审过 DPA 的人知道，谈判地位不是背景信息，而是策略变量。它应该影响风险处理动作、修改措辞、退让方案、补料请求和内部升级建议。

第三个问题，是对外谈判材料可能暴露内部底线。

内部升级说明可以写“没有拿到区域条款前不建议签署”，但这句话不能原样出现在对外谈判清单里。对外应该说：“请提供适用区域条款全文及版本，并确认其优先级和适用范围。”这就是专业交付里的边界。对外材料要能发给对方，内部材料要能支持决策，两者不能混。

第四个问题，是越改越偏。

有时候让 Agent 按我的想法改完，冷启动配置反而没了；有时候它又默认去检索官网链接，但真实审查的核心对象其实是用户上传的 Word；有时候输出模板偏了；有时候角色分支没锁住。于是只能继续测，继续指出哪里不对，再让 Agent 分析原因、修改规则、同步安装，再测。

这更像一个数据合规专家在用自己的经验给 Skill 做品控。

我不需要一开始知道每个工程问题怎么解决，但我知道这个结果不像真实审查。我知道它哪里不对，哪里轻重失衡，哪里不像中国法，哪里不符合谈判实务，哪里拿出去会误导业务。然后我把这些问题交给 Agent，让它去分析、修改、补样本、调输出、跑回归。

最后，这个 Skill 就慢慢变成了自己的东西。开源框架的影子越来越弱，我的审查习惯、风险分层、表达方式和交付逻辑越来越强。

五、为什么只有专家才能做出好的法律 Skill

这也是我最想写清楚的一点。

任何人都可以让 AI 生成一个合同审查流程、一个 DPA 审核清单、一个条款修改建议。模型很强，Agent 也很强，它一定能输出内容。

问题在于，非专家往往不知道输出哪里不对。

一个一两年级的律师，或者一个没有做过数据合规的人，也可以让 AI 审 DPA。但他很可能会平等用力。AI 告诉他有十个问题，他就以为这十个问题一样重要；AI 把跨境传输直接打成高风险，他可能不知道这里应该先做场景澄清；AI 给出强势修改条款，他可能不知道在弱谈判地位下更现实的是补料、澄清和内部留痕；AI 把内部底线写进对外材料，他可能意识不到这是谈判风险。

这就是专家的价值。

专家的价值不在于比 AI 更会背法条，而在于更知道一项任务真正难在哪里。专家知道 DPA 要先看数据处理活动，再看合同文字；知道 SCC 不能脱离跨境传输前提；知道角色判断会影响整份合同的义务分配；知道业务能不能看懂内部升级说明；知道哪些风险可以谈，哪些风险必须升级；知道 AI 输出看起来很完整的时候，仍然可能错在前提上。

所以，好的 Skill 不是知识库，也不是提示词资产。它是专家能力换了一种形式存在。

过去，专家能力体现在人亲自审合同、亲自带低年级律师、亲自和业务沟通、亲自判断风险轻重。现在，专家能力还可以体现在写 Skill、调 Skill、构建流程、设计 benchmark、选择测试样本、判断输出质量上。

AI 没有让专业能力消失。它只是把专业能力换了一个呈现形式。

一个好的 DPA 审核 Skill，真正说明的不是“AI 会审 DPA”，而是“一个数据合规专家把自己审 DPA 的方法，变成了 AI 可以执行、可以复用、可以继续迭代的流程”。

这才是我开发这个 Skill 最想讲的事。

领取朱律师同款 DPA 协议审核开源 Skill，可联系小助理 gin235525 获取开源插件地址。

六、顺手预告一下下一场直播

DPA Skill 讲的是一个很具体的切口：资深数据合规经验如何变成 AI 可以调用的能力格式。再往外走一步，就会碰到法律人的职业第二曲线。

2026 年 6 月 28 日 20:00，我会和颖哥聊一场直播，主题是 AI 时代，法律人的第二曲线。这一场会把“法律人怎么学 AI”往后放一放，更想聊两个有法律背景的人，为什么都离开了最初的职业轨道，却走向了完全不同的未来。

如果你也在想“未来十年，我还能成为谁”，欢迎来聊。预约海报稍后放在文末。

再次提示：本文仅用于学习、测试和工作流讨论，不构成法律意见，也不能替代律师审查。

说明：本文件为公众号渲染试稿，建议在浏览器中打开后复制渲染结果，再粘贴到公众号编辑器。