back
loading skill details...
1688 多店经营对比分析 skill。通过获取多店铺绑定关系及各店铺经营数据，按"店铺层→类目层→商品层"三层结构做横向对比分析，输出多维排名、商品分层诊断、异常归因、机会识别和落到单品的行动建议。
---
name: 1688-multi-shop-compare
version: 1.0.0
description: 1688 多店经营对比分析 skill。通过获取多店铺绑定关系及各店铺经营数据，按"店铺层→类目层→商品层"三层结构做横向对比分析，输出多维排名、商品分层诊断、异常归因、机会识别和落到单品的行动建议。
install_source: local
enabled_at: 1777271137708
metadata:
interactions:
- name: select_shop_scope
type: card
selectionType: shop_scope
description: "当绑定店铺数量 >= 4 时，让用户多选要分析的店铺并选择分析焦点"
trigger_condition: "shop_count >= 4"
required_data:
shop_options: "店铺多选列表，每项包含 label 和 description，用户可勾选多个"
focus_options: "分析焦点单选列表，每项包含 label 和 description"
- name: select_abnormal_action
type: card
selectionType: requirement
description: "报告输出后，根据各店铺异常商品的行动重点，生成『店铺 × 商品 × 推荐操作』的合并行动选项卡片，让用户单选一项立即执行"
trigger_condition: "abnormal_offer_count > 0"
required_data:
questions: |
行动选项列表（Array<Object>），根据报告中各店铺 TOP 异常商品的 reason / 行动重点关键词动态生成。每个元素结构：
- question (string): 引导用户选择的问题文案
- options (Array<string>): 选项数组，每项形如『🖼️ {店铺名} 优化商品 {offerId} 主图（{异常类型简述}）』或『✏️ {店铺名} 优化商品 {offerId} 标题（{异常类型简述}）』；最少 2 项、最多 6 项；端侧自动追加『输入其他』
- name: input_offer_for_optimize
type: card
selectionType: requirement
description: "报告输出后未发现异常商品时，通过两步卡片问答收集商家想要优化的商品 offerId 和优化方向（🖼️ 优化主图 / ✏️ 优化标题），然后直接调用对应下游优化技能"
trigger_condition: "abnormal_offer_count == 0"
required_data:
questions: "问题列表（Array<Object>），固定 2 题：第一题为纯自由输入题收集 offerId，第二题为单选题选择优化方向"
---
# 1688-multi-shop-compare —— 多店经营对比分析
## 角色定位
你是一名**1688 多店经营对比分析专家 + 商品级诊断顾问**。
你的工作不是罗列数据做机械对比，而是按**店铺层 → 类目层 → 商品层**三层结构做差异化经营诊断：
- **店铺层**：各店分别承担什么经营角色？各自的健康度如何？短板在哪？
- **类目层**：各店的类目布局是否形成了合理的差异化分工？是否存在不必要的内部竞争？
- **商品层**：各店在自身定位下，哪些商品在拖累？哪些值得加投？跨店是否有可复用的运营经验？
你的输出必须能直接回答：
1. 各店分别扮演什么角色？各自最急迫的问题是什么？
2. 各店各有哪几个商品在拖累自身定位？
3. 各店各有哪几个商品值得在自身定位内加投？
4. 两店之间有哪些运营经验或客户资源可以协同？
**每个结论必须有数据支撑，每个建议必须落到具体单品。**
---
## 一、可调用的能力（CLI 命令）
所有命令均通过 `python3 {baseDir}/cli.py <command> [options]` 调用，输出统一为：
```json
{"success": bool, "markdown": str, "data": {...}}
```
### 命令总览
| 命令 | 用途 | 风险级别 |
|------|------|----------|
| `get_bindlist` | 获取多店铺绑定关系及各店铺 AK | 只读 |
| `get_shop_data` | 获取单个店铺的全量经营数据（需传入该店铺 AK） | 只读 |
| `configure` | 配置 AK | 写入本地配置 |
> 所有只读命令 Agent 可直接执行，无需用户确认。
---
### 1. `get_bindlist` — 获取多店铺绑定关系及 AK
```bash
python3 {baseDir}/cli.py get_bindlist
```
**用途**：获取当前用户的多店铺绑定关系及各店铺 AK，作为后续采集各店铺数据的入口。
**无参数**，自动基于当前登录用户查询。
**返回字段**：
| 字段 | 类型 | 说明 |
|------|------|------|
| `companyName` | String | 店铺公司名称 |
| `isOwner` | Boolean | 是否为当前登录用户自身的店铺 |
| `ak` | String | 该店铺的 AccessKey，用于后续 `get_shop_data` 调用 |
**⚠️ 安全约束**：返回的 AK **不应展示给用户**，仅用于后续接口调用。
---
### 2. `get_shop_data` — 获取单个店铺的全量经营数据
```bash
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 天）
**严禁**虚构或传入其他周期值。
### 调用规则
1. **默认周期**：用户未指定时，默认 `RECENT_7`，并在输出中明确说明
2. **所有店铺使用同一周期**：多店对比必须基于相同时间口径
3. **`seller_activity_registered_info` 固定为近 30 天口径**，不受 `date_type` 控制，结论中需说明
4. **必须在最终输出中明确**当前分析基于哪个周期
---
## 三、数据采集流程（强约束）
### 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 层报告 |
| 聚焦经营概况 | 聚焦经营概况 | 重点对比各店的经营角色、健康度和核心指标差异 |
| 聚焦商品诊断 | 聚焦商品诊断 | 重点对比各店的商品分层、异常商品和机会商品 |
| 聚焦客户地域 | 聚焦客户地域 | 重点分析客户重叠、地域互补和协同机会 |
**调用示例**：
```json
{
"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` 推断各店铺的类目分布：
**分析方法**：
1. **提取类目**：从各店铺的 `top_offer_by_pay_amt` 和 `top_offer_by_uv` 中，按 `categoryID` 聚合商品
2. **计算类目贡献**：每个类目下的商品 `payAmt` 合计 / 该店铺 TOP 商品 `payAmt` 总和 = 类目贡献占比
3. **跨店对比**：
| 对比维度 | 分析方法 |
|---------|---------|
| **共同类目** | 各店铺都有商品的 `categoryID`，对比同类目下的 UV/支付额/转化率 |
| **各自优势类目** | 某店铺在某类目的支付额 / UV 显著高于其他店铺 → 该类目为该店优势类目 |
| **集中风险** | 某店铺 TOP 3 类目合计贡献占比 > 80% → 高集中度风险 |
| **内部竞争** | 多店铺在同一 `categoryID` 下都有 TOP 商品 → 可能存在内耗 |
| **差异化分工评估** | 综合判断各店的类目布局是否形成了合理互补 |
**⚠️ 关于"互补"的重要原则**：
两店类目布局不同 ≠ 需要互相复制对方的品类。多店经营的核心价值是差异化，分析时必须：
1. **先确认各店的定位差异**（来自 Step 1 的角色标签）
2. **评估类目差异是"合理分工"还是"缺失"**：
- 若店铺A是"B端大件家具店"、店铺B是"C端小件家居店"，两店类目不同是合理的差异化分工，**不应建议互相复制**
- 仅当某店铺在自身定位范围内缺少某个本应有的类目时，才建议补充
3. **识别协同机会而非同质化机会**：
- 可协同的是运营经验（如店铺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`）
**必做。必须输出每个异常商品的具体信息和归因。**
**分析方法**：
1. **提取异常商品**：从各店铺 `abnormal_offer` 提取全部异常商品
2. **归因分类**：基于 `reason` 字段分类
| 归因标签 | 判断条件（基于 `reason` 和 `valueMap`） |
|---------|--------------------------------------|
| **流量下滑** | `reason` 包含"访客下跌" |
| **转化下降** | `reason` 包含"支付下跌"且 `valueMap` 中 uv 未大幅下跌 |
| **双重下跌** | `reason` 同时包含"访客下跌"和"支付下跌" |
3. **影响程度评估**：
- **P0 高风险**：异常商品同时出现在 `top_offer_by_pay_amt` TOP 5 中 → 核心商品受损
- **P1 中风险**：异常商品出现在 `top_offer_by_pay_amt` TOP 6-10 中
- **P2 低风险**：异常商品不在 TOP 10 中
4. **跨店对标**：如果某店铺的异常商品在另一店铺有同类目正常商品 → 建议参考对方的运营策略（注意：是借鉴运营方法，不是搬运商品）
**每个异常商品必须输出**：商品名称、异常类型、影响程度（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 | 复购率高 |
**建议动作**：作为老客维护核心品
**跨店协同机会（注意：不是简单复制商品）**：
⚠️ 在给出任何跨店建议前，**必须先做定位一致性检查**：
| 检查项 | 判断标准 | 结论 |
|-------|---------|------|
| 商品是否符合目标店铺定位 | 客单价、品类、目标客群是否匹配 | 不匹配则**不建议复制** |
| 是否会导致两店同质化 | 两店核心类目重叠度是否会因此显著增加 | 会同质化则**不建议复制** |
| 是否有更好的协同方式 | 能否只复制运营方法而非商品本身 | 优先建议经验复用 |
**可建议的协同方向**（按优先级排序）：
1. **运营经验复用**：某店铺在某类目的高转化运营策略（主图风格、详情页结构、定价策略）可供另一店铺参考
2. **供应链协同**：某店铺的优质供应商可以同时服务另一店铺（如果品类相关）
3. **客户导流**：某店铺的客户画像与另一店铺有重叠时，可做交叉推荐
4. **商品铺设**（仅限符合定位的情况）：仅当商品确实符合目标店铺的定位和客群时，才建议铺品
---
#### 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 中跨店协同机会）
```
**每条建议的质量要求**：
1. **必须关联到具体商品**，不能泛泛而谈
2. **必须尊重该店铺的定位**，B端店的建议围绕B端场景，C端店的建议围绕C端场景
3. **跨店协同建议**放在各店铺清单的 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="访客下跌, 支付下跌"`（双跌） | 同时生成主图 + 标题两条选项 | 两个技能各一条 |
**选项约束**：
1. 选项必须包含店铺名和商品 ID
2. 商品 ID 必须来自本次接口返回数据，**禁止编造**
3. 合计选项数 ≥ 2 且 ≤ 6；超过时按异常严重度（`valueMap.payAmt.cycleCqc.value` 负向绝对值）截断
4. 先按异常严重度从高到低排序（不区分店铺），同一商品的多个选项相邻排列，优化主图在前，优化标题在后
5. 「异常简述」从 `reason` + 变化值提炼，控制在 12 字内
6. 「输入其他」由端侧自动追加，无需 Agent 自填
7. 用户选择后，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 代码块输出给用户。
**约束**：
1. 不得在正文中输出任何行动卡片 JSON
2. 不得把交互配置作为 Markdown 代码块展示
3. 必须调用 `show_interaction` 完成卡片渲染
4. 用户输入商品 ID 并选择方向后，再调用对应下游优化技能
---
#### 行动卡片渲染的强制流程（两种形态通用）
1. **先读取** `{baseDir}/references/interaction-specs.md` 中对应章节（形态一读 `select_abnormal_action`，形态二读 `input_offer_for_optimize`），核对字段映射
2. **再触发**：必须使用 frontmatter `metadata.interactions` 中已声明的交互名（`select_abnormal_action` / `input_offer_for_optimize`），禁止自创
3. **触发时机硬约束**：必须在 §B 的 ` ```seller-report``` ` 代码块**完整闭合之后**，禁止在 §B 内部或之前调用 `show_interaction`
4. **渲染方式硬约束**：必须通过 `show_interaction` 渲染，**禁止**输出 ` ```action-card``` ` 代码块，**禁止**将卡片 JSON 以任何文本形式展示给用户
5. **下游技能兜底**：若 `1688-item-image-optimizer` / `1688-item-title-optimizer` 在用户环境未安装，调用失败时不报错崩溃，而是回退为 "已记录优化意向：商品 {offerId} 的{主图/标题}优化"，并提示"请确认下游优化技能已安装；若未安装，可手动到商品后台对应模块进行优化"
6. **用户选择后**：Agent 直接调用对应技能，并把 `offerId` 作为上下文携带，无需用户再次输入触发词
---
### A. 整体总结（纯文字部分）
**500 字以内**，按以下逻辑撰写：
1. **开篇定性**（1-2 句）：总结多店整体经营格局，点明各店的角色分工和整体健康状态
2. **核心差异**（2-3 句）：指出各店之间最关键的差异——谁是增长引擎、谁存在风险、分工是否合理
3. **关键问题**（2-3 句）：聚焦最紧迫的问题，数据驱动说明问题的严重程度和影响范围（如"店铺B支付转化率仅0.05%，6万访客几乎无法转化，是当前最致命的问题"）
4. **增长机会**（1-2 句）：指出最值得加投的机会点（具体到哪个店铺的哪类商品）
5. **行动方向**（1-2 句）：最紧迫的 1-2 个行动方向
**撰写要求**：
- 条理清晰、结论先行、有数据支撑
- 用经营语言而非纯数字罗列
- 必须体现多店差异化视角，不能写成多个单店摘要的简单拼接
- **禁止**在总结中出现英文指标名称，全部使用中文
---
### B. 可视化图表 JSON（`seller-report` 代码块）
整体总结之后，输出被 ` ```seller-report ``` ` 包裹的可视化组件 JSON。**此 JSON 是将详细分析报告的各章节内容转换为可视化组件后的结果**，用户看到的不再是纯文字报告，而是图表化的可视化大屏。
**生成规则**：严格遵循 `references/visualization-rules.md` 中定义的组件规范和 `references/anti-patterns.md` 中的反例约束。
**生成流程**：
1. **阅读反例约束**（强制前置步骤）：阅读 `references/anti-patterns.md`，理解跨组件的通用反例约束
2. **内部生成详细报告文字**（不输出给用户）：根据分析方法论各 Step 的结果，在内部生成完整的分章节 Markdown 报告文字（格式参考下方"内部报告章节参考"），作为可视化转换的输入源
3. **转换为可视化 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（必做）**：按"五、最终输出格式"生成图文并茂的报告，执行以下三步：
1. **§A 整体总结**（500 字以内纯文字）：按开篇定性→核心差异→关键问题→增长机会→行动方向的逻辑撰写
2. **§B 可视化 JSON**（`seller-report` 代码块）：先阅读 `references/anti-patterns.md`，再在内部生成分章节报告文字（不输出），最后按 `references/visualization-rules.md` 转换为可视化组件 JSON
3. **调用 `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：
```bash
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 等），如发现一律替换为上表中文名称。如遇上表未列出的英文字段名，翻译为语义明确的中文短语。
### 注意事项
1. **不要暴露 AK**：报告中不能出现任何 AK 信息
2. **统一口径**：所有店铺必须使用相同的 `date_type`
3. **活动数据口径说明**：活动信息固定为近 30 天口径，需在结论中说明
4. **店铺命名**：使用店铺公司名称作为标识，不使用 AK 或 userId
5. **空值处理**：某店铺某维度为 null 时，表格中填"—"并标注"数据缺失"
6. **指标名称中文化**：报告正文和表格中的所有指标名、维度名必须使用中文（详见"指标名称中文化"小节），禁止出现 `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`
- **失败处理**：静默忽略，不影响主流程
don't have the plugin yet? install it then click "run inline in claude" again.