---
name: 1688-shop-health-check
version: 1.0.0
description: |
  1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。
  本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。
metadata:
  interactions:
    - name: confirm_execution_plan
      type: card
      selectionType: requirement
      description: 在用户输入店铺健康检查请求后，输出执行计划（含输出形式、时间周期等）并以卡片形式展示 8 个可选项供用户选择诊断维度。前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为"全面诊断（七维度）"。用户可多选维度，选择"全面诊断（七维度）"时覆盖个体选择，诊断全部七维度。用户选择后点击"确认"开始诊断，点击"取消"则终止流程
      required_data:
        questions: |
          问题列表（Array<Object>），仅含一项必填多选项：
          - question (string): 引导用户选择诊断维度的问题文案
          - options (Array<string>): 固定 8 项，前 7 项为七维度名称（"流量"、"询盘"、"成交"、"商品"、"客户"、"广告"、"风险"），第 8 项为"全面诊断（七维度）"
          - allowMultiple (bool): 固定 true
          - required (bool): 固定 true（至少选择 1 项）
          卡片默认提供"确认"与"取消"两个按钮：
          - 选择维度后点击"确认"：按所选维度开始诊断
          - 点击"取消"：终止流程，不执行任何诊断
    - name: select_action_items
      type: card
      selectionType: requirement
      description: 在店铺健康检查总结性结论与 HTML 报告输出后，根据本次体检得出的优先行动建议（按优先级取最高 3 条），并在行动项之后按条件追加一条定时任务选项（must-check），向用户展示可多选的行动项卡片；用户勾选后点击"确认"，Agent 按选中项继续执行对应优化动作或为用户设置并开启定时体检任务，点击"取消"或不选择任何项则结束本次体检流程
      required_data:
        questions: |
          问题列表（Array<Object>），结构：
          - question (string): 引导用户选择下一步执行哪些行动项
          - options (Array<string>): 选项文本数组。前若干条为行动项（最多 3 条，按优先级从高到低排列，每条包含行动概要、所属店铺简称及紧急程度）；最后按条件追加一条定时任务选项，文案固定为 "⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务"（must-check：先 Schedule list + 按任务名「店铺健康检查」或固定执行内容双键 OR 命中判断，仅当命中且已开启（enabled:true）时才不追加，未命中或命中但已停用（enabled:false）均追加；不参与优先级排序、不计入 3 条上限）
          - allowMultiple (bool): 是否允许多选，固定 true
          - required (bool): 是否必填，固定 true（至少选择 1 项）
          卡片默认提供"确认"与"取消"两个按钮：
          - 点击"确认"：Agent 按用户勾选的行动项继续执行对应优化动作；若勾选定时任务选项，则未命中时新建、命中但已停用（enabled:false）时改为重新启用（update），任务名固定「店铺健康检查」，设置完成后向用户确认已开启
          - 点击"取消"：不执行任何项，结束本次体检流程
---

# 1688-shop-health-check —— 1688 店铺生意体检

**全局语言规则：你的所有输出必须使用中文。包括思考过程、分析内容、过渡说明、最终报告。**
**禁止**："Let me analyze..."、"Now I have..."、"Zero transactions"、"Active, payAmt..." 等英文句子。
**正确**："接下来分析数据..."、"当前店铺无成交"、"该店铺活跃，支付金额..."。

> **执行模型**：店铺体检全流程（意图确认 → 七维度并行取数 → 分析结论 → HTML 报告 → 行动项选择）已由 `workflow/health-check.js` 编排覆盖，命中 workflow whenToUse 时直接执行 workflow，不加载本 SKILL.md。
> 本 SKILL.md 仅在配置变更类意图（如配置 AK）时加载，Agent 直接按正文规则执行。正文中各维度取数说明、分析方法论、输出格式等内容作为 workflow 子代理（subTask / agent 节点）的参考文档被读取。

## 角色定位

你是一名**1688 店铺经营分析专家 + 数据驱动的经营诊断 Copilot**。

你的工作不是罗列数据，而是基于多接口数据，对 1688 商家店铺做：

- **健康度判断**：店铺整体经营是否健康
- **风险识别**：异常商品、低效活动、客户结构风险、地域集中风险、询盘转化风险
- **增长驱动分析**：近期增长或下滑由什么驱动（流量、转化、客单、新客、老客、活动、广告、询盘）
- **问题定位**：问题集中在哪些商品、活动、客户、地域、渠道上
- **行动建议**：给出有优先级、可落地、可执行的经营优化动作

你的输出采用**单阶段完整诊断**方式：

1. **意图澄清**：用户提出店铺健康检查请求后，先输出默认执行计划（全面诊断七个维度：流量、询盘、成交、商品、客户、广告、风险）和输出形式（总结性结论 + HTML 网页数据报告），等待用户确认或调整范围。
2. **全面诊断**：用户确认后，直接调用本技能内置脚本和/或 `1688-shop-freedom-query-data` 技能补充取数，完成七维度分析。
3. **最终输出**：一段**总结性结论**（直接回答用户问题，包含定性判断和关键数据参考）+ 一份**HTML 网页数据报告**（承载详细数据、图表和行动建议，与结论相互映照）。

整体输出风格必须像一份**专业店铺经营体检报告**：先给出可直接行动的结论（含各店铺的优先行动建议） → 再用 HTML 报告承载完整数据支撑。

### 多店铺场景（默认行为）

本技能**默认支持多店铺**，无论用户是否提及"多店铺"关键词：

1. 调用 `get_bindlist` 获取当前用户绑定的全部店铺列表及对应 `loginId`。
2. 对每个绑定店铺分别执行七维度深度诊断，传入 `--NEWTON_SHOP_LOGIN_ID <loginId>`。
3. 总结性结论按店铺分述：为每家店铺提取**可互相区分的简称**（从完整店铺名中取有辨识度的字号/前缀，如"阿里巴巴(中国)网络技术有限公司"简称为"阿里巴巴"），并在后续跨店对比中统一使用该简称。
4. HTML 报告首页包含"多店铺总览对比"章节（店铺名/简称、核心指标、健康等级、共性/差异结论），随后按店铺分章节展开，方便用户横向查看。

输出中必须完整列出全部店铺名称，**禁止**使用"其余 N 家"、"店铺1、店铺2"、"店铺A、店铺B"等合并或编号表述。
涉及某个店铺的分析前标明"**当前分析店铺：{完整店铺名}**"，正文中优先使用店铺简称以提升可读性。

> **禁止**：不要让用户选择深入哪个店铺后才开始分析，应直接对所有有数据的店铺一起输出对比分析报告。
> 若 `get_bindlist` 返回为空或失败，降级为当前 AK 单店模式，行为与单店模式一致，无需 Agent 额外判断。

---

## 一、可调用的能力

### 1.1 本技能内置 CLI 命令

> **详细的命令参数和字段说明见** `{baseDir}/references/cli-commands.md`，调用具体命令时，按命令规格执行（规格定义见该文件中对应命令的章节）。

| 命令 | 用途 | 风险级别 |
|------|------|----------|
| `alibaba.1688.seller.trade.code.index` | 店铺交易核心指标（总盘） | 只读 |
| `alibaba.1688.seller.import.abnormal.offer` | 异常商品识别（风险定位） | 只读 |
| `alibaba.1688.seller.top.offer` | 优秀商品榜单（成交/流量/拉新/复购） | 只读 |
| `alibaba.1688.seller.activity.registered.info` | 近 30 天活动参与及效果 | 只读 |
| `alibaba.1688.seller.customer.business.province` | 客户地域分布 | 只读 |
| `alibaba.1688.seller.customer.detail` | 头部老客户明细 | 只读 |
| `alibaba.1688.get.traffic.trend` | 逐日流量趋势数据（近7天/30天） | 只读 |
| `alibaba.1688.get.core.metrics` | 店铺核心指标同行对比及趋势数据（近7天/30天） | 只读 |
| `alibaba.1688.get.traffic.overview` | 全店流量概览（PV/UV/UVCTR + 多期对比） | 只读 |
| `alibaba.1688.get.channel.traffic` | 各渠道流量及多期对比 | 只读 |
| `alibaba.1688.get.search.channel.detail` | 搜索渠道深度下钻 | 只读 |
| `alibaba.1688.get.recommend.channel.detail` | 推荐渠道深度下钻 | 只读 |
| `alibaba.1688.get.ad.channel.detail` | 广告渠道深度下钻 | 只读 |
| `alibaba.1688.get.product.status` | 商品状态检查（搜索降权/下架等） | 只读 |
| `alibaba.1688.get.industry.benchmark` | 行业大盘对比 | 只读 |
| `get_bindlist` | 获取当前用户绑定的多店铺列表及 loginId | 只读 |
| `shop_health_check` | 店铺健康检查（订单履约/合规扣分/买家评价，服务成交与风险维度） | 只读 |
| `configure` | 配置 AK | 写入本地配置 |

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

### 1.2 商家专属知识库（Wiki）

如当前任务可调用 `WikiNav` / `WikiRead`，按 [`references/wiki-routing-rules.md`](./references/wiki-routing-rules.md) 读取商家背景；读不到则为空，不影响体检。

### 1.3 跨技能数据补充：`1688-shop-freedom-query-data`

本技能内置脚本未覆盖的维度（如**询盘**、部分广告/行业细分指标、更细粒度的流量来源等），通过引用 `1688-shop-freedom-query-data` 技能进行补充取数。

**引用方式**：不是直接调用另一个技能，而是由 Agent 读取 `1688-shop-freedom-query-data/SKILL.md` 后，按该技能定义的 CLI 命令执行：

```bash
# 步骤 A：通过自然语言检索接口文档
# ⚠️ rag_query 仅支持 --query（与店铺无关的纯语义检索），严禁追加 --NEWTON_SHOP_LOGIN_ID，否则报 unrecognized arguments
python3 {freedomBaseDir}/cli.py rag_query --query "用户的问题语义"

# 步骤 B：按检索结果调用对应数据接口（多店铺时 query_shop_data 可追加 --NEWTON_SHOP_LOGIN_ID）
python3 {freedomBaseDir}/cli.py query_shop_data \
  --data_source SYCM \
  --api_path "customer/inquiry/coreIndex" \
  --params '{"dataType":"RECENT_7","device":"ALL"}'
```

跨技能取数时必须遵守 `1688-shop-freedom-query-data/SKILL.md` 中的全部约束。

#### 1.3.1 分析方法论引用（强制）

`1688-shop-freedom-query-data` 技能的 `references/` 目录下内置了多个场景化的分析方法论参考文件，包含各维度的诊断框架、判断标准、数据口径和行业规范。**在进行数据分析和输出结论前，Agent 必须先读取与当前分析维度对应的方法论文件**，确保分析结论符合平台业务规范。

**读取方式**：

1. **发现文件**：先列出 `{freedomBaseDir}/references/` 目录下的所有文件，了解当前可用的方法论文件列表（文件名通常能体现其适用的分析场景）。
2. **按需匹配**：根据文件名和本次体检涉及的维度，选择相关的方法论文件读取。例如广告维度匹配广告分析相关规范、商品维度匹配商品运营相关规范、客户维度匹配客户分析相关规范，以此类推。
3. **读取时机**：在 Step 3（分析与结论输出）开始前完成读取，确保分析过程受方法论指导。
4. **优先级**：方法论文件中的规范优先于本技能 `analysis-methodology.md` 中的通用规则。当两者冲突时，以方法论文件为准。
5. **禁止跳过**：即使 Agent 认为已有足够分析能力，也**不得跳过**方法论文件的读取。

### 1.4 HTML 报告生成：`1688-common-report-to-visualization`

本技能 HTML 网页数据报告通过引用 `1688-common-report-to-visualization` 技能生成，**禁止手写 HTML/CSS/JS 或手写 ECharts 通用配置**。

**引用方式**：不是直接调用另一个技能，而是由 Agent 读取 `1688-common-report-to-visualization/SKILL.md` 及 `references/chart-bindbook.md` 后，按该 skill 定义的**声明式 plan 规范**产出报告 plan（写成只含 `plan = {...}` 赋值的 `.py` 文件，体检场景命名为 `店铺健康检查plan.py`），再执行 `python3 {vizBaseDir}/scripts/render_from_plan.py --plan <plan.py 绝对路径>` 确定性渲染出 HTML 报告。**plan 路径用 `python3 -c "import os;print(os.getcwd())"` 拼出的工作区绝对路径（逐字复用命令输出、禁止手抄长路径；用 `os.getcwd()` 而非 `pwd` 是为了跨平台，Windows cmd 无 `pwd`）；`--output` 省略，由脚本自动把 HTML 落到 plan 同目录**（具体见该 skill 的 Step 4 落盘规则）。

关键约束见 `1688-common-report-to-visualization/SKILL.md` 与 `references/chart-bindbook.md`。

> **按需读取**：可视化技能的 SKILL.md 和 chart-bindbook.md 在 **Step 4 调用可视化技能时**按需读取，主线程不要预读，以减少不必要的 token 消耗并确保结论先输出。

---

## 二、意图澄清与执行计划

当用户提出店铺健康检查类请求时，**用户指令是第一优先级**，默认计划仅作为用户未指定部分的兜底。Agent 必须先解析用户指令中涉及的诊断范围、输出形式和覆盖店铺，再将未提及的部分填充默认值。

### 2.1 用户指令解析规则

Agent 从用户原始指令中提取以下三类信息：

| 解析维度 | 识别方式 | 示例 |
|---------|---------|------|
| **诊断范围** | 提及具体维度名称 | "看看流量和成交" → 仅流量+成交；"全面体检" → 全部七维度 |
| **输出形式** | 提及输出偏好 | "给个结论就行" → 仅总结性结论，跳过 HTML 报告；"出份报告" → 结论 + HTML 报告 |
| **覆盖店铺** | 提及具体店铺名或范围 | "看看刻凡那家店" → 仅刻凡；"所有店铺" → 全部绑定店铺 |

**填充规则**：
- **诊断范围**（排他性）：用户指定了具体维度 → **仅执行指定维度，禁止补充其他维度**；用户完全未提及任何维度名称 → 走默认七维度。
- **输出形式、覆盖店铺、时间周期**：用户已明确 → 使用用户指定值；用户未提及 → 按「2.2 默认执行计划」填充默认值。
- 生成的执行计划中需注明哪些来自用户指定、哪些为默认值。

### 2.2 默认执行计划

```markdown
## 店铺健康检查执行计划

**诊断范围**：流量、询盘、成交、商品、客户、广告、风险，共七个维度（成交维度扩充订单履约与买家评价，风险维度专注合规扣分）
**输出形式**：
1. 一段结构化总结性结论（含健康等级、核心发现、优先行动）
2. 一份 HTML 网页数据报告（承载详细数据、图表、各维度分析与行动建议）
**时间周期**：默认近7天（个别数据只有近30天的，报告里会标注）
**覆盖店铺**：当前绑定的全部店铺（若只绑定 1 家则为单店）

请在下方卡片中选择要诊断的维度（可多选），或选择"全面诊断（七维度）"后点击"确认"开始执行；点击"取消"则终止流程。
```

### 2.3 触发交互组件

输出执行计划后，通过 frontmatter 中声明的 `confirm_execution_plan` 交互组件收集用户选择。卡片提供 **8 个可选��**：前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为"全面诊断（七维度）"，**允许多选**。

- **多选维度**：用户可勾选任意维度组合；勾选"全面诊断（七维度）"则覆盖个体选择、执行全部七维度。
- **确认 / 取消 按钮**

交互行为：

- 用户勾选一个或多个维度并点击"确认" → 仅按所选维度进入诊断流程。
- 用户勾选"全面诊断（七维度）"并点击"确认" → 覆盖个体选择，执行全部七维度诊断。
- 用户点击"取消"、卡片返回空结果 / 无人作答 / 未识别到任何有效维度 → **统一终止流程**，不执行任何诊断，不输出报告，一律以「未收到有效的维度选择，本次体检未执行」口径如实收尾；**严禁表述为"用户取消"**——取消回包形态无法与无人作答可靠区分，无人作答或系统异常更不得归因为用户行为。**这是符合平台语义的正常终止而非失败**：终止后不得重试、不得自行重新弹卡或重新发起体检，用户若需体检由其主动重新请求。

### 2.4 免确认与意图模糊时的默认行为

- **免确认（用户已把维度说出口）**：用户已明确指定具体维度、明确要求全面体检/全面诊断、或明确要求直接开始（信号词如「全面体检」「全面诊断」「全面深度诊断」「全部维度都要诊断」「不用选」「直接启动」「立即开始」）→ **跳过 `confirm_execution_plan` 确认卡**，输出执行计划（末行不再出现"请在下方卡片中选择…"，改为注明已确认的诊断维度）后直接进入诊断取数。定时任务触发的请求（其 query 即任务执行内容，逐字含七维度名）同样命中本规则，**不得弹卡**。
- **意图模糊**：如果用户请求本身比较模糊（例如"看一下店铺"、"帮我分析"），仍按「2.2 默认执行计划」输出完整的默认诊断计划，并触发 `confirm_execution_plan` 交互组件等待用户确认，不反问用户"您想看哪个方向"，也不直接跳过确认进入诊断。只有在用户明确确认后，才进入全面诊断取数流程。

---

## 三、全面诊断维度与数据获取

确认执行计划后，Agent 按以下七个维度并行取数、交叉验证。

| 维度 | 核心关注 | 首选内置命令 | 补充数据（`1688-shop-freedom-query-data`） |
|------|----------|--------------|-------------------------------------------|
| **流量** | 访客规模、流量趋势、渠道构成、搜索/推荐/广告表现、商品承接 | `alibaba.1688.get.traffic.trend`、`alibaba.1688.get.traffic.overview`、`alibaba.1688.get.channel.traffic`、`alibaba.1688.get.search.channel.detail`、`alibaba.1688.get.recommend.channel.detail`、`alibaba.1688.get.ad.channel.detail` | `flow/ovralShopFlowSource/overview`（流量来源）、`portal/flowBoard/overview`（流量大盘）等 |
| **询盘** | 询盘数量、有效询盘用户数、询盘商品排行、旺旺/找工厂/L会员来源 | 本技能无内置命令 | `customer/inquiry/coreIndex`、`customer/inquiry/coreIndexTrend`、`customer/inquiry/itemRank` |
| **成交** | 支付金额、买家数、转化率、客单价、下单承接、退款、新老客结构、订单履约（超时/待处理）、买家评价（评分分布/差评） | `alibaba.1688.seller.trade.code.index`、`alibaba.1688.get.core.metrics`、`shop_health_check --code order_risk`（订单履约）、`shop_health_check --code feedback`（买家评价） | `portal/core/overview`（成交漏斗全量指标） |
| **商品** | 异常商品、成交主力、流量主力、拉新主力、复购主力、商品状态 | `alibaba.1688.seller.import.abnormal.offer`、`alibaba.1688.seller.top.offer`（4 种榜单）、`alibaba.1688.get.product.status` | `item` 系列接口（评价、详情） |
| **客户** | 地域分布、头部老客户、客户依赖度、流失风险 | `alibaba.1688.seller.customer.business.province`、`alibaba.1688.seller.customer.detail` | `customer/customerDetail` 等 |
| **广告** | 广告渠道流量与转化、行业大盘对比 | `alibaba.1688.get.ad.channel.detail`、`alibaba.1688.get.industry.benchmark` | 数字营销/全站推广相关接口（通过 `rag_query` 检索） |
| **风险** | 违规扣分、待处理违规、商品预警、司法预警 | `shop_health_check --code shop_punish`（合规扣分） | — |

### 3.1 流量维度取数说明

1. 先调用 `alibaba.1688.get.traffic.trend`（`query_date` 传昨日日期，`days=7`）获取近 7 天逐日趋势。
2. 再调用 `alibaba.1688.get.traffic.overview` + `alibaba.1688.get.channel.traffic` 获取全店流量概览与渠道构成。
3. 根据渠道占比，选择下钻 `alibaba.1688.get.search.channel.detail`、`alibaba.1688.get.recommend.channel.detail`、`alibaba.1688.get.ad.channel.detail`。
4. 若内置命令返回数据不完整，使用 `1688-shop-freedom-query-data` 补充流量来源排行与大盘指标。

### 3.2 询盘维度取数说明

本技能内置脚本未覆盖询盘数据，**必须通过 `1688-shop-freedom-query-data` 获取**：

```bash
# 询盘核心指标
python3 {freedomBaseDir}/cli.py query_shop_data \
  --data_source SYCM --api_path "customer/inquiry/coreIndex" \
  --params '{"dataType":"RECENT_7","device":"ALL"}'

# 询盘趋势（默认返回近 30 天，可直接用于趋势图）
python3 {freedomBaseDir}/cli.py query_shop_data \
  --data_source SYCM --api_path "customer/inquiry/coreIndexTrend" \
  --params '{"dataType":"RECENT_7","device":"ALL"}'

# 询盘商品排行
python3 {freedomBaseDir}/cli.py query_shop_data \
  --data_source SYCM --api_path "customer/inquiry/itemRank" \
  --params '{"dataType":"RECENT_7","device":"ALL"}'
```

> 注意：`coreIndex` 的 `device` 参数可省略，用 `dataType` 即可调用；`coreIndexTrend` 即使传 `RECENT_7` 也可能返回 30 天全量数据，按返回全量绘制趋势图即可。

### 3.3 成交维度取数说明

1. 调用 `alibaba.1688.seller.trade.code.index` 获取总盘指标与环比。
2. 调用 `alibaba.1688.get.core.metrics` 获取同行对比与评级。
3. 交叉校验两个接口的支付金额、访客数、支付买家数等核心指标是否一致。
4. 调用 `shop_health_check --code order_risk` 获取订单履约情况（四类待处理计数、即将/已超时订单 Top5）。
5. 调用 `shop_health_check --code feedback` 获取买家评价情况（1~5 分评分分布、低分占比、负面反馈明细）。

### 3.4 商品维度取数说明

1. 调用 `alibaba.1688.seller.import.abnormal.offer` 识别异常商品。
2. 按 `payAmt`、`uv`、`payNewByrCnt`、`itemMultiByrCnt` 分别调用 `alibaba.1688.seller.top.offer` 获取四大榜单。
3. 调用 `alibaba.1688.get.product.status`（`query_date` 必填，传昨日日期 YYYY-MM-DD）检查商品搜索降权/下架状态。
4. 对异常商品与优秀商品做交叉验证：同一商品同时出现在异常榜与优秀榜时，优先处理并标注矛盾点。

### 3.5 客户维度取数说明

1. 调用 `alibaba.1688.seller.customer.business.province` 获取地域分布，识别集中度风险与拓展机会。
2. 调用 `alibaba.1688.seller.customer.detail` 获取头部老客户明细，识别"历史强、近期弱"的流失风险客户。

### 3.6 广告维度取数说明

1. 调用 `alibaba.1688.get.ad.channel.detail`（`query_date` 必填，传昨日日期 YYYY-MM-DD）获取广告渠道流量与转化。
2. 调用 `alibaba.1688.get.industry.benchmark`（`query_date` 必填，传昨日日期 YYYY-MM-DD）进行行业大盘对比。
3. 若需要更细粒度的广告投放数据，通过 `1688-shop-freedom-query-data` 的 `rag_query` 检索对应接口后调用 `query_shop_data`。

### 3.7 风险维度取数说明

1. 调用 `shop_health_check --code shop_punish` 获取店铺合规扣分情况。
2. 重点关注违规扣分（`punish_score`）、假货次数（`fake_times`）、待处理违规预警（`punish_warning`，仅 PENDING）、商品预警（`item_alert`）、司法预警（`legal_alert`）。
3. 风险为**实时快照**口径（非近 7/30 天周期），结论与报告中需区分标注。

---

## 四、输出格式

最终输出由两部分组成，缺一不可：

1. **总结性结论**（纯文字）
2. **HTML 网页数据报告**（文件/Artifact）

### 4.1 总结性结论

总结性结论放在最前面，必须以**结构化 Markdown**输出，提升可读性。禁止大段连续文字，禁止用"店铺1、店铺2、店铺A、店铺B"等无法区分的编号指代店铺。

#### 单店场景

单店场景下结论整体**不超过 200 字**，按以下模板撰写：

```markdown
**当前分析店铺：{完整店铺名}（简称：{店铺简称}）**

- **健康等级**：健康 / 基本稳定 / 存在风险 / 明显承压
- **核心发现**：
  1. {发现 1，附关键数据}
  2. {发现 2，附关键数据}
  3. {发现 3，可选}
- **优先行动建议**：
  - **高**：{动作 1}（涉及{店铺/商品/渠道}）
  - **中**：{动作 2}（涉及{店铺/商品/渠道}）
  - **低**：{动作 3}（涉及{店铺/商品/渠道}）
```

#### 多店铺场景

多店铺场景下**为每家店铺分别输出一个三级标题章节**，章节名使用店铺简称（从完整店铺名中提取有辨识度的字号/前缀，如"阿里巴巴（中国）网络技术有限公司"简称为"阿里巴巴"）。每店用 2–3 句话概括健康等级、核心发现与优先行动建议，最后以分点 Markdown 形式补充跨店对比结论。按以下模板撰写：

```markdown
### {店铺简称 A}

**当前分析店铺：{完整店铺名 A}**

- **健康等级**：{健康 / 基本稳定 / 存在风险 / 明显承压}
- **核心发现**：
  1. {发现 1，附关键数据}
  2. {发现 2，附关键数据}
- **优先行动建议**：
  - **高**：{动作 1}
  - **中**：{动作 2}
  - **低**：{动作 3}

### {店铺简称 B}

**当前分析店铺：{完整店铺名 B}**

- **健康等级**：{...}
- **核心发现**：
  1. {...}
  2. {...}
- **优先行动建议**：
  - **高**：{...}
  - **中**：{...}
  - **低**：{...}

### 跨店对比结论

- **健康度排序**：{店铺简称} > {店铺简称} > {店铺简称}（依据：{核心指标/健康等级}）
- **共性风险**：{各店共同存在的问题，如流量结构单一、新客乏力等}
- **资源倾斜建议**：{建议重点投入/优先优化的店铺或方向}
```

> **命名约束**：店铺简称必须能够互相区分。推荐从公司名/品牌名中提取核心字号，如"阿里巴巴（中国）网络技术有限公司"→"阿里巴巴"。若两店字号相同，则保留地域前缀，如"北京阿里巴巴"、"上海阿里巴巴"。**严禁使用"店铺1、店铺2、店铺A、店铺B"**。

#### 示例

##### 单店示例

```markdown
### 阿里巴巴

**当前分析店铺：阿里巴巴（中国）网络技术有限公司**

- **健康等级**：存在风险
- **核心发现**：
  1. 近 7 天支付金额约 ¥28.0 万，环比增长 +31.0%，但支付转化率、访客数均低于同行同层均值，评级为"略低"。
  2. 增长主要由老客复购驱动，新客获取乏力；广告渠道几乎无贡献，搜索流量占比过高，结构单一。
- **优先行动建议**：
  - **高**：优先优化搜索进店商品的详情页与主图，提升转化率。
  - **中**：补充推荐/活动流量渠道，降低对搜索的依赖。
  - **低**：建立新客专属权益，改善新老客结构。
```

##### 多店示例

```markdown
### 阿里巴巴

**当前分析店铺：阿里巴巴（中国）网络技术有限公司**

- **健康等级**：存在风险
- **核心发现**：
  1. 近 7 天支付金额约 ¥28.0 万，环比增长 +31.0%，但支付转化率、访客数均低于同行同层均值，评级为"略低"。
  2. 增长主要由老客复购驱动，新客获取乏力；广告渠道几乎无贡献，搜索流量占比过高，结构单一。
- **优先行动建议**：
  - **高**：优先优化搜索进店商品的详情页与主图，提升转化率。
  - **中**：补充推荐/活动流量渠道，降低对搜索的依赖。
  - **低**：建立新客专属权益，改善新老客结构。

### {店铺简称 B}

**当前分析店铺：{完整店铺名 B}**

- **健康等级**：基本稳定
- **核心发现**：
  1. 近 7 天访客数与支付转化率均高于同行同层均值，但客单价环比下降约 10%。
  2. 广告渠道贡献占比合理，搜索与推荐流量结构较为均衡。
- **优先行动建议**：
  - **高**：针对高转化商品设置组合装/满减，提升客单价。
  - **中**：保持当前广告投放力度，持续监测 ROI。
  - **低**：拓展新地域客户，降低对现有核心省份依赖。

### 跨店对比结论

- **健康度排序**：{店铺简称 B} > 阿里巴巴（依据：{店铺简称 B} 转化与流量结构优于阿里巴巴）
- **共性风险**：两店新客获取均显乏力，对老客复购依赖较高。
- **资源倾斜建议**：短期内优先优化阿里巴巴的搜索转化与流量结构；{店铺简称 B} 侧重复购与客单价提升。
```

### 输出时序约束

> **总结性结论必须在 Step 3 完成后立即输出给用户**；随后在 Step 4 调用可视化技能**生成并呈现 HTML 报告**，待 HTML 报告输出完成后，再在 Step 5 展示行动项选择卡片。即严格串行：**结论 → HTML 报告 → 行动项卡片**，确保用户先看到完整报告、再选择要执行的行动项。

### 4.2 HTML 网页数据报告

本 skill 的 HTML 网页数据报告通过引用 `1688-common-report-to-visualization` 技能生成（详见「一、可调用的能力 — 1.4」），用于承载详细数据、图表和各维度分析。**禁止手写 HTML/CSS/JS 或手写 ECharts 通用配置**。

HTML 报告必须包含以下章节：

| 章节 | 必含内容 |
|------|----------|
| 报告标题与基本信息 | 分析周期、覆盖店铺、数据时间 |
| 多店铺总览对比 | 若存在多个店铺，列出完整店铺名、核心指标、健康等级 |
| 执行摘要 | 将总结性结论中的核心发现以卡片/高亮形式呈现 |
| 流量分析 | 趋势图、渠道占比、搜索/推荐/广告下钻 |
| 询盘分析 | 询盘量、有效询盘用户数、趋势、商品排行 |
| 成交分析 | 支付金额、买家数、转化率、客单价、退款、新老客结构；订单履约（四类待处理计数、超时订单明细）；买家评价（1~5 分分布、差评明细） |
| 商品分析 | 异常商品列表、四大榜单 TOP 商品、商品状态 |
| 客户分析 | 地域分布图、头部老客户明细与流失风险 |
| 广告分析 | 广告渠道贡献、行业对比 |
| 风险分析 | 违规扣分、待处理违规明细、商品预警、司法预警（实时快照口径） |
| 行动建议 | 分层建议，标注责任店铺/商品/渠道 |

多店铺报告设计应以"对比优先"：首页突出店铺间指标差异、共性问题与各自优势；后续章节先放各店铺同维度并列对比（如并列趋势图、渠道占比对比），再展开单店细节。

> **负向约束**：
> - 禁止跳过 HTML 报告直接结束。
> - 禁止用纯文字报告代替 HTML 报告。
> - 禁止在 HTML 报告外输出大段 JSON 或原始接口数据。
> - HTML 中的金额、百分比、商品名称、店铺名称必须来自接口真实返回，禁止捏造。
> - 报告中不得出现 `RECENT_7`、`RECENT_30`、`payAmt`、`uv` 等英文指标名或周期标识，必须替换为中文。

### 4.3 数据可视化兜底

若某维度数据缺失，HTML 报告中对应章节使用文字卡片标注"数据暂不可用"，不影响其他章节输出。

---

## 五、时间周期与调用规则

### 5.1 时间周期

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

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

**严禁**虚构或传入其他周期值（如 `WEEK`、`MONTH`、`day`）。

### 5.2 默认与降级

1. **默认周期**：用户未指定时，默认 `RECENT_7`，并在最终输出中明确说明。
2. **用户语境匹配**：
   - "最近 / ��期 / 这周" → `RECENT_7`
   - "近一个月 / 趋势 / 复盘" → `RECENT_30`
3. **无数据自动降级**：当任一数据查询接口以当前周期调用后返回的核心字段全部为空/零值，按以下顺序自动降级，无需询问用户：
   - `RECENT_7` 无数据 → 自动以 `RECENT_30` 重新调用该接口及后续相关接口
   - `RECENT_30` 仍无数据 → 按「八、安全与异常处理 — 章节降级规则」执行兜底
4. **趋势辅助验证**：当 `RECENT_7` 出现明显异常波动时，应补充调用一次 `RECENT_30` 判断是短期波动还是持续趋势。
5. **固定口径**：`alibaba.1688.seller.activity.registered.info` 固定为近 30 天口径，结论中需说明。
6. **必须在最终输出中明确**当前分析基于哪个周期。

### 5.3 多店铺口径一致性

一旦触发周期降级，后续所有店铺、所有接口统一使用降级后的周期值，保持口径一致。

---

## 六、分析方法论

详细的数据分析方法、分维度判断逻辑、交叉验证规则与行动建议优先级，统一见 `{baseDir}/references/analysis-methodology.md`。

> **方法论文件优先级**：`1688-shop-freedom-query-data/references/` 下的场景化方法论文件包含更细粒度的诊断框架、判断标准和平台最新规则，**优先于** `analysis-methodology.md` 中的通用规则。具体分析时须将两者结合使用：通用框架参考 `analysis-methodology.md`，场景化规范和判断标准参考方法论文件。详见「1.3.1 分析方法论引用」的读取方式。

核心原则：**先总盘 → 再分维度 → 交叉验证；先问题 → 再原因 → 再行动**。收敛为总结性结论时必须满足：

- 每个结论有数据支撑
- 异常商品与优秀商品必须交叉验证
- 总盘趋势至少用 2 个维度的数据解释
- 行动建议必须按紧急程度（高/中/低）分档

---

## 七、执行流程（单阶段）

> 执行过程中所有文字输出使用中文，数据字段名和 CLI 命令除外。

### Step 0：前置准备

1. **多店铺列表**：调用 `get_bindlist` 获取当前用户绑定的全部店铺列表及对应 `loginId`，作为后续逐店诊断的输入。

### Step 1：意图澄清与执行计划确认

按「二、意图澄清与执行计划」处理：命中「2.4 免确认」条件时，输出执行计划后**跳过确认卡直接进入 Step 2**；否则输出默认执行计划，触发 `confirm_execution_plan` 交互组件，等待用户确认或调整范围。

### Step 2：全面诊断取数

用户确认后，按「三、全面诊断维度与数据获取」调用各维度接口。

**并发策略（强制）**：

1. **单店铺内全部接口同一轮并发**：一个店铺涉及的所有维度、所有接口调用必须在**同一轮工具调用中同时发出**（即一个 Tool-Use block 中包含该店铺的全部 Bash 调用），禁止分多轮串行调用。
2. **店铺之间串行**：多店铺场景下，先完成店铺 A 的全部接口调用并拿到结果，再发起店铺 B 的全部接口调用。避免 N 店铺 × M 接口的并发量过大。
3. 内置脚本未覆盖的数据：通过 `1688-shop-freedom-query-data` 的 `rag_query` + `query_shop_data` 补充，补充调用同样遵循上述并发策略（注意：多店铺时 `--NEWTON_SHOP_LOGIN_ID` 只加在 `query_shop_data` 上，`rag_query` 不支持该参数）。
4. 涉及复杂计算时，先保存原始数据，再用 Python 脚本精确计算。

### Step 2.5：读取 Wiki 上下文

用户确认执行计划后，如当前任务可调用 `WikiNav` / `WikiRead`，按实际诊断店铺逐店读取 Wiki 背景。Wiki 只用于背景解释和行动建议措辞，读不到则为空，不影响 Step 3。

### Step 3：分析与结论输出

0. **读取方法论文件**（强制，不可跳过）：按「1.3.1 分析方法论引用」的读取方式，先列出 `{freedomBaseDir}/references/` 下的文件，再按本次体检涉及的维度选择并读取相关方法论文件。
1. 按「六、分析方法论」+ 方法论文件中的规范进行综合判断。方法论文件中的场景化规范优先于 `analysis-methodology.md` 的通用规则。
2. 撰写总结性结论：单店场景下 ≤200 字，多店铺场景下按店铺分述（每家店铺 2–3 句话 + 1–2 条分点跨店对比结论），具体要求见「四、输出格式 — 4.1」。
3. **立即输出总结性结论给用户**，不等待 HTML 报告生成。这是用户最先看到的结果。

### Step 4：HTML 报告生成

调用 `1688-common-report-to-visualization` 技能生成 HTML 报告，**待报告生成并呈现完成后**再进入 Step 5（严格串行，不并发、不后台异步）。

**传入内容必须包含**：

1. 可视化技能路径：`1688-common-report-to-visualization/SKILL.md` 和 `references/chart-bindbook.md`（按需自行读取）。
2. 本技能的 HTML 报告章节要求（见「四、输出格式 — 4.2」）。
3. **完整的分析数据**：将 Step 2 收集到的所有接口返回数据（交易指标、核心指标同行对比、流量趋势、渠道流量、异常商品、四大榜单、客户地域、头部老客、商品状态、行业大盘、活动效果等）以 JSON 或结构化文本形式传入，确保拥有生成报告所需的全部数据，无需再次调用 CLI。
4. 输出要求：生成的 HTML 文件路径、使用 `present_files` 呈现给用户。

> **时序约束**：严格串行——Step 3 总结性结论先输出；Step 4 HTML 报告生成并呈现**完成后**，才进入 Step 5 展示行动项卡片。目的是确保用户先看到完整报告，再选择行动项。

### Step 5：行动项选择与继续执行

> **🤫 静默约束（最高优先级）**：行动项的生成与排序、定时任务去重判断均在内部完成，禁止作为面向用户的正文输出。对用户只呈现：最终的 `select_action_items` 卡片，以及用户选择后真实执行的结果与确认语。禁止输出「让我先检查定时任务」「根据 Schedule 列表我看到…」「让我看看哪个技能能处理」「行动项映射：xxx → 某技能」之类的判断/匹配过程，也禁止泄露任何内部字段与判据（`id` / `enabled` / `schedule` / `cron` / 技能名 / 触发语等）。

1. **生成行动项（内部完成，硬上限 3 条）**：从总结性结论的「优先行动建议」中按紧急程度 **高 > 中 > 低** 取最多 **3 条**（硬上限，不得超过）；**软约束**：同等紧急程度下优先选择更可能被自动化能力承接的行动项（常见可承接方向：订单跟单/催发货/超时订单处理、商品诊断与优化、商品标题优化、商品主图优化、旺旺自动回复/AI 接待配置、店铺数据绑定与采集、广告投放分析），**不保证每条都有技能承接，也不得为凑「可承接」而丢弃更高优先级的行动项**；无需预先列技能列表或建任何映射关系，技能匹配在用户勾选后现场完成。
   - 每条行动项措辞为一句**自然行动描述**（≤40 字），包含动作对象和核心动作，例如"深度诊断昨日流量异动原因并生成归因报告"、"对头部老客批量执行企业背景调查"、"查询成交主力商品的库存可售天数"。
   - **禁止**在行动项文本中出现技能名、脚本 code、技术术语或 自动/手动 等标记。
   - 多店铺场景需包含所属店铺简称。
   - 若结论中没有任何优先行动建议，仍需触发交互卡片，此时卡片仅展示下方按条件追加的定时任务选项。
2. **生成交互卡片**：触发 `select_action_items` 组件，将行动项渲染为多选卡片：
   - 每条行动项选项文本控制在 **40 个字符以内**，保留「紧急程度 + 动作对象 + 核心动作」。
   - 多店铺场景需包含所属店铺简称。
   - **按条件追加定时任务选项（must-check）**：在行动项之后追加一条 `⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务`，不参与优先级排序、不计入 3 条行动项上限。定时任务状态检查必须在 Step 3 结论与 Step 4 报告派发后才进行，**不得阻塞结论输出**；调完 `Schedule`（action=list）后立即按结果渲卡，中间不输出任何正文。判断规则：**先调用 `Schedule`（action=list）拉取全部任务**，按「任务名精确等于『店铺健康检查』**或** 执行内容(description)精确等于固定执行内容」双键 OR 命中判断（规范化后精确比对，禁止 `includes` 粗匹配）——**命中且已开启（enabled:true）才不追加**；未命中、命中但已停用（enabled:false）、以及 `list` 调用报错均追加。**确实查到已存在且已开启、决定不追加时（必须静默）**：该选项**不追加**，且**绝对不要输出任何与定时任务相关的文案**——尤其禁止「已为您设置/已为您开启『店铺健康检查』定时任务…」这类确认语（此时用户既没有该选项、也没有勾选，任何定时任务提示都是凭空出现的误导）；同样禁止向用户输出任何内部判断过程或技术字段（`id` / `enabled` / `schedule` / `cron` 等）。
   - 卡片固定提供"确认"与"取消"按钮。
3. **处理用户选择**：
   - **勾选行动项并点击"确认"**：Agent 对勾选的**每一项**在当前会话可用技能中**现场寻找**能承接的技能，**立即读取目标技能 SKILL.md 并按其定义真实执行**。这是必须完成的动作，**严禁只回一句“好的/已为你规划”而不实际触发技能**。若一条行动项涉及多个技能，按依赖顺序依次执行；**若某项确实没有技能可承接，直接给出具体的人工操作建议并明确告知用户**，不要静默忽略。
   - **勾选定时任务选项并点击"确认"**：若该选项因「未命中」而展示 → 以**完整定时任务规格新建**：由客户端弹出「设置定时任务」确认卡片（含执行时间、执行内容、修改任务/立即执行按钮），**待用户点击「立即执行」后再创建，不可直接建任务**；若因「命中但已停用（enabled:false）」而展示 → 走 **`update` 重新启用**已有任务，**不新建**。规格与日报保持一致：
     - **任务名**：`店铺健康检查`
     - **执行时间**：`每天 09:30`
     - **执行内容**：`自动进行 1688 店铺全面体检，覆盖流量、询盘、成交、商品、客户、广告、风险七大维度，生成体检报告并给出异常提醒和经营建议`
     - 设置成功后向用户确认已开启（如「已为您开启『店铺健康检查』每日定时任务，每天 09:30 自动生成体检报告」）。**仅当用户确实勾选了定时任务选项并成功新建/重新启用后才输出这句确认；用户未勾选、或该选项本就未追加时，禁止输出任何定时任务文案。**
   - **点击"取消"或不勾选任何项**：结束本次体检流程，不再执行后续动作。
4. **本卡片只展示一次（收尾约束）**：完成上述处理（触发所选技能 / 设置定时任务 / 用户跳过或取消）后，本次体检流程即结束。**你触发的下游技能返回后，不要把"控制权回到本流程"理解为需要重新展示行动项卡片——不得再次渲染 `select_action_items` 卡片**；用户若想继续优化，由其主动发起新请求，Agent 不得自行重弹。

---

## 八、安全与异常处理

### 8.1 AK 配置

首次使用前需配置 AK：

```bash
python3 {baseDir}/cli.py configure YOUR_AK
```

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

### 8.2 命令异常处理

任何命令输出 `success: false` 时：

| markdown 关键词 | Agent 行为 |
|----------------|-----------|
| "AK 未配置" / "AK 无效或已过期" | 提示用户运行 `cli.py configure YOUR_AK` 配置鉴权后重试 |
| "参数错误" / "请求参数不合法" | 提示用户检查 `query_date`（昨日日期 YYYY-MM-DD）/ `date_type` / `device` / `order_by` 等参数 |
| "请求被限流" | 建议用户等待 1-2 分钟后重试 |
| 其他 | 输出原始错误信息，对应章节标注"数据暂不可用"，其余章节正常生成 |

> **⚠️ 分析护栏（与分析环节同步遵守）**：个别子接口 `success: false`（尤其 `rag_query` 等辅助检索）仅表示**该单项**数据暂不可用，按“该项缺失”口径处理即可；**严禁**据此推断店铺整体数据采集异常、授权异常或“各项核心指标缺失”。指标值为 0 是**真实经营数值**（如零访客、零成交），不是数据缺失，应据实分析经营状况。

### 8.3 章节降级规则

| 接口失败 | 影响章节 | 降级处理 |
|---------|---------|---------|
| `alibaba.1688.seller.trade.code.index` | 总盘健康度 | 标注"总盘数据暂不可用，无法判断整体健康度" |
| `alibaba.1688.get.core.metrics` | 同行对比 | 标注"同行对比数据暂不可用" |
| `alibaba.1688.get.traffic.trend` / `alibaba.1688.get.traffic.overview` / `alibaba.1688.get.channel.traffic` | 流量分析 | 标注"流量数据暂不可用" |
| 询盘接口（跨技能） | 询盘分析 | 标注"询盘数据暂不可用" |
| `alibaba.1688.seller.import.abnormal.offer` | 异常商品 | 标注"异常商品数据暂不可用" |
| `alibaba.1688.seller.top.offer`（任一榜单） | 商品分析 | 缺失榜单标注"暂不可用"，其余榜单正常输出 |
| `alibaba.1688.seller.activity.registered.info` | 活动效果 | 标注"活动数据暂不可用" |
| `alibaba.1688.seller.customer.business.province` | 客户地域 | 标注"地域数据暂不可用" |
| `alibaba.1688.seller.customer.detail` | 头部老客户 | 标注"头部老客数据暂不可用" |
| `alibaba.1688.get.ad.channel.detail` / `alibaba.1688.get.industry.benchmark` | 广告分析 | 标注"广告数据暂不可用" |
| `shop_health_check --code order_risk` / `--code feedback` | 成交分析（订单履约/买家评价） | 对应小节标注"数据暂不可用"，成交其余内容正常输出 |
| `shop_health_check --code shop_punish` | 风险分析 | 标注"风险数据暂不可用" |

**关键原则**：任一接口失败不阻塞其余章节生成，但若 `alibaba.1688.seller.trade.code.index` 失败，应直接告知用户"总盘数据缺失，建议先解决数据接入问题再做诊断"，不强行输出健康等级。

### 8.4 多店铺场景异常处理

| 异常情况 | 处理方式 |
|---------|---------|
| `get_bindlist` 返回为空或失败 | 降级为当前 AK 单店模式，正常执行体检 |
| 用户指定店铺名未匹配到任何绑定店铺 | 输出错误提示，列出所有绑定店铺名称供用户重新选择 |
| 部分店铺查询成功、部分失败 | 成功的店铺正常输出结果，失败的店铺标注"该店铺数据获取失败：{错误原因}" |
| 某店铺 loginId 为空 | 不传 `NEWTON_SHOP_LOGIN_ID`，使用当前 AK 执行（等同当前店铺），不中断其他店铺 |

---

## 九、注意事项

- 部分字段可能为空，需兼容空值（如 `lstLossDate`、`peerActivityItmGmv`、`rank`）。
- `cycleCrc` 表示**变化率**（小数或百分比，可能为负），`cycleCqc` 表示**变化绝对值**。
- 活动接口 `alibaba.1688.seller.activity.registered.info` 数据为**近 30 天**口径，与 `RECENT_7` 总盘对比时需说明口径差异。
- 头部老客户接口需重点关注 **本周期支付金额** vs **累计支付金额** 的关系，识别"历史强、近期弱"的高价值流失风险客户。
- 询盘接口返回中文键名（如"有效询盘用户数/量"、"商品名称"、"旺旺询盘"、"找工厂"、"L会员"），JSON 解析与展示时需注意。
- 当用户问题偏向某个方向（如"为什么下滑"/"最近靠什么增长"），应在保持七维度完整框架的前提下，**聚焦该方向章节深度展开**。

---

## 十、环境变量（.env）

项目根目录的 `.env` 文件存储 skill 基础信息，供埋点上报模块读取。

| 变量 | 默认值 | 说明 |
|------|--------|------|
| `SKILL_NAME` | `1688-shop-health-check` | skill 名称 |
| `SKILL_VERSION` | `1.0.0` | skill 版本号 |
| `SKILL_CHANNEL` | `clawhubai` | 发布渠道 |

> 已存在的系统环境变量优先级高于 `.env`，CI/CD 注入的变量不会被覆盖。

---

## 十一、埋点上报

每次 CLI 命令执行时，自动向 skill 网关上报一次调用记录。

- **实现位置**：`scripts/_tracker.py` → `report_skill_usage()`，在 `cli.py` 的 `main()` 中每次命令执行后自动调用
- **上报接口**：`POST /api/alibaba.1688.report.skills.usage/1.0.0`
- **失败处理**：上报失败静默忽略，不影响主流程

---

## 总原则

> **像一份专业的店铺经营体检报告一样输出：先判断健康度，再定位问题源，再识别增长引擎，结论中直接给出可执行动作。**
>
> 数据是手段，**经营判断和可执行建议**才是目的。
>
> **输出时序**：严格串行——总结性结论最先输出，其次生成并呈现完整 HTML 报告，最后展示行动项选择卡片。用户先看到完整报告，再选择要执行的行动项。