Ozon-竞店截流专家 | 青虎AI

青虎AI Ozon 竞店截流：锁定对标店铺后拉出它的全部在售商品、店铺趋势快照与热销结构，复刻它的选品逻辑与出单矩阵，并盯住它新上、正在起量的潜力新品做实时截流。当用户要在 Ozon 分析竞争店铺、看对手在卖什么、复刻竞店选品、监控对手新品、做竞店截流时必须触发。关键词：青虎AI、Ozon、俄罗斯、竞店、对标店铺、截流、店铺分析、出单矩阵、新品监控、店铺榜单。

把一家跑得好的 Ozon 店拆开看：它靠哪些品出单、品类怎么搭、价格怎么排、最近在推什么新品——然后在它把新品做起来之前跟上。

对标店铺选得准，比自己乱扫榜有效得多。

何时触发

• 「分析一下这家 Ozon 店」「对手在卖什么」
• 「找几家做得好的同行店铺」
• 「盯住这家店的新品」「竞店有什么新上的款」
• 「复刻这家店的选品思路」

数据接口

本技能的数据全部来自青虎数据接口——一个普通的 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=1788417429126 注册/登录，再到 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) 查工具入参

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

json

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

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

2) 发起调用

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

json

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

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

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

json

{"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 里看不出来的取值来源与前置步骤。

工具	中文名	用在哪一步
queryhotshoprankings	店铺热销榜单	没有明确对标时，先从榜单里找候选店铺
queryshopdetails	查店铺详情	店铺基础数据（shopIds 必填）
queryshopitemdetails	查店铺商品列表	拉出该店在售商品（shopKeyword 必填），这是出单矩阵的原料
queryshoptrendsnapshots	店铺趋势快照	店铺整体销售走势，判断它在涨还是在掉
queryproducttrendsnapshots	产品趋势快照	对它的潜力新品逐个验证起量情况
queryproductdetails	查商品详情	批量补齐商品明细
querycategorydetail	市场销售数据	对照类目大盘，看它是靠类目红利还是真本事

Ozon 工具的类目 ID、关键词 ID、店铺 ID 都要先查后用：类目走 querylevel1categories → querylevel2categories → querylevel3categories 逐级下钻，关键词 ID 走 queryhotkeywordrankings，店铺 ID 走 queryhotshoprankings。不要编 ID。 period / updatePeriod 决定榜单周期（周榜 / 月榜 / 季度 / 年度），跨周期的数字不要混在一张表里比。

工作流程

1) 确定对标店铺

用户直接给店铺就用；只说「找几家同行」就先用 queryhotshoprankings 按类目筛出候选， 优先选规模相近、增速快的店——照抄行业老大通常抄不动。

2) 摸店铺底细：queryshopdetails + queryshoptrendsnapshots

先确认这家店值不值得抄：整体在涨的店才有参考价值，在掉的店抄了是接盘。

3) 拉出单矩阵：queryshopitemdetails

把在售商品按销量排序，看三件事：

• 主力款：销量集中在哪几个品（通常 20% 的品贡献 80% 的量）；
• 品类结构：是深耕一个细分还是横向铺货；
• 价格阶梯：引流款 / 利润款 / 形象款分别在什么价位。

4) 找潜力新品：上架时间近 + 销量在爬

用 queryproducttrendsnapshots 对新上架的款逐个看走势。 在它评论还少、排名还没稳的时候切进去，才叫截流；等它成了爆款再跟就是接盘。

5) 输出可执行的复刻方案

不是把它的品照抄一遍，而是：先跟哪几个款、用什么价格切、差异化点放在哪。

输出

• 店铺画像：规模、类目结构、价格带分布、增长方向。
• 出单矩阵表：主力款/引流款/利润款分层，配销量与价格。
• 潜力新品清单（重点交付）：上架时间、当前销量、趋势方向、建议跟进优先级。
• 复刻建议：先跟哪几个、怎么差异化、注意什么风险。
• 商品明细按「数据交付」导出。

数据交付

• 工具返回的记录数组 ≥ 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 万积分」等于把账算错一万倍）。没实测过就写「费用以实际扣费为准」，不要编数字，也不要照抄工具描述里出现的任何点数。

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

  text

  本次共消耗 9.6 青虎积分
  

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

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

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

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

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

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

能力边界

• 本技能围绕店铺展开。只想扫爆款走「Ozon-爆款跟卖与选品大师」，想选赛道走「Ozon-蓝海赛道挖掘专家」。
• 不做 Ozon 上架操作与店铺代运营。
• 跟卖对标店铺的商品前，品牌授权与专利风险要用户自行核查。

相关技能

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

• Ozon-爆款跟卖与选品大师：对截流出来的新品做跟卖决策
• 1688选品供应链：为截流的款找同款货源