罗斯蒙德合同审查

概述

南京罗斯蒙德基于已交付项目沉淀的合同审查场景：合同解析 → 条款语义比对 → 风险审查 → 三件套报告 → 审批流转。

聚焦智能写作 / 文档交付 / AIGC / 定制开发的背靠背合同——这是通用合同审查覆盖不到、也最容易亏钱的地方。

仅做风险初筛，不替代法务终审。

运行环境

脚本为纯标准库 Python，最低 3.6，不需要 pip 安装任何东西。

但各机器的解释器命令名不一致：Linux / macOS 多为 python3，Windows 上可能只有 python 或 py，而部分老系统上的裸 python 是 Python 2。因此执行任何脚本前，先解析一次可用解释器：

# POSIX：Linux / macOS / Git Bash
PY="$(command -v python3 || command -v python)"
"$PY" --version        # 必须 >= 3.6；若显示 2.x，换下一个候选

# Windows PowerShell
$PY = (Get-Command python3 -ErrorAction SilentlyContinue).Source
if (-not $PY) { $PY = (Get-Command python -ErrorAction SilentlyContinue).Source }
& $PY --version

想一次看清本机情况，用任意一个可用的 Python 跑自检脚本——它会列出全部候选、标出哪些版本过低，并给出本机对应的安装命令：

"$PY" scripts/env_check.py

下文所有命令示例中的 $PY，即指这里解析出的解释器；不要照抄成裸 python。

一、这个技能解决什么（企业场景）

合同审查是高频、重复、可标准化的动作，但依赖法务逐份人工过一遍，成本高、周期长，且口径因人而异。

本技能把「合同审阅与合规初筛」做成可复用流水线。与普通合同审查的差异在于业务专项：

南京罗斯蒙德的典型合同是「技术服务 + 定制开发」的背靠背结构——甲方（总集/渠道方）委托乙方服务最终客户。这类合同的亏损点高度集中且通用审查查不出来：

• 付款/验收背靠背且无最迟付款日、无视为验收条款 → 乙方无限垫资、无限返工
• 验收标准写成「最终客户满意」这类主观标准 → 永远触发不了付款节点
• AI 生成内容的著作权归属、能否用甲方文档训练模型、生成内容标识责任
• 交付物只有 PDF 成品、不交源文件与提示词模板 → 甲方无法二次维护
• 处理客户文档时的数据合规（第三方大模型 API 调用、删除返还、出境）

目标是在不替代法务终审的前提下，把重复可标准化的审查动作前置，降低人工初筛成本。

一个技能解决一个完整业务流，不做工具集合包——不涵盖诉讼代理、深度法律研究等非标动作。

二、什么时候用 / 什么时候不要用

适用

• 合同审查（买卖/服务/采购/框架/保密/授权等各类合同）
• 智能写作 / 文档交付 / AIGC / 定制开发类合同（本技能强项）
• 背靠背合同（甲方转委托、以最终客户验收为准）
• 合同语义比对（两份合同差异/版本差异定位）
• 合同用章检查（用章合规性初筛）
• 招标文件评分细则检查（评分项完整性、权重合法性）
• 单一来源采购条款分析（合规性论证）
• 自动生成诉状（事实梳理 + 案由 + 请求项初稿）

不适用（请转专业渠道）

• 出具正式法律意见、替代法务/律师终审
• 诉讼策略制定、法庭代理
• 与合同无关的通用文档审查（走 ai-writing）

三、能力地图

四、标准流程

方法论：文本提取 → 合同解析 → 条款语义比对 → 风险审查（用章/审批/合规 + 业务专项） → 三件套报告 → 交付自检 → 审批流转

步骤 0 · 文本提取（Text Extraction）

后续两个强制校验脚本只吃纯文本。合同是 PDF/Word 时必须先跑提取，不得跳过：

"$PY" scripts/extract_contract_text.py --input 合同.pdf --output 合同.txt
"$PY" scripts/extract_contract_text.py --input-dir ./contracts --out-dir ./txt   # 批量

• 支持 .pdf / .doc / .docx / .rtf / .txt / .md，按环境自动降级（pdftotext → pypdf → pdfminer；python-docx → textutil → pandoc）
• 扫描件/图片型 PDF 提取不到文本时，脚本会如实报错并退出码 1 —— 此时先 OCR 重跑，

严禁在无文本的情况下让下游脚本"假装通过"

步骤 1 · 合同解析（Contract Parsing）

• 读取合同文本，识别合同类型、主体、标的、金额、期限、违约责任、争议解决等关键要素
• 结构化抽取：合同要素表（当事人、金额、履行节点、生效条件、终止条款、管辖）

，字段定义见 references/clause_templates.md

• 输出中间产物：结构化合同要素 JSON，供后续比对与审查引用
• 缺失关键字段（如金额、主体不清）时标记红灯，进入步骤 3 重点提示
• 同时识别是否为背靠背 / AIGC / 文档交付类合同（识别特征见

references/rosemond_domain_rules.md 第零节），命中则步骤 3 必须叠加业务专项

步骤 2 · 条款语义比对（Clause Semantic Diff）

• 输入：待审合同 vs 标准模板 / 历史已审合同 / 对方上一版
• 逐条款做语义级比对，定位：缺失条款、表述差异、责任偏移、对我方不利修改
• 输出差异清单（条款号、差异类型、原文 vs 比对基准、影响等级）
• 比对基准优先用公司标准模板库；无模板时与行业通用条款比对并注明基准来源

步骤 3 · 风险审查（Risk Review：用章 / 审批 / 合规 + 业务专项）

分三类并行审查，逐项标注风险等级（高/中/低）与依据。

1. 用章检查：比对用章类型与用章审批记录/权限是否一致；超权限、错用章（合同章 vs 公章）、

缺失用章审批流程标记高风险。仅凭合同文本无法确认审批链时，标注「需人工核验用章审批单」

1. 审批检查：检查合同是否经过规定的内部审批节点（金额分级、部门会签），未走流程或越级审批标记风险
2. 合规检查（13 类通用维度）

逐项对照 references/review_checklist.md。完整清单见其第五节，速记如下：

1. 业务专项叠加（本技能差异化）

命中背靠背 / AIGC / 文档交付 / 定制开发 / 驻场任一特征时，叠加references/rosemond_domain_rules.md：

• 背靠背传导：主合同是否作为附件提供、付款是否有最迟付款日、验收是否有视为验收条款、

责任是否超过主合同对应部分、非乙方原因终止时是否按已完工作量结算

• AIGC 专项：生成内容著作权归属、能否用甲方数据训练模型、训练数据合法来源承诺、

生成内容标识义务（《人工智能生成合成内容标识办法》及 GB 45438-2025，2025-09-01 施行）、内容事实性责任、违法内容责任划分

• 交付物与源文件：交付清单是否穷举、是否交付可编辑源文件、提示词/模板库权属
• 数据合规：个人信息合法性基础、委托处理定性、数据返还与删除、

是否允许调用第三方大模型 API、数据出境

• 验收标准客观化、驻场与 SLA

通用维度判定为「低」的项，叠加专项后可能升级为「高」

（例：验收条款「有」但写成「最终客户满意」→ 专项判为高风险）。

脚本强制触发（必执行，非可选）

"$PY" scripts/check_amount_consistency.py --input 合同.txt --output amount_report.json
"$PY" scripts/check_typo.py --input 合同.txt --output typo_report.json

重要：脚本产出为线索，须回原文复核后再落报告，不得直接照抄为结论。

• 金额脚本只把同一处大小写数值对不上（type=conflict）判为高风险；

「仅有小写、未标注大写」是常见写法，按金额大小判为低/中，不直接升高风险

—— v1 曾把所有未匹配项一律升高风险，误报率极高，v2 已修正

• 大小写配对为就近配对（同句，或同章节且字符距离 ≤30），避免把相邻两条不同条款的

金额误配成「一致」

• 专业术语可能误报，逐条判断

步骤 4 · 三件套报告输出（Review Report）

• 结构化审查报告：合同概况、主体信息、风险清单（等级+所属章节+依据+修改建议）、核对表、待人工复核项
• 报告分级：绿灯（可推进）/ 黄灯（需修改后复审）/ 红灯（建议法务介入或终止），由 Markdown 报告自动判定

产物三件套（每份合同一套，同目录同名）

HTML + Markdown 必须脚本生成，禁止手工拼装

"$PY" scripts/build_report.py --data <审查数据.json>                    # 单份，同时出 HTML + MD
"$PY" scripts/build_report.py --data-dir <目录> --out-dir <输出目录>     # 批量（多合同场景必用）
"$PY" scripts/build_report.py --data <审查数据.json> --no-md            # 只出 HTML

脚本套用 assets/report_style.css 与 assets/report_script.js，输出单文件自包含 HTML。改样式或交互只改 assets 下这两个文件，禁止在输出 HTML 里另写一套 CSS/JS。

数据填写三条硬纪律

1. 定位用「所属章节」，禁用行号：每条风险必须填 section 字段（如「费用及结算 → 分阶段付款」）；

行号随文档编辑漂移，报告中不得出现「第 X 行」

1. KPI 只放简短结论（≤8 字符），说明文字放正文高危项或核对表，不得塞进 KPI
2. KPI 数值必须与实际风险条数一致：high_risk == high_risks 条数，以此类推，

金额/易错词 KPI 应与脚本产出对得上（由步骤 5 自检强制）

字段规范、页面显示映射、可访问性底线（WCAG AA）详见 references/report_template.md。

步骤 5 · 交付自检（Pre-delivery Gate）

报告出具前必须跑自检，把第十节清单中可自动判定的部分固化为门禁：

"$PY" scripts/validate_review_data.py --data <审查数据.json> 
    --amount-report amount_report.json --typo-report typo_report.json

• P0 问题（退出码 1）= 禁止交付：KPI 与风险条数不一致、风险缺 section、

出现行号表述、三件套不全、缺免责声明

• P1 提示（退出码 0，加 --strict 则阻断）：KPI 值超 8 字符、风险编号缺失或重复、

金额/易错词 KPI 与脚本产出对不上

步骤 6 · 审批流转（Approval Routing）

• 将审查报告与风险标记推送至对应审批节点（法务 → 业务 → 财务，按金额/类型路由）
• 高风险未关闭不得进入用章环节
• 记录审查结论与审批轨迹，留痕存档
• 对接企业审批系统（如飞书审批/企业微信）时按需唤起，无系统对接则仅输出待办清单供人工发起

五、怎么用（输入→产出）

把合同原文（或两份待比对合同）发给本技能，例如：

• 「帮我审一下这份合同」
• 「对比两份合同差异」
• 「这份背靠背合同有什么风险」
• 「AI 生成内容的著作权归谁，条款有没有问题」
• 「检查招标文件评分细则」
• 「审一下用章是否合规」
• 「帮我起草/生成一份诉状」

输入：合同原文（PDF/Word/图片扫描件/文本）+ 可选比对基准（标准模板/历史版本）产出：_审查报告.html + _审查报告.md + _审查数据.json 三件套 + 两份脚本校验 JSON

六、输出样例

examples/ 下有一份可直接运行的完整样例（智能写作平台技术服务合同，含真实的大小写金额矛盾）：

一键复现：

cd examples
"$PY" ../scripts/check_amount_consistency.py --input 示例合同_智能写作平台技术服务.txt --output 示例合同_金额校验.json
"$PY" ../scripts/check_typo.py --input 示例合同_智能写作平台技术服务.txt --output 示例合同_易错词.json
"$PY" ../scripts/build_report.py --data 示例合同_智能写作平台技术服务_审查数据.json
"$PY" ../scripts/validate_review_data.py --data 示例合同_智能写作平台技术服务_审查数据.json 
    --amount-report 示例合同_金额校验.json --typo-report 示例合同_易错词.json

七、卡点自救

• 扫描件无文本 → extract_contract_text.py 会如实报错退出码 1；先 OCR 再重跑，不得凭空推断条款
• PDF 提取到乱码/缺字 → 换 --input 原件另存为文本版 PDF；或 pdftotext -layout 后人工校对
• KPI 卡片撑破 → KPI 位只放 ≤8 字符简短结论，说明文字移到正文高危项
• 同名合同分不清 → Hero 的「类型」行不可删，靠类型行末尾的最终客户区分
• 金额脚本报高价差 → 输出是线索，回原文复核口径（含税/不含税、大小写、分项合计）后再落结论；

只有 type=conflict 才映射高风险

• 金额脚本 orphan 很多 → 「仅有小写、未标注大写」是常见写法，属提示非缺陷，不要一律升高风险
• 用章审批链无法核验 → 标注「需人工核验用章审批单」，不得默认通过
• 批量报告样式不一致 → 只改 assets/report_style.css 与 assets/report_script.js，勿手改输出 HTML
• 自检报 P0 禁止交付 → 按提示回步骤 3/4 修复，不要用 --no-md 或缺文件的方式绕过门禁
• 环境无法生成 docx/PDF → 交付 Markdown 并说明，不得假装已生成

八、质量护栏

1. 不替代法务终审：本技能输出为风险初筛与提示，不能作为正式法律意见；涉及重大金额、股权、诉讼的合同必须人工法务复核签字
2. 不虚构审查依据：风险提示必须指明条款位置或法规来源；引用法规须写清名称与生效状态，禁止凭空生成「合规/不合规」结论
3. 用章/审批核验有限：仅凭合同文本无法确认真实审批链与用章记录时，必须标注「需人工核验」，不得默认通过
4. 脚本产出是线索不是结论：须回原文复核后再落报告；专业术语可能误报
5. 诉状初稿需校对：自动生成诉状的事实与法律依据须人工核对，禁止直接提交法院
6. 格式受限如实告知：需要 docx/PDF 正式版且当前环境无法生成时，交付 Markdown 并说明，不得假装已生成
7. 无文本不得放行：扫描件提取失败时如实报错，严禁让下游脚本在空文本上"通过"

执行优先级：用户明确要求 > 技能默认规则；风险等级高 > 低（报告按等级排序）；要素缺失标红 > 表述优化建议；无法核验项如实标注 > 默认通过；不虚构审查结论，降级继续并说明。

九、与其他技能的边界

合同起草（从零写一份合同正文）不属于本技能，走 ai-writing；写好的合同需要审查再回到本技能。若审查对象是能源/电网/石化或纯招投标场景且无背靠背/AIGC 特征，contract-ai-review 亦可胜任。

十、检查清单（报告交付前自检）

优先跑 scripts/validate_review_data.py（步骤 5），以下为完整清单：

交付前逐项核对（建议直接用自检脚本），全部通过后方可提交。

十一、参考资源索引