汇付支付证据诊断 Doctor

联调时 AI 最容易错在哪

汇付/斗拱接入里，「调不通」往往被当成接口字段问题：模型会猜 sys_id、notify_url，或根据浏览器回调就判定支付成功。真实联调需要的是可验证的证据链——请求是否带对 HTTP 头、签名是否对原始 body、查单是否用了下单时持久化的 req_seq_id/hf_seq_id。

本技能定位在诊断层：不重讲官方文档，而是像联调诊断员一样，把现象拆成证据、主因和修复动作；只有需要精确字段时才路由到更窄的汇付接入 Skill。

技能如何推进诊断

1. 分层收证：从路由（产品线、阶段、SDK/环境）到单笔失败交易（URL、状态码、脱敏 body/头），再到本地持久化、Webhook 或前端收银台证据；够判就停，不重复索要已有日志。
2. 归入一个主诊断桶：如 signing、request-header、order-create、checkout、final-state、webhook、query-close、refund、reconciliation、credential/environment 等，并按桶内固定顺序做检查（例如验签前先确认 payload 未被 JSON 改写）。
3. 输出可执行动作：代码/数据/运营侧修复建议；症状表覆盖「签名失败」「预下单成功但收银台拉不起」「前端成功后台未成功」「异步通知重试」等常见表述。

复杂案例、可靠联调清单或上线验收标准时，会引用 references/diagnostic-playbook.md 做更深处理。

边界与安全

• Hard stops：产品线不明、checkout-js 未确认托管预下单、缺真实商户值却要生产代码、日志与 SDK 行为矛盾时，会先短问一句再继续。
• 绝不索要私钥、完整证书、生产密码或 token；用户粘贴敏感信息会要求轮换。
• 不编造商户侧真实标识；不以页面跳转单独认定支付成功；不猜测原交易号用于查单/退款/对账。