contract-review：一个 Playbook 驱动的 AI 法务助理

你见过法务团队审合同的场面吗？不是大家围坐讨论条款，是一个人对着屏幕，把 PDF 从头翻到尾，再从尾翻到头。一份 50 页的 SaaS 协议，逐条比对公司的谈判手册，标记偏差、起草修订建议、评估风险等级。这一套走下来，短则半天，长则三天。

合同审查的痛不是工作量大，是重复性劳动高到荒谬。同一类条款的同一类问题，在不同合同里出现 20 次，就要手动标注 20 次。任何一个做过合同审查的法务都会告诉你：这份工作 80% 的时间花在机械比对和格式化标注上，剩下 20% 才真正在做判断。

Anthropic 在 knowledge-work-plugins 仓库里放了一个叫 contract-review 的 Skill，试图解决的就是这 80%。它不替代法务，但把机械比对那部分自动化了。在 Smithery 上它的评分是 4.3，每周安装量稳定在 340 以上，已经在 Claude Code、Cursor、GitHub Copilot 等多个平台落地。

说白了这篇文章就想讲清楚一件事：这个 Skill 到底怎么把审查流程从”人翻文件”变成”机器执行规则”，它的 Playbook 机制为什么是整个设计的灵魂，以及这种设计在真实法务场景下能跑多远。

环境准备

contract-review 不是独立应用，是 Anthropic Claude 生态下的一个 Agent Skill。你需要一个支持 Skill 机制的 Claude 客户端。目前 Smithery 的数据显示它已适配以下主流平台：

• opencode
• codex
• gemini-cli
• GitHub Copilot
• Cursor

安装只有一行命令：

npx skills add https://github.com/anthropics/knowledge-work-plugins --skill contract-review

装完之后你可以上传一份合同 PDF 做快速验证。在 Claude 对话中直接说”review this contract against our playbook”，Skill 会自动加载并开始逐条分析。如果环境就绪，你会看到它先检查 Playbook 配置，然后开始按章节扫描合同文本。

这里有一个很容易被忽略的前置条件，也是整个 Skill 运转的燃料：谈判手册。Skill 本身不带任何预设条款标准。它需要你在本地配置一份组织的谈判手册，定义每个主要条款类型的标准立场、可接受范围和升级触发线。如果没有配置，它会退一步基于通用商业标准做基准审查，但会在报告中明确标注”非组织标准”。

这一点是故意的设计选择，不是功能缺失。让 Skill 不内置任何条款标准，意味着它的审查输出完全由你的组织立场驱动，而不是 Anthropic 的假设。对法务团队来说，这比任何”智能推荐”都更安全。

操作流程

contract-review 的审查链路是五步递进的，每一步的输入输出都很明确。

第一步，加载谈判手册。Skill 启动后先检查本地是否有已配置的 Playbook。手册里定义了组织在各类条款上的标准立场。没有这份手册，审查就没有基准线，接下来的所有分析都站不住脚。

第二步，确定合同类型和角色立场。Skill 需要知道你在审什么类型的合同以及你是供应商还是客户。同一个条款，”你是供应商”和”你是客户”的审查方向完全相反。责任限制条款供应商希望越低越好，客户希望越高越好，赔偿条款的 IP 侵权范围也是同理。

第三步，通读全文后再标记问题。这是设计上很聪明的一个选择：Skill 要求先读完整个合同再开始逐条分析，而不是看到一条标一条。原因很简单，条款之间相互关联。一个无上限的赔偿条款，可能因为隔壁责任限制条款的覆盖面而被部分缓解。先读后判，能大幅减少假阳性。

第四步，逐条对照审查六大类条款。Skill 覆盖的条款类型有明确边界：

• 责任限制
• 赔偿条款
• 知识产权
• 数据保护
• 合同期限与终止
• 适用法律与争议解决

每类条款都有结构化的检查清单。以责任限制为例，它会逐一检查以下维度：

• 赔偿上限的计算方式
• 是否双方对等
• 间接损失是否排除
• 赔偿上限的例外情况

这七个维度的检查覆盖了责任限制条款最常见的风险点。

第五步，分级和生成红线建议。审查完成后，每项偏差被归入 GREEN、YELLOW、RED 三级。每个需要行动的项目都附带完整的红线建议，格式统一为六个字段：

• 条款引用
• 当前原文
• 修改建议
• 理由
• 优先级
• 备选方案

这个输出可以直接嵌入到反馈邮件中。

这五步的核心价值不是自动化，是把隐性的审查判断流程显性化了。任何一个有成熟谈判手册的团队，审查的一致性和可追溯性都会立刻提升。不是因为 AI 更聪明，是因为同一个标准被严格按照同一套规则执行了。

关键设计

contract-review 有三个设计决策，拆开来看每一步都有值得说的点。

第一个是 Playbook 作为单一真相源。很多法律 AI 工具的做法相反：内置一套”行业标准”条款库，然后告诉你某条条款低于标准。问题在于，A 公司觉得 12 个月费用上限是底线，B 公司觉得 6 个月也能接受。内置标准本质上是替团队做商业决策。contract-review 不做这件事。它的审查结论完全由你自己的 Playbook 驱动，AI 只负责比对和执行。

第二个是 GREEN/YELLOW/RED 三级分类体系。这不是随便分的颜色标签，它直接映射了大多数法务团队的实际工作流。GREEN 让审查者快速跳过无问题条款，RED 确保真正危险的项目不会被埋在 YELLOW 堆里。实际效果是，一份 50 页的合同，审查者可能只需要关注 5-8 个 YELLOW 和 2-3 个 RED，其余全自动过。比”全部标红”的工具实用得多，因为全部标红的报告等于没有报告。

第三个是红线建议的六字段格式：

• 条款引用
• 当前原文
• 修改建议
• 理由
• 优先级
• 备选方案

每个字段都有明确的用途。优先级进一步拆成三个谈判层级：Tier 1 必须守住，Tier 2 是核心谈判目标，Tier 3 可以在谈判中主动放弃以换取更重要的让步。这本质上把谈判策略也结构化地编码进了输出格式里。

这三个设计共同指向一个底层哲学：好的法律 AI 工具不需要”懂法律”，它需要的是”懂流程”。contract-review 没有内置法条、判例或法律分析模型，它只是一个结构化的比对引擎加格式化的输出模板。正因为不试图做法律判断，它在法务团队手里反而更安全。

使用场景

contract-review 最擅长的两个场景非常明确，而且几乎覆盖了大部分企业法务团队的日常。

第一个是供应商合同审查。采购发来新 SaaS 工具的 Terms of Service，法务需要在半天内给反馈。这种合同的条款结构高度标准化，80% 的内容跟上一份 SaaS 协议几乎一样。真正需要关注的只有核心问题：责任上限的数额、数据保护的 sub-processor 授权、自动续约的通知期限。contract-review 几分钟跑完，把 80% 标 GREEN 跳过，YELLOW 和 RED 附上修订建议。

审查者的角色从”逐条找问题”变成”审核 AI 标注是否准确”。这两个角色需要的脑力完全不在一个量级。前者的注意力消耗在比对和格式上，后者的注意力可以用在判断上，这个 YELLOW 在当前交易背景下要不要升级成 RED？这个 RED 有谈判空间吗？

第二个是谈判准备。重要谈判前需要快速整理所有条款的立场和策略。传统做法是手动列核心条款，逐条标注底线和谈判空间。用 contract-review 的话，跑一遍合同草案，Skill 自动生成三层优先级的红线清单。输出结果可以直接作为谈判准备文档的起点，不需要从零开始整理。

局限也很明显。高度定制的复杂合同，涉及多司法管辖区的跨国并购协议，条款间的交互关系远超过 Playbook 线性比对能覆盖的范围。更隐蔽的问题是谈判手册自身的维护。如果手册过时或写得含糊，审查结果会悄悄崩塌。Skill 不会告诉你”你的 Playbook 有问题”，它只会忠实地用错误的标准生成错误的结果。

洞察与反思

拆完 contract-review 的 SKILL.md 之后，我最大的感触不是”AI 在替代法务”，而是”法务工作正在被拆成两种完全不同的能力”。

一种是判断。什么条款风险大，什么可以妥协，在谈判桌上用什么策略。这些依赖三个东西：

• 经验
• 商业直觉
• 对具体交易的理解

AI 目前做不了这个，短期也看不到突破口。另一种是执行。逐条比对条款、检查是否偏离标准、按固定格式生成修改建议。这些是纯体力活，AI 不仅更快，还不会漏。

contract-review 的价值恰恰在于它把这个边界划得异常清晰。它不假装自己能做判断，老老实实干执行层的事。这让它在团队中落地的阻力小了很多。法务不会觉得”AI 要来取代我了”，而是觉得”终于有人帮我做最烦的那部分了”。

不过这里藏着一个更根本的问题。法务的传统成长路径是先做 2-3 年合同审查的苦力活，在逐条比对中建立条款直觉，然后才承担谈判和判断的工作。如果审查这一步被自动化了，新人的”条款直觉”从哪里积累？这可能是整个法律 AI 赛道最被低估的问题，而目前没有任何技能或工具在回答它。

从更广的视角看，contract-review 代表了 Anthropic 对企业级 AI 技能的一种定义方式：不是通用聊天机器人加法律知识，而是高度结构化的规则引擎配合 AI 的自然语言理解能力。AI 负责读合同和写建议，规则引擎负责判标准和定等级。这种架构比纯端到端的 LLM 审查方案更可控，也更适合需要审计轨迹的企业法务场景。

资源地址

总结

contract-review 解决的不是合同审查的全部问题，但问题拆对了。它专注于比对和标注那 80% 的体力活，把判断和决策留给真正该做的人。如果你的团队每周审 5 份以上合同，而且已经有一套相对成熟的谈判手册，值得花十分钟装上看效果。

不过别指望它告诉你”这份合同能不能签”。那不是它的设计目标，现在也没有任何工具应该做这件事。审查和判断的边界，可能比审查的速度更重要。

写完这篇文章我想到另一个问题：Playbook 驱动对标审查的模式，在合同领域成立是因为条款结构高度标准化。但这种模式能不能复制到其他需要”对标审查”的领域，安全合规审计、供应链资质审核、投资条款清单评审？如果你在这个方向上做过尝试，很想知道你的看法。