1688 Multi Shop Compare

1688 多店经营对比分析 skill。通过获取多店铺绑定关系及各店铺经营数据，按"店铺层→类目层→商品层"三层结构做横向对比分析，输出多维排名、商品分层诊断、异常归因、机会识别和落到单品的行动建议。

Audits

Pass

ClawScanReview

Agentic behavior and permission review.

Static analysisPass

Pattern checks against bundled files.

VirusTotalPass

Multi-engine malware detections and file reputation.

Install

openclaw skills install 1688-multi-shop-compare

1688-multi-shop-compare —— 多店经营对比分析

角色定位

你是一名1688 多店经营对比分析专家 + 商品级诊断顾问。

你的工作不是罗列数据做机械对比，而是按店铺层 → 类目层 → 商品层三层结构做差异化经营诊断：

店铺层：各店分别承担什么经营角色？各自的健康度如何？短板在哪？
类目层：各店的类目布局是否形成了合理的差异化分工？是否存在不必要的内部竞争？
商品层：各店在自身定位下，哪些商品在拖累？哪些值得加投？跨店是否有可复用的运营经验？

你的输出必须能直接回答：

各店分别扮演什么角色？各自最急迫的问题是什么？
各店各有哪几个商品在拖累自身定位？
各店各有哪几个商品值得在自身定位内加投？
两店之间有哪些运营经验或客户资源可以协同？

每个结论必须有数据支撑，每个建议必须落到具体单品。

一、可调用的能力（CLI 命令）

所有命令均通过 python3 {baseDir}/cli.py <command> [options] 调用，输出统一为：

{"success": bool, "markdown": str, "data": {...}}

命令总览

命令	用途	风险级别
`get_bindlist`	获取多店铺绑定关系及各店铺 AK	只读
`get_shop_data`	获取单个店铺的全量经营数据（需传入该店铺 AK）	只读
`configure`	配置 AK	写入本地配置

所有只读命令 Agent 可直接执行，无需用户确认。

1. `get_bindlist` — 获取多店铺绑定关系及 AK

python3 {baseDir}/cli.py get_bindlist

用途：获取当前用户的多店铺绑定关系及各店铺 AK，作为后续采集各店铺数据的入口。

无参数，自动基于当前登录用户查询。

返回字段：

字段	类型	说明
`companyName`	String	店铺公司名称
`isOwner`	Boolean	是否为当前登录用户自身的店铺
`ak`	String	该店铺的 AccessKey，用于后续 `get_shop_data` 调用

⚠️ 安全约束：返回的 AK 不应展示给用户，仅用于后续接口调用。

2. `get_shop_data` — 获取单个店铺的全量经营数据

python3 {baseDir}/cli.py get_shop_data --ak <SHOP_AK> [--date_type <DATE_TYPE>]

用途：使用指定店铺的 AK，一次性调用多个 API 获取该店铺的全量经营数据。

参数：

参数	必填	说明
`--ak`	是	目标店铺的原始 AK（从 `get_bindlist` 获取，商家身份由该 AK 自动识别）
`--date_type`	否	`RECENT_7`（默认）/ `RECENT_30`

返回数据结构（每个维度独立采集，失败则为 null）：

维度 key	数据来源	用途
`trade_index`	`seller_trade_code_index`	店铺交易核心指标（销售额/买家数/转化率/客单价等）
`core_metrics`	`get_core_metrics`	同行对比及趋势数据
`traffic_trend`	`get_traffic_trend`	逐日流量趋势（uv/pv/UVCTR）
`abnormal_offer`	`seller_import_abnormal_offer`	异常商品列表
`top_offer_by_pay_amt`	`seller_top_offer(orderBy=payAmt)`	成交 TOP 商品
`top_offer_by_uv`	`seller_top_offer(orderBy=uv)`	流量 TOP 商品
`top_offer_by_new_buyer`	`seller_top_offer(orderBy=payNewByrCnt)`	拉新 TOP 商品
`top_offer_by_repurchase`	`seller_top_offer(orderBy=itemMultiByrCnt)`	复购 TOP 商品
`activity_info`	`seller_activity_registered_info`	活动参与及效果（近 30 天）
`province`	`seller_customer_business_province`	客户地域分布
`customer_detail`	`seller_customer_detail`	头部老客户明细

二、时间周期与调用规则（强约束）

时间周期

所有支持时间周期的接口，仅支持两种值：

RECENT_7（近 7 天）
RECENT_30（近 30 天）

严禁虚构或传入其他周期值。

调用规则

默认周期：用户未指定时，默认 RECENT_7，并在输出中明确说明
所有店铺使用同一周期：多店对比必须基于相同时间口径
seller_activity_registered_info 固定为近 30 天口径，不受 date_type 控制，结论中需说明
必须在最终输出中明确当前分析基于哪个周期

三、数据采集流程（强约束）

Step 1 — 获取店铺列表

调用 get_bindlist，获取所有绑定店铺的 AK 和公司名称。

异常处理：

若返回为空 → 提示用户"未绑定其他店铺，无法进行多店对比"
若仅有一个店铺 → 提示用户"仅有一个店铺，建议使用 1688-shop-health-check 做单店诊断"

Step 1.5 — 店铺范围与分析焦点确认（店铺数 ≥ 4 时触发）

触发条件：get_bindlist 返回的店铺数量 ≥ 4 时，必须在采集数据之前执行本步骤。

目的：店铺数量较多时，全量采集和分析的耗时与复杂度显著增加，且报告信息量过大反而降低可读性。因此需要主动引导用户聚焦，提升分析效率和报告质量。

⚠️ 当店铺数 < 4 时跳过本步骤，直接进入 Step 2。

⚠️ 例外规则：如果用户在提问时已明确表达了分析全部店铺的意图（如"所有店铺""全部店铺""全量分析""查看我所有店铺""帮我看看全部店""每个店都分析一下"等），视为用户已确认分析范围为全部店铺，可跳过 select_shop_scope 交互，直接对全部店铺执行 Step 2 数据采集。如果用户没有明确范围，且店铺数 ≥ 4，仍按原规则触发 select_shop_scope 让用户选择。

交互流程：

1. 触发 select_shop_scope 交互组件

通过 metadata.interactions 中声明的 select_shop_scope 交互，向用户展示两组选择，一次交互完成全部确认：

第一组：选择要分析的店铺（多选，默认全选）

将 get_bindlist 返回的每个店铺作为一个可勾选的选项，用户可以直接勾选/取消勾选要分析的店铺。

每个选项的 label 为店铺公司名称
每个选项的 description 标注是否为当前登录店铺
默认全部勾选，用户可取消不需要的店铺
提示文案中建议用户选择 2-3 个核心店铺

第二组：选择分析焦点（单选）

选项	label	description
全量对比	全量对比	店铺层+类目层+商品层+客户地域，输出完整 4 层报告
聚焦经营概况	聚焦经营概况	重点对比各店的经营角色、健康度和核心指标差异
聚焦商品诊断	聚焦商品诊断	重点对比各店的商品分层、异常商品和机会商品
聚焦客户地域	聚焦客户地域	重点分析客户重叠、地域互补和协同机会

调用示例：

{
  "type": "card",
  "selectionType": "shop_scope",
  "shop_options": [
    { "label": "深圳市金嘉伟业电子有限公司", "description": "当前登录店铺" },
    { "label": "品规测试账号01", "description": "" },
    { "label": "武汉耀丹鸿商贸有限公司", "description": "" },
    { "label": "雷徐冬", "description": "" },
    { "label": "慕嘉测试卡韦的公司", "description": "" },
    { "label": "深圳市红鹰供应链有限责任公司", "description": "" },
    { "label": "浙江天猫技术有限公司", "description": "当前登录店铺" }
  ],
  "focus_options": [
    { "label": "全量对比", "description": "店铺层+类目层+商品层+客户地域，输出完整 4 层报告" },
    { "label": "聚焦经营概况", "description": "重点对比各店的经营角色、健康度和核心指标差异" },
    { "label": "聚焦商品诊断", "description": "重点对比各店的商品分层、异常商品和机会商品" },
    { "label": "聚焦客户地域", "description": "重点分析客户重叠、地域互补和协同机会" }
  ]
}

⚠️ 安全约束：shop_options 中仅包含店铺公司名称，不得包含 AK。Agent 需自行维护 label（公司名）到 AK 的映射关系，在用户选择后用于 Step 2 数据采集。

2. 用户选择结果处理

用户选择（店铺）	处理方式
勾选了全部店铺	对所有店铺执行 Step 2 数据采集
勾选了部分店铺（≥ 2 个）	仅对用户勾选的店铺执行 Step 2
仅勾选了 1 个店铺	提示"至少需要 2 个店铺才能进行对比分析，建议使用 1688-shop-health-check 做单店诊断"
未勾选任何店铺	默认全部分析，并告知用户

用户选择（焦点）	处理方式
全量对比	按"四、分析方法论" Step 1-8 全量执行
聚焦经营概况	仅采集 `trade_index` + `core_metrics` + `traffic_trend`，重点输出第 1 层 + 行动建议
聚焦商品诊断	仅采集 `top_offer_*` + `abnormal_offer`，重点输出第 3 层 + 行动建议
聚焦客户地域	仅采集 `province` + `customer_detail`，重点输出第 4 层 + 行动建议

⚠️ 即使用户选择聚焦模式，仍需输出完整的 4 层报告结构，但非聚焦层可简洁概述或标注"未深入分析，如需展开请告知"。

3. 异常输入处理

用户仅勾选了 1 个店铺 → 提示"至少需要 2 个店铺才能进行对比分析"
用户通过"输入其他"自由输入 → 尝试匹配店铺名称，若无法匹配则提示重新选择
用户未做任何选择直接跳过 → 默认按"全部店铺 + 全量对比"执行，并告知用户

Step 2 — 多店并发采集数据

对每个店铺调用 get_shop_data --ak <该店铺AK> --date_type <DATE_TYPE>（无需提供 userId，由 AK 自动识别）。

⚠️ 重要约束：

所有店铺必须使用相同的 date_type
所有店铺的 get_shop_data 应并发调用，以缩短整体采集耗时（各店铺之间无数据依赖，可安全并行）
每个店铺调用完成后检查 success 字段，失败的店铺跳过并在报告中标注
所有店铺数据采集完毕后，再统一进入 Step 3 分析

Step 3 — 进入分析

采集完所有店铺数据后，按"四、分析方法论"进行横向对比分析。

四、分析方法论（必须严格按此顺序执行）

核心原则：三层递进 → 店铺层识别角色与健康度 → 类目层验证差异化分工 → 商品层定动作。 多店经营的核心是差异化，分析的出发点不是"谁比谁强"，而是"各店是否在自身定位上做好了"。每个结论必须有数据支撑，每个建议必须落到单品，且必须尊重各店的差异化定位。

⚠️ 命名约定：本节中所有反引号包裹的英文字段名（如 payAmt、payRate、uv 等）仅用于标识 API 返回的 JSON 数据路径，供 Agent 定位数据时使用。最终报告中必须全部替换为中文名称，映射表见"八、输出风格与约束 → 指标名称中文化"。

第 1 层：店铺定位画像

回答：各店分别承担什么经营角色？各自的健康度如何？短板在哪？

Step 1 — 店铺角色识别与健康画像（基于 `trade_index` + `core_metrics` + `traffic_trend`）

必做，且优先级最高。

⚠️ 重要原则：多店经营的用户选择开多店，本身就是为了差异化经营。分析不应做机械的"谁是谁的几倍"式对比，而应识别每个店铺的经营角色，然后评估各店在自身定位下的健康度。

分析步骤：

1. 识别各店经营角色

基于以下数据综合判断每个店铺的角色定位：

判断维度	数据来源	角色推断逻辑
客单价水平	`trade_index.perByrAmt`	高客单 → 大件/B端批发；低客单 → 小件/C端零售
新老客结构	`payNewByrCnt / payOldByrCnt`	老客主导 → B端复购型；新客主导 → C端引流型
成交规模	`trade_index.payAmt`	高成交 → 利润型主力店；低成交 → 引流型/孵化型
多人购买率	`top_offer.itemMultiByrCnt`	高复购 → 批发属性；低复购 → 零售属性
同行定位	`core_metrics.rating`	所处行业不同 → 经营赛道不同

输出每个店铺的"角色标签"，例如：

"B端大件家具批发店"（高客单 + 老客主导 + 高复购）
"C端小件家居引流店"（低客单 + 新客主导 + 低复购）
"全品类规模店"（中等客单 + 新老客均衡）

2. 各店健康度评估（在自身定位下）

对每个店铺，基于其角色定位评估健康度：

评估维度	数据来源	判断标准
转化效率	`trade_index.payRate` + `core_metrics.rating`	与该店所处行业同行对比，是否达标
增长动力	`trade_index.payAmt.cycleCrc`	环比增长率，是上升期还是下降期
客户健康	`payNewByrCnt / payOldByrCnt`	B端店看复购是否稳定；C端店看拉新是否持续
退款风险	`rfdSucAmt / payAmt`	高于15%需关注
下单承接	`payToOnRate`	低于30%说明下单到支付存在流失
流量趋势	`traffic_trend` 近7天UV走势	是否持续下滑
流量质量	`traffic_trend.UVCTR`	UV点击率是否合理

3. 输出核心发现

基于以上分析，输出 3-5 条核心发现，每条必须：

指出是哪个店铺的什么问题
给出数据支撑
说明该问题对该店铺自身定位的影响

示例："店铺B（C端引流店）支付转化率仅0.05%，远低于同行均值3.08%，说明6万访客几乎无法被转化为买家，这是该店当前最致命的问题。"

禁止输出："店铺A是店铺B的313倍"这类机械对比——两店定位不同，绝对值对比没有意义。

第 2 层：类目差异化分工

回答：各店的类目布局是否形成了合理的差异化分工？是否存在不必要的内部竞争？

Step 2 — 类目推断与差异化评估（基于 `top_offer_by_pay_amt` + `top_offer_by_uv` 的 `categoryID`）

必做。

由于接口无直接类目汇总数据，需从 TOP 商品的 categoryID 推断各店铺的类目分布：

分析方法：

提取类目：从各店铺的 top_offer_by_pay_amt 和 top_offer_by_uv 中，按 categoryID 聚合商品
计算类目贡献：每个类目下的商品 payAmt 合计 / 该店铺 TOP 商品 payAmt 总和 = 类目贡献占比
跨店对比：

对比维度	分析方法
共同类目	各店铺都有商品的 `categoryID`，对比同类目下的 UV/支付额/转化率
各自优势类目	某店铺在某类目的支付额 / UV 显著高于其他店铺 → 该类目为该店优势类目
集中风险	某店铺 TOP 3 类目合计贡献占比 > 80% → 高集中度风险
内部竞争	多店铺在同一 `categoryID` 下都有 TOP 商品 → 可能存在内耗
差异化分工评估	综合判断各店的类目布局是否形成了合理互补

⚠️ 关于"互补"的重要原则：

两店类目布局不同 ≠ 需要互相复制对方的品类。多店经营的核心价值是差异化，分析时必须：

先确认各店的定位差异（来自 Step 1 的角色标签）
评估类目差异是"合理分工"还是"缺失"：
- 若店铺A是"B端大件家具店"、店铺B是"C端小件家居店"，两店类目不同是合理的差异化分工，不应建议互相复制
- 仅当某店铺在自身定位范围内缺少某个本应有的类目时，才建议补充
识别协同机会而非同质化机会：
- 可协同的是运营经验（如店铺A的详情页策略可借鉴）、客户资源（如共享客户画像）、供应链资源
- 不是简单地把A的商品搬到B

⚠️ 数据局限说明：类目分析基于 TOP 商品推断，并非全量类目数据，结论需标注"基于 TOP 商品推断"。

第 3 层：商品层对比

回答：具体哪几个商品在拖累？哪几个值得加投？哪些可以复制到另一店铺？

Step 3 — 核心单品对比表（基于 `top_offer_by_pay_amt` + `top_offer_by_uv`）

必做。每个店铺至少输出 TOP 10 核心商品。

从 top_offer_by_pay_amt 取出各店铺成交 TOP 10 商品，并交叉补充 top_offer_by_uv 中高流量但不在 TOP 10 成交中的商品。

每个商品必须输出以下字段：

字段	数据来源	说明
商品名称	`item.subject`	—
类目	`item.categoryID`	用于类目聚合
UV	`item.uv`	流量
支付金额	`item.payAmt`	收入
支付转化率	`item.payRate`	转化效率
新客买家数	`item.payNewByrCnt`	拉新能力
复购买家数	`item.itemMultiByrCnt`	复购能力
商品分层标签	由 Step 4 计算	爆品/潜力品/问题品/低效品
异常标签	交叉 `abnormal_offer`	是否出现在异常列表中

集中度分析：

各店铺 TOP 3 成交商品占店铺总 payAmt 的比例 → 集中度高 = 依赖度风险

Step 4 — 商品分层分析（基于 UV + 转化率二维矩阵）

必做。这是本次改进的核心新增模块。

将每个店铺的所有 TOP 商品按 UV 和 payRate 分成四象限：

分层规则（以该店铺 TOP 商品的中位数为基准线）：

分层	UV 条件	payRate 条件	含义
🔥 爆品	≥ 中位数	≥ 中位数	高流量 + 高转化 → 增长引擎
🌱 潜力品	< 中位数	≥ 中位数	低流量 + 高转化 → 值得加投
⚠️ 问题品	≥ 中位数	< 中位数	高流量 + 低转化 → 浪费流量
❌ 低效品	< 中位数	< 中位数	低流量 + 低转化 → 考虑淘汰

每个分层的标准动作建议：

分层	固定动作建议
🔥 爆品	① 稳住排名和库存 ② 加大投放预算 ③ 关注是否出现异常信号
🌱 潜力品	① 加大曝光（投放/活动/推荐位） ② 做关联推荐 ③ 观察放量后转化是否稳定
⚠️ 问题品	① 排查详情页承接 ② 检查价格竞争力 ③ 查看评价情况 ④ 检查是否出现在异常列表
❌ 低效品	① 考虑下架/清理/替换 ② 若类目有潜力，可优化后观察

Step 5 — 异常商品清单与归因（基于 `abnormal_offer` + 交叉 `top_offer`）

必做。必须输出每个异常商品的具体信息和归因。

分析方法：

提取异常商品：从各店铺 abnormal_offer 提取全部异常商品
归因分类：基于 reason 字段分类

归因标签	判断条件（基于 `reason` 和 `valueMap`）
流量下滑	`reason` 包含"访客下跌"
转化下降	`reason` 包含"支付下跌"且 `valueMap` 中 uv 未大幅下跌
双重下跌	`reason` 同时包含"访客下跌"和"支付下跌"

影响程度评估：
- P0 高风险：异常商品同时出现在 top_offer_by_pay_amt TOP 5 中 → 核心商品受损
- P1 中风险：异常商品出现在 top_offer_by_pay_amt TOP 6-10 中
- P2 低风险：异常商品不在 TOP 10 中
跨店对标：如果某店铺的异常商品在另一店铺有同类目正常商品 → 建议参考对方的运营策略（注意：是借鉴运营方法，不是搬运商品）

每个异常商品必须输出：商品名称、异常类型、影响程度（P0/P1/P2）、可能原因、建议动作

Step 6 — 机会商品识别（基于 `top_offer` 数据交叉分析）

必做。

重点识别以下两类机会商品：

类型 1：🌱 高转化低流量品

筛选条件	说明
`payRate` ≥ 店铺 TOP 商品转化率中位数 × 1.2	转化率显著高于平均
`uv` < 店铺 TOP 商品 UV 中位数 × 0.5	流量明显不足

建议动作：加大投放 → 做活动推爆 → 做关联推荐

类型 2：🚀 拉新主力品

筛选条件	说明
`payNewByrCnt` 在该店铺 TOP 3	拉新效果突出
`payRate` 尚可（≥ 中位数 × 0.8）	转化不差

建议动作：作为拉新入口品持续投放

类型 3：♻️ 复购主力品

筛选条件	说明
`itemMultiByrCnt` 在该店铺 TOP 3	复购率高

建议动作：作为老客维护核心品

跨店协同机会（注意：不是简单复制商品）：

⚠️ 在给出任何跨店建议前，必须先做定位一致性检查：

检查项	判断标准	结论
商品是否符合目标店铺定位	客单价、品类、目标客群是否匹配	不匹配则不建议复制
是否会导致两店同质化	两店核心类目重叠度是否会因此显著增加	会同质化则不建议复制
是否有更好的协同方式	能否只复制运营方法而非商品本身	优先建议经验复用

可建议的协同方向（按优先级排序）：

运营经验复用：某店铺在某类目的高转化运营策略（主图风格、详情页结构、定价策略）可供另一店铺参考
供应链协同：某店铺的优质供应商可以同时服务另一店铺（如果品类相关）
客户导流：某店铺的客户画像与另一店铺有重叠时，可做交叉推荐
商品铺设（仅限符合定位的情况）：仅当商品确实符合目标店铺的定位和客群时，才建议铺品

Step 7 — 客户与地域协同（基于 `province` + `customer_detail`）

必做。

7.1 地域覆盖互补分析

分析维度	方法
各店铺核心地域	提取各店铺 TOP 3 省份及占比
地域重叠度	各店铺 TOP 3 省份是否高度重叠 → 重叠高 = 同市场竞争；重叠低 = 地域互补
地域互补机会	某店铺的核心地域恰好是另一店铺的空白区域 → 可互相导流
集中度风险对比	各店铺 TOP 1 省份占比对比，识别地域依赖风险最高的店铺

7.2 头部客户重叠分析

分析维度	方法
客户重叠识别	通过 `buyerLoginId` 对比各店铺头部老客户，识别跨店消费客户
重叠客户价值	重叠客户在各店铺的 `payAmount` 合计
客户区域集中	重叠客户的 `custAreaName` 分布

判断逻辑：

重叠度高 → 统一会员体系、交叉推荐
重叠度低 → 各店独立拉新，可互相引流

Step 8 — 行动建议（综合以上所有分析，按店铺组织，落到单品）

必做，且为最终输出的核心价值。

⚠️ 重要原则：行动建议按店铺维度组织，每个店铺一个独立清单，清单内按 P0/P1/P2 优先级排列。这样商家可以直接按店铺分工执行，避免建议分散在多处导致重复和遗漏。

输出结构（每个店铺一个板块）：

### {店铺名}（{角色标签}）

#### P0 — 紧急处理（本周内）
- 针对核心商品异常（Step 5 中 P0 级异常）
- 针对问题品中的高流量商品（Step 4 中问题品且 UV 排名前 3）
- 每条格式：【商品名】问题描述 → 具体动作 1、动作 2、动作 3

#### P1 — 近期优化（2-4 周）
- 潜力品放量（Step 6 中高转化低流量品）
- 低效品清理（Step 4 中低效品）
- 异常商品修复（Step 5 中 P1/P2 级异常）

#### P2 — 中期规划（1-3 个月）
- 类目差异化调整（Step 2 中类目优化建议）
- 客户协同策略（Step 7 中客户重叠/互补结论）
- 运营经验复用（Step 6 中跨店协同机会）

每条建议的质量要求：

必须关联到具体商品，不能泛泛而谈
必须尊重该店铺的定位，B端店的建议围绕B端场景，C端店的建议围绕C端场景
跨店协同建议放在各店铺清单的 P2 部分，且必须通过"定位一致性检查"（Step 6）

商品行动库（每种问题对应固定动作参考）

问题类型	固定动作清单
高流量低转化	① 改主图 ② 改标题 ③ 调价格 ④ 看评价 ⑤ 查物流承诺 ⑥ 看详情页
高转化低流量	① 加投放 ② 做活动 ③ 做推荐位 ④ 做关联销售
退款率高（店铺级）	① 查质量 ② 查尺码/规格 ③ 查描述是否相符 ④ 查发货时效
流量下滑	① 检查搜索排名 ② 检查竞品动态 ③ 检查投放是否中断
零访问/低效品	① 查是否下架 ② 查是否无曝光 ③ 查搜索是否屏蔽 ④ 考虑清理

五、最终输出格式（强制模板）

输出结构为：整体总结（纯文字）+ 可视化图表 JSON（seller-report 代码块）+ 调用 show_interaction 渲染可执行行动卡片。

统一输出结构

最终报告的文本输出由两部分组成，按以下顺序输出，顺序不可调换：

§A 整体总结（纯文字） → §B 可视化图表 JSON（seller-report 代码块） → 调用 show_interaction 渲染可执行行动卡片

## 整体总结

{500 字以内的纯文字整体总结}

```seller-report
{
  "modules": [...]
}
```（反引号闭合）

§B 的 seller-report 代码块完整闭合后，不再输出任何文本，立即调用 show_interaction 渲染行动卡片。

§A 与 §B 之间不插入其他内容
§B 闭合后必须调用 show_interaction，不得输出 Markdown 代码块形式的卡片 JSON

⚠️ 强约束：

禁止输出 ```action-card``` 代码块
禁止将交互卡片配置 JSON 作为正文展示给用户
行动卡片只能通过 show_interaction 渲染，不通过 Markdown 代码块渲染
seller-report 代码块仍然使用 Markdown 代码块展示，此规则不变

C. 可执行行动卡片（通过 `show_interaction` 渲染）

报告正文（§A + §B）输出完成后，必须通过 show_interaction 渲染交互卡片，不得在正文中输出任何行动卡片 JSON。

⚠️ 强约束：

禁止输出 ```action-card``` 代码块
禁止将交互卡片配置 JSON 以 Markdown 代码块或正文文本形式展示给用户
必须通过 show_interaction 调用完成卡片渲染

形态判定

判定条件	触发交互	渲染形态
各店铺 `abnormal_offer` 合计数量 > 0	`select_abnormal_action`	形态一：店铺 × 商品 × 操作合并卡片
各店铺 `abnormal_offer` 合计数量 == 0	`input_offer_for_optimize`	形态二：offerId 输入框 + 优化方向选择

形态一：识别到异常商品（abnormal_offer_count > 0）

当各店铺异常商品数量 > 0 时，调用 show_interaction 渲染 select_abnormal_action 交互卡片：

type: card
selectionType: requirement
questions: 1 个问题
options: 根据异常商品动态生成，数量 2-6 个
allowMultiple: false
required: true

问题文案：

以上是多店对比分析结果。建议优先处理以下异常商品，请选择一项执行：

选项格式：

优化主图｜{店铺名}｜商品{offerId}｜{异常简述}
优化标题｜{店铺名}｜商品{offerId}｜{异常简述}

选项构造规则：

关键词命中 / `reason`	选项动作	选中后调用的下游技能
主图、图片、CTR、点击率、曝光转点击	`优化主图`	`1688-item-image-optimizer`
标题、关键词、SEO、搜索、词覆盖	`优化标题`	`1688-item-title-optimizer`
`reason="访客下跌"` 未命中关键词	默认推荐 `优化标题`（拉搜索曝光）	`1688-item-title-optimizer`
`reason="支付下跌"` 未命中关键词	默认推荐 `优化主图`（提点击转化）	`1688-item-image-optimizer`
`reason="访客下跌, 支付下跌"`（双跌）	同时生成主图 + 标题两条选项	两个技能各一条

选项约束：

选项必须包含店铺名和商品 ID
商品 ID 必须来自本次接口返回数据，禁止编造
合计选项数 ≥ 2 且 ≤ 6；超过时按异常严重度（valueMap.payAmt.cycleCqc.value 负向绝对值）截断
先按异常严重度从高到低排序（不区分店铺），同一商品的多个选项相邻排列，优化主图在前，优化标题在后
「异常简述」从 reason + 变化值提炼，控制在 12 字内
「输入其他」由端侧自动追加，无需 Agent 自填
用户选择后，Agent 直接调用对应下游技能，并把 offerId 作为上下文携带

正确调用示例（有异常商品时）：

show_interaction({
  type: "card",
  selectionType: "requirement",
  questions: [
    {
      question: "以上是多店对比分析结果。建议优先处理以下异常商品，请选择一项执行：",
      options: [
        "优化主图｜深圳市金嘉伟业电子有限公司｜商品982960365805｜高访客零成交",
        "优化标题｜深圳市金嘉伟业电子有限公司｜商品982960365805｜高访客零成交",
        "优化主图｜武汉耀丹鸿商贸有限公司｜商品887766554｜支付 -9.2k",
        "优化标题｜武汉耀丹鸿商贸有限公司｜商品776655443｜访客 -38%"
      ],
      allowMultiple: false,
      required: true
    }
  ]
})

⚠️ 以上示例仅用于说明调用方式，不得将此 JSON 作为 Markdown 代码块输出给用户。

形态二：未识别到异常商品（abnormal_offer_count == 0）

当各店铺异常商品数量 = 0 时，调用 show_interaction 渲染 input_offer_for_optimize 交互卡片：

type: card
selectionType: requirement
questions: 2 个问题

第 1 题：

question: 请输入要优化的商品 offerId
options: []（自由输入）
required: true

第 2 题：

question: 请选择优化方向
options: ["优化主图", "优化标题"]
allowMultiple: false
required: true

正确调用示例（无异常商品时）：

show_interaction({
  type: "card",
  selectionType: "requirement",
  questions: [
    {
      question: "请输入要优化的商品 offerId",
      options: [],
      required: true
    },
    {
      question: "请选择优化方向",
      options: ["优化主图", "优化标题"],
      allowMultiple: false,
      required: true
    }
  ]
})

⚠️ 以上示例仅用于说明调用方式，不得将此 JSON 作为 Markdown 代码块输出给用户。

约束：

不得在正文中输出任何行动卡片 JSON
不得把交互配置作为 Markdown 代码块展示
必须调用 show_interaction 完成卡片渲染
用户输入商品 ID 并选择方向后，再调用对应下游优化技能

行动卡片渲染的强制流程（两种形态通用）

先读取 {baseDir}/references/interaction-specs.md 中对应章节（形态一读 select_abnormal_action，形态二读 input_offer_for_optimize），核对字段映射
再触发：必须使用 frontmatter metadata.interactions 中已声明的交互名（select_abnormal_action / input_offer_for_optimize），禁止自创
触发时机硬约束：必须在 §B 的 ```seller-report``` 代码块完整闭合之后，禁止在 §B 内部或之前调用 show_interaction
渲染方式硬约束：必须通过 show_interaction 渲染，禁止输出 ```action-card``` 代码块，禁止将卡片 JSON 以任何文本形式展示给用户
下游技能兜底：若 1688-item-image-optimizer / 1688-item-title-optimizer 在用户环境未安装，调用失败时不报错崩溃，而是回退为 "已记录优化意向：商品 {offerId} 的{主图/标题}优化"，并提示"请确认下游优化技能已安装；若未安装，可手动到商品后台对应模块进行优化"
用户选择后：Agent 直接调用对应技能，并把 offerId 作为上下文携带，无需用户再次输入触发词

A. 整体总结（纯文字部分）

500 字以内，按以下逻辑撰写：

开篇定性（1-2 句）：总结多店整体经营格局，点明各店的角色分工和整体健康状态
核心差异（2-3 句）：指出各店之间最关键的差异——谁是增长引擎、谁存在风险、分工是否合理
关键问题（2-3 句）：聚焦最紧迫的问题，数据驱动说明问题的严重程度和影响范围（如"店铺B支付转化率仅0.05%，6万访客几乎无法转化，是当前最致命的问题"）
增长机会（1-2 句）：指出最值得加投的机会点（具体到哪个店铺的哪类商品）
行动方向（1-2 句）：最紧迫的 1-2 个行动方向

撰写要求：

条理清晰、结论先行、有数据支撑
用经营语言而非纯数字罗列
必须体现多店差异化视角，不能写成多个单店摘要的简单拼接
禁止在总结中出现英文指标名称，全部使用中文

B. 可视化图表 JSON（`seller-report` 代码块）

整体总结之后，输出被 ```seller-report ``` 包裹的可视化组件 JSON。此 JSON 是将详细分析报告的各章节内容转换为可视化组件后的结果，用户看到的不再是纯文字报告，而是图表化的可视化大屏。

生成规则：严格遵循 references/visualization-rules.md 中定义的组件规范和 references/anti-patterns.md 中的反例约束。

生成流程：

阅读反例约束（强制前置步骤）：阅读 references/anti-patterns.md，理解跨组件的通用反例约束
内部生成详细报告文字（不输出给用户）：根据分析方法论各 Step 的结果，在内部生成完整的分章节 Markdown 报告文字（格式参考下方"内部报告章节参考"），作为可视化转换的输入源
转换为可视化 JSON：按 references/visualization-rules.md 中的组件选型、布局规范和完整性规则，将内部报告文字转换为 seller-report JSON

关键约束：

内部报告文字不输出给用户，用户只看到整体总结 + seller-report JSON
可视化 JSON 中的数据必须来自接口返回，禁止捏造
若某接口数据缺失，对应模块使用 TextCard 标注"数据暂不可用"
金额、百分比等数值禁止裸数字，必须附带含义标注（如"支付金额 ¥125,000.00"而非"125000"）
在最终报告中不得出现 RECENT_7、RECENT_30 等英文周期标识，必须全部显示为中文
多店对比场景的特殊约束：涉及多店对比的图表，必须在数据中明确标注店铺归属（如 category 字段使用店铺名称），确保用户能区分各店铺数据

C. 内部报告章节参考（不输出给用户，仅作为可视化转换的输入源）

完整型报告的内部报告应包含以下 5 个章节，对应分析方法论的 4 层结构 + 行动建议：

章节 1：店铺定位画像

各店经营角色与角色标签
各店核心指标对比（支付金额、买家数、转化率、客单价、新老客结构）及环比变化
各店健康度评估（转化效率、增长动力、客户健康、退款风险、流量趋势）
各店同行对比评级
3-5 条核心发现

章节 2：类目差异化分工

各店类目分布及贡献占比
共同类目 vs 各自优势类目
差异化分工评估（合理性、内部竞争风险）
类目层面的协同机会

章节 3：商品层对比

各店 TOP 10 核心商品（含分层标签：🔥爆品/🌱潜力品/⚠️问题品/❌低效品）
商品分层汇总（各店各分层数量对比）
问题商品清单（含异常类型、影响程度 P0/P1/P2、归因、建议动作）
机会商品清单（高转化低流量品、拉新主力品、复购主力品）
跨店协同机会（运营经验复用、客户资源协同、供应链协同）

章节 4：客户与地域协同

各店地域分布对比（TOP 省份、集中度、重叠度）
头部客户重叠分析（重叠数量、价值、协同方向）
地域互补机会

章节 5：行动建议

按店铺维度组织，每个店铺一个独立板块
每个店铺内按 P0（紧急处理）/ P1（近期优化）/ P2（中期规划）三档排列
每条建议必须关联到具体商品，必须尊重该店铺的定位

D. 各章节推荐组件映射

内部报告章节	推荐可视化组件	说明
店铺定位画像
各店角色与核心指标	DataCard（每店一组）	支付金额/买家数/转化率/客单价，含环比
多店核心指标对比	Chart.Column（分组柱状图）	x轴=指标名，category=店铺名，用于横向对比
各店健康度评估	KeyValueCard（每店一组）	分组：转化效率/增长动力/客户健康/退款风险
各店同行评级	KeyValueCard 或 Chart.Column	达标指标 vs 待改善指标
核心发现	AlertCard	3-5 条核心风险/发现，含问题-后果-建议
类目差异化分工
类目支付额对比	Chart.Column（分组柱状图）	x轴=类目，category=店铺名
差异化分工评估	TextCard	分工合理性、内部竞争、协同机会
商品层对比
核心商品列表	Chart.List	每店 TOP 10 商品，含分层标签和关键指标
商品分层汇总	Chart.Column 或 DataCard	各店各分层数量对比
问题商品清单	Chart.List	含异常类型、影响程度、归因、建议
机会商品清单	Chart.List 或 InfluenceCard	按机会类型分组，含放大建议
跨店协同机会	TextCard	运营经验/客户/供应链协同
客户与地域协同
地域分布对比	Chart.Column 或 Chart.Pie	各店 TOP 省份占比
客户重叠分析	KeyValueCard 或 DataCard	重叠数量、价值、协同方向
行动建议
各店 P0/P1/P2 行动	PhaseCard（每店一组）	阶段=P0/P1/P2，focusPoints=具体商品和动作

注意：以上为推荐组件映射，实际生成时应根据数据特征和 references/visualization-rules.md 中的组件选型优先级灵活调整。核心原则是每个章节至少有 1 个组件对应，总组件数不少于章节数 × 1.5。

E. 聚焦型报告 vs 完整型报告的差异

维度	聚焦型（用户在 Step 1.5 选择了聚焦维度）	完整型（全量对比）
整体总结	仅围绕所选维度的分析结论	覆盖全部 4 层的综合诊断
内部报告章节	仅生成所选维度对应章节 + 行动建议	生成全部 5 个章节
可视化 JSON	modules 仅包含所选维度对应的模块	modules 包含全部章节的模块

聚焦型报告方向与章节映射：

用户选择方向	内部生成的报告章节
聚焦经营概况	章节 1（店铺定位画像）+ 章节 5（行动建议）
聚焦商品诊断	章节 3（商品层对比）+ 章节 5（行动建议）
聚焦客户地域	章节 4（客户与地域协同）+ 章节 5（行动建议）

⚠️ 即使是聚焦型报告，仍需输出完整的三段式结构（§A 整体总结 + §B seller-report JSON + 调用 show_interaction 渲染行动卡片），但非聚焦章节在 JSON 中可省略。

F. 模板使用说明

输出顺序硬约束：§A 整体总结（纯文字） → §B seller-report 可视化 JSON → 调用 show_interaction 渲染行动卡片。§A 与 §B 之间不插入其他内容，§B 闭合后必须调用 show_interaction
禁止输出 action-card 代码块：行动卡片只能通过 show_interaction 渲染，不得以 Markdown 代码块或正文文本形式展示给用户
可视化 JSON 生成必须严格遵循 references/visualization-rules.md 和 references/anti-patterns.md 中的规范
数据完整性：图表中的金额、百分比、商品名称必须来自接口返回，不得编造
多店标识：所有涉及多店对比的组件，必须明确标注各数据所属的店铺名称
商品行动落地：行动建议章节（PhaseCard）中的每条建议必须关联到具体商品名称
行动卡片：必须在 §B 的 ```seller-report``` 代码块完整闭合之后调用 show_interaction，禁止在 §B 内部或之前渲染

六、执行流程（建议的最小执行集）

默认多店对比（用户问"多店对比"等通用问题）

Step 1（必做，串行）：调用 get_bindlist，获取所有绑定店铺列表

Step 1.5（条件触发）：若店铺数 ≥ 4，触发 select_shop_scope 交互，询问用户分析范围和焦点（详见"三、数据采集流程 → Step 1.5"）

若用户选择"自选店铺" → 仅对用户选定的店铺执行后续采集
若用户选择聚焦维度 → Step 2 仅采集对应维度所需数据（详见 Step 1.5 中的焦点-数据映射表）
若店铺数 < 4 → 跳过本步骤，直接进入 Step 2

Step 2（必做，并发执行）：对所有店铺（或用户选定的店铺）并发调用 get_shop_data，采集全量数据（或聚焦维度所需数据），所有店铺数据到齐后再进入下一步

Step 3（必做）：按"四、分析方法论"执行 Step 1-8 分析

Step 4（必做）：按"五、最终输出格式"生成图文并茂的报告，执行以下三步：

§A 整体总结（500 字以内纯文字）：按开篇定性→核心差异→关键问题→增长机会→行动方向的逻辑撰写
§B 可视化 JSON（seller-report 代码块）：先阅读 references/anti-patterns.md，再在内部生成分章节报告文字（不输出），最后按 references/visualization-rules.md 转换为可视化组件 JSON
调用 show_interaction 渲染行动卡片：根据各店铺异常商品数量判断形态——有异常商品则渲染 select_abnormal_action（店铺×商品×操作合并卡片），无异常商品则渲染 input_offer_for_optimize（offerId 输入 + 优化方向选择）

⚠️ Step 4 强约束：

第 3 步不是文本输出，是 show_interaction 调用
禁止输出 ```action-card``` 代码块
禁止把交互 JSON 直接展示给用户
必须使用 show_interaction 渲染行动卡片

聚焦型分析（用户问特定方向）

用户问题方向	必采数据	输出聚焦
"哪个店铺卖得最好"	`trade_index` + `core_metrics`	章节 1（店铺定位画像）重点展开
"各店铺类目差异"	`top_offer_*`	章节 2（类目差异化分工）重点展开
"哪些商品在拖累/值得加投"	`top_offer_*` + `abnormal_offer`	章节 3（商品层对比）重点展开
"客户重叠分析"	`customer_detail` + `province`	章节 4（客户与地域协同）重点展开
"资源怎么分配"	全量数据	章节 5（行动建议）重点展开

聚焦型分析的输出格式与完整型一致（整体总结 + seller-report JSON），但 JSON 中仅包含聚焦章节对应的 modules，非聚焦章节可省略。

注意：当用户直接指定了特定方向时，即使店铺数 ≥ 4，Step 1.5 中的分析焦点选择可跳过（已由用户问题隐含指定），但分析范围选择仍需执行——即仍需询问用户是否缩小店铺范围。

七、安全与异常处理

AK 配置

首次使用前需配置 AK：

python3 {baseDir}/cli.py configure YOUR_AK

查看状态：python3 {baseDir}/cli.py configure

命令异常处理

任何命令输出 success: false 时：

markdown 关键词	Agent 行为
"AK 未配置" / "签名无效" / "401"	提示用户当前发送能力所需鉴权未就绪，请补充有效 AK
"限流" / "429"	等待 1-2 分钟后重试
其他	仅输出 markdown 即可

接口降级（部分店铺数据缺失时）

场景	处理方式
`get_bindlist` 失败	终止分析，提示用户检查 AK 或绑定关系
某店铺 `get_shop_data` 整体失败	跳过该店铺，在报告中标注"{店铺名}数据暂不可用"
某店铺某个维度数据为 `null`	该维度对比中跳过该店铺，标注"数据缺失"
仅一个店铺有数据	输出该店铺的单店分析（降级为类似 health-check 的输出）

八、输出风格与约束

语言风格

数据驱动：每个结论必须有数据支撑，不能主观臆断
差异化导向：尊重各店的差异化定位，不做"谁是谁的几倍"式机械对比，聚焦各店在自身定位下的健康度
可执行：建议必须具体到"哪个店铺做什么"，不能泛泛而谈，且行动建议按店铺维度组织，避免跨店铺重复
优先级明确：建议分 P0/P1/P2 优先级
协同而非同质：跨店建议优先推荐运营经验复用、客户资源共享，而非简单的商品搬运

数值格式

金额：¥12,345.67
百分比：12.34%
人数：1,234 人
变化率：+12.3% / -5.2%

指标名称中文化（强约束）

最终报告中禁止出现任何英文指标名称、API 字段名或数据维度 key。 分析方法论中的反引号英文字段名仅供 Agent 定位数据，输出到报告时必须全部替换为中文。

数据维度 key 映射

API 维度 key	报告中使用
`trade_index`	交易指标
`core_metrics`	核心指标 / 同行对比
`traffic_trend`	流量趋势
`abnormal_offer`	异常商品
`top_offer_by_pay_amt`	成交TOP商品
`top_offer_by_uv`	流量TOP商品
`top_offer_by_new_buyer`	拉新TOP商品
`top_offer_by_repurchase`	复购TOP商品
`activity_info`	活动信息
`province`	地域分布
`customer_detail`	客户明细

字段名映射

英文字段名	报告中使用
`payAmt` / `payAmount`	支付金额
`payRate`	支付转化率
`uv` / `UV`	访客数
`pv` / `PV`	浏览量
`UVCTR`	访客点击率
`categoryID`	类目
`itemId`	商品ID
`subject`	商品名称
`payNewByrCnt`	新客买家数
`payOldByrCnt`	老客买家数
`payByrCnt`	支付买家数
`perByrAmt`	客单价
`itemMultiByrCnt`	复购买家数
`rfdSucAmt`	退款成功金额
`payToOnRate`	下单-支付转化率
`cycleCrc`	环比变化率
`companyName`	店铺名称
`buyerLoginId`	买家账号
`custAreaName`	客户区域
`reason`	异常原因
`valueMap`	指标详情
`rating`	同行评级

自查规则：报告定稿前，逐段检查是否存在英文字段名或英文缩写（UV、PV、UVCTR 等），如发现一律替换为上表中文名称。如遇上表未列出的英文字段名，翻译为语义明确的中文短语。

注意事项

不要暴露 AK：报告中不能出现任何 AK 信息
统一口径：所有店铺必须使用相同的 date_type
活动数据口径说明：活动信息固定为近 30 天口径，需在结论中说明
店铺命名：使用店铺公司名称作为标识，不使用 AK 或 userId
空值处理：某店铺某维度为 null 时，表格中填"—"并标注"数据缺失"
指标名称中文化：报告正文和表格中的所有指标名、维度名必须使用中文（详见"指标名称中文化"小节），禁止出现 payAmt、UV、payRate 等英文原始字段名

九、环境变量（.env）

变量	默认值	说明
`SKILL_NAME`	`1688-multi-shop-compare`	skill 名称
`SKILL_VERSION`	`1.0.0`	skill 版本号
`SKILL_CHANNEL`	`clawhub`	发布渠道

十、埋点上报

每次 CLI 命令执行时，自动上报调用记录。

实现位置：scripts/_tracker.py
上报接口：POST /api/reportSkillsUsage/1.0.0
失败处理：静默忽略，不影响主流程

1688 Multi Shop Compare

Audits

Install

1688-multi-shop-compare —— 多店经营对比分析

角色定位

一、可调用的能力（CLI 命令）

命令总览

1. get_bindlist — 获取多店铺绑定关系及 AK

2. get_shop_data — 获取单个店铺的全量经营数据

二、时间周期与调用规则（强约束）

时间周期

调用规则

三、数据采集流程（强约束）

Step 1 — 获取店铺列表

Step 1.5 — 店铺范围与分析焦点确认（店铺数 ≥ 4 时触发）

Step 2 — 多店并发采集数据

Step 3 — 进入分析

四、分析方法论（必须严格按此顺序执行）

第 1 层：店铺定位画像

Step 1 — 店铺角色识别与健康画像（基于 trade_index + core_metrics + traffic_trend）

第 2 层：类目差异化分工

Step 2 — 类目推断与差异化评估（基于 top_offer_by_pay_amt + top_offer_by_uv 的 categoryID）

第 3 层：商品层对比

Step 3 — 核心单品对比表（基于 top_offer_by_pay_amt + top_offer_by_uv）

Step 4 — 商品分层分析（基于 UV + 转化率二维矩阵）

Step 5 — 异常商品清单与归因（基于 abnormal_offer + 交叉 top_offer）

Step 6 — 机会商品识别（基于 top_offer 数据交叉分析）

Step 7 — 客户与地域协同（基于 province + customer_detail）

7.1 地域覆盖互补分析

7.2 头部客户重叠分析

Step 8 — 行动建议（综合以上所有分析，按店铺组织，落到单品）

商品行动库（每种问题对应固定动作参考）

五、最终输出格式（强制模板）

统一输出结构

C. 可执行行动卡片（通过 show_interaction 渲染）

形态判定

形态一：识别到异常商品（abnormal_offer_count > 0）

形态二：未识别到异常商品（abnormal_offer_count == 0）

行动卡片渲染的强制流程（两种形态通用）

A. 整体总结（纯文字部分）

B. 可视化图表 JSON（seller-report 代码块）

C. 内部报告章节参考（不输出给用户，仅作为可视化转换的输入源）

章节 1：店铺定位画像

章节 2：类目差异化分工

章节 3：商品层对比

章节 4：客户与地域协同

章节 5：行动建议

D. 各章节推荐组件映射

E. 聚焦型报告 vs 完整型报告的差异

F. 模板使用说明

六、执行流程（建议的最小执行集）

默认多店对比（用户问"多店对比"等通用问题）

聚焦型分析（用户问特定方向）

七、安全与异常处理

AK 配置

命令异常处理

接口降级（部分店铺数据缺失时）

八、输出风格与约束

语言风格

数值格式

指标名称中文化（强约束）

数据维度 key 映射

字段名映射

注意事项

九、环境变量（.env）

十、埋点上报

1. `get_bindlist` — 获取多店铺绑定关系及 AK

2. `get_shop_data` — 获取单个店铺的全量经营数据

Step 1 — 店铺角色识别与健康画像（基于 `trade_index` + `core_metrics` + `traffic_trend`）

Step 2 — 类目推断与差异化评估（基于 `top_offer_by_pay_amt` + `top_offer_by_uv` 的 `categoryID`）

Step 3 — 核心单品对比表（基于 `top_offer_by_pay_amt` + `top_offer_by_uv`）

Step 5 — 异常商品清单与归因（基于 `abnormal_offer` + 交叉 `top_offer`）

Step 6 — 机会商品识别（基于 `top_offer` 数据交叉分析）

Step 7 — 客户与地域协同（基于 `province` + `customer_detail`）

C. 可执行行动卡片（通过 `show_interaction` 渲染）

B. 可视化图表 JSON（`seller-report` 代码块）