外贸客户背调（真伪与欺诈风险初筛）

这个技能做什么

给外贸销售一个在报价之前就能用的判断：这家海外客户是真的在买货，还是在走某个诈骗剧本，以及如果要做这单，付款和放货条件应该怎么设。

输出不是一份资料汇总，而是一个结论 + 证据 + 可执行的交易条件，并且每一句判断都能被第三方按来源编号复核。

明确的边界：
- 只做公开信息初筛，不做征信、不做偿付能力担保、不替代银行资信证明或第三方验厂。
- 不做付费数据库调用（D&B、Panjiva 等）。需要时在报告里写明「建议补一份银行资信证明」。
- 不查个人隐私，不尝试绕过注册库的付费墙或验证码。

八条硬规则（按优先级排列，不可妥协）

规则 1 · 所有判断必须有明确来源

这是本技能的第一约束。没有来源的判断不许写进报告。

• 建立来源清单 sources[]，每项分配唯一编号 S1、S2……并记录 name / url / accessed（访问日期）。
• 报告中每一条结论、每一条风险、每一个关键信息项、每一行交易建议、每一个维度评分都必须带 src: ["S1"]。
• 渲染时一律加 --strict：
  bash python3 <skill-dir>/scripts/build_dashboard.py case.json --strict
  只要有一条判断漏了来源编号，脚本直接报错退出并列出缺哪些条。
• 同一个来源可以在多处复用；禁止把推断写成事实——事实引用来源，推断写成推断并说明推理链。
• 「查不到」必须写成 unknown 并说明卡在哪，不允许因为没有来源就不写，也不允许换个说法当成已核实。

规则 2 · 官网内容必须全站阅读，但报告只给核心总结

只读首页和联系页就下结论，等于把 80% 的信息扔掉。买家网站里最能暴露真实情况的往往在配送细则、退货条款、品牌列表、新闻和商品页里。

python3 <skill-dir>/scripts/site_reader.py https://buyer-site.com \
    --out /tmp/site --include-products 12

• 脚本会遍历 sitemap 下所有子地图，按「静态页 → 品牌页 → 品类页 → 博客 → 商品页」顺序抓取，输出 <out>.json（每页标题、正文、邮箱、电话、金额、地址）与 <out>.md（可直接读的摘要）。
• 静态页、品类页、博客必须全读；商品详情页按 --include-products 抽样，博客要看最后一篇的日期判断内容是否还在维护。
• 站点被 WAF 拦时不要放弃：脚本自带 cookie 会话与限流重试；仍失败则记录失败 URL 并说明，不能用「首页能打开」代替全站结论。

但报告里不要贴逐页清单。 全站阅读是取证方法，不是交付物。报告只写「官方网站核心内容总结」：按主题（公司定位与自述 / 联系方式与地址 / 结算与配送 / 退货与合规 / 商品与价格带 / 品牌与代理 / 敏感物项 / 运营维护状态 / 口径不一致 / 全站缺失的关键信息）提炼成 8–12 行，每行带来源编号。

• 阅读范围（读了多少页、抽了多少商品页、哪些没读）写在 site_reading_note 一行里，不展开成表格。
• 逐页明细属于信息过载：62 行页面清单会把读者淹在细节里，反而看不出结论。要核查细节的人可以自己点开链接复核。
• 只保留对交易决策有影响的发现（如「全站不公布 ЄДРПОУ」「工时两处口径不一致」），纯枚举型信息（各品类价格区间）不写进总结。
• 最后一行写「全站缺失的关键信息」——翻遍全站仍查不到的东西往往比查到的更能决定结论。

规则 3 · 搜索引擎必须查，纠纷专项是重点

官网说自己是什么，搜索引擎告诉你别人怎么说它——尤其外贸纠纷、投诉、评价、海关记录，这些官网永远不会写。

python3 <skill-dir>/scripts/search_probe.py \
  --name "Scorpion-2000" --local-name "Скорпіон-2000" --domain scorpion-2000.com \
  --country Ukraine --phone "+380503308910" --email "info@scorpion-2000.com" \
  --out /tmp/search.json

• 全球引擎 + 地方引擎都要查。Google 查英文名与域名；Yandex 查俄语区（RU/UA/KZ/TR/EE 的纠纷与评价基本都藏在俄语平台）。DuckDuckGo / Mojeek 作为可达性兜底。
• 检索必须覆盖五组：身份与足迹 / 外贸纠纷 / 注册主体 / 贸易活跃度 / 口碑。纠纷组是重点，关键词含诈骗、投诉、起诉、仲裁，以及外贸高频话术「未履行、未发货、未退款、卷款」。
• 查不到也要写：报告里必须有「搜索引擎检索记录」区块，逐条写清引擎、查询式、结果；命中写「发现记录」，干净写「未见记录」，引擎被墙写「无法检索（原因）」。把「查不到」写成「无纠纷」是造假。
• 同名必须拆开：搜索会返回大量同名主体。判定前比对至少两项（法定主体名/税号、注册地址、电话、域名、邮箱域），对不上就是不同主体，只能作为「同名风险」提示，不能算在目标客户头上。
• 命中纠纷时优先去海关/提单数据站（NBD Trade Data、ImportYeti、Volza）——那是外贸纠纷的高发地，也是判断真做进出口最硬的外部证据。
• 详细查询式库、引擎可达性实测、同名处理规则见 references/search-playbook.md。

规则 4 · 用户上传的原始材料必须一并展示

名片、截图、询盘邮件截图是一手材料，报告读者必须能亲眼看到它，否则无法判断二手信息是否可信。

• 用户上传的图片放进 meta.card_image（本地路径或 data URI），渲染时以 base64 内嵌进单文件 HTML，放在「客户关键信息」右侧。
• meta.card_caption 说明这是什么材料（例：用户提供的原始名片 / 询盘邮件截图）。
• 名片上的每一条信息（公司名、电话、邮箱、地址、联系人）都要单独作为一行进入身份核验表，与官网/注册库交叉比对。
• 名片内容与官网不一致时，不要替用户猜哪个是对的——两条都写进核验表，标 partial，并给出「如何确认」的动作。

规则 5 · 首页是一张背调看板表，明细全部折叠

报告首页最上方就是整个背调看板：一张表格，一行一个核验维度，销售不用展开就能逐项扫完。

第一段 · 背调看板（不折叠）
1. 抬头：客户名、国别、行业、官网、评级环 + 一句话定性 + 结论与建议
2. 背调看板表（dashboard[]）：每行 = 一个核验维度 → 查证结论 → 来源编号
3. 核心结论（完整版，可以写透）
4. 交易建议（付款 / 账期 / 物流 / 样品 / 首单上限 + 底线条款）

第二段 · 完整核查记录（每个区块默认折叠）
5. 搜索引擎检索记录（纠纷专项在前，身份与足迹在后）
6. 官方网站核心内容总结
7. 买家画像与客户档案
8. 风险提示明细
9. 分维度推断与依据
10. 身份锚点核验表
11. 原始材料（用户上传的名片 / 询盘截图）
12. 证据链
13. 全部信息来源

看板表的每一行都必须带 src，来源编号直接跟在结论文字后面，点击可跳到《全部信息来源》。折叠是强制的——明细区块一律用 <details>，summary 行显示结论要点 + 计数徽标（如「纠纷专项 12 组」「15 项核验」）。

规则 6 · 看板必须覆盖的核验维度

看板不是「想到什么写什么」，下面这些维度逐项都要有一行，缺项视为背调没做完：

营收与利润是「推算」，必须标出来。 登记库里没有的数不要凭空写，用登记财务数据 + 业务结构推算，并在 detail 里写清推算依据。kind 字段区分三者：fact（可引用来源的事实）/ estimate（按数据推算）/ infer（推断与判断），渲染成行内标签，读者一眼能分清。

规则 7 · 只报有决策价值的差异，其余删掉

不是所有不一致都是风险。 小型贸易商日常就有一堆"不一致"，把它们塞进风险区只会淹没真正重要的信号。

默认不写进风险提示的正常差异（可以写进核验表存档，但不要单列成风险）：
- 销售手机号与官网总机不同 —— 小公司由业务负责人用个人手机对外联系是常态
- 官网写的房间号与登记房间号不同 —— 同一栋办公楼多主体各占不同房间很常见
- 官方总机与第三方目录收录的旧号码不同 —— 目录常年不更新
- 用 Gmail 等免费邮箱 —— 小微企业普遍如此，看官网是否也在用同一域名
- 域名 WHOIS 隐私保护、缺 Impressum —— 小站点常态
- 员工数、门店数与自述口径略有出入

判断标准：这个差异会不会改变我的交易动作？
- 会 → 写进风险区，并给出具体动作（要注册号 / 改付款方式 / 要求担保）
- 不会 → 不提，或只在核验表里记一笔

把"电话不一致"当风险，等于告诉销售"这个客户有问题"，而对方可能完全正常——这是损害判断质量的噪音。

规则 8 · 区分事实、推断与道德判断

• 事实：可直接引用来源（「Handelsregister 显示成立日 2024-08-14」）。
• 推断：从多个事实推出（「自述 8 年但注册 2 年 → 经营年限陈述不实」）。推断必须写清推理链，并标明它是推断。
• 道德判断：不许出现在报告里。不写「对方可疑」「像骗子」「不老实」。
• 不写「信誉良好」「实力雄厚」这类无依据褒义词；搜不到负面只写「未见公开负面信息」。

何时使用

• 收到陌生海外询盘，要判断真假
• 老客户突然要求改账期、改收款账户、放大订单量
• 客户要求先发货后付款、要求独家代理授权、要求出具邀请函
• 老板问「这个客户靠不靠谱」「能不能给 60 天账期」
• 已经被骗或疑似被骗，要复盘对方哪一步露的马脚

不适用：常规报价、物流安排、产品认证咨询。

工作流

第 0 步：收集材料与身份锚点

把用户给的一切原始材料先收齐并保存（名片图、询盘邮件、PI 草稿、平台聊天记录）。从询盘与名片里抽取：

必填：公司全名（与签署 PI 的一致）、声称国家、联系人姓名、邮箱
强烈建议：网站域名、电话（含国际区号）、注册号/VAT 号、声称的地址
可选但有用：询盘来源、首单金额与数量、对方要求的付款方式与账期、
           对方自述的经营年限/员工数/仓库面积、收到的 PI 或合同草案

先读询盘话术本身，不用查资料就能定性的几条：是否要求我方先付钱、是否极度急迫、是否拒绝提供税号、是否要求账期但金额远超规模。这些直接决定后面花多少功夫。

缺资料就问用户一次性列全要，不要来回问；但信息少不等于拒绝开工。

第 1 步：机器化锚点探测

python3 <skill-dir>/scripts/anchor_probe.py \
  --company "Buyer Name" --country "Country" \
  --domain buyer.com --email buyer@buyer.com --phone "+00 ..." \
  --out /tmp/obv_anchors.json

拿到：网站可达性/标题/占位页标记/copyright 年份/联系渠道、DNS 与 MX、域名注册年龄（RDAP）、邮箱是否免费邮箱、邮箱域名与网站是否一致、电话区号与国家是否匹配，以及自动 flags。

脚本的 flag 是启发式，写报告前必须人工复核。 已知误报场景：站点有 WAF 时 SITE_UNREACHABLE / NO_CONTACT_CHANNEL 会误判（可用第 2 步的全站抓取结果交叉验证）；PHONE_COUNTRY_MISMATCH 可能只是用了国际虚拟号。

whois.registered: false → 域名根本没注册，是强信号，但仍需排除拼写错误。不要手动跑 whois 取创建日期：注册局不可达时 macOS 会回退 IANA 并返回顶级域创建日（.com = 1985-01-01），会让任何域名看起来有 40 年历史。

第 2 步：全站阅读（规则 2）

按上面命令跑 site_reader.py，然后读 <out>.md，逐页提取：
- 法定主体名 / EDRPOU / VAT / 地址 / 电话 / 邮箱（页脚、联系页、付款页最常出现）
- 经营年限、员工数、仓库、门店等自述（用于与注册信息交叉）
- 支付与配送条款（透露真实业务结构：是否先收定金、是否到付、有无外仓）
- 品牌与商品线、价格带（判断规模与品类真实性）
- 退货/保修/条款页（有没有，本身就是合规成熟度信号）
- 有无 Impressum / Legal Notice（欧盟法定）、博客最后更新日期
- 敏感物项（无人机、图传、卫星通信、军警装备）——用于出口管制判断

提取完后按主题归并成 site_summary[]（8–12 行），不要把逐页清单直接搬进 case JSON。全站阅读是取证方法，不是交付物。

第 3 步：主体与税务核验

按 references/country-registries.md 第 1、2 节找到该国官方注册库与税号校验入口，用 WebFetch 逐项核实：

1. 注册库检索公司全名 → 注册号、成立日期、法人、注册资本、经营状态
2. 税号校验（VAT/GST/ABN/CNPJ）→ 名称与地址是否与注册库一致
3. 若自称是某大企业的采购部 → 打该公司官网总机核实（冒充是最常见剧本之一，这步不要省）
4. 若查到注册地址 → 用 Google Maps 街景看那栋楼是什么

status 口径：match 一致 / partial 主体在但细节不符 / mismatch 明确矛盾 / unknown 查询受限或需付费。

小语种与非英语市场的检索现实：WebSearch 对乌克兰语、俄语等查询会退化成英文关键词匹配（搜「Скорпіон」可能返回完全无关的同名商品）。改用 WebFetch 直读官网与聚合站；乌克兰、俄罗斯等国的登记库多为 JS 渲染或反爬，拿不到就记 unknown，不要为了凑结论去猜。

第 4 步：贸易记录与负面信息

• 贸易真实性：优先 ImportYeti 查美国方向提单；无提单数据的市场改用行业目录（Europages / Kompass）、展会参展商名录、LinkedIn 采购岗、以及 "公司名" + supplier/import/container 检索。
• 负面信息：破产公告库、诉讼、多来源诈骗举报，用 "公司名" (fraud OR scam OR insolvent OR 诈骗 OR 破产) 组合检索，不要只搜公司名。
• 制裁筛查：OpenSanctions + OFAC 各跑一遍，公司名、法人姓名、地址分别查。同名命中必须比对地址与注册号，不能直接写「命中制裁」。

第 5 步：话术匹配（决定性的一步）

打开 references/fraud-patterns.md，逐条对照：

1. 先看 V1-V8 一票否决项。命中任一 → 直接判 D，后面的打分只是补充说明。
2. 再看 12 类诈骗剧本，判断对方在走哪一条。核心判据：对方是否在索取任何形式的「先付出」——先付钱、先发货、先授权、先给佣金。
3. 勾选 H1-H10 / M1-M11 信号，作为 D6 的打分依据。
4. 读 fraud-patterns.md 第三节「反向检查：避免误判」，确认自己勾的不是常识误判。

第 6 步：评分与定级

按 references/scoring-model.md：六维加权（D1 主体 25 / D2 联系方式 15 / D3 足迹 20 / D4 贸易 15 / D5 负面 15 / D6 行为 10）→ A(≥85) / B(70-84) / C(55-69) / D(<55)。

检查上限规则（主体无法验证最高 B、无提单数据该维最高 65、未打通电话最高 B）与否决覆盖（V1-V8 一律 D）。按矩阵给出付款/账期/物流/样品/验货/首单上限。

打分时先写事实，再落分数；每个维度要能用一句话说清「为什么是这个分」，并列出依据（dimensions[].evidence[]，每条带 src）。

第 7 步：写 case JSON 并生成看板

按 assets/sample_case.json 的结构写一份 case_<公司名缩写>.json。先写 dashboard[]，它是首页的主体；其余字段是看板的展开与支撑。

python3 <skill-dir>/scripts/build_dashboard.py case.json --strict

--strict 会先做来源审计（漏引用、引用了不存在的编号都会报错），通过后才生成 HTML。不要去掉 --strict；如果它报错，回去补来源，而不是绕开校验。审计范围覆盖 dashboard / conclusions / risks / risks_brief / key_facts / dimensions（含其 evidence）/ evidence / identity_checks / trade_advice.rows / red_lines。

写完先自检三件事：
1. dashboard[] 是否覆盖规则 6 的全部核验维度，每行是否有 src，推算类是否标了 kind 与 detail。
2. identity_checks 里每条 mismatch 是否都能在 risks_brief 或 trade_advice 里找到对应动作。查出了问题却不给动作，等于没查。
3. 按规则 7 复查一遍风险区——有没有把"电话不一致""房间号不同"这类正常差异写进去？写进去的每条都要能回答"这会改变我的什么动作"。

渲染后用 present_files 把 HTML 交给用户。

第 8 步：给销售的三句话

1. 能不能做：级别 + 一句核心依据
2. 怎么收钱：付款条件
3. 必须先问清什么：1-2 个具体动作（要仓库地址、回拨官网总机核实）

case JSON 字段

{
  "meta": {
    "case_id": "OBV-20261025-002",
    "buyer_name": "英文/对外名称",
    "buyer_name_local": "当地语言名称（可选）",
    "country": "Ukraine", "flag": "🇺🇦",
    "industry": "行业",
    "contact": "联系人 · 电话 · 邮箱",
    "website": "https://...",
    "card_image": "/path/to/card.jpg",   // 规则 4：用户上传的原始材料
    "card_caption": "用户提供的原始名片",
    "investigated_at": "2026-10-25 10:05",
    "investigator": "WorkBuddy"
  },
  "verdict": { "level": "B", "score": 70, "label": "一句话定性", "one_liner": "3 行内结论+建议" },

  // 规则 5/6：首页背调看板表。一行一个核验维度，顺序即阅读优先级。
  // kind: fact=事实 / estimate=推算 / infer=推断；tone: good|warn|bad|info（左侧色条）
  // detail: 推算类行的依据说明
  "dashboard": [
    { "dim": "企业基本信息", "finding": "查证结论（1-2 句）", "tone": "good",
      "kind": "fact", "src": ["S1","S2"] },
    { "dim": "营收预估", "finding": "年营收量级 ...", "tone": "warn",
      "kind": "estimate", "detail": "推算依据：...", "src": ["S17"] }
  ],

  // 规则 5 第二段：企业介绍（两三句，读者不看证据链也能对上一个生意模型）
  "company_profile": [ { "text": "一段话介绍这家公司是干什么的、规模多大、以什么方式做生意", "src": ["S1"] } ],

  // 规则 5 第二段：客户档案。group=profile 归入「企业基本介绍」，其余归入「核心关键信息」
  "key_facts": [ { "group": "profile|key", "label": "买家名称", "value": "...", "tone": "warn", "src": ["S1"] } ],

  // 规则 7：只放会改变交易动作的差异，正常差异不列
  "risks_brief": [ { "severity": "high", "title": "...", "note": "一行说明", "src": ["S2"] } ],
  "conclusions": [ { "text": "...", "src": ["S1","S3"] } ],
  "trade_advice": {
    "rows": [ { "label": "付款条件", "value": "...", "src": ["S2"] } ],
    "red_lines": [ { "text": "...", "src": ["S2"] } ]
  },

  // 规则 5 第二段（全部折叠）
  "dimensions": [ { "name": "主体真实性", "score": 60, "weight": 25,
                    "verdict": "推断", "src": ["S1"],
                    "evidence": [ { "text": "事实依据", "src": ["S1","S4"] } ] } ],
  "identity_checks": [ { "field": "...", "claim": "买家声称", "verified": "公开可查",
                         "status": "match|partial|mismatch|unknown",
                         "source": "来源名", "url": "...", "src": ["S1"] } ],

  // 规则 2：官网核心内容总结（8-12 个主题，不是逐页清单）
  "site_summary": [ { "topic": "公司定位与自述", "content": "该主题下的核心结论", "src": ["S2"] } ],
  "site_reading_note": "读了多少页、抽了多少商品页、哪些没读——一句话交代范围与抽样口径",

  // 规则 3：搜索引擎检索记录
  "search_coverage": "检索矩阵 + 各引擎实际可达性（哪个被墙/限流）",
  "web_search": [ { "engine": "DuckDuckGo", "query": "\"域名\"", "outcome": "检索结论",
                    "url": "https://...", "src": ["S9"] } ],
  "trade_disputes": [ { "engine": "DuckDuckGo", "query": "\"公司名\" (fraud OR scam OR 诈骗)",
                        "result": "检索结论",
                        "verdict": "hit|clean|blocked",   // 发现记录 / 未见记录 / 无法检索
                        "src": ["S9"] } ],

  "evidence": [ { "tag": "注册", "date": "2026-10-25", "title": "...",
                  "quote": "原文引述", "finding": "说明", "url": "...", "src": ["S1"] } ],
  "sources": [ { "id": "S1", "name": "Handelsregister", "url": "https://...", "note": "查什么", "accessed": "2026-10-25" } ],
  "disclaimer": "..."
}

site_reading_note 必须如实写明阅读范围与抽样口径，不许用「已阅读官网」一句带过。

trade_disputes[].verdict 三档各有严格含义：hit = 发现记录（必须写清记录内容与来源）、clean = 未见记录（写清检索覆盖到哪一步）、blocked = 无法检索（写清原因，如人机验证、429 限流、抓取失败）。把「查不到」写成「无纠纷」是造假。

输出形式

主交付物：单文件 HTML 看板。首页是背调看板表 + 核心结论 + 交易建议，其后是完整核查记录，每个区块默认折叠（见规则 5）。图片以 base64 内嵌，无外部依赖，可离线打开、可打印 A4。

用户明确要求 Word / Excel / Markdown 时，用同一份 case JSON 的数据改写为目标格式，不得重新组织结论或丢掉来源编号。

参考资源

脚本

常见错误