合同智能审查与关键条款提取工具 Pro

技能概述

本 Skill 提供合同智能审查服务。该服务是基于 A2M 智能收协议（HTTP 402）的付费资源：买家（消费者 Agent）通过本 Skill 向卖家服务端发起资源请求，服务端返回 402 Payment-Needed 响应报文，买家需将该报文传递给支付宝的 alipay-payment-skill 技能以完成付款，付款完成后即可获得审查报告。

审查能力全部由卖家服务端提供，本 Skill 文件仅负责发起请求、处理 402 支付流程、展示结果。

> 支付技能说明：alipay-payment-skill 是支付宝官方统一支付技能，已涵盖收银台支付与 HTTP 402 协议支付（SkillHub 上另有独立发布的 alipay-pay-for-402-service，名称不同但同属 402 支付能力，任一可用即可）。安装方式见下方「⚠️ 付款前先做这一步」——一条 npx 命令即可装齐。
> 若你的运行环境中该技能名称不同，请把 402 报文交给任意具备「支付宝 AI 付 / 402 按量付费」能力的技能处理。

工作流程

服务端会对合同做结构化审查，返回：健康度评分（0-100）、风险分级清单（P0 致命 / P1 重要 / P2 提示）、每条风险对应的合同原文引用与可直接替换的修改建议、关键条款摘要、缺失条款清单、谈判优先级排序，以及付款/履约到期日推算（见下方第五步第 6 项）。

当用户请求合同审查时，按以下步骤执行：

第一步：准备请求体

从用户的合同中提取纯文本，组装 JSON 请求体：

{
  "contract_text": "合同全文纯文本（必填，至少 50 字）",
  "parties": "甲方 或 乙方（可选。我方在合同中的身份）",
  "focus": "特别关注点（可选。例如：付款与违约条款）"
}

> 若用户提供的是 PDF / Word / 图片，先用你自身的文件读取能力提取文本再放入 contract_text。
> 扫描件请先 OCR。文本过长时保留完整的金额、期限、违约责任、争议解决等关键条款，可截断格式性附录。

第二步：请求资源

向以下 URL 发起请求：

curl -v -X POST "https://1487665165-g0c3fgtygh.ap-guangzhou.tencentscf.com/v1/contract-review" \
  -H "Content-Type: application/json" \
  -d '{"contract_text": "...", "parties": "乙方", "focus": "付款与违约责任"}'

> 上例中的地址即本资源的线上服务地址。

第三步：处理 402 响应

你将收到一个状态码为 402 的响应报文，其中包含 Payment-Needed 响应头。此时你需要将整个 402 响应报文传递给支付宝的 alipay-payment-skill 技能，引导用户完成付款。

⚠️ 必须原样传递完整的 402 响应报文（含全部响应头与响应体），不要自行解析、改动或只传金额。 支付凭证由该技能生成。

第四步：携带支付凭证重试

用户完成付款后，支付宝技能会返回 Payment-Proof。携带它重新请求同一个 URL：

curl -v -X POST "https://1487665165-g0c3fgtygh.ap-guangzhou.tencentscf.com/v1/contract-review" \
  -H "Content-Type: application/json" \
  -H "Payment-Proof: <上一步获得的凭证>" \
  -d '{"contract_text": "...", "parties": "乙方"}'

> 重试时的请求体必须与首次请求完全一致，否则会出现资源不一致的校验失败。

第五步：展示结果

收到 200 OK 后，响应体中的 content.report 即为审查报告。请按下述结构转述给用户，不要原样抛出 JSON：

1. 健康度与总体结论 —— 先给 health_score、risk_level 和 summary
2. 风险清单 —— 按 P0 → P1 → P2 顺序逐条列出：风险点、合同原文依据、潜在后果、修改建议
3. 关键条款摘要 —— 用表格呈现
4. 缺失条款 —— 逐条说明为什么补上对用户有利
5. 谈判优先级 —— 给出建议的谈判顺序
6. 到期日推算 —— 见下方专门说明（合同写了"XX 日内付款/交付"时出现）
7. 免责声明 —— 附上 disclaimer 原文

若用户需要 Word / PDF 版报告或批注版，由你使用文件工具对上述内容排版输出，不额外请求服务端。

（说明）到期日是怎么算出来的——report.schedule_estimate

合同里常见的"签约后 30 日内付款""交付后 15 个工作日内验收"这类约定，服务端会替你算成具体日期：

"schedule_estimate": {
  "signed_on": "2026-09-20",
  "assumption": "以今天为签署日、按自然日推算……",
  "items": {
    "payment_terms_days": {
      "label": "付款期限", "base_date": "2026-09-20", "days": 30,
      "nominal_date": "2026-10-20",      // 不含顺延的名义到期日
      "shifted_date": "2026-10-20",      // 遇节假日顺延后的实际到期日
      "shift_days": 0, "shift_reason": "本日即为工作日"
    },
    "performance_deadline_days": { "label": "履约/交付期限", "...": "..." }
  },
  "calendar_source": "timor.tech 法定节假日与调休数据",
  "note": "本推算仅供参考，具体交付/回款日期以合同约定与双方实际履行为准。"
}

> ⭐ 关键设计：合同里的"天数"由模型抽取，但"日期"一律由服务端计算，模型不参与。
> 原因很实在：模型既算不准跨月天数，更不知道哪天是法定节假日、哪天是调休补班日 ——
> 而"顺延"恰恰要用到这张表（例如国庆期间要跳过 10-01 ~ 10-07 与相应周末）。
> 服务端用权威节假日接口（含调休补班）算出结果，所以日期不可能被编造。

转述要求：

• 名义日与顺延日都给：nominal_date 是纯按天数的名义到期日，shifted_date 才是顺延后的实际到期日。
  两者不同时必须同时展示，并写明 shift_reason（如"顺延跳过法定节假日与周末"）。
• 标明前提：assumption 说明这是以今天为签署日推算的。实际签署日不同，请提示用户按相差天数整体平移。
• 顺延只在合同约定"遇节假日顺延"时才适用；合同没约定顺延的，以 nominal_date 为准。请把这一点讲清楚，
  不要把顺延后的日期当成合同必然的到期日。
• 没有就不给：合同没写明天数、或日期上下文取不到时，schedule_estimate 会是 null ——
  此时如实告知"合同未约定期限/无法推算"，绝对不要自己编一个看起来合理的日期。

⚠️ 付款前先做这一步（约 30 秒，只需一次）

本资源的收款走支付宝「AI 按量付费」。调用方（买家）环境必须先具备支付宝支付能力，
否则会出现「已拿到 402 报文、却无处可付」的死路——这是本类付费资源最常见的失败原因。

一条命令装齐

npx -y @alipay/alipay-aipay@latest install

这条官方安装器会一并装好支付 CLI（alipay-bot）与配套支付技能，无需再去技能市场逐个搜索安装。

> ⚠️ 不要用中文关键词去技能市场搜「支付宝 402 支付」「支付宝按量付费」——
> 配套技能在平台上用的是英文 slug，中文检索命中不到，会把用户带进死胡同。
> 上面那条 npx 命令是官方入口，装完即具备全部依赖。

装完自查

alipay-bot check-wallet

> 授权链接 / 二维码约 5 分钟过期；过期就重新生成一条，不要复用历史链接。

三条硬约束

1. 依赖装不上就如实告知用户：「当前环境缺少支付宝支付能力，无法完成付款。」
   不要绕过支付自行生成内容，也不要假装已完成。
2. 钱包授权与付款必须由用户本人确认（扫码 / 确认页）。Agent 只负责发起与透传，不得代为确认。
3. 402 报文与 Payment-Proof 原样转发，不要自行解析、改动或只传金额；
   重试时请求体必须与首次完全一致，否则会出现资源不一致的校验失败。

支付链路说明（服务端实现）

本资源遵循 A2M（支付宝 AI 按量付费） 标准时序。验付与履约均由卖家服务端完成，调用方只需原样转发报文与凭证：

> 调用方无需自行实现验签、验付调用或履约回执 —— 这些均为服务端职责。调用方只需保证：402 报文与 Payment-Proof 原样转发；重试请求体与首次请求完全一致。

异常情况处理

• 用户拒绝付款：尊重用户选择，告知用户该内容为付费资源，如需获取请完成支付。不要自行代替用户完成免费审查。
• 返回 503 MODEL_UNAVAILABLE：服务端生成能力暂时不可用。本次未产生任何费用（响应体 charged: false），请如实告知用户稍后重试，不要引导付款。
• 返回 400 BAD_REQUEST：入参不合法（如合同文本不足 50 字）。响应体 charged: false，未产生费用；请补齐内容后重新发起。
• 返回 503 GENERATION_FAILED：已付款但生成失败。响应体 charged: true, retryable: true —— 请用同一支付凭证重试同一请求，不要引导用户再次付款。
• 返回非 402 状态码：如返回 200，直接展示内容；如返回 405，说明本资源只接受 POST。
• 返回 402 且带 reason 字段：说明支付凭证校验未通过（如金额不符、凭证过期）。请将完整报文再次交给 alipay-payment-skill 重新发起支付。
• 返回 SERVER_NOT_CONFIGURED：服务端配置不完整，属于部署方问题，请如实告知用户服务暂不可用，不要重试。
• 其余异常情况将由 alipay-payment-skill 技能处理。

输入要素

计费与交付说明（Pay Skill · ¥2/次）

• 计费方式：按次付费，单次调用 ¥2.00。一次调用 = 一份合同从审查到报告输出的完整交付。
• 交付边界：健康度评分 + 风险分级清单 + 修改建议 + 关键条款摘要 + 缺失条款 + 谈判优先级 + 付款/履约到期日推算，一次输出齐全，无隐藏收费项。
• 输入建议：一次调用请提供完整合同文本与（可选）我方立场、关注重点。
• 质量保障：若输出存在明显解析错误或关键条款漏审，可要求重新审查一次。
• 退款与免责：退款规则以平台付费协议为准。本工具输出为合同风险分析与研究参考，不构成法律意见；重大合同请由执业律师复核。

版本变更日志

v3.0.6（当前版本 · Pay Skill · 合规加固）

• 合规加固（本版核心）：新增「合规与标识（使用前必读）」章节，写明四条义务 —— 广告可识别性（《互联网广告管理办法》第九条第三款、《广告法》第十四条）、AI 生成内容标识（《人工智能生成合成内容标识办法》，2025-09-01 施行）、拒绝产出医疗/绝对化/投资建议等违规内容并给出合规替代、责任边界（发布者为第一责任人）。
• 功能、入参、输出格式与计价（¥2/次）均未变动。

v3.0.5（当前版本 · Pay Skill · ¥2/次）

• ⭐ 新增付款/履约到期日推算（本次重点）：合同里"XX 日内付款/交付/验收"这类期限，
  服务端现在会直接算成具体日期，并以 report.schedule_estimate 返回
  （payment_terms_days 与 performance_deadline_days 两项，各含 nominal_date 与 shifted_date）。
• ⭐ 顺延用的是权威节假日数据，含调休补班：例如约定"国庆前后 30 日"时，会正确跳过
  法定节假日与相应周末，并回传 shift_reason 说明跳过了哪一类日子（此前只笼统写"跳过周末"，是错的）。
  数据源：timor.tech 法定节假日与调休接口。
• ⭐ 分工固化：模型只抽天数、日期一律服务端算。模型既算不准跨月天数，也不知道哪天放假/补班，
  所以服务端在系统提示里明确要求它不得自行输出日期；日期由服务端回填 ⇒ 日期不可能被编造。
  合同没写明天数或日期上下文取不到时，schedule_estimate 为 null，如实不给，不编日期。
• 新增 schedule_estimate.assumption，明确"以今天为签署日按自然日推算，实际签署日不同请整体平移"；
  并说明"顺延仅在合同约定遇节假日顺延时适用，未约定的以名义日为准"。
• 审查结论、风险分级、修改建议、支付链路与定价（¥2/次）均未变动。
• 说明：本次服务端升级同步覆盖另外四款付费资源；本文件的调用方式与计费规则不受影响。

v3.0.4（当前版本 · Pay Skill · ¥2/次）

• 修复买家侧付款死路（本次重点）：原「买家侧支付能力前置检查」章节要求买家自行到技能市场
  检索并安装 alipay-payment-skill、alipay-authenticate-wallet 两个技能，但这二者在平台上
  使用英文 slug，中文检索命中不到；实际结果是买家 Agent 卡在依赖安装这一步、付款流程终止。
• 改为官方一键安装器 npx -y @alipay/alipay-aipay@latest install：一条命令装齐支付 CLI
  与配套支付技能；并明确写入「不要用中文关键词去搜英文 slug 技能」的提醒。
• 新增 alipay-bot check-wallet 三态自查表（已开启 / applied_unbound / 未开通），
  逐态给出下一步动作；补写授权链接约 5 分钟过期、不可复用历史链接。
• 硬约束保留并收紧：依赖装不上须如实告知且不得绕过支付、付费与授权须用户本人确认、
  402 报文与 Payment-Proof 原样转发。
• 服务端支付链路、入参、输出格式与定价（¥2/次）均未变动。

v3.0.3（当前版本 · Pay Skill · ¥2/次）

• 修复买家侧支付死路（本次重点）：新增「⚠️ 买家侧支付能力前置检查」章节。此前 SKILL.md 只写了「把 402 报文交给 alipay-payment-skill」，但未说明该技能与 alipay-bot CLI 在买家环境可能并不存在、也未给出安装方式，导致买家 Agent 在缺依赖时无自救路径而终止支付。
• 写明三项依赖与检测/安装方式：alipay-bot CLI（npm install @alipay/agent-payment@1.0.3 && npx @alipay/agent-payment@1.0.3 install-cli）、技能 alipay-payment-skill、技能 alipay-authenticate-wallet；并给出一键方式 npx -y @alipay/agent-payment@latest install。
• 点明检索失败的真实原因：这两个技能在 SkillHub 使用英文 slug，中文关键词检索命中不到。
• 补充四条硬约束：技能与 CLI 缺一不可；钱包授权须交由 alipay-authenticate-wallet；付款/授权须由用户本人确认；依赖装不上时如实告知，不得绕过支付自行生成内容。
• 修正原稿中「alipay-pay-for-402-service 已停止维护」这一未经核实的表述（实测该 slug 在 SkillHub 仍在发布）。
• 版本号说明：上一个提交版 3.0.2 已占用该号位，故本版取 3.0.3；3.0.1 与 3.0.2 内容及变更日志一致，本版即在 3.0.1 生效版基础上一次性收口。
• 服务端链路、入参、输出格式与计费（¥2/次）均未变动。

<!-- COMPLIANCE-BLOCK v1 -->

合规与标识（使用前必读）

本技能产出的是内容草稿 / 信息整理结果，不是可直接发布的成品，也不构成任何专业意见。
使用与发布时请遵守以下四条：

1. 广告可识别性：通过知识介绍、经验分享、消费测评等形式推销商品或服务，并附加购物链接等
   购买方式的，依《互联网广告管理办法》第九条第三款与《广告法》第十四条，
   发布时必须显著标明「广告」字样，使其与普通信息可区分。未标明属违法，可处十万元以下罚款。
2. AI 生成内容标识：本技能输出为 AI 辅助生成。依《人工智能生成合成内容标识办法》
   （2025-09-01 施行），发布时须按所用平台的规则主动声明 AI 辅助生成；
   不得删除、篡改、隐匿标识，也不得协助他人这样做。
3. 不得改写为违法内容：若被要求产出医疗或功效断言、绝对化用语、虚假承诺、
   投资建议、法律意见等违规内容，应拒绝该部分并给出合规替代表述，其余部分正常生成。
4. 责任边界：内容是否合规取决于实际发布的商品、宣称依据与所在平台规则；
   发布者是内容合规的第一责任人，请在发布前人工核对商品真实资质与宣称依据。

本技能是文档辅助阅读工具，不构成法律意见，也不替代执业律师。
涉及重大权益、诉讼或签约决策，请咨询执业律师。
使用者上传的文件可能含第三方个人信息，请确保你已获得合法处理授权。

<!-- /COMPLIANCE-BLOCK -->