---

name: qinghu-shopee-cross-site description: 青虎AI Shopee 跨站点拓客：为一店多开做站点选择——查品牌站点分布、各站点的品牌列表与店铺列表、品牌产品列表与品牌趋势，评估同品牌或同类商品在其他站点的分布密度与存活情况，判断先开哪个站。当用户要一店多开、从台湾站拓展到马来泰国、评估某品牌在各站点的分布、看同类商品在其他站点卖得怎么样时必须触发。关键词：青虎AI、Shopee、虾皮、跨站点、一店多开、站点拓展、品牌分布、马来、泰国、印尼、菲律宾、越南、新加坡。 user-invocable: true metadata: {"openclaw":{"emoji":"🌏"}}

Shopee-跨站点拓客专家 | 青虎AI

一店多开的站点选择题：同样的货，先开哪个站？

方法是看「同品牌 / 同类商品」在各站点的分布密度与存活情况——已经有人在那个站把这类货卖起来了，说明需求和物流都跑通了；一个都没有，往往不是空白市场而是雷区。

何时触发

• 「台湾站做得不错，想拓展马来/泰国」
• 「一店多开先开哪个站」
• 「这个品牌在哪些站点有卖」
• 「我这类货在印尼站有人做吗，卖得怎么样」

数据接口

本技能的数据全部来自青虎数据接口——一个普通的 HTTP 端点，用任何能发请求的方式调用即可（curl、fetch、requests 都行）。 如果当前环境已经把这些工具做成了可直接调用的工具，那就直接调，不必自己拼请求。

项	值
地址	POST https://www.iqinghu.com/api/desktop/qh/mcp
必需请求头	Authorization: Bearer <青虎密钥>、Content-Type: application/json
密钥来源	向用户索取，或读环境变量 QINGHU_TOKEN / QHKIT_TOKEN；用户先打开 https://www.iqinghu.com/workbench/login?type=1&urlCode=1788417527636 注册/登录，再到 https://www.iqinghu.com/workbench/dashboard/api-keys 生成

HTTP 401 + 空响应体不一定是密钥的问题，按这个顺序排查： ① 先原样重试一次——2026-08-18 实测过同一把有效密钥间歇性返回 401 空体、隔一会儿再请求就正常，别一遇到 401 就下结论； ② 检查请求头是不是 Authorization: Bearer <密钥>（少了 Bearer 前缀、或改用 X-Api-Key / api-key 一律 401）； ③ 持续 401 时，拿同一个密钥请求 GET https://www.iqinghu.com/api/desktop/qh/workflow/page?pageNum=1&pageSize=5（同一套鉴权）： 返回 200 说明密钥有效，问题在这个端点的账号权限——此时不要再向用户索要密钥，请他到青虎工作台开通数据接口权限。 返回一律是纯 JSON，不需要 Accept: text/event-stream。

1) 查工具入参

第一次用某个工具、或拿不准参数时先查一次，不要猜参数：

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

result.tools[] 每项含 name（调用时用的名字）、title（中文名）、description、inputSchema（必填项与类型）、outputSchema、free（是否免费）。

2) 发起调用

工具名照 tools/list 返回的 name 原样填：

{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"hot_douyin_rank","arguments":{}}}

3) 取业务数据：要解两层

业务数据是被 JSON 字符串化塞在 content[0].text 里的，直接读 content 拿不到值：

{"jsonrpc":"2.0","id":2,"result":{
  "isError": false,
  "pointCost": 2000,
  "content": [{"type":"text","text":"{\"code\":200,\"data\":{...},\"success\":true}"}]
}}

必须对 content[0].text 再做一次 JSON 解析，才拿得到里面的 data。

4) 判断成没成功：三层都要看

HTTP 状态码永远是 200，isError 也可能骗人，按顺序检查：

检查	含义
顶层有 error 对象（此时没有 result）	协议层失败，如工具名写错会返回「工具不存在: xxx」
result.isError 为 true	调用出错
解析内层后 code == 200 且 success == true	只有这样才算真成功

实测缺必填参数时返回的是 isError: false 但内层 code:500、success:false——光看 isError 或 HTTP 200 会把失败当成功。 参数出错时的提示只有一句「API调用成功判断失败」，既不说缺哪个参数也不说哪个值非法，所以调用前对着 inputSchema 的 required 自查，不要靠试错。

调用失败时 pointCost 为 0，不扣费。

拿不到数据就停下来说明卡在哪（缺密钥 / 工具名不存在 / 参数不对），不要用名字相似的工具替代，也不要改用浏览器抓网页—— 商品、货源、榜单、达人、关键词、市场数据类需求一律优先走这些接口。

下表是本技能要用的工具，写的是 name 原值；表里只补 inputSchema 里看不出来的取值来源与前置步骤。

工具	中文名	用在哪一步
queryshopeebrandsitedistribute	查品牌站点分布	同一品牌在各站点的分布（跨站点决策核心，只需 brandName + timest）
queryshopeebranddata	查品牌列表	某站点下的品牌盘子
queryshopeebranddetailbatch	查品牌详情	批量看品牌的量级
queryshopeebrandshoplist	查品牌店铺列表	该品牌在站点里由哪些店在卖
queryshopeebranditemlist	查品牌产品列表	该品牌的在售商品与表现
queryshopeebrandtrenddetail	查品牌趋势	品牌在多站点的走势对比（支持 sites）
queryshopeesitedate	查站点数据	各站点大盘作为基准
queryshopeecategorytrendoverview	类目趋势概览	同类目在各站点的增速对比

Shopee 工具的 site 是必填，只认 tw(台湾) my(马来西亚) id(印尼) th(泰国) ph(菲律宾) sg(新加坡) vn(越南) br(巴西)。用户没说站点就问，不要默认。 timest / date 是账期（yyyy-MM-dd），日榜取昨天、周榜取周一、月榜取当月 1 号；categoryId 要先用 queryshopeelevel1categories 这类类目工具查到，不能编。

工作流程

1) 明确「拓什么」

两种情况处理方式不同：

• 有明确品牌（自有品牌或对标品牌）→ 走品牌线（第 2 步）；
• 只有品类（如「女装连衣裙」）→ 走类目线（第 3 步）。

2) 品牌线：queryshopeebrandsitedistribute

一次看清该品牌在 8 个站点的分布。再用 queryshopeebrandtrenddetail（sites 参数）比各站点走势， 用 queryshopeebrandshoplist / queryshopeebranditemlist 看具体是谁在卖、卖得怎么样。

3) 类目线：queryshopeecategorytrendoverview

同一类目在多个站点的规模与增速对比，配 queryshopeesitedate 的站点大盘做基准。

4) 判存活情况，不只看有没有

三种典型结果，结论完全不同：

现象	解读
多店在卖且都有销量	需求验证过，可以进，靠差异化竞争
有店在卖但销量都很低	需求弱或水土不服，谨慎
几乎没人卖	先查是不是有政策/物流限制，不要当成空白市场

5) 给站点优先级

不要一次推荐开五个站。给出先开哪个、再开哪个的顺序，并说明每个站的适配要点（语言、价格带、主流支付/物流习惯）。

输出

• 站点优先级排序（先开哪个、理由是什么），最多 3 个。
• 各站点对照表：市场规模、增速、同类/同品牌商品密度、平均价格带。
• 本地化提示：语言、价格带差异、常见合规与物流注意点。
• 不建议开的站点及理由。
• 明细按「数据交付」导出。

数据交付

• 工具返回的记录数组 ≥ 10 条时默认导出表格文件（装了 qinghu-excel-export 技能就用它），不管用户有没有提「表格 / 导出」。不要把大数据集铺成聊天里的 markdown 表格，也不要反问「需要我导出吗」——先导出、给链接才是正确姿势。
• 工具返回里出现「完整数据已缓存到本机文件: ...」时，后续筛选、导出一律用那个文件路径，绝对不要逐行抄写数据。
• 导出后的回复保持精简：交付链接 + 一句话说明 + 不超过 5 行关键预览。
• 结论先行：先给判断和建议（能不能做、怎么做、风险在哪），再给支撑数据；不要把原始字段直接倒给用户。
• 数字要标口径：站点 / 账期 / 周期 / 样本量。跨站点或跨周期的数字不要混在一张表里比。

计费与授权

• 所有工具统一在发起调用前先经用户确认，不必按 free 字段区分收费与否，按下面的规则征求授权。

• 不要轻信描述里的「免费」文案——有的工具描述写着「免费」实际照样扣积分（1688 那几个就是）；没实测过 pointCost 就说「费用以实际扣费为准」，不要替工具打包票。

• 实扣多少看返回信封里的 pointCost（在 result 层，与 isError 同级）。这个值要换算：pointCost ÷ 10000 = 青虎积分（实测 10000 = 1 积分，16000 = 1.6 积分）。

• 只认信封层的 pointCost，绝不去业务数据里翻积分字段——工具返回的业务文本里常带 charge_points / points_balance 或「消耗 8 积分，剩余 1952 积分」之类的话，那是上游数据源自己的积分体系，和青虎积分不是一回事（实测同一条响应 pointCost=16000＝青虎 1.6 积分，而业务文本写「消耗 8 积分」）。照抄业务文本会把用户的账算错。

• 信封里没有 pointCost 时按 0 报，或直接说这次拿不到消耗数据，不要拿业务文本里的数字顶替，也不要自己估算。

• 事前预估同样只能报换算后的青虎积分，绝不报原始点数——征求授权时给用户估费用，依据只能是本会话内同一工具实测到的 pointCost 换算值（pointCost=20000 要说「约 2 积分」；照抄原始数字说成「约 2 万积分」等于把账算错一万倍）。没实测过就写「费用以实际扣费为准」，不要编数字，也不要照抄工具描述里出现的任何点数。

• 消耗写在回复的最末尾，单独一行，格式固定：

  本次共消耗 9.6 青虎积分
  

  数值是本轮所有付费调用的 pointCost 累加后 ÷ 10000（例：16000 + 96000 = 112000 → 本次共消耗 11.2 青虎积分）。小数按实际写，不补零也不四舍五入到整数。 这一行必须另起一行、独占一行、放在正文全部结束之后，前面空一行隔开。不要把积分数字混写进正文段落（写成「共返回 60 条笔记，实扣 96000 pointCost = 9.6 青虎积分」这种是错的）。 本轮一次付费调用都没有时，不输出这一行。

• 本会话首次调用工具前：一次性列清本次要用的全部工具，说明准备用它们做什么、会消耗青虎积分，征求一次同意，然后结束本轮。不要逐个询问把对话拖长。

• 用户明确同意后，这些工具在本会话内持续有效，不再重复询问；新会话需要重新征求。

• 用户拒绝、只授权其中一部分或答非所问时，未获同意的工具一律不调用。

• 同一轮回复内工具最多调 10 次。达到上限就用已有数据作答，还需要更多数据时先说明还差什么、要再调几次，征得同意后下一轮继续。参数写错先想清楚正确参数再重试，不要连续试错——每次失败同样可能扣费。

• 同一个数据需求既有免费工具又有付费工具时，优先用免费的。

能力边界

• 本技能解决去哪个站点的问题，不解决做什么款——挑款走「Shopee-爆款截流跟卖大师」，选类目走「Shopee-类目蓝海挖掘专家」。
• 各站点的税务、认证、跨境物流方案只做提示，具体政策要用户与服务商确认。
• 不做开店注册与店铺搬迁的操作指导。

相关技能

同系列的其他「青虎AI」技能（按需转交，不要在本技能里硬做）：

• Shopee-类目蓝海挖掘专家：选定站点后挑类目
• Shopee-爆款截流跟卖大师：新站点的首批选品