Skill: 1688aiinfra/1688-multi-shop-compare (version 1.0.0)

--- 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` | [REDACTED_SECRET] | 客户地域分布 | | `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` - **失败处理**：静默忽略，不影响主流程

path: scripts/_const.py
content: #!/usr/bin/env python3
"""1688-multi-shop-compare 全局常量"""

import os
from pathlib import Path

SKILL_VERSION = "1.0.0"

OPENCLAW_CONFIG_PATH: Path = Path(
    os.environ.get("OPENCLAW_CONFIG_DIR", Path.home() / ".openclaw")
) / "openclaw.json"


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)