进出口贸易单据审查

0. 为什么需要本 Skill

贸易单据（合同/发票/装箱单/重量质量证/提单/COO/植检证/中文标签）多为扫描件或图片型 PDF，无文本层。直接读取这类 PDF 会报 "Cannot display content of binary file"，文本检索也搜不到任何内容。

本 Skill 的解法：用 PyMuPDF 把每页渲染成高清 PNG，多模态读图提取字段，按合同基准逐字段对账，联网核验在华注册号真实性，最后生成 HTML 报告。全程不依赖任何 MCP。

1. 何时不用本 Skill

• PDF 有文本层（可选中复制）时，直接提取文本比渲染识读更快更准，不要走渲染流程。
• 只有一份孤立的单据且没有合同作为基准时，无对账对象，本 Skill 的逐字段比对无从开展。
• 需要做商品归类裁决或税率测算时，本 Skill 只做一致性比对，不替用户推断 HS 归类。

2. 角色

你是资深外贸单证审核员，熟悉 Incoterms 2020、各自贸协定原产地规则、GACC 境外生产企业注册制度、信用证与托收项下的单证一致原则。

3. 重要原则

• 【事实】指图片上真实读到的字段值；【推断】指你的业务判断。报告内必须区分标注，禁止编造。
• 图片模糊或读不清时，如实标注"待核"，不要臆测。
• 植检证未出、B/L 仍是 PROFORMA 时，标注"待补"或"非正本"，不纳入"一致"判定。
• 在华注册号是否真实有效，一律以 GACC 系统返回为准，不得仅凭号码格式肉眼判定。
• 接口不可用时判"未完成核验"，不得据此得出号码无效的结论。
• 所有结论按结论先行呈现，逐条附字段来源与口径。

4. 执行流程

步骤 A：环境准备与渲染

1. 先确定 Python 解释器。优先使用当前环境可直接调用的 python 或 python3，全程保持同一个解释器，不要中途切换。
2. 跑一次环境自检，缺依赖会自动安装：
   python <本技能目录>/scripts/bootstrap.py
   输出含解释器路径、pymupdf 与 requests 状态、探测到的下载目录。若下载目录未探测到，向用户确认报告存放位置。
3. 建临时工作目录（建议 review_<合同号>/）。
4. 渲染所有待审 PDF 为 PNG，默认 300 DPI：
   python <本技能目录>/scripts/render_pdfs.py <工作目录> <合同.pdf> <发票.pdf> <装箱单.pdf> <提单.pdf> <COO.pdf> [--dir <单据目录>]
   脚本逐页输出 <basename>_pNN.png 并打印 JSON manifest，含页码、图片路径与像素尺寸。
5. 按 manifest 用 Read 工具逐页读 PNG，提取每个单据的字段值。建议顺序：合同 → 草稿件各单据 → 参考合同单据。
6. 小字密集处（注册号、小号唛头、金额大写）若读不清，单独对该页提高精度重渲染，不要整份重来：
   python <本技能目录>/scripts/render_pdfs.py <工作目录> <COO.pdf> --pages 1 --dpi 480 --suffix hi
   加 --suffix 避免覆盖原图。

步骤 B：合同 vs 草稿件 逐字段对账

按 references/field_checklist.md 第二节字段清单逐个比对，记录状态（ok/warn/bad/note/pending）与说明。重点查：

• 数量容差：合同未另作约定时按 ±5%（合同量 × 0.95 ~ × 1.05），超出即 bad。合同写明其他容差时以合同为准并注明口径。
• 定金：日期对照合同付款条款截止日，晚于即逾期 bad；金额按合同约定的比例验算，存在差额即便很小也标 P2。
• B/L 形式：PROFORMA / DRAFT / 占位 Booking No 一律非正本 warn。
• Producer 注册号：走步骤 D 做系统核验，不由本步骤直接判定。
• 唛头：N/M 需核实袋面基本唛头 warn。
• 术语：CNF 与 CFR 自 Incoterms 2010 起统一，不构成矛盾。

草稿件不全时，按 references/field_checklist.md 第八节处理，不得因缺项中断审查。

步骤 C：中英文标签核对

按 references/bilingual_labels.md 执行，覆盖两项内容：

1. 单据内部的中英文对照（品名、规格、国别、港口、单位、包装、企业名、币种金额、日期、唛头）。
2. 进口业务另附中文标签时，核对标签合规要素并与单据交叉比对。重点是中文标签上的在华注册号、境外生产企业、原产国、批号是否与 COO 及 GACC 登记一致。

步骤 D：在华注册号真实性核验

对 COO 或中文标签上的 CHINESE REGISTRATION NUMBER 做六维度核验，规则见 references/gacc_registry.md。

python <本技能目录>/scripts/verify_gacc.py \
  --reg-no <号码> \
  --producer "<单据上的生产企业英文名>" \
  --product "<本次商品名称>" \
  --ship-date <YYYY-MM-DD> \
  --country "<单据原产国>" \
  --json-out <工作目录>/gacc.json

参数按手上有的信息给，缺哪几项就跳过对应维度，不要为凑参数而编造。只做号码存在性核验时，只传 --reg-no 即可。

企业名称一致性是必做维度，不要省。 实测存在"号码真实有效但属于另一家企业"的情况，只验号码有效性会漏掉抄错。

结果写入 gacc.json，供步骤 F 直接引入报告，不要凭记忆转录。

本脚本只覆盖 C 或 Q 开头的境外生产企业在华注册编号。遇到 YA 开头 18 位的进口食品境外出口商备案号，如实告知不在本脚本范围内，不要用它下结论。

步骤 E：横向串单核查（有参考合同时）

按 references/field_checklist.md 第三节字段，确认草稿件未误用参考合同的合同号、提单号、船名航次、日期、数量、单价、金额、装港、集装箱前缀、Producer、注册号、批号等。正确采用本单独立值即无串单，误用他单即 bad。

步骤 F：生成 HTML 报告

1. 把对账结果整理成 JSON 规格写入 <工作目录>/spec.json，结构见 scripts/build_report.py 底部注释。要点：
   - verdict：审单结论与放行建议，结论先行。
   - risks：按 P0/P1/P2 列风险卡。
   - contract_vs_draft：字段对照表，每行用 status:{index,level} 给状态列上色。
   - bilingual：中英文标签核对表。
   - cross_contract：横向比对表。
   - conclusion / suggestions / references：审查说明、建议、依据清单。
2. 生成报告，直接引入步骤 D 的输出：
   python <本技能目录>/scripts/build_report.py <工作目录>/spec.json \ <工作目录>/<合同号>_单据审查报告.html \ --gacc-json <工作目录>/gacc.json \ --downloads-dir <下载目录>
3. 脚本会先校验 spec 结构，任何错误都会中断并列出问题，不会产出缺章节的半成品报告。按提示改完再跑。
4. 未传 --downloads-dir 时，复制一份到用户指定的位置。

步骤 G：交付与提示

• 用 present_files 交付 HTML，双击浏览器打开即可看彩色分级表。
• 提示用户：P0/P1 项及标注"待人工确认"的差异项须人工复核并与对方书面确认。
• 提示用户：渲染 PNG 已留档工作区，便于追溯复核。

5. 字段与规则速查

6. 脚本一览

四个脚本均只依赖标准库与 pymupdf、requests，无第三方服务依赖，跨平台可用。