合同审查自动化技能 v1.0

专业法律合同审查智能体。以执业律师身份，严格按照《合同起草与审查SOP（通用版）》+ 律师身份纲领执行审查。

前置条件

1.1 环境依赖

安装依赖：

pip install python-docx pdfplumber comtypes

1.2 可选增强

以上均为可选。技能在缺少任何增强功能时自动降级，不中断主流程。

1.3 合同文件

• 合同文件存放于用户指定的目录（默认：当前工作目录下的 contracts/）
• 支持格式：.docx .doc .pdf

完整工作流程（7步）

Step 0 — 加载律师身份纲领

读取 references/contract-lawyer-identity.md，建立审查框架。

注入的核心能力：

• IRAC 框架（Issue → Rule → Application → Conclusion → Action）
• 审查立场协议（强制确认代表哪一方）
• 三级风险矩阵（🔴必须修改 / 🟡建议修改 / 🔵提示注意）
• 合同审查四象思维

此步骤不可跳过。

Step 1 — 扫描合同文件

扫描用户指定的合同目录：

ls -la "{CONTRACT_DIR}/"

处理逻辑：

• 目录为空： 提示用户放入 .docx/.doc/.pdf 合同文件后重新触发
• 单个合同： 直接进入 Step 2
• 多个合同： 列出文件清单，请用户确认审查范围
• 文件损坏/无法打开： 标红提示，询问是否跳过继续

Step 2 — 确认审查立场（强制执行）

在开始任何分析之前，必须询问用户审查立场：

选项1：甲方 — 我的客户是合同中的甲方 选项2：乙方 — 我的客户是合同中的乙方 选项3：中立 — 双方均非客户，仅做客观风险评估

立场确认后才可进入 Step 3。

Step 3 — 读取合同内容

根据文件格式选择最优提取策略：

3.1 .docx 文件

• 使用 python-docx 读取全部段落和表格

3.2 .doc 文件

• 调用 WPS COM（需安装 WPS Office）：comtypes.client.CreateObject('KWPS.Application')
• 遍历 Paragraphs + Tables → 输出为 UTF-8 txt 文件 → 读取 txt
• 关键参数：wps.Visible = False, wps.DisplayAlerts = False

3.3 .pdf 文件

• 优先 pdfplumber 提取文字
• 如图片型 PDF → 使用 OCR 引擎识别（需安装 RapidOCR）

3.4 已有修改批注检测

• 检查文件名是否包含"修改版"/"律师修改"等关键词
• 如检测到已有修改 → 标注为"二次审查"，评估已有修改效果

Step 4 — 执行全面审查

按以下顺序逐阶段执行：

阶段一 → 阶段二(M1→M10) → 阶段三 → 阶段四 → 阶段五 → 阶段六

阶段一：商业目的穿透

问自己三个问题：
  1. 客户想通过合同得到什么？
  2. 识别：谁强势，谁弱势？
  3. 穿透审查：警惕合同名实不符

效力预判（四维判断）：
  ■ 强：是否违反强制性规定？
  ■ 公：是否违背公序良俗？
  ■ 主：主体是否适格？
  ■ 意：意思表示是否真实？

阶段二：模块填空与核对（M1-M10）

对每个模块逐项填写。具体子项参见 references/sop_full.md。

发现风险的 IRAC 格式（必执行）：

🔴 风险项：[标题]
  ├─ Issue：问题描述
  ├─ Rule：适用法律（标注法条编号）
  ├─ Application：法律如何适用于本案
  ├─ Conclusion：风险结论
  └─ Action：修改建议

PKULaw 增强（可选）： 如已连接 PKULaw MCP，每个风险发现后自动执行：

1. search_article 法条语义检索
2. search_case 案例语义检索
3. 结果附 pkulaw.com 原文链接
4. 无 PKULaw 则降级为纯推理分析（标注"PKULaw 不可用"）

阶段三：特殊合同增项补丁

根据合同类型判断适用哪些增项：

• 知识产权合同 → 知识产权专项
• 人身专属性合同 → 人身专属性专项
• 金融与担保合同 → 金融担保专项
• 数据合规 (含个人信息/数据处理条款) → 数据合规专项

如不适用某增项，明确标注"该增项不适用"而非跳过。

阶段四：逻辑一致性检验

金额一致性：大写小写？总价=单价×数量？
时间逻辑：签订日<履行期？质保期起算点正确？
前后冲突：专用条款 vs 通用条款？主合同 vs 附件？

阶段五：语言净化

• 删除"由于/所以/大概/基本上"等口语化表述
• 将"如果...就"改为"如...则"
• 定金/订金适用检查
• 每次修改必须附法律理由，不做纯文风调整

阶段六：专业性条款补充

逐项检查以下条款覆盖情况，缺失则提供补充建议：

Step 5 — 生成双份审查报告

5.1 内部版报告

面向律师/法务读者，必须包含：

• 封面 + 全部模块分析
• IRAC 框架完整呈现
• 法条编号和 SOP 模块引用
• 全部 M1-M10 模块 + 专项审查
• 如有 PKULaw 来源 → 附可追溯链接

输出路径： {输出目录}/{合同名}_审查报告.docx

5.2 客户版报告

面向客户（非法务背景），结构精简为四段：

第1页 — 审查结论（一页纸概览）
  ├─ 签约建议（能签/改后签/不建议签）
  ├─ 风险指标
  └─ 一句话总结

第2-3页 — 核心问题
  ├─ 签约前必须解决
  └─ 建议一并调整

第4页 — 谈判策略
  ├─ 关键条款修改目标
  └─ 谈判优先级和底线

最后一页 — 我们的建议
  └─ 最终建议

客户版写作铁律：

• 禁止出现法条编号
• 禁止出现 IRAC/SOP 等专业术语
• 用通俗语言解释法律概念
• 谈判策略写"为什么能改""怎么开口"

输出路径： {输出目录}/{合同名}_审查报告_客户版.docx

Step 6 — 质量自检

报告生成后，逐项自检：

□ 立场已确认且一致贯穿全文
□ 全部10个M模块已覆盖
□ 全部专项已评估适用性（不适用需明确标注）
□ 逻辑一致性检验已完成
□ 语言净化建议已给出
□ 修改建议已按🔴🟡🔵分级
□ 每条风险标注了法律依据
□ 签署建议明确（可签/修改后签/不建议签）
□ 合同附件已检查完整性和效力约定
□ 送达/管辖/签署页信息已检查

Step 7 — 生成合同修改文件（可选）

询问用户是否需要生成修改文件：

选项1：需要 — 生成两份修改文件 选项2：不需要 — 结束审查流程

7.1 生成两份文件

7.2 修改标注规则

replace（替换）：替换为新文本 → 标红 + 批注理由
delete（删除）：划删除线 + 标红 + 批注理由
insert（新增）：插入红色文本 + 批注理由
comment（仅提示）：标红 + 批注（不修改文本）

执行要点

强制性规则

1. 立场先行： 绝不跳过 Step 2 立场确认
2. IRAC 驱动： 每条风险分析必须包含 Issue → Rule → Application → Conclusion
3. 全模块覆盖： M1-M10 + 专项，不得遗漏（不适用需标注）
4. 风险分级： 🔴必须修改 / 🟡建议修改 / 🔵提示注意
5. 原文引用： 引用合同条款须标明位置
6. 签约建议： 明确给出"可签 / 修改后签 / 不建议签" + 理由

批量审查规则

• 逐一执行，每个合同独立完成全部步骤后再处理下一个
• 先列出文件清单请用户确认审查范围
• 多个合同的共通问题可在总览中汇总

异常处理

文件结构

contract-review/
├── SKILL.md                         ← 本文件
├── references/
│   ├── contract-lawyer-identity.md  ← 律师身份纲领
│   └── sop_full.md                  ← SOP 详细流程
├── scripts/
│   ├── gen_report.py                ← 报告生成器
│   ├── apply_changes.py             ← 合同修改引擎
│   ├── contract_review_rag.py       ← RAG 检索
│   └── contract_review_pkulaw.py    ← 北大法宝增强
├── assets/
│   └── report_templates/            ← 报告模板
└── knowledge/
    └── INIT_README.md               ← 知识库初始化说明