做数据合规这些年，我一直觉得，这份工作里有相当一部分消耗，很难从最终交付的报告中看出来。

业务发来一份PRD，希望尽快得到合规意见。但PRD描述的是功能，评估需要弄清楚的却是：哪些人在什么情况下提供了哪些数据，数据经过哪些系统，谁能访问，保存多久，是否会被用于其他目的。这些信息往往散落在产品文档、界面、技术方案和几轮沟通里，需要一点点拼起来。

好不容易完成评估，产品又改了。此前确认的事实是否还成立，哪些建议已经落实，哪些问题需要重新判断，还得继续追踪。一份报告写完，工作并没有结束。

如果你也做这类工作，可能会有一个很具体的念头：这些反复发生的事情，能不能做成一个适合自己使用的工具？比如，先从产品材料里整理出待确认的问题，让业务补充信息，再把评估意见和整改进度留在同一个地方。

但从“我知道这里很麻烦”到“我能做出一个工具”，中间似乎还隔着不少东西。尤其对于不会写代码的法律人来说，第一步到底应该做什么？

最近看到Cece准备的一场分享，恰好触到了这个问题。她邀请了一位有9年法律科技从业经验、不会写代码的“文科生”产品经理，分享如何用AI搭建数据合规评估系统。

Cece此前从全球数据隐私管理工具市场的变化谈起，讨论了AI与这类工具的关系。这次，她准备把话题落到实际的产品设计和构建过程上。

直播时间是9月13日（周日）19:30，由Cece主持。 她本身是法律AI产品出身，我很期待这场对谈能给法律人带来一个产品视角：我们熟悉的一项业务，究竟怎样被拆成可以设计、实现和验证的功能？

我想邀请大家一起去看，也想借这个机会做一份小调查。因为看完怎样构建产品，我还想和大家继续讨论：自己的专业经验应该放在产品的哪些地方，又怎样判断这些经验确实改善了结果？文末的小调查，就是为后续这一步收集真实问题。

过去我们聊了不少Agent和Skill，也看过它们在具体法律任务中的表现。围绕这些能力做一个系统，还会遇到另一组问题。

以数据合规评估为例，专业人员通常会先想到需要收集哪些事实、适用什么规则、最终给出什么意见。到了产品设计中，还要继续考虑：谁来发起评估？业务上传文档，还是填写问卷？材料不全时，怎样提示补充？法务修改过的判断如何保存？产品更新后，使用者怎样找到上一次评估，并知道哪些内容需要重新确认？

这些安排会影响一个工具能否进入日常工作。使用者可能认可评估方法，却因为不知道该提交什么、看不懂结果，或者无法把任务交给下一位同事，最后又回到邮件、表格和群聊里。

我们开头提到的那些消耗，恰好也是产品设计需要处理的问题。 信息散落，涉及材料如何组织；反复追问，涉及输入和补充流程；整改难跟进，涉及任务、状态和责任人。把这些关系梳理清楚，才有可能从“让AI帮我分析一次”，走到“做一个能够反复使用的工具”。

Skill可以承载其中一部分评估方法，系统则还要组织用户如何调用这些能力、如何处理结果，以及如何继续推进工作。对于已经尝试制作Skill的朋友，这场分享也提供了一个向外看一步的机会。

本场嘉宾会结合Cursor实践，分享需求拆解、功能设计、测试验证和迭代，也会谈到模块混乱、权限问题等开发过程中的坑。我尤其想听听，最初的想法怎样被缩小成第一版功能，哪些需求后来调整了，AI做出来的东西不符合预期时，又如何发现和修正。

嘉宾不会写代码，但有9年的法律科技经验。这样的背景很值得拆开来看：对用户和业务的理解，怎样帮助他做出产品？哪些方法是其他法律人也可以学习、尝试的？这比单纯看一个漂亮的最终界面，更能帮助我们找到自己的起点。

从我的数据合规背景出发，我自然还想往下追问。

假设系统已经可以接收材料、组织评估并生成结果，那么，材料没有写清楚保存期限时，它会列出待确认事项，还是补上一个看起来合理的期限？业务填写的答案前后矛盾时，它能否发现？评估建议写了“完善告知、加强安全措施”，使用者是否知道具体要改哪里？

这些问题既涉及专业判断，也会反过来影响产品设计。

专家知道哪些事实会改变结论，就可以据此设计追问和补充材料的节点；知道哪些情形无法仅凭现有材料判断，就需要让产品保留不确定性，并安排人工确认；知道整改建议经常停留在纸面上，就要考虑如何把建议转成可以跟踪的动作。

专家经验怎样从人的判断，变成产品中可以执行、检查和复用的方法，是我想继续研究的重点。

因此，在Cece这场产品分享之后，我计划演示自己制作的数据合规评估Skill，邀请薛颖律师一起点评，也希望通过不同版本的实际输出，看看专家意见加入之后，事实提取、风险判断和建议究竟发生了什么变化。Cece可以继续从产品视角参与讨论，帮助我们思考这些意见怎样转成具体的设计。

前后两场可以围绕同一类工作展开：先观察产品如何被构建，再检验其中的专业方法。我们也能更具体地讨论，法律人的经验如何与AI能力结合，形成有用的成果。

我们各自觉得值得开发的功能，未必就是使用者最需要的。有人最头疼的是追问业务，有人已经有了完整材料，却卡在判断和建议；也有人做出了自己的Skill，但不知道怎样让同事用起来。

所以，我准备了一份约2分钟的小调查，想了解：

• 你做数据合规时，哪一步最耗费时间？
• 如果先做一个小工具，你最希望它解决什么？
• 从一个想法到一个系统，你最想了解哪部分设计和构建过程？
• 工具能够运行以后，你认为哪些地方最需要专家经验参与？

不需要提供真实项目材料，请勿填写客户名称、个人信息或未公开的业务内容。暂时没有开发经验也完全可以参与，告诉我一件你希望少花些时间、少反复几次的工作，就很有帮助。

这些选择和留言会帮助我准备后续与薛律师的讨论，选择值得实测的场景，也会成为星月计划分领域实战内容的参考。我希望我们围绕具体问题练习：怎样把需求说清楚、把项目运行起来，再把专业经验沉淀进去，并检查实际效果。

如果你也想了解不会写代码的法律人怎样开始构建系统，欢迎先预约CC的这场分享：

一行代码都看不懂：“文科生”无代码手搓数据合规系统实操经验分享

时间：9月13日（周日）19:30
主持：Cece｜法律AI产品出身
嘉宾：9年法律科技从业者、不会写代码的“文科生”产品经理
本场演示：数据合规评估功能的设计与构建

欢迎带着自己工作中最麻烦的那一步来看。我也想知道，看完这场分享之后，你会不会对它有一个新的解决思路。

我是朱玲凤，持续研究数据合规与法律AI如何进入真实工作。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发，我们下篇见。

THANKS FOR READING