AI时代律师生存之道（六）：以合同修订skill为例，如何出品生产级别的skill

什么是生产级别的skill？能用，能稳定输出，能达到行业80%以上的输出质量的skill就是生产级别的skill。这里的稳定，不是每次给出完全相同的答案，而是面对不同材料，仍然执行同一套可靠的判断流程。

一个完整的skill，通常不只是一个SKILL.md文件。我的理解是，它至少可能包含三类内容。

第一类是SKILL.md，也就是这个skill的总说明书：它解决什么问题，什么情况下调用，按什么步骤工作，遇到什么情况停止或追问，最后交付什么。核心流程要放在这里。

第二类是参考文件。它们可以放按需读取的子规则、审查清单、示范条款、失败处理规则，也可以放模板。模板的作用经常被低估：如果要反复生产格式相同的函件、法律意见书、尽调报告或者其他文书，模板对稳定格式、结构和交付口径很有帮助。所有任务都必须遵守的核心规则仍要留在SKILL.md里，只有特定场景才使用的材料才放到参考文件中。主文件还要告诉Agent在什么情况下读取哪个参考文件，否则文件放在那里，不等于Agent一定会用。

第三类是脚本。律师不需要成为技术人员才可以用脚本。可以把脚本理解为skill里负责“精确动手”的部分：模型负责理解合同、作出法律判断、生成修改方案；脚本负责读取电脑文件、定位文本、写入Word修订痕迹、检查结果是否正确。这些恰好是大模型容易说得很好、但不能稳定精确完成的事情。

以合同修订skill为例，我的word_redline.py脚本会先读取Word文档结构，帮助定位拟修改的段落；再把模型确定的修改动作写成Word/WPS可以识别的原生修订和批注；最后检查修订数量、作者、时间戳、文档XML是否完整。律师不一定要看得懂脚本，但要知道脚本做什么、什么情况下不能用，以及怎么验收它的结果。

这也和Anthropic公开的实践经验相同：不要让Agent每次都用自然语言重新完成重复、确定的操作，而应把这类能力沉淀为脚本或函数库。脚本把定位、写入、校验这类需要精确执行的动作固定下来，Agent则把有限的上下文和推理留给判断、组合与例外处理。脚本不替代律师判断，恰恰是让律师判断不必消耗在容易跑偏的机械操作上。

我总结了出品生产级别skill的五步法。

第一、定义skill。你想要什么skill，这个skill的边界在哪里，适不适合做成skill，做成一个skill还是多个skill。这需要自己的思考。合同修订就是个典型且合适的skill场景，之所以叫合同修订而不是合同审查skill，也确定了它的边界，要像律师一样用修订模式修改合同。

第二、梳理流程。合同修订不是一个环节繁多的场景，但它仍然有一条必须讲清楚的流程：确定修订立场，判断审查强度，找出真正需要修改的风险，再把这些判断落实为Word红线并完成校验。创建skill的秘诀之一，就是把这些看起来理所当然的动作拆开，好比把大象关进冰箱需要几步。

不同skill需要解决的流程难题不一样。合同修订skill真正难的，不只是让Agent“使用修订模式”，而是让它学会红线修订，也可以叫最小化修订。我也是经过多次反复修改，才获得一个接近真人、能够真实完成红线修订的skill，当然也伴随着模型能力的进步。合同不是改得越多越专业。语言不够漂亮、顺序不够顺眼、条款还能写得更强势，都不当然构成修改理由。只有不修改会实质影响委托方核心权利、合同履行或者风险救济时，才有必要动正文。

但最小化修订也不是简单地少改几个字。以我的合同修订skill为例，我把合格的红线概括为“必要、原子、到位”：必要，是这处确实该改；原子，是一次修订只表达一个连续差异，尽量不整段重写；到位，是既然改了，就要在当前句或者当前款内补齐主体、条件、期限、标准、例外或者责任后果，不能只删掉一个风险词，留下半截条款。因此，最小化修订的意思不是改得越少越好，而是只改必要的地方，并且每一处都改到位。

这套流程最后还要有完成标准：每一处修改都能在Word/WPS里显示为可追踪的增删改，修改后句义完整、格式不乱，并且通过脚本校验和人工复读。

第三、融入knowhow。知道工作流程远远不够，更重要的是融入knowhow，也就是一个资深的合同高手到底如何审查合同，这个方法要交付给Agent。你可以把你审查合同的独门秘籍告诉Agent，在交流中总结出合同审查的方法。

例如，我的合同修订skill要求同时从两个角度看条款：正常履行时，主体、期限、标准、付款、交付和验收是否清楚；发生违约时，解除、追责和争议解决能不能真正落地。它还要区分法律风险和商业条件，不能因为站在甲方立场，就擅自把违约金从20%改成30%。这类判断不会因为写进了流程就自动出现，它们才是真正需要融入skill的knowhow。

多数时候我们并不具备这样的秘籍或者抽象能力。幸好，合同审查这个典型工作场景，有很多参考资料，把这些资料喂给AI，即所谓“蒸馏”，再在与Agent的交流中形成符合自己工作习惯的方法，这是第二种方式。第三种同样有效的方法是把质量上乘的合同修订稿提供给AI学习并总结出方法。以上三种方法，适合于各种场景，经常需要相互结合。

第四、制作skill。各大Agent都有创建skill的skill。这些skills不仅能够创建skill，而且能够用来优化skill，看起来是一句平淡无奇的话，其实不少人没有意识到。这里隆重推荐我近期发现的大神Matt Pocock写的skill：writing-great-skills。通过认真研读“writing-great-skills”文档，我对什么是好的skill也有了更深刻的认识。

一个很实用的制作原则是：主流程要短，规则要有唯一的位置，细分材料要外置。不要把每一种合同的审查细则、每一条示范条款都硬塞进SKILL.md。主文件只写所有合同修订都适用的判断流程和交付标准；股权转让、劳动、租赁、数据合规等特别规则，可以作为参考文件，在需要时再读。这样既不机械，也不会因为上下文混淆而失控。

优化skill也不是一味往里增加规则。重复的规则、已经失效的旧要求，以及“专业、全面、严谨”这类不能真正改变Agent行为的空话，都应该删掉。规则越多不一定越稳定，重要的是每一条都在发挥作用。

第五、测试效果。有了初代skill后就进入了测试、反复测试、修改skill的循环，这是个枯燥且必要的环节。

测试不要只拿一份“干净合同”跑通就算完成。至少可以准备几类材料：甲方强势和乙方弱势的合同、付款和验收风险突出的合同、责任限制和解除条款复杂的合同、格式复杂或已有修订的Word。测试时分别看四件事：法律判断是否站稳立场；修改是否真正解决风险而不是为了显得全面乱改；Word修订痕迹和排版是否可交付；脚本或流程遇到复杂对象、定位失败时如何解决。能把失败处理好，往往比多改几条条款更接近生产级别。

还有什么注意事项吗？

首先，你要准确定义你的skill。例如，要不要为这个技能加上不同合同的不同修订规则，原则上没有必要。高频的同类型合同当然可以配一套专门的参考规则或模板，但不必因此把通用合同修订skill塞成万能工具。况且大模型的智能在进步。如果你需要大量修订同类型合同，更可能需要的是一套面向该类业务的专门规则、模板，甚至一个新的skill或配套脚本。

要不要为每处修订批注理由？不需要，这个只会让客户觉得你很AI，绝大多数场景下修订理由已经直接体现在修订内容中。需不需要输出审查报告？同理，只有特殊情形才需要。

其次，要正确理解skill的“自动调用”。各大Agent都宣传能够自动调用skill，这当然是真的，但并不意味着所有skill都应该交给大模型自动选择。skill大体可以分成两类：一类由用户自己点名调用，适合内部专用、边界复杂或者不希望误触发的工作；另一类由大模型根据用户的任务自动判断是否调用，适合高频、边界清楚的工作。两种方式没有高下，区别只是谁来决定使用它。

如果希望大模型自动调用，description就要写准。它很像给skill写一个简短的案由，要让模型知道这个skill处理什么任务、在什么情况下使用。比如：“合同修订：把合同审查判断直接写入.docx原生修订。用户要求按某一方立场修改合同、输出Word红线稿、保留修订痕迹时使用。”这样就能把合同修订与法律意见、纯法律咨询、重写合同等相邻任务区分开。如果本来就要求用户点名调用，description只需要让用户看得懂它是做什么的，不必塞入一长串触发条件。

再次，你要学会找skill和修改skill。有很多已经开源的skill。至于怎么修改，和创建skill一样，也可以交给创建skill的skill，上文已经说过。

最后，我们要知道，Agent给文科生带来的最大能力，是把工作代码化，而关于电脑的一切都由代码驱动。合同修订skill里有一些脚本，我压根看不懂，但它们确实在有效工作。我们还能让Agent写单独的脚本，比如监控电脑文件夹，发现待审合同就自动提交审查，从而实现工作自动化。技术门槛正在降低，这时候对人更高的要求，是有想象力，而且真的会工作。

潘松，大成成都分所高级合伙人，专注投融资与合规领域。