两份表格对账 · 找出对不上的记录（服务端执行型）
给两份表，答三件事：哪些记录只在一边？哪些金额对不上？两边合计差多少？
> 为什么必须走服务端：比对本身不难，难的是两份表根本长得不一样 ——
> 列名一个叫「订单号」一个叫「商户订单号」、金额列一个叫「应收金额」一个叫「收款金额」、
> 单号里混着全角数字、Excel 文本标记、多余空格和连接符。这些「认列 + 归一」的规则库在服务端，
> 本地包里没有副本，也不应该有（有就等于包公开可下载、直接调主产物绕过付费门）。
第 0 步 · 前置检查（免费，先判值不值得跑）
| 检查项 | 判定 |
|---|---|
| 输入形态 | 两份文件：.csv / .tsv / .txt / .xlsx（列名不认识也可以，会按值的形态判断） |
| 数量上限 | 每份 ≤10000 行、≤40 列。超限拒单，不做抽样 —— 对账抽样 = 漏检 |
| 金额列 | 没有金额列也能跑（只比单号），但结论里会写明「本次只比单号」 |
| 先跑预检 | 先 --dry-run（免费）：报读到的行列与将要比对的列，确认无误再正式调用 |
> ⚠️ 别为了凑进上限而删行：按时间区间拆成几批分别核对（每批一次付费），
> 拆批比抽样安全得多。
第 1 步 · 发起对账（未付费返回 402）
python scripts/table_recon.py --a 订单明细.xlsx --b 支付账单.csv
python scripts/table_recon.py --a a.csv --b b.csv --dry-run # 免费预检（推荐先跑）
python scripts/table_recon.py --a a.csv --b b.csv --key-a 订单号 --key-b 商户订单号
脚本读表后 POST 到 https://skills-gate.airpriv.com/api/table-recon-license。
首次调用一定拿到 402 Payment Required（设计如此），响应里带 payment_needed、amount、out_trade_no。
第 2 步 · 完成支付
把响应里的 payment_needed 对象交给支付宝 AI 付（或按 references/402-payment.md 用 CLI），
拿回 Payment-Proof。不要自己伪造 —— 服务端会拿它去支付宝网关做真实校验。
第 3 步 · 携凭证重试（直接拿到结果）
python scripts/table_recon.py --a 订单明细.xlsx --b 支付账单.csv --proof "<Payment-Proof>"
成功返回 200：控制台打印差异汇总 + 结论 + 完整报告，并写出差异清单
订单明细_对账差异.csv（Excel 直接打开不乱码）——每行一条差异，含差异类型 / 对账键 /
两侧行号 / 两侧金额 / 差额 / 备注。
| 字段 | 含义 |
|---|---|
summary.matched |
成功匹配上的记录数 |
summary.only_in_a / only_in_b |
只在表A / 只在表B 的记录数（各自带金额合计） |
summary.amount_mismatch |
键对得上、金额不等的条数 + 绝对差合计 |
summary.total_delta |
双边金额合计差（B − A），最常用的一句结论 |
summary.loose_matched |
去掉连接符后才匹配上的条数（格式差异，不是业务差异，单独归类） |
summary.duplicates_a / b |
同一键在某一侧重复出现（业务异常，单独列出） |
summary.balanced |
四类差异全为 0 时才为 true |
report_md |
完整的中文核对报告，可直接转述 |
data_as_of |
本次比对时间（口头结论带上它） |
一次付费 = 一次对账调用；同一订单重复请求原样返回首次结果，不重复计费。
交付给用户的说法（照这个口径，别夸大）
- 「宽松匹配」要单独说：去掉连接符/空格后才对上的，是导出格式差异，不一定是真业务差异 ——
逐条人工确认后再决定算不算问题。 - 「键匹配上了」≠「金额也对得上」：只有
amount_on=true时才比过金额；否则结论里会写明「本次只比单号」。 - 差异明细有条数上限（每类 500 条），但计数是全量的；被截断时报告与差异文件里都会显式标注。
- 不做模糊/近似匹配：避免把两张不同的单子判成同一张（宁可报成单边差异，也不误配）。
- 键为空的行不参与匹配，但会单独计数 —— 这类行需要用户自己回原表看。
诚实边界（用户问到时照实说）
- 只做两个文件之间的核对，不做银行/平台联网查询，不替用户判断「谁对谁错」——
差异是事实，归因在用户业务流程里。 - 列名不认识时按值的形态判断键列/金额列，认错列会直接导致结果不可用 ⇒
预检（--dry-run）与显式指定（--key-a等）是主要护栏；结果里的「比对口径」段会写明这次用的是什么列。 - 不产生会计凭证、不出具审计结论。
<!-- skillhub-payblock -->
付费链路自检（与平台五项自查一一对应）
本 Skill 的付费链路由服务端承担验付、资源交付与商家履约确认；Skill 只负责
发起请求、调用官方支付能力并展示结果。逐条对应平台自查项如下：
| 平台自查项 | 本 Skill 的实现 |
|---|---|
| 402 账单 | 未付款时请求 POST https://skills-gate.airpriv.com/api/table-recon-license 返回 HTTP 402 Payment Required；响应头 Payment-Needed 携带账单，响应体含 payment_needed / amount / out_trade_no。 |
| 凭证重试 | 支付后携带请求头 Payment-Proof: <凭证> 重发同一个请求（URL、请求方法、请求体与原请求保持一致），服务端校验通过后返回 200，结果在 content.data 内。 |
| 服务端验付 | 服务端调用支付宝 AI 按量付费凭证校验接口 alipay.aipay.agent.payment.verify 验签并核对订单、金额与服务标识；凭证无效或已过期时不交付任何资源，只回 402 账单让用户重新支付。 |
| 商家履约 | 资源交付后由服务端调用 alipay.aipay.agent.fulfillment.confirm 上报履约确认；上报失败可对同一订单重试，重试幂等，不会产生第二次扣费。 |
| 订单与幂等 | 每笔订单以唯一 out_trade_no 持久化于服务端订单库，状态可恢复；同一订单重复请求只履约一次、不重复扣费。 |
> 支付能力由支付宝 AI 按量付费官方链路承担，本 Skill 不接触支付密钥、不自行实现付款或签名。
<!-- /skillhub-payblock -->
