面向中小企业的合同审查技能（contract-review）：8 大风险类别、分级标注与红线 DOCX 导出实战

导读

contract-review 是 knowledge-work-plugins 仓库中 small-business 插件（15 个原子技能之一）内置的合同审查技能，定位是"没有专职法务的中小企业主也能读懂自己签了什么"。它从本地文件、Gmail 附件或 DocuSign 信封三种来源读取合同，从运营与财务视角梳理 8 大风险类别，输出按严重程度分级的审查摘要与谈判剧本，并可将建议修改以删除线/下划线标记的形式导出为独立的红线（redline）DOCX。阅读本文后，你将掌握该技能从取件、通读到分级标注、导出红线的完整方法论，理解每条"红旗"背后的判断标准，并知道如何在 Claude Cowork / Claude Code 中触发这条工作流。

重要声明：该技能及其输出不构成法律意见（该插件在 small-business/README.md 中明确提示"does not provide financial, tax, legal, or HR advice"）。本文所述内容仅供了解工具机制与技术流程，涉及签署决定请咨询执业律师。

技能定位与触发方式

在仓库中，该技能的文件入口是 small-business/skills/contract-review/SKILL.md，其 frontmatter 中声明了名称与描述：

name: contract-review
description: >
  Lightweight NDA, MSA, and vendor contract review for SMBs without legal on
  staff. Reads contracts from local files, Gmail attachments, or DocuSign
  envelopes; flags non-standard terms; explains risks in plain English; and
  outputs a marked-up redline as a separate DOCX. Use when the user says
  "review this contract," "what am I signing," "red flags," "flag any concerns,"
  "check the payment terms," or uploads/forwards a contract or legal agreement.

从描述可以看出，该技能的适用合同类型以 NDA、MSA（主服务协议）、SOW（工作说明书）及各类供应商合同为主，其 frontmatter 描述本身即是一组触发短语：当用户说"review this contract""what am I signing""red flags""flag any concerns""check the payment terms"，或直接上传/转发合同文件时，技能便会被激活。

在 small-business/README.md 的"All 15 commands"表格中，它被 /review-contract 命令调用，该命令的说明是"Plain-English contract review with red flags and severity ratings"（使用合同审阅，附红旗标记和严重性评级），触发短语示例为"review this contract""NDA""should I sign this"；它不强制依赖任何连接器（文件上传即可工作），Gmail、DocuSign 属于可选连接。安装方式（以 Claude Code 为例）：

claude plugin marketplace add anthropics/knowledge-work-plugins
claude plugin install small-business@knowledge-work-plugins

完整工作流：从取件到红线导出

SKILL.md 定义了一个五步工作流，下面按原文档脉络逐步展开。

第 1 步：获取合同（三种来源，按优先级）

1. Gmail：搜索最近带附件的合同邮件，参见 reference/gmail-fetch.md；
2. DocuSign：按信封 ID 获取信封，或搜索等待签署的最近草稿，参见 reference/docusign-fetch.md；
3. 本地文件或直接粘贴：通过 Read 工具读取 PDF 或 DOCX；10 页以上的 PDF 使用 pages 参数分段读取；若用户直接粘贴文本，则基于已有文本工作。

关键纪律：分析前必须通读全文。危险的条款往往藏在文档末尾的附件（exhibits）、附表（schedules）里。

Gmail 取件的具体做法（见 reference/gmail-fetch.md）：使用 Gmail MCP 连接器的 search_threads 工具，查询最近带附件的合同邮件：

Query: "has:attachment (contract OR agreement OR NDA OR MSA OR SOW) newer_than:14d"

拿到结果后的处理流程是：若多个候选匹配，先列出一个简短清单（主题、发件人、日期）；请用户确认后再下载；然后用 get_thread 获取完整线程，定位并读取附件。若 Gmail 未连接或未找到匹配附件，回退话术为："I didn't find a recent contract attachment in Gmail — can you forward it or attach the file directly?"（我未在 Gmail 中找到近期的合同附件——你能直接转发或上传文件吗？）。该流程有两条硬性禁令：不得阅读与合同无关的邮件（禁止一般性收件箱扫描）；审查工作流期间不得发送任何回复或草拟邮件。

DocuSign 取件的具体做法（见 reference/docusign-fetch.md）：使用 DocuSign MCP 连接器拉取待签署的信封。先用 getEnvelopes 列出 sent 或 delivered 状态（即等待收件人操作的）信封：

Tool: getEnvelopes
Params: { status: "sent" }  // or "delivered"

返回的信封列表包含 envelopeId、emailSubject、createdDateTime、status、recipients 字段。随后用 getEnvelope 按 envelopeId 获取完整信封详情并下载文档供阅读。该技能是纯审查性质的，有三条禁止事项：绝不调用 triggerWorkflow 或任何推进签署流程的操作；绝不调用 updateEnvelope 修改文档；绝不调用 createEnvelope。若 DocuSign 未连接或找不到信封，回退话术为："DocuSign isn't connected — paste the contract text or attach the file directly."（DocuSign 未连接——请直接粘贴合同文本或上传文件。）

第 2 步：识别合同类型与当事方

确定协议类型（NDA、MSA、SOW、SaaS 订阅、咨询、分包商、供应商等），并判断用户公司是合同中的哪一方、相对方是谁。特别留意：若合同明显是相对方的模板（counterparty template），这类合同通常明显偏向单方，且相对方本就预期你会讨价还价——这是谈判策略判断的重要输入。

第 3 步：按 8 大风险类别分析

从没有内部法务的中小企业主的运营/财务视角逐类过一遍合同。类别按典型风险严重程度排序，具体判断时需结合上下文灵活运用。

类别 1：付款条款与现金流

• 付款周期：Net-30 是标准；Net-60 及以上可标记；Net-90/120 是强硬谈判点；
• 付款触发条件：过长的验收期会让客户无限期拖延审批；
• 逾期付款罚则：缺失本身就是一个值得指出的缺口；
• 开票要求：僵化的格式或 PO 编号要求可能在细节上拖延付款；
• 费用报销：注意预审批要求和上限；
• 费率调整：多年期合作应关注年度费率上调机制。

类别 2：责任与赔偿（Liability and indemnification）

• 责任上限：无上限责任永远是红旗；
• 相互赔偿还是单方赔偿；
• 赔偿范围：对"因服务引起的任何及所有索赔"承担赔偿并非标准表述；
• 保险要求：E&O、网络保险、一般责任险——按约定限额是否可达成；
• 间接损失豁免：缺失 = 需重点标注。

类别 3：终止与退出

• 便利终止（termination for convenience）：是否对等？30 天通知是典型做法；
• 违约终止（termination for cause）：是否有补救期（cure period）？泛泛的"重大违约"若未定义即有问题；
• 收尾（wind-down）：终止时对进行中工作的付款安排；
• 过渡协助（transition assistance）：收费还是不收费、限时还是无期限；
• 存续条款（survival clauses）：无限期存续的赔偿义务 = 红旗。

类别 4：知识产权

• IP 转让（assignment）还是许可（license）；
• 既有 IP 与背景工具（background tools）的例外条款：缺失意味着可能被无意中一并转让；
• 交付成果（work product）定义的广度：草稿、笔记、内部工具是否被纳入。

类别 5：范围与变更管理

• 范围定义的清晰度；
• 变更单（change order）流程：缺失 = 无补偿的范围蔓延；
• 验收标准：主观表述（"以客户满意为准"）vs 明确定义；
• 时间表的不对称性：客户延迟反馈不受罚，而你方延迟却受罚。

类别 6：竞业限制与排他性

• 竞业限制的范围、"竞争者"的定义、期限；
• 对用户公司的排他性要求；
• 禁止招揽（non-solicitation）：禁止挖角员工是正常约定，行业级别的宽泛限制则不是。

类别 7：保密与数据

• 保密范围：无例外的"共享的所有信息"过于宽泛；
• 期限：2–3 年是典型，永久的则激进；
• 数据安全处理要求与公司规模和数据类型是否匹配；
• 终止后的数据返还/销毁要求。

类别 8：运营关注点

• 管辖法律与争议解决，强制仲裁；
• 自动续约：选择退出窗口与通知期（错过 60 天窗口是 SMB 常见失误）；
• 转让权（assignment rights），尤其当客户被收购时；
• 最惠国待遇（most favored nation）：会约束整个客户组合的定价；
• 审计权：范围与频率。

第 4 步：呈现分级摘要

按严重程度组织输出，共五个板块：

• 🔴 红旗（签署前必须回击）——对每一条：引用确切条款原文、用通俗语言解释问题、给出具体的替代措辞建议；
• 🟡 黄旗（可谈判，非毁约项）——对每一条：引用条款、说明顾虑、描述"更好的样子"长什么样；
• 🟢 需知悉的关键条款（仅提示）——付款安排、通知期、续约日期、保险要求、关键联系人；
• 📋 合同摘要——通俗语言概述：谁做什么、多少钱、多长时间、在什么条件下；
• 💡 谈判剧本（Negotiation playbook）——针对每一条红/黄旗：该要求什么、如何组织表述、合理的折中方案是什么。

第 5 步：导出红线 DOCX

呈现摘要之后，主动询问是否导出红线 DOCX。使用 docx 技能生成 Word 文档，要求满足三点：

• 保留原合同结构；
• 建议删除处以删除线标记、建议新增处以下划线标记；
• 添加一页封面页汇总所有变更。

导出前的固定话术："Want me to export a redlined DOCX you can send back to the counterparty?"（需要我导出一份可发回给相对方的红线 DOCX 吗？）

分级标注的完整实例：SaaS 协议审查输出

仓库在 reference/examples/flagged-summary-saas.md 提供了一个完整的工作示例，输入为："Review this SaaS agreement before I sign. We're a 12-person consulting firm."（签署前帮我审一下这份 SaaS 协议。我们是一家 12 人的咨询公司。）合同为一份 18 页的 SaaS 订阅协议，供应商模板，适用加利福尼亚州法律。其输出结构完整展示了第 4 步的落地形态：

📋 合同摘要：12 个月 SaaS 订阅、按年自动续约；供应商提供项目管理软件；$2,400/年按月计费；供应商托管数据、你拥有数据但授予供应商"产品改进"用途的宽泛许可；你可以 30 天通知终止，但需付清至合同期末的费用。

🔴 红旗 1——无上限责任：引用原文"IN NO EVENT SHALL VENDOR'S LIABILITY EXCEED THE AMOUNTS ACTUALLY PAID BY CUSTOMER IN THE THREE (3) MONTHS PRECEDING THE CLAIM."（供应商的责任在任何情况下均不超过索赔前三个月客户实付金额）。问题：三个月费用 = $600，若供应商数据泄露导致客户数据外泄，赔付上限仅 $600。建议要求：改为 12 个月实付费用（$2,400）上限，或数据安全事件固定 $50,000 下限，给出可直接插入的措辞："Vendor's total liability shall not exceed the greater of (a) fees paid in the twelve (12) months preceding the claim or (b) $50,000 for claims arising from data security incidents."

🔴 红旗 2——带 60 天退出窗口的自动续约：引用原文关于自动按年续约、需提前 60 天书面通知不续约的条款。问题：$2,400/年的合同，错过 60 天窗口即被锁定一年。建议：缩短为 30 天退出窗口或要求供应商增加提醒义务；或者立刻在日历上标出退出截止日（2026-05-01 签署则对应 2027-04-01）。

🟡 黄旗 3——宽泛的数据许可：引用原文"Customer grants Vendor a non-exclusive, worldwide license to use, process, and analyze Customer Data to improve Vendor's products and services."（客户授予供应商非排他、全球范围的许可，使用、处理和分析客户数据以改进产品与服务）。顾虑：供应商可将包括客户项目数据在内的数据用于训练产品，可能与你的客户保密义务冲突。建议限制为聚合、匿名化的使用："...limited to aggregated, de-identified data and expressly excluding any Customer Data that identifies Customer's clients or projects."

🟡 黄旗 4——无违约补救期的解约条款：引用原文"Vendor may terminate this Agreement immediately upon Customer's material breach."（供应商可在客户重大违约时立即终止本协议）。顾虑："material"（重大）无定义，供应商可随时切断访问，项目中途可能丢失数据访问权。建议加入 15 天补救期："...upon written notice and Customer's failure to cure such breach within fifteen (15) days."

🟢 需知悉的关键条款：按月自动扣款（信用卡失效即暂停服务）；数据可随时导出、终止后 30 天内可导出（取消前先规划导出）；适用加州法律、争议由 Santa Clara 县法院管辖；可用性 SLA 99.5%/月，且以账户额度而非现金形式补偿。

💡 谈判剧本：以表格形式呈现"旗标 → 要求 → 表述口径"：

Flag	Ask	Framing
责任上限	提高至 12 个月（$2,400）或安全事件 $50K	"我们处理客户数据——责任上限需反映实际风险"
自动续约窗口	缩短至 30 天	"60 天对小型团队太紧——30 天更常见"
数据许可	限制为匿名/聚合	"我们的客户协议限制了项目数据的共享方式"
解约补救期	增加 15 天补救期	"我们需要在访问被切断前有机会修复问题"

示例末尾同样标注了 "This is not legal advice. For binding decisions, consult an attorney."，并说明红线 DOCX（tracked-changes 格式）已导出至 contract-review-redline-2026-05-01.docx。

容易踩坑的边缘情况（Gotchas）

reference/gotchas.md 用"坏做法/好做法"成对呈现了四类典型陷阱，直接关系到输出质量：

1. 把标准样板条款当成红旗。 过度标记会让用户逐渐忽略摘要——"如果什么都是红旗，那就没有红旗了"。例如标准对等 NDA、2 年期限属于市场常态，标成红旗会破坏信噪比；正确做法是跳过不标。红旗应只留给真正非标准的条款。

2. 缺失条款不等于可以忽略。 对 SMB 而言，标准保护条款（责任上限、变更单流程、间接损失豁免）的缺席往往比不利条款更危险——因为默认法律状态会填补空白，而默认通常偏向对方。合同没有责任上限时，应明确标注"🔴 Missing: No liability cap"，并给出标准建议措辞："Each party's total liability shall not exceed the fees paid or payable in the 12 months preceding the claim."（各方总责任不超过索赔前 12 个月已付或应付费用。）

3. 大 PDF 读到一半就被截断。 超过 20–30 页的合同，最危险的条款往往在末尾的附件、附表或"Order Forms"里。若只读到第 15 页，就会静默漏掉关键条款。正确做法：用 pages 参数分块读取（如 1–10、11–20、21–40 页），全部读完再出摘要；凡章节标题出现"Schedule""Exhibit""Appendix"等字样，要显式标注并确认已读到。

4. 把相对方模板当成可协商草稿。 建议必须匹配谈判情境。对 Fortune 500 的采购模板（其中约 80% 的条款通常不可协商），把 Net-60 付款条件建议为"应该能改成 Net-30"是不现实的，会浪费用户的谈判资本。正确做法：标为黄旗而非红旗，指出 Net-60 在企业采购模板中常见，可尝试折中为 Net-45，并如实说明首次合作时付款条款往往不可协商。

审批门槛（Approval gates）：输出质量红线

SKILL.md 列出了七条不可逾越的规则，既是输出规范也是质量保证：

• 绝不可将输出定性为法律意见；红旗条款或具有约束力的决定必须建议交由律师复核；
• 引用条款原文而非转述——用户谈判电话里需要精确文本；
• 要标记缺失项，而不只是已存在的条款——对责任上限或变更单保持沉默的合同，往往比明确不利条款更危险；
• 不标记标准样板条款——公平且符合市场标准的条款应跳过，用户要的是信号，不是逐条复述；
• 标记时对照市场惯例——如"Net-90 在专业服务中不常见——Net-30 才是标准"；
• 建议要匹配权力结构——Fortune 500 采购 MSA 的谈判与小型初创协议完全不同；
• 未经用户明确确认，绝不把红线 DOCX 发给相对方。

技能文件组织与仓库语境

从 cowork-plugin-management/skills/create-cowork-plugin/references/component-schemas.md 中定义的插件组件规范可以确认本技能遵循了标准的"渐进式披露"结构：frontmatter 的 name + description（约 100 词）始终在上下文中用于触发判断；SKILL.md 正文（核心工作流，建议控制在 5,000 词内）在技能触发时加载；references/ 下的细节文档按需加载。contract-review 技能正是按此结构组织：

small-business/skills/contract-review/
├── SKILL.md                                  # 核心工作流与审批门槛
└── reference/
    ├── gotchas.md                            # 边缘情况（好/坏做法对照）
    ├── docusign-fetch.md                     # DocuSign 取件
    ├── gmail-fetch.md                        # Gmail 附件查找
    └── examples/
        └── flagged-summary-saas.md           # SaaS 协议完整示例

整体架构上，本技能是 small-business 插件 "Skills（原子能力）→ Commands（工作流）→ Router（自然语言入口）"三层体系中的 Skill 层：Router 用自然语言识别意图，/review-contract 命令把 contract-review 技能链入完整流程，而合同审查技能自身只负责"把一件事做透"。插件体系中还存在面向企业法务的 legal 插件 review-contract 技能，其方法基于组织的谈判剧本（playbook）做逐条比对，与本技能面向无法务 SMB、以市场惯例为基准的分级标注形成互补——理解这一语境有助于按自身规模选用合适的能力。

小结

contract-review 技能把一套可复用的 SMB 合同审查方法论固化成了机器可执行的指令：三种取件通道（Gmail / DocuSign / 本地文件）、通读全文后再分析的纪律、覆盖付款/责任/终止/IP/范围/竞业/保密/运营的 8 类风险清单、红/黄/绿分级 + 合同摘要 + 谈判剧本的输出结构、以及删除线/下划线标记的红线 DOCX 导出。它最核心的价值主张有三个：引用原文（谈判需要精确措辞）、标记缺失（沉默条款往往比不利条款更危险）、匹配权力结构（建议必须符合谈判现实）。对于没有内部法务的中小企业，"What am I signing?" 这道题，从此有了一个能先帮你把风险摊开、再决定要不要请律师介入的起点——但请始终记住，最终签署决定仍需专业法律意见兜底。