Contract Intelligence Cn

---
name: contract-intelligence-cn
description: Review and redline Chinese contracts with verification.
version: 2.2.0
author: 戴永密律师, Hermes Agent
license: CC-BY-NC-4.0
platforms: [linux, macos, windows]
metadata:
  language: zh-CN
  domain: Chinese civil and commercial contract review
  tags: [法律, 合同审核, 原文留痕, Word, 对抗审查, 风险控制]
---

# 合同智审——中国律师原文留痕式合同审查与修改 Skill

将“法律分析—条款落地—Word原文修改—交付核验”整合为一个可执行流程。适用于用户提供 `.doc`、`.docx` 合同并要求从甲方、乙方、买方、卖方、发包人、承包人、管理人、投资人等特定立场审核或修改的情形。

> 本 Skill 仅辅助法律专业人员工作，不替代律师独立判断。所有法条、案例、税费和监管要求均须核验现行有效性。

## 一、成功标准

任务完成必须同时满足：

1. 明确委托方立场、交易目的及核心风险；
2. 形成“请求—抗辩—再抗辩”式风险分析；
3. 将审核意见转化为可直接执行的合同条款；
4. 在原 Word 文档中定点修改，不重写合同、不破坏原结构；
5. 交付红色留痕版和清洁签署版；
6. 核验金额、日期、编号、表格、红色覆盖和页面版式；
7. 不虚构法条、案例、数据或合同事实。
8. 区分“合同约定基础”与“已生效裁判文书、调解书、行政决定等上位履行依据”，不得让新协议倒退或削弱既有权利；
9. 严格执行用户的修改边界，用户要求“现有内容不变、只改指定部分”时，非目标内容必须通过前后比对验证未改变。

## 二、触发方式

用户出现下列意图时使用：

- “从甲方/乙方角度审核合同”；
- “在原合同上修改并保留痕迹”；
- “不要重写，保持原格式”；
- “出审核意见，再生成红线版和清洁版”；
- “检查金额、付款条件、违约责任、解除、管辖”；
- “只增加一段，其他内容不要动”。

仅需从零起草新合同、且不存在原文修改任务时，可以使用本 Skill 的法律分析模块，但不强制执行原文留痕流程。

## 三、第一步：读取文件与锁定范围

### 1. 文件处理

- `.docx`：直接读取；
- `.doc`：先用 LibreOffice 转为 `.docx`；
- 扫描件：先 OCR，标注识别不确定项；
- 同目录存在附件、补充协议、报价单、授权书时一并核对。
- 同时检查是否存在判决书、调解书、仲裁裁决、执行和解、股东会决议、债权确认文件等已经确定权利义务的外部依据。

不得将二进制 `.doc` 当文本读取。

### 2. 修改范围确认

先识别用户属于哪种指令：

| 指令 | 执行方式 |
|---|---|
| 审核并修改整份合同 | 全文风险扫描，定点修订 |
| 只改指定条款 | 仅处理目标条款及其必然关联条款 |
| 只增加一段 | 精确插入一段，其余内容逐字不动 |
| 不要直接修改 | 仅提交修改意见，等待确认 |
| 只转换PDF | 不改任何文本和格式 |

用户的最小修改指令优先于一般审查流程。

## 四、第二步：建立交易与请求权模型

在修改前，先用内部工作表回答：

1. 合同类型及交易目标是什么？
2. 委托方是谁，控制哪些资源？
3. 对方控制哪些履约节点、账户、印章、资料或登记？
4. 委托方的核心请求权是什么？
5. 请求权成立需要哪些要件和证据？
6. 对方最可能提出哪些抗辩？
7. 现有条款是否导致权利存在但无法执行？
8. 终止交易时如何结算、返还、交接和追责？
9. 现有权利义务是否已经被裁判文书、调解书、仲裁裁决、行政决定或生效决议确认？
10. 当前合同是否错误回到原基础合同，重新设置审核、结算、确认等前置条件，从而削弱既有确定权利？

### 请求—抗辩—再抗辩链条

每项重大条款至少推演一轮：

> 委托方请求 → 对方合同抗辩 → 委托方证据与条款回应 → 残余风险

示例：

> 买方要求返还价款 → 卖方主张付款已经发生、交付条件未成就 → 检查付款凭证、交付清单和解除条款 → 增加交付条件、逾期解除和返还期限。

## 五、第三步：七层合同审查矩阵

### 1. 主体与授权

- 名称、证照、住所、签约主体是否一致；
- 签署人是否有权代表；
- 是否存在代收代付、第三方履行、关联方承诺；
- 签署页、首页、附件中的主体是否冲突。

### 2. 标的与范围

- 标的是否可识别；
- “全部/部分”“包括但不限于”等是否失控；
- 主合同、附件、清单、图纸、报价是否形成闭环；
- 保留资产、排除事项及接口责任是否明确。

### 3. 价款、税费与支付

- 金额、小写、大写是否一致；
- 分期金额是否等于总价；
- 百分比合计是否为100%；
- 付款条件是否客观、可证明、可控制；
- 发票、税费、代扣代缴、第三方收款是否明确；
- 是否存在先全额付款后取得控制权的风险。

所有算术必须使用代码或计算工具，不得心算后直接下结论。

### 4. 履行、验收与证据

- 时间、地点、标准、程序、通知和异议期；
- 是否有交付清单、签收、验收、对账、结算机制；
- “视为认可”是否有合理期限和送达前提；
- 微信、邮件、系统记录能否作为有效通知和证据。

### 5. 陈述保证与风险归属

- 权利完整性、无负担、无未披露债务；
- 历史税务、劳动、诉讼、行政处罚；
- 数据、印章、证照、账户和资料；
- 风险是否由能够控制和防范的一方承担。

### 6. 违约、解除与结算

- 违约是否以过错、因果关系和实际损失为基础；
- 违约金是否畸高或单向；
- 是否有催告、补救期、暂停履行、抵扣；
- 解除后的退款、移交、清算和持续义务；
- 一期逾期是否错误导致全部债务加速到期。

### 7. 争议解决与生效

- 管辖、仲裁条款是否明确有效；
- 是否不合理选择对方总部法院；
- 生效条件、份数、附件效力和文本冲突顺位；
- 签字、盖章、捺印、骑缝签及电子签名要求。

### 8. 外部法律依据与文件顺位

- 是否存在已生效判决、调解书、仲裁裁决、执行和解或行政决定；
- 新协议的“鉴于”、履行条件、金额和期限是否与该等文件一致；
- 是否明确本协议系履行既有法律文书，而不是重新确认尚待审核的债权；
- 本协议与生效法律文书不一致时，效力顺位及解释规则是否明确；
- 是否明确本次履行计入哪一期、哪一笔金额，避免重复履行或履行归属不明；
- 原基础合同已被生效法律文书调整时，不得无提示地恢复原合同中的审核、结算、付款条件。

完整清单见 `references/review-matrix.md`。

## 六、第四步：形成审核意见

审核意见采用四段式：

1. **原条款/位置**；
2. **风险判断**；
3. **对方可能利用的抗辩**；
4. **建议修改条款**。

风险等级：

- `A 必须修改`：可能导致交易目的落空、重大付款损失、权利无法执行或责任失控；
- `B 建议修改`：存在较大争议空间或举证困难；
- `C 优化建议`：主要影响操作效率、表达准确性或版式。

不要只写“建议完善”“存在风险”，必须给出可直接放入合同的条款文本。

## 七、第五步：原文精准留痕

### 不可违反的规则

1. 不重新生成整份合同；
2. 不擅自调整标题、编号、表格、页眉页脚、签署页；
3. 不删除非目标内容；
4. 新增或替换内容用红色 `C00000`；
5. 修改表格时必须遍历表格单元格，不能只处理正文段落；
6. 原文存在数字矛盾时不得擅自选择一个数字，应标注待核实；
7. 用户要求“只增加一段”时，删除新增段落后必须能恢复原文。
8. 用户要求“现有内容均不变、只改封面/某页/某条”时，只允许定点修改目标节点；生成后应比较非目标正文文本或XML哈希。
9. 用户提供的是第三方版本、对照版本或已修改版本时，必须先确认每份文件的来源和地位，避免在错误底稿上修改。

### 两类交付

- **修改留痕版**：修改、新增文字为红色；
- **清洁签署版**：内容一致，统一黑色，可直接签署。

参考实现见 `references/docx-redline-guide.md` 和 `scripts/contract_skill.py`。

对于真实案件，可先由法律分析形成结构化修改计划JSON，再使用通用 `apply-plan` 执行器生成双版本；示例见 `examples/通用修改计划示例.json`。固定 `demo-redline` 仅用于竞赛示例一键演示，不代表通用能力边界。

## 八、第六步：自动核验

交付前必须执行：

### 1. 内容核验

- 修改目标是否全部命中；
- 是否存在旧条款与新条款并存；
- 是否遗漏表格中的主体、金额、签署信息；
- 大小写金额、分期总和、百分比、日期是否一致；
- 是否误改非目标内容。
- 与生效裁判文书、调解书或决议的金额、期限、条件是否冲突；
- 用户要求局部修改时，非目标部分前后文本是否一致。

### 2. 红色覆盖核验

重新打开 `.docx`，统计正文和表格中的红色段落/单元格。预期有修改但红色数量为零时，不得交付。

### 3. 版式核验

将 `.docx` 转为 PDF，逐页检查：

- 文字重叠、截断、越界；
- 表格行高和单元格换行；
- 标题孤立、异常空白页；
- 账号、金额、主体名称被拆行；
- 签署栏、页码、页眉页脚错位。

### 4. 生成核验报告

至少列明：

- 文件是否可打开；
- 页数；
- 红色覆盖数量；
- 金额核验结果；
- 关键条款是否存在；
- 是否发现版式异常。

## 九、交付格式

用户未另行要求时，交付：

1. 《合同审核意见书》；
2. 《合同名称（修改留痕版）.docx》；
3. 《合同名称（清洁签署版）.docx》；
4. 《自动核验报告.txt》或 `.md`。

微信回复保持简洁，说明核心修改、开放问题和文件路径。

## 十、安全与真实性边界

- 不虚构法律规定、裁判案例、行业数据；
- 法律依据不确定时标注 `【待核实】`；
- 不承诺合同绝对有效或案件结果；
- 不通过合同排除依法不得排除的责任；
- 不将内部协议包装成虚假登记、税务或监管材料；
- 不以新协议隐性放弃、降格或重新附条件于已经生效法律文书确认的权利，除非用户明确知悉并作出真实意思表示；
- 培训和公开演示使用虚构或脱敏数据，不包含客户身份、案号、账户及其他可识别保密信息；
- 不替用户隐瞒违法事实或制作虚假证据；
- 输出仅供法律专业人员审阅定稿。

完整可执行安全要求见 `references/data-security-confidentiality.md`：未脱敏或授权不明时，应停止向第三方服务上传材料；任务完成后按数据生命周期清理临时文件和日志。

## 十一、失败条件

出现下列任一情形，应视为任务未完成：

- 只给分析，没有修改原Word；
- 整体重写导致原格式丢失；
- 修改未标红或表格内容遗漏；
- 金额未计算核对；
- 未实际打开验证输出文件；
- 未转PDF进行版式检查；
- 声称引用法律或案例但无法核验来源。
- 忽略已经存在的生效裁判文书、调解书或其他权利确认文件；
- 用户要求只改指定内容，却连带重排或改写其他正文；
- 将“清洁签署版”误称为“已签署版”或对未填写、未签章文件作完成性陈述。

## 十二、真实实务迭代规则（脱敏）

本 Skill 已在真实律师工作流中反复迭代，新增以下可复用规则：

1. **三方抵扣/以房抵债协议**：不仅审查合同文字，还必须追溯基础债权是否已由法院调解书等生效文书确认；重点核对抵扣期次、网签登记期限、房屋不得处分、解除后债权恢复及协议与调解书的顺位。
2. **最小修改任务**：用户只要求增加一段或只改封面时，不得借机重写全文；正文前后文本哈希应一致。
3. **多版本底稿管理**：明确“对方提供版、我方修改版、清洁版、最终签署版”的文件身份；没有签章的清洁稿只能称“待签署清洁版”。
4. **事实与结果口径**：合同约定金额不等于实际履行结果；已回款、已签署、已解除等结果只能依据材料或用户明确确认表述。
5. **视觉交付不是形式步骤**：Word可打开不等于可以交付，必须检查表格、标题、签署区、长账号、跨页及异常留白。


## 十三、安装、扩展与复现文件

- 安装、依赖、兼容性与故障排查：`references/installation-compatibility.md`；
- 专业合同类型扩展：`references/contract-type-modules.md`；
- 审核意见模板：`templates/合同审核意见书模板.md`；
- 法律依据核验模板：`templates/法律依据核验记录模板.md`；
- 一键公开示例：`scripts/run_demo.py`；
- 正向及负向测试：`scripts/run_tests.py`；
- 版本维护与问题反馈：`references/maintenance.md`。