把 Claude for Legal 拆开揉碎——给中国法律人的一份说明书
|
· |
|
导 · 读 Anthropic 2026 年 5 月 12 日正式发布「Claude for Legal」——12 个法律专业场景插件、150 个 SKILL.md 文件、20+ MCP 连接器、覆盖全球顶级律所协调站台。我们第一时间拆开看，把它的架构、设计哲学、对中国律师的可用性，都梳理在这一篇里。 |
01 |
这是一次全产业链协调后的正面下场
5 月 12 日，Anthropic 正式发布 Claude for Legal，这是一次罕见的垂直领域深度整合入场：
|
20,000+ 法律从业者注册了 Anthropic 配套法律 webinar，是他们历史上最大的法律会议 |
4 家顶级律所 Freshfields、Quinn Emanuel、Holland & Knight、Crosby Legal 联合站台，已用 Claude 处理活跃案件 |
|
12 个 法律专业场景插件——不是泛用合同审查 |
20+ MCP 连接器 DocuSign / Box / Ironclad / iManage / Lexis+ / Everlaw / CourtListener / Thomson Reuters 等 |
Fortune、TechCrunch、Artificial Lawyer、LawNext、Yahoo Finance 同步深度报道。Thomson Reuters 与 Anthropic 公开宣布双向战略合作——Westlaw 旗下 CoCounsel 重写在 Claude 底层上，同时 Claude 可以反向调用 CoCounsel 作为工具。Microsoft 365 全套（Word / Outlook / Excel / PowerPoint）也已经深度集成。
这是 Anthropic一次极其重要的行业入场动作。它的核心野心非常清晰——不让 Harvey、Legora 等应用层从底层模型上"窃取"客户。
但更值得关注的是：这次发布真正惊到法律科技圈的是"专业场景的落地程度"。
|
值 · 得 · 关 · 注 Anthropic 2 月份就发布过初代法律插件，被业内视为"模型公司试水"。5 月这次升级一口气上了 12 个法律具体场景——商业合同、公司 / M&A、劳动雇佣、隐私合规、产品法律、监管合规、AI 治理、知识产权、诉讼、法律诊所、法学生、Skill 应用市场——每一个领域都是一整套独立运转的工作流。 这说明 Anthropic 对法律业务的具体使用场景做了深度调研。这不是"提供个 prompt 库"的开源——是"把法律业务工作流操作系统化"的开源。 |
Apache 2.0 License——允许商用、允许修改、允许再分发。任何人可以拿去改、拿去卖、拿去做本地化版本。这是 Anthropic 一贯的"开放 + 内化"并行打法。
但这套体系完全基于美国法和欧美法系：FRE 408 证据排除、Bluebook 引注、UCC 商法、CACI 加州陪审团指南、Iqbal / Twombly 起诉标准、ABA 律师执业规则、Westlaw 检索⋯⋯直接拿来到中国用，会撞到一整面墙。
但拆开看，每个 Skill 的"工作流方法论"本身是普适的——不重写学生草稿的教育原则、不可绕过的冲突检查、[VERIFY] 标记机制、引证忠实纪律、对弱论点的坦诚⋯⋯这些设计在中国法律实务中同样成立，甚至更稀缺。
所以这篇文章试图回答两个问题：
|
· Anthropic 这套体系是怎么组织的？（架构层） · 中国法律人能拿到什么？踩到什么？（实务层） |
02 |
仓库的整体架构——12 个插件 + 5 类资产
打开 anthropics/claude-for-legal，根目录下是这样：
|
📁 claude-for-legal/
📁 12 个 First-Party 插件
📁 external_plugins/ — 合作伙伴维护的插件
📁 managed-agent-cookbooks/ — 云端定时任务部署方案
|
仓库数据浓缩：12 个核心插件 + 1 个外部合作插件 + 5 个云端方案。SKILL.md 共 150 个，Agent 共 10 个，References 资源共 22 项。每个核心插件都包含 .claude-plugin/plugin.json + CLAUDE.md + README.md + .mcp.json 四个标准文件。
注意一个特别的存在：legal-builder-hub。它不做任何具体法律业务——它做"Skill 应用市场"：搜索社区 Skill、信任评估、安装、自动升级。Anthropic 自己做了一个开源的法律 Skill 商店，默认监视 3 个第三方注册中心。有点像把一个我们做的“法律元力”站点安装到了本地。
03 |
单个插件长什么样
12 个插件结构高度一致。打开任何一个：
|
📁 <plugin-name>/
📁 skills/ — 业务能力（每个 = 一个 slash 命令）
📁 agents/ — 命名 Agent（按 cron 跑或用户调用） 📁 hooks/ — 钩子配置 (PreToolUse / PostToolUse) 📁 references/ — 静态参考资料（模板库、查询表、SOP） |
这套五件套（Skill / Agent / Hook / References / MCP）覆盖了一个法律 AI 工作流需要的所有抽象：
|
Skill = 用户主动调用的命令，对应单次任务 Agent = 复杂任务执行器，可调用多个 Skill，可定时运行 Hook = 事件触发器，"做 X 之前 / 之后自动做 Y" References = 静态查询资料库 MCP = 外部工具桥接（Slack、Google Drive、合同管理系统等） |
但所有这些都围绕一个文件转：CLAUDE.md。
04 |
CLAUDE.md：插件运转的中枢
每个插件都有一份 CLAUDE.md——但仓库里的是模板，第一次安装时是空白的。用户跑完一次叫 cold-start-interview 的 Skill，模板才会被填成用户特定的实务画像。
commercial-legal 的 CLAUDE.md 里写的是什么？
|
· 你这个团队负责销售方还是采购方 · 你的合同审查手册（playbook）——LoL 责任上限、赔偿方向、保密期限、DPA 立场、治理法律 · 你的红线条款——什么是绝对不能签的 · 你的升级矩阵——什么样的偏离需要主办律师签字、什么样的需要总法务签字 · 你的所内文书风格——进攻型 vs 克制型 · 你的合作律所、CLM 系统、签字流程 |
之后每一次 commercial-legal:review、commercial-legal:amendment-history、commercial-legal:stakeholder-summary 这些 Skill 运行——第一件事都是读这份 CLAUDE.md。
如果用户跳过 cold-start，CLAUDE.md 是模板态，Skill 进入 [PROVISIONAL] 模式，按通用默认值跑。输出能看，但是不贴合用户业务。
这就是 Anthropic README 反复强调的那句话：
|
"Skipping setup is the single most common reason a skill produces generic output." （跳过设置是 Skill 输出泛泛的头号原因。） |
|
设 · 计 · 哲 · 学 "实务档案"不是配置文件，是 AI 的"业务画像"。这是 Anthropic 设计中最有方法论价值的一点——它把"让 AI 个性化"这件事从"prompt engineering"层级，提升到了"产品工作流"层级。 |
· · ·
05 |
深度走查：commercial-legal 是怎么工作的
挑一个最贴近企业法务和商务律师日常的插件——商业合同。来看它的完整工作流。
5.1 首次安装：cold-start-interview 的两条路径
新装这个插件，第一件事是跑 /commercial-legal:cold-start-interview。两条路径可选：
快速版（2 分钟）
只问基础——角色、销售方 / 采购方、当前接通的工具。其他全部用 [DEFAULT] 标记。结束语温柔且诚实：
|
"好了。可以开始用了。我用了合理的默认 playbook、升级阈值、所内风格。当某个 Skill 输出让你觉得不对，那通常是某个 default 该调了——它会告诉你是哪个。" |
完整版（15 分钟）
进入真正的实务档案搭建。这里有两种输入路径：
|
① 过往文档上传 用户提供 5-10 份最近签的合同（"越多越好，20 份能看出清晰模式"）+ 升级矩阵文档。Skill 反向提取你实际签下的 playbook 立场——这里有个精巧的设计：Skill 会标注"你声称的立场 vs 你实际签下的"差异，作为审稿提示。 |
|
② 互动制定 没有种子文档？Skill 用结构化的 A/B/C 选择题一项项问。"你的责任上限是合同金额的 12 个月、24 个月、36 个月、还是 unlimited？""你的红线条款是什么？""超过哪个金额需要总法务签字？" |
两种路径可以混用。最终输出的是一份用户用纯文本能直接编辑的 Markdown 实务档案——不是 YAML、不是 JSON。Anthropic 的设计原则原话：
|
"The lawyer should never see a YAML config file. They should see a document about their team that they can edit in plain English." （律师永远不应该看到 YAML 配置文件。他们应该看到一份关于自己团队的、可以用纯英文编辑的文档。） |
5.2 实际审一份合同：8 步工作流
cold-start 跑完后，用户拿到一份对方发来的供应商协议，调用 /commercial-legal:review。Skill 内部发生了 8 步：
|
读 CLAUDE.md → 拿到 playbook、升级矩阵、所内风格 |
|
从合同标题识别类型（NDA / vendor MSA / SaaS subscription / 其他） |
|
路由到对应子 Skill： · NDA → nda-review（红/黄/绿三档分流） |
|
子 Skill 逐项审查，标记偏离 playbook 的条款 |
|
评估每一处偏离的风险等级 |
|
生成具体修订建议措辞（不是含糊的"建议修改"，是直接给替代措辞） |
|
按升级矩阵识别哪些偏离需要升级，路由到对应审批人 |
|
整合输出：一份审查备忘录 + 一份给业务方的两分钟摘要 |
输出末尾有几个标志性元素：
|
· 每一处法律命题都标了引证来源（不同来源用不同标签提示信任度） · 不确定的事项用 [VERIFY] 标记 · 弱论点直接标"这一点弱因为 X，选项是 A / B / C" · "下一步决策树"——给主办律师 5 个选项让他选 |
5.3 升级和续约自动化
commercial-legal 还带 3 个 Agent，把工作流闭环：
|
renewal-watcher 扫合同库找到期日。每天跑一次。发现 90 天内到期的合同就推送。 |
|
escalation-flagger 配合 hooks：当 review Skill 发现"偏离超过审稿人审批权限"时自动触发，把案子上报到对应级别的审批人。 |
|
playbook-monitor 长期追踪所内的偏差日志——同一条款类型在 3 个月里被偏离 5 次，自动生成一份 playbook 更新提案，让主办合伙人审。这是审查手册的自我迭代。 |
工作流闭环长这样：
↓
↓
↓
↓
↓
↓
↻ 又开始新一轮 review |
|
核 · 心 · 特 · 点 整套链路没有"AI 替代法律人"的幻想，全程是"AI 让人更快做出更好判断"。每一处实质性决策都留给主办律师或是法务；AI 做的是结构化、归集、初稿、路由。 |
· · ·
06 |
但它只在 Claude 自家产品里完整运转——其他 AI 工具要适配
到这里 commercial-legal 的工作流听起来很美。但同事在测试时立刻发现一个现实问题：这套 plugin 拿到 Claude Code 和 Claude Cowork 之外的环境，就跑不起来了。
不是说"完全跑不起来"——而是"能跑一部分，但越往深走断点越多"。这件事和 Apache 2.0 license 的开放精神有点反差——开源不等于通用。
可移植性的 3 个层级
把"plugin"和"skill"切开看，可移植性其实是三层结构：
|
层 1 · Plugin（最不便携）= Claude Code / Cowork 专属 · marketplace.json + plugin.json · /plugin marketplace add / install 命令 · /<plugin>:<skill> slash 命令 namespace · 自动加载 .mcp.json + 注册 agents/ + hooks/ · ~/.claude/plugins/config/ 目录写入
|
越往外层，绑死的"私有约定"越多。Plugin 这一层是 Anthropic 自家两个产品的专属壳——其他工具至多支持到层 2 或层 3。
典型工作流断点图
以"用户首次安装 commercial-legal 到执行一次合同审查"为例，12 步工作流在不同环境里的可执行情况：
|
步骤 |
Claude Code |
MyAgents |
其他国产 |
|
① /plugin marketplace add |
✓ 原生 |
✗ 无概念 |
✗ |
|
② /plugin install |
✓ |
✗ |
✗ |
|
③ 触发 cold-start |
✓ slash |
△ 自然语言 |
△ |
|
④ cold-start 问问题 |
✓ |
✓ |
△ |
|
⑤ 写入 config 路径 |
✓ |
✗ 路径无 |
✗ |
|
⑥ slash 命令调用 review |
✓ |
✗ 无 ns |
✗ |
|
⑦ Skill 读 CLAUDE.md |
✓ |
✗ PROVISIONAL |
✗ |
|
⑧ 跨 skill 路由 |
✓ |
✗ 无机制 |
✗ |
|
⑨ Skill 调 MCP |
✓ 自动 |
△ 手动配 |
△ |
|
⑩ Hooks 触发 |
✓ |
✗ 无 |
✗ |
|
⑪ Agents 定时跑 |
✓ |
✗ 无 loader |
✗ |
|
⑫ 输出到 matter folder |
✓ |
✗ 约定异 |
✗ |
断点根因——为什么这些步骤走不通
|
步骤 ① ② · plugin 安装机制 Plugin 安装是 Anthropic 自定义的——需要 Claude Code/Cowork 自带的 plugin loader + marketplace 协议解析 marketplace.json 和 plugin.json。其他 AI 工具没有这套加载器。 |
|
步骤 ③ ⑥ ⑧ · plugin 命令 /commercial-legal:review 这种带 namespace 的 slash 命令是 Claude Code slash 命令系统的特性。其他工具只有"自然语言匹配 description 触发"，没有 plugin namespace 概念。跨 skill 调用直接断。 |
|
步骤 ⑤ ⑦ ⑫ · ~/.claude/plugins/config/ 路径 Anthropic 工具的硬编码目录约定——只有 Claude Code/Cowork 会自动创建并写入。Skill body 里直接 hardcode 了这个绝对路径，在其他工具里读不到、写不进。 |
|
步骤 ⑨ ⑩ ⑪ · MCP / Hooks / Agents MCP 协议本身是开放标准，但 plugin 内 .mcp.json 的自动加载是 Claude Code/Cowork 行为。Hooks 是 Claude Code 的事件总线。定时 Agent 需要 host 提供 scheduler。这些机制其他 AI 工具的 runtime 里都没有。 |
各家 AI 工具兼容矩阵
|
工具 |
Plugin |
Skill |
SKILL.md |
|
Claude Code CLI |
✓ 完整 |
✓ |
✓ |
|
Claude Cowork |
✓ 完整 |
✓ |
✓ |
|
MyAgents |
✗ |
△ 兼容层 |
✓ |
|
Cursor |
✗ |
✗ |
✓ |
|
Continue / Cline / Roo |
✗ |
✗ |
✓ |
|
OpenCode |
✗ |
✗ |
✓ |
|
Kimi K2 / Kimi Code |
✗ |
✗ |
✓ |
|
通义灵码 / 字节 Trae / 腾讯 CodeBuddy |
✗ |
✗ |
✓ |
|
关 · 键 · 判 · 断 把 Anthropic 的 Plugin 体系"原样搬到中国 AI 生态"并不丝滑——Plugin 这一层是 Claude Code / Cowork 的专属壳，绑死了 marketplace 协议、namespace、目录约定、事件系统等一整套 Anthropic 自定义的 runtime 行为。 中国 AI 工具如果要承接 Claude for Legal 的资产，必须做"拆解 + 重组 + 适配 runtime"——把 plugin 拆成单个 skill，把 hardcoded 路径重写为站方约定，把跨 skill 调用替换为站方 skill 调用机制，把 hooks 和 agents 重新实现或丢弃。 虽然今天的智能体非常强大，可能根据需求，Agent能在每个人的电脑上都重写一套适配机制，但能否稳定高效运行就因人因机而异——不是简单的 git clone + 翻译就可以无损接入的。 |
· · ·
07 |
中国法律人避坑指南——直接拿来用之前必须知道的 12 件事
把这套体系搬到中国实务，会撞到一整面合规墙。我们逐条扫描过 150 个 Skill 后，整理出最高频的踩坑清单：
|
引注规范：Bluebook 不是中国规范 Skill 默认按 Bluebook / ALWD 格式做引证。中国法律文书引注遵循最高院《人民法院诉讼文书样式》+ 学术引注 GB/T 7714。直接套出来的代理意见会被法官挑出来。 |
|
律师特权 ≠ 律师保密义务 Skill 把 "privilege" 作为不能跨越的红线。但中国法没有英美法系下的"律师特权"——中国对应的是《律师法》第 38 条的"律师保密义务"，性质是律师的执业义务，不是当事人的证据特权。两个制度的法律后果完全不同。 |
|
FRE 408 不存在——对应是《民诉证据规定》第 67 条 调解 / 和解通讯证据排除：美国是联邦证据规则 408 条，中国对应是《民诉证据规定》第 67 条 +《民诉法解释》第 107 条。重点：保护来自陈述目的与情境，不来自标签——仅仅在律师函上加"调解阶段"字样并不当然产生证据排除保护。 |
|
UCC 2-612 在中国对应是《民法典》第 633、634 条 分批 / 分期交付合同的违约处理：美国 UCC 第 2-612 条，中国是《民法典》第 633 条（分批交付）+ 第 634 条（分期付款保留所有权）。门槛措辞和法律后果略有差异，起草分批违约函时不能错引。 |
|
Discovery 在中国民诉没有——对应是律师调查令 Skill 频繁出现 "deposition"、"interrogatory"、"RFA"——这些是美国民诉的证据调取程序，中国民诉无对应。中国律师的证据补强手段是：律师调查令、申请法院依职权调取证据、申请证据保全。Skill 输出里的"调查取证手段"建议必须重写。 |
|
Iqbal / Twombly 起诉标准不存在 美国联邦民诉的起诉 plausibility 标准来自 Iqbal 和 Twombly 两个最高法院判例。中国不适用——中国起诉条件是《民诉法》第 122 条 +《民诉法解释》第 208 条。起诉条件审查的逻辑也不同：中国法院立案审查更宽松，但开庭后会审查"事实和理由"的具体性。 |
|
"Holding" 概念不能套——中国判决书没有先例约束力 Skill 在 case-brief 中要求学生先陈述 "holding"——美国判例法体系下的"裁判规则"。中国是制定法体系，普通判决无 stare decisis 约束力。中国对应概念： · 指导性案例"裁判要点"（下级法院"应当参照"） · 最高院公报案例"裁判摘要"（强参考意义但无约束力） · 普通生效判决仅"裁判理由"（无先例效力） |
|
合理使用：美国 4 要素 vs 中国 13 项穷尽列举 美国著作权合理使用是 17 USC §107 的开放性 4 要素分析。中国《著作权法》第 24 条是穷尽列举的 13 项情形 + 第 13 项兜底——落不到列举的具体情形之一，合理使用抗辩通常不成立。范式差异显著。直接拿美国 fair use 分析套中国案件，结论可能完全反着来。 |
|
商标侵权混淆：Polaroid 八因素 vs 中国《商标法》第 57 条 美国各联邦巡回法院有自己的多因素混淆测试（Polaroid、du Pont、Sleekcraft）。中国按《商标法》第 57 条 + 最高院司法解释 + 北京高院审理指南。因素清单部分重合，但权重和判断标准不同——直接套美国测试会忽略中国实务对"相关公众""驰名商标特殊保护""跨类保护"等本土逻辑。 |
|
商业秘密追诉路径：DTSA 民事 vs 中国《刑法》第 219 条刑事 美国商业秘密保护主要是民事（DTSA + 各州 UTSA）。中国对商业秘密侵权设有刑事追诉路径——《刑法》第 219 条侵犯商业秘密罪，给商业秘密权利人造成"重大损失"可处三年以下有期徒刑，"特别严重后果"可处三年以上七年以下。Skill 在分流时不会提示这条刑事风险——潜在被指控方需要特别注意。 |
|
Westlaw / CourtListener 不可用——对应是中国法律检索工具 Skill 大量引用美国法律检索工具：Westlaw、CourtListener、Trellis、Descrybe。中国对应的是：北大法宝、威科先行、元典法律检索、Alpha 法律检索、聚法案例、中国裁判文书网。翻译时不能保留原英文工具名——会让中国律师无所适从。 |
|
法学院诊所 / Bar Exam 整体不适用 legal-clinic 整套基于美国 ABA 法学院诊所体系（5.5 学生执业规则、6.5 短期法律服务规则、督导审核流程）。law-student 的 bar-prep-questions 基于美国各州律师资格考试。中国法学院诊所参照《关于推进高等学校法学教育改革的若干意见》，体制完全不同。中国法考也是独立体系。这两个插件原版直接不可用——需要重新设计中国版。 |
· · ·
08 |
写在最后
把 Anthropic 的 Claude for Legal 拆开看，最大的收获不是"我们能拿来用什么 Skill"——是看见了一种让 AI 在法律工作里运转的工作流哲学：
|
· AI 不替代法律人，但让人在每一处实质性判断之前更快进入状态 · 实务档案是 AI 个性化的起点，不是配置文件 · 每一个 AI 输出都是供律师审阅的草稿，永远不是结论 · [VERIFY] / [UNCERTAIN] / [CITE NEEDED] 三个标记是审稿环节显式可见的设计 · 不可绕过的冲突检查、不重写学生草稿、对弱论点的坦诚——是 AI 法律工具最值得学的设计原则 |
但中国法律人不能直接 git clone 这个仓库跑——以上 12 条踩坑指南只是表面，背后还有大量制度、概念、引注规范的细节差异。把这套体系本地化为中国版法律 AI 工作流，需要的不是翻译，是重新设计。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
6
0- 0
已为社区贡献107条内容
所有评论(0)