!封面
!封面
!封面
最近因为陆续做了一些AI认知方面的分享，加上开源了Claude-for-Legal-ZH（中国法适配版）项目以及合同审核、法律分析几个项目，我接到了不少交流或评测邀请。北京、上海多家做法律AI产品的公司，也有不少个人开发者，来聊产品方向和技术路线。
这些交流里有一个非常一致的倾向：几乎所有人都在强调同一个词——Skill（可复用的AI能力单元）。做产品的说自己在堆Skill库，做投资的问"你们的Skill有多少个"，做竞品分析的比较"谁的Skill覆盖面更广"。
整个法律AI赛道似乎正在形成一个集体判断：Skill就是法律AI的产品核心，谁掌握了最多、最好的Skill，谁就赢了。
这个判断只对了一半。Skill确实重要，但它不是全部，甚至不是最难的部分。我想说清楚为什么，从我在这几轮交流中发现的问题说起。
Skill为什么重要但不够
Skill是一段封装好的指令，让AI在特定场景下执行特定任务。"审查一份买卖合同"是一个Skill，"检索某个案由的类案"是一个Skill，"提取合同中的关键条款"也是一个Skill。它就是工具箱里的一把扳手，确实不可或缺。没有Skill，AI面对法律场景什么事也干不了。
但Skill有几个自身框架内解决不了的局限。
它首先是扁平的。Skill要么放在全局，要么放在项目，中间没有层。法律工作的复杂度却是分层的：有些规则对所有案件通用，比如证据认定的一般原则；有些规则只适用于某个业务领域，比如建设工程特有的结算规则；还有些规则只针对某个具体项目，比如某个客户的专属审查标准。你把一个合同审查Skill放在全局，它照顾不到项目的特殊性；放在项目里，又失去了通用性。这不是Skill写得不好，是Skill这个容器本身的结构限制。
更麻烦的是上下文割裂。每个Skill独立运行，Skill之间没有状态传递。合同审核做完发现了风险条款，这个发现能不能自动喂给后续的风险评估？案例检索找到了三个类案，能不能自动进入下一个写作环节作为论据？在纯Skill架构下，这些"之间"的事没人管。每个Skill只对自己的输入输出负责，不关心上下游。
还有一个根本性的问题：能力不等于编排。拥有一百个法律Skill，和拥有一个能协同调用这一百个Skill的系统，是完全不同的事。100个零件散落在地上不等于一辆车。零件之间的关系——谁先谁后、谁调谁、什么条件下触发——才是让零件变成系统的关键。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 260">
<rect width="600" height="260" fill="#fafafa" rx="4"/>
<text x="130" y="28" text-anchor="middle" font-size="14" font-weight="700" fill="#333" font-family="system-ui, sans-serif">纯 Skill 架构</text>
<rect x="30" y="52" width="90" height="34" rx="3" fill="#e8e8e8" stroke="#ccc" stroke-width="1"/>
<text x="75" y="74" text-anchor="middle" font-size="11" fill="#666" font-family="system-ui, sans-serif">合同审查</text>
<rect x="140" y="48" width="90" height="34" rx="3" fill="#e8e8e8" stroke="#ccc" stroke-width="1"/>
<text x="185" y="70" text-anchor="middle" font-size="11" fill="#666" font-family="system-ui, sans-serif">案例检索</text>
<rect x="60" y="102" width="90" height="34" rx="3" fill="#e8e8e8" stroke="#ccc" stroke-width="1"/>
<text x="105" y="124" text-anchor="middle" font-size="11" fill="#666" font-family="system-ui, sans-serif">法条查询</text>
<rect x="170" y="98" width="90" height="34" rx="3" fill="#e8e8e8" stroke="#ccc" stroke-width="1"/>
<text x="215" y="120" text-anchor="middle" font-size="11" fill="#666" font-family="system-ui, sans-serif">文书起草</text>
<rect x="100" y="155" width="90" height="34" rx="3" fill="#e8e8e8" stroke="#ccc" stroke-width="1"/>
<text x="145" y="177" text-anchor="middle" font-size="11" fill="#666" font-family="system-ui, sans-serif">风险评估</text>
<text x="130" y="230" text-anchor="middle" font-size="12" fill="#999" font-family="system-ui, sans-serif">各 Skill 独立运行，互不关联</text>
<line x1="278" y1="125" x2="322" y2="125" stroke="#333" stroke-width="2"/>
<polygon points="320,120 330,125 320,130" fill="#333"/>
<text x="470" y="28" text-anchor="middle" font-size="14" font-weight="700" fill="#333" font-family="system-ui, sans-serif">Harness 架构</text>
<rect x="350" y="42" width="240" height="185" rx="4" fill="none" stroke="#333" stroke-width="1.8"/>
<text x="470" y="62" text-anchor="middle" font-size="11" fill="#333" font-weight="600" font-family="system-ui, sans-serif">HARNESS 编排层</text>
<line x1="358" y1="70" x2="582" y2="70" stroke="#e0e0e0" stroke-width="1"/>
<rect x="358" y="78" width="108" height="26" rx="2" fill="#f0f0f0" stroke="#aaa" stroke-width="1"/>
<text x="412" y="95" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">规则引擎</text>
<rect x="474" y="78" width="108" height="26" rx="2" fill="#f0f0f0" stroke="#aaa" stroke-width="1"/>
<text x="528" y="95" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">工具路由</text>
<rect x="358" y="112" width="108" height="26" rx="2" fill="#f0f0f0" stroke="#aaa" stroke-width="1"/>
<text x="412" y="129" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">知识编排</text>
<rect x="474" y="112" width="108" height="26" rx="2" fill="#f0f0f0" stroke="#aaa" stroke-width="1"/>
<text x="528" y="129" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">状态管理</text>
<rect x="358" y="146" width="224" height="26" rx="2" fill="#f0f0f0" stroke="#aaa" stroke-width="1"/>
<text x="470" y="163" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">工作流管线</text>
<line x1="358" y1="182" x2="582" y2="182" stroke="#e0e0e0" stroke-width="1"/>
<rect x="358" y="190" width="68" height="24" rx="2" fill="#e0e0e0" stroke="#bbb" stroke-width="1"/>
<text x="392" y="206" text-anchor="middle" font-size="9" fill="#888" font-family="system-ui, sans-serif">Skill A</text>
<rect x="434" y="190" width="68" height="24" rx="2" fill="#e0e0e0" stroke="#bbb" stroke-width="1"/>
<text x="468" y="206" text-anchor="middle" font-size="9" fill="#888" font-family="system-ui, sans-serif">Skill B</text>
<rect x="510" y="190" width="68" height="24" rx="2" fill="#e0e0e0" stroke="#bbb" stroke-width="1"/>
<text x="544" y="206" text-anchor="middle" font-size="9" fill="#888" font-family="system-ui, sans-serif">Skill C</text>
<text x="470" y="247" text-anchor="middle" font-size="12" fill="#999" font-family="system-ui, sans-serif">Harness 调度 Skill，协同运转</text>
</svg>真正的壁垒在编排层
我想再强调这个概念：Harness（驾驭层）。
Harness不是AI本身，是让AI在真实工作场景中可靠运转的那套工程体系。打个粗略的比方：如果AI模型是发动机，Harness就是整台车——传动系统、刹车系统、仪表盘、安全气囊——让发动机的动力能可靠地传到轮子上的所有东西。
具体来说，Harness管几件事：什么时候触发什么规则，规则冲突时怎么排优先级；什么任务用什么工具，工具挂了怎么降级；什么场景调什么知识库，不同来源的信息可信度怎么标注；从输入到输出的完整流程怎么串，每个环节的质检标准是什么；跨步骤、跨会话的上下文怎么延续。
在这个架构里，Skill只是一个被调度的能力单元，和命令行工具、MCP服务器（一种让AI调用外部工具的标准接口）、规则文件是平级关系。调度它们的不是某个全能的Skill，是Harness。
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 290">
<rect width="600" height="290" fill="#fafafa" rx="4"/>
<text x="300" y="26" text-anchor="middle" font-size="14" font-weight="700" fill="#333" font-family="system-ui, sans-serif">Harness 分层架构示意</text>
<rect x="60" y="42" width="480" height="46" rx="3" fill="#f2f2f2" stroke="#aaa" stroke-width="1.5"/>
<text x="300" y="62" text-anchor="middle" font-size="12" font-weight="600" fill="#333" font-family="system-ui, sans-serif">全局规则层</text>
<text x="300" y="78" text-anchor="middle" font-size="10" fill="#888" font-family="system-ui, sans-serif">证据认定原则 · 法律研究规范 · 输出规范</text>
<rect x="100" y="102" width="400" height="46" rx="3" fill="#e8e8e8" stroke="#999" stroke-width="1.5"/>
<text x="300" y="122" text-anchor="middle" font-size="12" font-weight="600" fill="#333" font-family="system-ui, sans-serif">领域规则层</text>
<text x="300" y="138" text-anchor="middle" font-size="10" fill="#888" font-family="system-ui, sans-serif">建工结算规则 · 投融资审查标准 · 合同分类路由</text>
<rect x="140" y="162" width="320" height="46" rx="3" fill="#ddd" stroke="#888" stroke-width="1.5"/>
<text x="300" y="182" text-anchor="middle" font-size="12" font-weight="600" fill="#333" font-family="system-ui, sans-serif">项目规则层</text>
<text x="300" y="198" text-anchor="middle" font-size="10" fill="#888" font-family="system-ui, sans-serif">客户专属标准 · 案件特定配置</text>
<rect x="80" y="228" width="100" height="30" rx="2" fill="#d0d0d0" stroke="#aaa" stroke-width="1"/>
<text x="130" y="248" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">Skill 插件</text>
<rect x="195" y="228" width="100" height="30" rx="2" fill="#d0d0d0" stroke="#aaa" stroke-width="1"/>
<text x="245" y="248" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">CLI 工具</text>
<rect x="310" y="228" width="100" height="30" rx="2" fill="#d0d0d0" stroke="#aaa" stroke-width="1"/>
<text x="360" y="248" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">MCP 服务</text>
<rect x="425" y="228" width="100" height="30" rx="2" fill="#d0d0d0" stroke="#aaa" stroke-width="1"/>
<text x="475" y="248" text-anchor="middle" font-size="10" fill="#555" font-family="system-ui, sans-serif">知识库</text>
<text x="300" y="280" text-anchor="middle" font-size="10" fill="#aaa" font-family="system-ui, sans-serif">能力单元层 — 被 Harness 调度，不做调度</text>
</svg>Harness比Skill难复制得多。一段Prompt封装的Skill，竞争对手花几天就能逆向。你写了一个合同审查Skill，别人拿你的输出样本做参照，迭代几轮也能做到八九不离十。但Harness是系统工程——架构设计、分层规则、工具链编排、知识库治理，每一个环节都需要和具体的法律业务深度磨合。这种磨合是在真实案件中、在客户反馈中、在一次次幻觉和错误中迭代出来的，不是坐在办公室里能想出来的。
一句话：Skill是菜谱，Harness是后厨管理体系。菜谱可以抄，但一家餐厅能不能稳定出菜，看的是管理体系。
行业里也能看到这个趋势。Anthropic自己在Claude for Legal上的方向，推的是整套工作流编排能力，不是一个Skill市场。真正在企业级场景跑通的法律AI产品，竞争力都不在单一Skill的数量上，而在整体系统的可靠性上。
几个会被问到的反驳
说到这里，通常会引来几个反驳，我逐个回应。
有人会说，Skill多了自然能组合出复杂工作流。其实不能。组合需要编排逻辑，编排逻辑本身是更高层的设计。你可以有最齐全的一箱子工具，但没有施工图告诉你先用哪个后用哪个、遇到意外怎么处理，工具箱再满也是摆设。
也有人说，用户不需要懂Harness，用好Skill就行了。短期确实如此。用户还在"试一试"的阶段，单个Skill好不好用确实是第一感知。但一旦进入日常依赖——律师每天用它审合同、写文书、做检索——Skill的局限就会暴露：同一个任务今天和昨天的结果不一致，不同Skill的输出互相矛盾，想针对自己的案件做一点定制却改不了。企业级客户需要的不是更多Skill，是更可控的系统。
还有人会问，那你的意思是Skill就不重要了？不是。Skill是Harness的必要组件，没有好的Skill，Harness就是空架子。问题在于把Skill当成"全部"还是"一部分"。这个定位判断，决定了产品方向的天壤之别。
交流中的隐忧
回到那些交流场景。
每一场对话我都认真听了。一个很明显的规律：越是把Skill当成产品核心的团队，在"系统可靠性"这个点上越容易语焉不详。问"合同审核做完发现问题，怎么自动流转到下一个环节"——答不上来。问"不同项目的规则差异怎么处理"——说"我们正在做"。问"跨会话的上下文怎么保持一致"——沉默。
这些都不是靠加更多Skill能解决的。它们是编排层的问题。
这让我有些担忧。如果整个行业都在朝Skill堆量的方向狂奔，忽视了编排层的建设，客户最终拿到的是"能力很多但系统不可靠"的产品。法律场景对可靠性的容忍度极低。律师可以接受AI偶尔不够聪明，但没法接受它今天说的和明天说的不一样，或者在一个关键条款上悄悄改了判断。一次严重的流程断裂，可能就让客户彻底失去信任。
而客户失去信任之后，离开的不是某一家产品，是"法律AI"这个品类。这对整个行业都是灾难。
我也走过弯路
我最早搭法律AI工作流的时候，也在堆Skill。合同审核、案例检索、法条查询、文书起草，一个一个往上加，加完觉得自己挺厉害。
很快碰到了天花板。瓶颈不在单个Skill的能力上，在它们之间怎么协同：什么时候调哪个Skill，不同项目的规则差异怎么适配，知识库的权威性和时效性怎么保证，跨步骤的状态怎么传递。
后来我把重心转到了Harness上。做了分层规则引擎——全局规则对所有项目生效，领域规则只对特定业务生效，项目规则只对当前案件生效。做了工具路由表——什么任务用什么工具，工具挂了怎么降级。做了知识库交叉引用——写完文章自动检索知识库，验证引用的法条和案例是否仍然有效。做了输出流程管线——从大纲到正文到去AI痕迹到附作者简介，每个环节有明确的质检标准。
这些不是Skill。但它们决定了Skill能不能在正确的时机、以正确的方式被调用。开源出来的Claude for Legal项目，核心架构就是这个思路——Skill只是Harness里的一个插件元素。
结尾
法律AI的下一阶段竞争，焦点会从"谁有更多Skill"转向"谁的Harness更可靠"。
如果你在做法律AI——做产品也好，给自己搭工具也好——花在编排层架构上的时间，至少应该和花在单个Skill上一样多。不是Skill不重要。是光有零件不够，你得把它们装成一台能跑的车。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。