Anthropic透露了对法律AI插件基础设施的顶尖理解

假设你git到了Anthropic 官方发布，面向法律行业的插件claude-for-legal 的源码，里面有12个插件：商事合同、劳动法、诉讼、合规、尽职调查……

但你一看，这玩意儿针对美国的啊，我是跟中国法打交道的，玩个锤子还，做适配先。

于是你在这个基础上做了中国化改造，把北大法宝的MCP接口或着我星球会员的法律法规和案例查询CLI接进去了，把审查逻辑里的 Delaware law 换成了《民法典》，把 GDPR 换成了《个人信息保护法》。

你想用这个改造过的版本搭一套自己的法律AI体系。

你装好了劳动法插件，花了一个小时完成初始化，填好了你们所的劳动争议审查规则、经济补偿金的计算偏好、哪类风险点要标红。

第二天插件出了新版，你安装更新。打开一看，配置全没了，模板恢复了初始状态。

你让AI检索类似案件，它回复说"根据北大法宝查到的相关判例……"，但北大法宝的MCP你还没有配置，账号也还没有绑定。

AI看到配置文件里声明了北大法宝的连接信息，就认为它能用，然后从训练数据里"补充"了一批看起来真实的判决引用。

你说"帮我看看这个劳动合同"，系统里有竞业限制审查、劳务派遣合同审查、保密协议审查等十几个专项技能。

AI选了一个，结果是错的，和你发的合同类型不符。你重发了一遍，这次选了另一个，结论又不一样。

这三个问题，不是偶发的bug，是没有基础设施时必然会发生的系统性缺陷。解决它们的，是四个文件：plugin.json、.mcp.json、CLAUDE.md、SKILL.md。

第一层：plugin.json — 插件怎么被识别

每个插件根目录下有一个隐藏文件夹 .claude-plugin/，里面是一个8行的 plugin.json，只有四个字段：name、version、description、author。

name 是整个插件在系统里的地址起点。技能的触发命令从这里派生——商事合同插件叫 commercial-legal，它的审查技能触发命令就是 /commercial-legal:review；劳动法插件叫 employment-legal，对应命令是 /employment-legal:review。两个插件都有叫 review 的技能，但前缀来自各自的 name，永不冲突。用户配置文件的存储路径也从 name 派生，不同插件的配置物理上分开存放。

version 不是给用户看的更新日志，是给系统的迁移信号。用户在 1.0.1 下填好了所有配置，插件升到 1.0.2，系统看到版本号变了，就知道要去旧路径检查有没有已填写的配置，找到了就迁移到新路径，再触发增量问卷，只问新增字段，不让用户重来。

版本号永远写 "1.0.0" 不更新，这个机制就失效了。

description 是四个字段里最容易被忽视的。它不是给人看的说明，是给AI做技能匹配的触发信号。

当用户说"帮我审一下这份劳动合同"，系统需要从12个插件、几十个技能里找到最相关的那个，判断依据就是把用户意图和每个插件的 description 做语义匹配。

description 里写"review employment contracts under PRC Labor Contract Law"还是只写"法律合同插件"，决定的是匹配精度，也是这个技能能不能在正确的时机被调用。

author 是信任链的起点。Anthropic 出品的插件和社区贡献者出品的插件，在安装时走不同的审查路径。后者要通过白名单核验，author 字段不在白名单里，安装请求被拒绝。

第二层：.mcp.json — AI的外部工具怎么接入

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 提出的一个开放标准：让AI可以直接向外部系统发请求，而不是依赖人工把数据粘贴到对话框里。.mcp.json 这个文件，告诉AI它有哪些外部工具可以用。

每个连接器声明里，description 字段是最重要的。AI决定要不要调用一个工具，看的是这里，不是 title。

Ironclad 的 description 里写了"expiring MSAs（即将到期的主服务协议）、termination clauses（终止条款）、vendor agreements（供应商协议）"，当用户问"有没有快到期的合同"，AI会想到Ironclad；如果 description 只写"contract database"，AI可能想不到去调它，或者调了却不知道该传什么参数。

不同法律领域需要完全不同的连接器集合。商事合同插件连接 Ironclad（合同库）、DocuSign（电子签名）、iManage（文档管理）。诉讼插件连接 CourtListener（联邦判例库）、Trellis（州法院数据）、Everlaw（电子取证平台）。劳动法插件只需要 Slack 和 Google Drive。

连接器不是越多越好，多余的连接器会干扰 AI 的调用决策，让它在不合适的场景下尝试调用一个根本用不到的工具。

配置了不等于能用，这是这一层最核心的规则。.mcp.json 里声明了北大法宝，不代表北大法宝可以查，可能是账号没有、API key 没配置、网络不通。

冷启动面试（插件初始化向导）有一个专门的探测步骤：只有实际调用成功了，才标记为"✓ 可用"；声明了但没有探测通过的，标记为"⚪ 未验证"，并说明怎么确认。

这条规则的代价是每次初始化要真正发出测试请求。收益是：AI 不会在连接器不可用时从训练数据里"补充"一个听起来真实的引用。

在法律工作里，一个有来源但来源是虚构的结论，比没有来源的结论更危险，因为它看起来已经有依据了。

第三层：CLAUDE.md — 用户配置怎么在版本升级中活下来

这是开头那个"配置全没了"问题的解法。

根本矛盾在于：插件自带的 CLAUDE.md 是模板，随着插件版本更新会被替换。但用户填进去的配置是用户数据，不能被替换。

如果模板和用户数据住在同一个文件里，更新模板就必然损坏用户数据，没有中间地带。

解法是物理分离：让它们住在不同的文件，放在不同的路径。

插件目录里的 CLAUDE.md 是只读模板，跟着插件版本走，每次升级可以被覆盖。用户配置住在 ~/.claude/plugins/config/claude-for-legal/<插件名>/CLAUDE.md，完全在插件目录之外，插件怎么升级都碰不到它。还有第三层：跨插件共享的公司画像，存在 ~/.claude/plugins/config/claude-for-legal/company-profile.md，12个插件都读它，不需要每个插件里重复填一遍公司信息。

模板里凡是需要用户填写的位置，都有一个 [PLACEHOLDER] 标记。每个技能在开始工作之前，都会先检查用户配置文件。发现 [PLACEHOLDER] 还在，技能停下来，拒绝继续：

"这个插件还没有配置，无法给出有用的输出。请先运行冷启动面试，大约需要10-15分钟。"

[PLACEHOLDER] 不是给人看的提示，是给技能代码看的执行拒绝信号。宁可拒绝工作，也不输出一个通用的、看起来像定制但实际上什么都没考虑的法律审查意见。通用的审查意见让人误以为已经针对自己的情况做了分析，这比没有审查意见更危险。

第四层：SKILL.md 路由 — 用户的一句话怎么到达正确的技能

用户说"帮我看看这份合同"，系统里有十几个审查技能，用哪个？

claude-for-legal 的解法是两层分离：一个路由技能负责识别文档类型，再调用对应的专项技能。路由逻辑的核心是一张硬编码的映射表：

这里有个容易忽略的设计：路由优先读文档标题，不是优先读正文关键词。

一份40页的主服务协议，正文里"confidential"这个词可能出现上百次。如果用关键词匹配正文，系统会把这份MSA误判为NDA，审查结论完全错误。文档标题是路由的主要信号，正文是备用。

路由技能发现文档附件里有数据处理协议（DPA），会同时调用对应的数据保护分析，合并成一份完整的审查备忘录。子技能被标记为 user-invocable: false，用户不能直接输入 /nda-review，这条技能只能由路由触发。原因很直接：用户如果直接用 /nda-review 审一份 SaaS 合同，结论是错的。

为什么不让AI自由决定路由，有两个理由。

一是可审计性。硬编码的映射表，路由出了问题，能看到哪一步走错了，能修复。AI自由决策，出了问题不知道为什么，也没法系统性修复。

二是一致性。同一类合同每次都走同一条路由，同类合同的审查结论才能横向比较。法律工作需要稳定的、可重复的流程，不能"今天心情好就路由对了"。