夜雨聆风
Claude for Legal 这几天在法律圈刷屏。但很少有人注意到它的一个反常之处。
Anthropic 作为一家以"通用大模型"立身的公司，并没有给法律行业发布一个"法律大模型"。它发布的是一套插件——12 个领域、上百个 skill、若干持续运行的 agent、一组系统连接器，以及一份明确写着"不替代律师"的官方说明。换句话说，他们做的不是一个"会做法律工作的 AI"，而是一套"让法律工作可以被 AI 承接的框架"。
这两件事的差别，对中国大企业法务部门而言至关重要。
因为它意味着：法律 AI 的真正瓶颈，可能从来就不在模型层，而在法律工作本身有没有被组织成 AI 可以承接的形态。这件事在 Claude for Legal 里已经被 Anthropic 帮英美法律工作做了一遍；中国大企业法务部门要不要做、怎么做、谁来做——是一个还没被认真讨论的问题。
笔者想讨论的，正是这个问题。
本文较长，将分三篇发送，目录如下，本篇为第〇至第四节。
〇、当下法务负责人面对的真正问题
一、Claude for Legal 是什么
二、Claude for Legal 的 12 个模块及其对应工作场景
三、为什么选 product-legal 与 corporate-legal 作为反推对象
四、为什么不能把 Claude for Legal 直接“汉化”
五、两个样板模块分别揭示了什么
六、通用架构总览：成熟法务 agent skill 系统的七个层次
七、通用架构展开
八、从两个模块抽象出的三种建设范式
九、中国大企业法务部门的建议建设顺序
十、五种最常见的失败模式
十一、为什么“文件夹管理能力”其实是法务 AI 化的关键能力
十二、对中国大企业法务部门的若干现实提醒
十三、如果要把这件事讲给 CEO 听
十四、结论：一套值得中国法务部门追求的目标形态
〇、当下法务负责人面对的真正问题
在进入 Claude for Legal 本身的拆解之前，先回到中国大企业法务部门自己的处境——因为只有把"我们要解决的真正问题"放在前面，后面对样板的讨论才不会变成对别人产品的隔空仰望。
如果今天召集十位中国大型企业的总法律顾问坐下来，请他们各自描述一下部门眼下最难处理的事，答案会高度一致。
业务的体量和复杂度不断攀升，新法规出台的速度比团队消化的速度更快，海外业务铺开后涉及的法域和小语种远超原有储备，外所费用稳定上升，但 ROI 越来越难向管理层解释。与此同时，高价值的判断经验大量留在少数资深法务脑中（人走即丢），不断采购的 AI 工具由不同人在不同场景下零散地使用，而部门整体能力并未因此上一个台阶。
在这种背景下，"要不要用 AI"已经不再是一个有效问题——大部分大企业法务已经在用。真正的问题是：为什么用了 AI 之后，部门的整体能力并没有发生结构性变化？
这个问题的答案不在模型层，而在系统层。一个法务用 Claude 或某个国产模型审一份合同、起草一份 memo、做一次结构化整理，这种使用方式的天花板，是这名法务自己的判断框架；判断框架不流通，部门的整体能力就不会增长。新人入职依旧靠师徒制慢慢带，资深法务跳槽依旧把组织最关键的判断逻辑一起带走，外部律师依旧拿着按小时计费的账单做着本可以沉淀到部门内部的重复工作。
如果把"使用 AI"理解为给每名法务配一把更好的工具，那么这条路径的尽头大致就在这里。要让部门整体能力真正发生改变，需要换一个问题：不是"我们每个人怎么用 AI 用得更好"，而是"我们怎么把部门里那些反复发生的专业判断，建成一个可以被组织调用、被新人继承、被外部律师之外的力量承接的系统？"
这就是本文希望开启的讨论：通过拆解 Claude for Legal 提供的 product-legal 和 corporate-legal 两个模块，尝试反推出一个样板——但这不是终点，只是一个让我们能看清问题结构的参照物。
一、Claude for Legal 是什么：一个面向法律工作的插件生态，而不是一个单独产品
在进入对两个具体模块的拆解之前，有必要先交代 Claude for Legal 本身是什么。它并不是一个独立的法律 AI 产品，如果不先建立这层认知，后文关于 skill、agent、connector 和模块化架构的讨论，容易被误读成某个单一工具的个别实现。
根据 Anthropic 的官方材料，Claude for Legal 可以被理解为 Anthropic 面向法律工作的一个开放式能力组合：它把不同法律实践领域所需的skills、subagents 和 connectors打包成可安装插件，用于在 Claude Cowork、Claude Code 或通过 Managed Agents API 运行的工作流中支持法律专业人士。官方材料将 skill 定义为"可复用、被编码的工作流"，用于教会 Claude 以可重复的方式完成特定法律任务；将 connector 定义为通过 MCP 连接外部数据源的接口；将 plugin 定义为把 skills、subagents 和 connectors 打包到某一法律实践领域中的安装单元。
这意味着，Claude for Legal 并不是一个单独的"法律大模型"，也不是一个孤立的"合同审查软件"。它更像是一套围绕不同法律实践场景组织起来的参考实现库：
一方面，它展示了 Anthropic 认为哪些法律工作可以如何被拆解为标准化 skill； 另一方面，它也展示了这些 skill 如何与持续运行的 agent、外部系统 connector、人工复核和组织 playbook 结合起来。
Anthropic 官方材料特别强调：这些插件并不替代律师，所有输出都应由专业人士审阅；法律团队的成功采用通常遵循"先打基础、再做聚焦试点、再逐步扩展"的路径——这一点对于中国大企业法务部门尤其重要，因为它提示我们：Claude for Legal 的价值首先在于展示一种建设方法，而不是提供一套可直接复制上线的现成答案。
二、Claude for Legal 的 12 个模块及其对应工作场景
截至官方材料当前版本，Claude for Legal 体系中列出了 12 个面向法律专业人士的插件模块。它们并非都针对企业法务，也并非都适合中国企业直接迁移；但从"法律工作如何被拆成 skill"的角度看，这 12 个模块共同构成了一张很有价值的能力地图。
从这张图片可以看到，Claude for Legal 并不是围绕单一"法律 AI 助手"展开，而是把法律工作拆成若干相对稳定的实践领域，再在每个领域内部继续拆出更细的工作单元。这种"领域模块化 + 模块内 skill 化"的思路，正是后文架构分析的基础。
三、为什么选 product-legal 与 corporate-legal 作为反推对象
12 个模块面向不同读者各有价值，本文之所以单独选 product-legal 与 corporate-legal 作为反推对象，有两层原因。
1. 这两个模块代表了两种几乎相反的系统形态
product-legal 围绕一条连续业务链路展开——从风险校准、快速分流、正式上线审查、复杂事项评估到前置监测，强调的是"一条业务流上不同深度的工作如何分层处理"。
corporate-legal 则覆盖多个相对独立的专业域——并购、董事会与公司秘书、公众公司治理、实体管理，强调的是"多个专业域如何在共享治理底座上并行运行"。
中国大企业法务部门的真实工作，既不是纯粹前者，也不是纯粹后者，而是两种形态的组合。理解这两种几乎相反的设计逻辑，对反推自己部门该建什么、按什么顺序建，比逐一研究 12 个模块更有效率。
2. 这两块业务也是笔者亲历过的两类工作
笔者此前曾负责某大型企业的投资法务部门，对应的工作正是 corporate-legal 所覆盖的那类问题——并购尽调、交易文件、董事会与股东会决议、交割清单、交割后整合……这些工作的特征是周期长、文件多、跨域协同、单点失误后果重，是典型的"专业模块型"和"事项链路型"工作。
当下笔者则负责该大型企业的产品出海合规法务部门，对应的工作正是 product-legal 所覆盖的那类问题——多法域产品上线审查、营销表述合规、AI 与数据相关功能的风险评估、跨境业务的前置预警。这类工作的特征是高频、节奏快、与业务系统强耦合、需要前置介入。
之所以提及这层背景，不是为强调资历，而是为了说明：本文对这两个模块的拆解，不是从产品介绍页或官方文档反推出来的"想象中的工作流"，而是把 Claude for Legal 的样板，放回到笔者亲身负责过的两类业务里去检验——它对应的是真实部门里反复发生的工作。这种"亲历对照"也正是本文倾向于把两个模块作为对照样本、而不是按 12 个模块逐一展开的原因。
3. 这两个模块也对应了本文最想推进的判断
无论是投资法务还是产品出海合规法务，真正值得讨论的都不是"要不要给法务配一个大模型"或"要不要做几个法律问答 bot"，而是另一个更难也更值得做的问题：
怎么把部门里反复发生的专业判断、隐性经验和工作链路，建成一套能够长期嵌入组织、持续承接专业工作的 agent skill 系统？
这里所说的 agent skill 系统，不应被理解为"很多 skill 的集合"，更准确地说，它是：
将法务部门的专业经验、工作范式、组织规则、系统接口和持续运行机制，转化为一套可调用、可复用、可审阅、可治理、可扩张的数字化专业系统。
所选两个讨论模块的价值正在于此：它们各自给出了在不同业务形态下，这样一套系统应当如何被组织、如何被拆解、如何被运行的具体示范——为本文后面要展开的"通用架构"反推，提供了两个最有信息量的样本。
四、为什么不能把 Claude for Legal 直接"汉化"后规模化用于中国企业法务部门
Claude for Legal 对中国法务部门最有价值的地方，在于它提供了一个非常优秀的学习示范；但它并不是一个可以直接翻译、换法规、再批量部署到中国企业法务部门的现成系统。
1. 差异不是一层，而是四层
直接照搬不可行的原因，至少分布在四个互不重叠的层次上。把它们混为一谈，会导致"加个中国法适用要求就能落地"这种最常见的误判。
第一层 法律体系层——适用法律、监管框架、文书格式、阈值标准、风险分类的差异。这一层最明显，也相对容易处理：换法规、换模板、换术语。
第二层 组织结构层——决策路径、签批层级、董事会与股东会的实际权重、党委与法务的关系、集团与子公司的法律事务分工。这一层决定了同一个"董事会决议"在不同组织里的真实流转方式完全不同，仅靠翻译解决不了。
第三层 工作方式层——法务部门在公司里的定位差异。英美大企业的 in-house 多数定位为 business partner，介入早、决策权重高、与外律分工边界清楚；中国大企业法务相当一部分仍处于"风险把关人"位置，介入晚、对业务节奏的影响力有限。这层差异决定了"前置介入"型 skill 未必能在中国企业法务部门里跑起来。
第四层 技术栈与数据生态层——Claude for Legal 默认连接的是 Slack、Drive、Jira、Linear、Asana、Box、VDR；中国大企业的真实环境是飞书/企业微信/钉钉、企业自研 OA/BPM、合同管理系统、电子签、印章管理。这一层差异容易被低估，但常常是项目跑不动的真正原因。
四层差异中，最容易处理的是第一层，最难处理的是第二、第三层。一篇只解决了第一层的"中国版方案"，往往会在第二、第三层撞墙。
2. 法律内容不同，只是最表层的问题
最容易想到的障碍，是其大量 skill 基于美国法、英国法或英美法律工作习惯设计。对中国企业而言，当然需要替换：
适用法律；
监管框架；
文书格式；
审批机制；
风险分类；
业务系统连接。
但如果仅把这些内容"汉化"，本质上仍然只是对既有模板做本地化编辑，并没有回答更关键的问题：中国企业法务工作究竟按何种逻辑运转？
3. 企业法务部门与个体律师或法务使用 Claude for Legal，不是同一个问题
对一名律师或一名公司法务个人而言，Claude for Legal 可以作为个人生产力工具：无论是帮助其审核具体合同、起草法律意见是还是做结构化整理。
但对一个大型企业法务部门而言，要解决的问题则更为复杂和体系化，例如：
多个团队是否共用同一判断口径；
历史经验能否沉淀为组织资产；
skill 输出能否进入现有审批和业务系统；
不同业务线之间如何共用底座、保留差异；
风险等级、升级链、人工复核、权限控制如何被制度化；
系统怎样维护、更新、审计和持续进化。
因此，个人层面的"拿来就用"，与部门层面的"规模化建设"，本质上是两类问题。
4. 真正需要建设的是"本部门自己的系统"，而不是"适配别人的系统"
笔者认为，对中国大企业法务部门而言，可以考虑以下路径：
首先将本部门真实存在的业务场景、流程、风险判断和组织规则梳理清楚；
其次识别哪些场景最适合先被 AI 提效（claude for legal 各工作模块和下层 skill 所对应场景是很好的参考材料）；
然后围绕这些场景，从 0 到 1 设计自己部门的以下工具：
shared playbook：整套系统共同遵守的规则底座。它先回答几个最根本的问题：这个法务部门由谁组成、负责什么业务、风险偏好如何、什么事项必须升级、什么动作必须由人确认。可以把它理解为一份“机器可读的部门手册”；
skills：一个个被标准化的专业动作，例如产品上线初筛、并购尽调问题提取、营销文案审查、董事会决议起草。它们不是泛泛的“会做法律工作”，而是各自有清晰的输入、输出、判断口径和升级条件；
agents：持续承担某类职责的代理。比如持续扫描未来上线项目的“上线雷达”，持续监控数据室新增文件的“数据室 watcher”。它们真正带来的变化，是让法务从被动响应走向主动发现；
references：这套系统背后的知识层，包括内部审查框架、标准 schema、先例库、易变事项清单和模板库。没有这一层，skill 和 agent 就很难稳定地按本部门的方式做事；
connectors：负责把系统接入真实业务环境，例如飞书、钉钉、OA、合同系统、电子签、知识库和数据室。没有这些连接，系统当然也能在聊天窗口里工作，但它很难真正进入业务流程；
review gates：是嵌入关键节点的人类复核机制，用来区分哪些结论可以自动流转、哪些必须由法务确认、哪些重大事项必须升级到 GC。这也是法律 AI 与普通办公自动化最重要的分界线；
持续更新机制：把法规变化、内部制度调整、失败案例和用户反馈不断回流进系统。否则，再好的系统也会随着时间慢慢失真。
换言之，中国企业法务部门真正需要的是一种工程化建设，而不是一种翻译式迁移。
因此，可以把 Claude for Legal 在中国企业法务场景中的定位概括为：
它是一个极好的"参考实现"和"教学样板"，但不是一个可以直接大规模复制到法务部门的成品系统。
这一区分非常重要。因为只有承认这一点，后续的建设思路才会从"如何把别人的系统改成中文版"，转向"如何借鉴别人的系统方法，搭建我们自己的法务 AI 操作系统"。
