lov-review-doc v1.0.0A

Immutable. This exact content is served forever at /api/v1/blob/c355693c133a2f39.

---
name: sgc-review-doc
description: >
  专业合同分析、审阅、批注与红线修订。用于用户要求审查合同、协议、条款、NDA、采购或服务合同、SaaS 或数据协议、劳动或顾问协议、知识产权许可、投融资文件，或要求风险分析、逐条批注、修订模式、谈判建议、审阅报告时；支持 DOCX 原位批注和修订，以及 PDF、图片或纯文本的定位审阅。
license: MIT
metadata:
  author: lovstudio
  version: "1.0.0"
  category: business
  tags: contract legal review annotate redline negotiation 合同 审阅 批注 修订
  compatibility: Python 3.8+、python-docx 1.0+、lxml 4.9+；支持 macOS、Windows 和 Linux
---

# 合同专家审阅

以资深交易律师与法务负责人的工作标准审阅合同。既判断法律风险，也判断交易能否履行、责任是否对等、证据是否留得住、争议时是否执行得了。不要把关键词扫描冒充专业审阅。

## 不可降低的标准

- 先确认审阅立场、法域、合同类型、交易目标和风险偏好；信息不足时列明合理假设并继续，不因非关键缺口停工。
- 区分三类判断：`文本事实`、`法律判断`、`商业判断`。不得把商业偏好写成法律强制要求。
- 引用法律结论前核验当前有效的官方来源、施行日期和适用法域。不得凭记忆引用条号。
- 保留原文件，输出新文件；不得覆盖用户原件。
- 每个高风险问题必须包含后果、建议和可落地的替代文本。只写“建议咨询律师”不算完成。
- 不臆造缺失附件、主体资质、金额、日期、法条、判例或谈判背景。未知项标为“待确认”。
- 对重大交易、跨境、监管、争议中或需要正式法律意见的事项，明确建议由对应法域执业律师复核；这不替代本次实质审阅。

## 工作流程

### 1. 建立审阅任务书

优先从用户材料和上下文提取以下信息：

- 我方身份与希望保护的利益
- 对方身份、主体类型和履约能力
- 适用法、争议解决地、合同语言
- 合同类型、交易金额、期限和关键时间点
- 必须接受、可以交换、不可接受的商务条件
- 当前阶段：初稿、对方稿、谈判稿、待签稿或履约争议
- 交付偏好：仅批注、仅修订、批注加修订，或审阅报告

缺少信息时采用默认值：站在提供文件一方的利益立场；中国大陆一般商事合同；中等风险偏好；输出“批注 + 修订 + 审阅报告”。在报告开头显著列出这些假设。

### 2. 准备并完整读取文件

根据输入格式处理：

- **DOCX**：运行 `scripts/contract_docx.py extract`，读取正文、表格、页眉和页脚。不得只看正文段落。
- **PDF**：使用可用的 PDF/OCR 能力，保留页码和条款号；扫描件先检查 OCR 置信度。无法安全写回时输出页码级批注表，不伪称已写入原文件。
- **图片**：逐页 OCR，保留图片序号和区域定位。
- **纯文本/Markdown**：按标题、条款号和原文短引定位。

同时检查附件、定义、目录、签署页、价税表、SLA、DPA、订单和引用文件是否齐全。缺失材料单独列为“审阅范围限制”。

DOCX 命令：

```bash
python3 scripts/contract_docx.py extract --input 合同.docx --output 合同-blocks.json
python3 scripts/contract_docx.py validate --input 合同.docx --annotations 审阅数据.json
python3 scripts/contract_docx.py annotate --input 合同.docx --annotations 审阅数据.json --output 合同-批注修订版.docx
```

需要 `python-docx>=1.0` 与 `lxml>=4.9`。如果缺失，先在隔离环境安装；不要修改用户项目依赖。

### 3. 确定法律与行业基线

先识别适用法域，再选择权威来源。中国大陆合同先阅读 [中国大陆法律核验基线](references/prc-legal-baseline.md)。其他法域仅使用对应立法机关、法院、监管机构或官方法库；无法可靠核验时明确限制，不把中国法规则套用到境外合同。

对数据、金融、医疗、教育、广告、消费者、劳动、建设工程、房地产、进出口等受监管交易，追加行业专项核验。

### 4. 做七轮审阅

按顺序完成，不因发现前几项问题而跳过后续检查：

1. **交易结构**：主体、授权、标的、对价、税费、交付、验收、付款闭环。
2. **定义与一致性**：定义是否完整；条款、附件、日期、金额、币种、比例和交叉引用是否一致。
3. **权利义务**：触发条件、履行标准、期限、依赖项、审批权、变更机制是否清晰且可执行。
4. **风险分配**：陈述保证、赔偿、违约责任、责任上限、免责、保险、不可抗力和第三方索赔。
5. **生命周期**：生效、续期、暂停、解除、终止、交接、退款、数据返还或删除、存续条款。
6. **合规与争议**：强制性规则、审批登记、知识产权、保密、数据、出口管制、反商业贿赂、适用法和争议解决。
7. **可操作与可举证**：通知、确认、记录、审计、送达、签署、版本优先级、证据留存和执行成本。

按合同类型加载 [合同类型与条款检查表](references/review-playbook.md)，但不要机械套模板。

### 5. 形成问题清单并定级

每个问题记录：原文定位、原文短引、风险等级、问题类型、结论、依据、可能后果、首选修订、退让方案、是否需业务确认。

风险等级：

- **致命**：可能导致交易目的不能实现、重大无上限责任、明显无效或重大监管风险；签署前必须解决。
- **高**：发生概率或损失显著，且现有文本明显不利；原则上必须修改或取得书面风险接受。
- **中**：会增加履约、举证或争议成本；建议修改，可用商务条件交换。
- **低**：清晰度、格式或轻微不一致；有余力时修正。
- **提示**：不是缺陷，但需要业务决策、补资料或持续关注。

谈判优先级另行标记为 `必须坚持`、`优先争取`、`可交换`、`可接受`。风险等级与谈判优先级不得混为一谈。

### 6. 写批注与修订

默认同时提供批注和红线修订。批注解释“为什么改”，修订文本解决“怎么改”。遵循 [批注数据与交付格式](references/annotation-schema.md)。

每条批注使用以下结构，控制在 2 至 5 句：

```text
【高风险｜责任限制｜必须坚持】本条将间接损失排除仅适用于对方，且未设置我方累计责任上限。发生服务中断时，我方可能承担不可预测且无上限的赔偿。建议改为双方对等排除间接损失，并将一般责任上限设为过去十二个月已付费用；保密、知识产权侵权和故意重大过失可另设例外。
```

修订时：

- 尽量做最小必要修改，保留原有措辞、编号、格式和商业口径。
- 给出可直接粘贴的完整句子或完整条款，不用“酌情调整”“按法律规定”等空话。
- 高风险条款同时给出首选版本和可接受的退让版本；不要把所有条件都改成极端单边保护。
- 中英文合同保持术语和定义一致；如两种文本同等效力，检查冲突处理机制。
- 不确定的商业数字使用 `[待业务确认：…]`，不得自行填数。

### 7. 输出完整交付物

默认生成：

1. `原文件名-合同审阅-YYYY-MM-DD.docx`：含批注和修订痕迹。
2. `原文件名-审阅报告-YYYY-MM-DD.md`：便于决策和谈判。
3. `原文件名-审阅数据-YYYY-MM-DD.json`：可复核的结构化批注与修订数据。

审阅报告采用以下结构：

```markdown
# 合同审阅报告

## 审阅结论
签署建议：可签 / 修改后可签 / 暂缓签署
用一段话说明总体风险、关键前提和审阅范围。

## 审阅任务书与假设
我方立场、适用法、合同类型、风险偏好、材料范围、待确认项。

## 必须在签署前解决
只列致命和高风险事项，按谈判顺序排列。

## 风险清单
表格列：编号、定位、风险、类别、问题、后果、建议、谈判优先级。

## 缺失条款与材料
列出缺失附件、空白字段、未闭环机制和建议补充文本。

## 谈判方案
首选条件、可交换条件、底线、建议话术。

## 法律依据与核验日期
只列实际使用的权威来源、条文或规则、链接、核验日期。

## 审阅范围限制
列出 OCR、材料缺失、法域或行业专项意见等限制。
```

### 8. 做签署前质量检查

交付前逐项确认：

- 原文件未被覆盖，输出文件能正常打开。
- DOCX 的批注和修订数量与 JSON 一致；运行 `validate` 无错误。
- 每个致命和高风险问题都有明确替代文本或可执行动作。
- 所有定位、原文短引、定义、条款号和交叉引用准确。
- 金额、日期、币种、税率、付款比例、期限和附件名称前后一致。
- 争议解决条款写明机构或法院、地点、适用规则、语言和适用法，且组合可执行。
- 法律来源为当前有效的官方文本，并记录核验日期。
- 报告明确签署建议、谈判底线、待确认项和审阅限制。

如果质量检查失败，先修复再交付；不要把脚本“执行成功”当成审阅完成。

## 交付边界

- 不声称自己是用户的执业律师，不出具律师事务所法律意见书或法律认证。
- 不协助伪造签名、日期、审批、证据或交易背景。
- 不因风险提示而擅自替用户接受条款、签署、发送给对方或提交监管机构。
- 涉及高额、控制权、股权、担保、破产、刑事、制裁、跨境数据或迫近诉讼时，在完成实质审阅后建议专项律师复核。