shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 数据与分析需要 API Key

店客多外卖品牌/门店诊断及数据分析

店客多门店/品牌分析数据报表技能。生成 9 种经营报表（门店对齐 / 门店单平台 / 品牌 × 日/周/月）+ 近N天智能分析 + AI 深度诊断回填闭环。当用户说"XX门店数据怎么样"、"分析XX门店/XX品牌日报周报月报"、"生成报表/一键生成"、"近7天数据分析"、"报表AI诊断回填"、"XX品牌经营分析"时使用。

person作者: user_6edddaf4hubcommunity
download下载资源包

dkd-brand-data-analysis - 门店/品牌分析数据报表技能

三份文档分工（优先级声明）：本文件 SKILL.md = 唯一权威规范（怎么干，冲突时一律以本文件为准）；AGENTS.md = 多工具操作速查（前置配置/脚本/路由/输出）；CLAUDE.md = Claude Code 快速上手。文档间以本文件为准，改动须三处同步。

0️⃣ ⚡ 执行索引（AI 首屏定位 · 先看这里）

| 用户需求 | 入口 | |---|---| | 任何需求先拆解（时间/主体/维度/TOP 提取 → 多平台并列拆 N 个查询） | 「5.3 🧩 需求拆解逻辑」（强制 · 接收需求第一动作） | | 报表（门店/品牌/平台 × 日/周/月、近N天、自定义区间） | 「5️⃣ 报表体系」 → 对应 generate_* 一键脚本（命令唯一来源） | | 平台门店诊断（"诊断XX门店/帮我诊断店铺"） | 「1️⃣4️⃣ 门店诊断」 → generate_platform_diagnose.py 取数（独立脚本） + 平台诊断文档判定（场景②专属流程） | | 实时/TOP/增长/评价/自定义分析（报表与诊断之外） | 「8️⃣ 接口编排」 → extend_query.py --action / chain_business.py 现场编排 | | 输出规范（五段式/卡片/打开页面/深度完整性） | 「7️⃣ 输出规范」（所有分析强制） | | 数据口径 / 判定字段映射 | 「1️⃣1️⃣ 数据口径」 + 美团/淘宝诊断文档顶部「0️⃣ 诊断判定字段映射表」 |

2️⃣ 🔀 一键优先路由（强制执行 · 最高优先级 · 先于一切流程）

任何报表/分析需求，生成前先判定属于哪一类场景（三类互斥、不得混淆），再按对应路径执行：

| 场景类别 | 识别信号（用户怎么说） | 执行路径（唯一正确做法） | |---|---|---| | ① 9 大报表生成 | 门店/品牌/平台 + 日报/周报/月报/近N天/自定义区间 | 直接跑对应 generate_* 一键脚本（命令见「5️⃣ 报表体系」，参数按「AI 执行规则」填入，零自写代码、零现场编排） | | ② 平台门店诊断 | "诊断XX门店 / 帮我诊断店铺"（提到美团/淘宝/闪购按平台路由） | 走 「1️⃣4️⃣ 门店诊断」专属流程：①search_shops(shop_name=店名关键词, platform=平台) 取 shopUniqueKey（如 "1_17822902671"，仅 1 家时直接用；多家时让用户选）→ ②取数与渲染共用 shopUniqueKey：generate_platform_diagnose.py --shop-id <shopUniqueKey> --platform P --days N 取数（独立诊断脚本 · 与周报完全分离）→ ③render_diagnosis.py --shop-id <shopUniqueKey> --platform P --days N --widget 渲染（同一 shopUniqueKey 直接复用，不重复查门店）→ ④读 diagnostic_data.json 按对应平台诊断文档七维度判定——不属 9 类报表、不现场编排 | | ③ 其他分析 | 上述两类之外的任意需求（实时TOP/增长排行/评价归因/分平台对比/自定义编排…） | 用 extend_query.py --action（高频已封装，仅取数）或 chain_business.py 现场编排（见「8️⃣ 接口编排」） |

🚫 禁止条款（DO NOT）：

  • 禁止为 9 类覆盖范围内的需求自写/复制编排脚本——generate_* 已内置环比对比期、商圈排名、门店等级分档、健康体检、6 层诊断框架、趋势图
  • 禁止把「平台门店诊断」当普通报表或现场编排处理——诊断必须走「1️⃣4️⃣」专属流程
  • 禁止改写 generate_* 脚本本体（需要新报表形态 → 走「8️⃣ 接口编排」产出 HTML/文字，不改标准脚本）
  • 禁止命中 9 类时用 extend_query / chain_business 现编替代一键脚本

⚠️ 反面案例：生成「XX品牌 2026年7月 品牌月报」时，绕过 generate_brand_report.py，自写脚本 → 缺环比对比期/商圈/分档。9 类场景 = 一键脚本；平台门店诊断 = 专属诊断流程，没有例外。

3️⃣ 前置配置与安装

Token 配置 / 多工具适配 / 上手引导：详见 AGENTS.md「前置配置」与本节末段速查。

独立配置（强制）：scripts/config.json 存放接口地址与 Token，不硬编码在脚本中（缺失/占位符时引导填写）：

{ "mcp_url": "https://api.diankeduo.net/chain/business/mcp", "mcp_token": "<客户Token>" }

Token 三级优先级：环境变量 CHAIN_MCP_TOKEN（临时覆盖）→ config.json → 无兜底（缺失引导填写）。 缓存指纹：.cache/shop_list_<平台>_<token_fp>.json 绑定 Token 指纹，换 Token 自动失效重拉，无需 action=clear_cache。

多工具适配：Trae / Qoder / Codex / Cline → 自动读 AGENTS.md；Cursor → AGENTS.md + CLAUDE.md；Claude Code → CLAUDE.md；MCP 直连见 mcp.example.json（Streamable HTTP + Bearer）。

上手引导：Token 配置成功后自然语言提问即用，例：分析 XX门店 昨天 / XX品牌 本月经营数据 / XX门店 美团 近7天数据。

4️⃣ 目录结构

dkd-brand-data-analysis/
├── SKILL.md / AGENTS.md / CLAUDE.md       # 文档（SKILL.md 为唯一权威）
├── mcp.example.json                        # MCP 注册示例
├── 接口能力与应用场景.md / 用户场景话术库.md  # 接口编排 + 话术路由
├── 美团门店诊断逻辑.md / 淘宝门店诊断逻辑.md   # 平台诊断体系（按平台按需读）
├── docs/                                   # 输出规范参考 / 接口编排 / 报表特性
├── scripts/
│   ├── config.json                         # 独立配置（换 Token 改这里）
│   ├── chain_business.py                   # MCP 接口封装（含缓存与异常处理）
│   ├── check_token.py                      # Token 检查 + 上手引导
│   ├── extend_query.py                     # 接口编排 5 个高频示例
│   ├── generate_{store,platform,brand}_{daily,weekly,monthly}.py  # 9 大报表
│   ├── chart.umd.min.js / echarts.min.js   # 图表库（Chart.js + ECharts）
│   ├── .cache/                             # 门店列表缓存（Token 指纹绑定）
│   ├── assets/logos/                       # 平台 Logo PNG
│   ├── templates/                          # 诊断模板 HTML
│   └── ai_diagnosis_*.json                 # AI 诊断文件（脚本同目录）
└── examples/                               # 诊断 JSON 格式示例

诊断文件放哪：ai_diagnosis_{门店/品牌}_{daily/weekly/monthly}.json 一律放在 scripts/（脚本同目录）。

5️⃣ 报表体系（9 种 + 近N天 + 自定义）· 命令唯一来源

本节是全部报表命令的唯一权威来源；「6️⃣ 核心工作流」与「13️⃣ 9报表诊断场景」只引用本节，不重复命令。

5.1 报表一览表（运行于技能根目录）

| 报表 | 脚本 | 周期 | 对比口径 | |------|------|------|----------| | 门店对齐日报 | python scripts/generate_store_daily.py --shop X [--brand Y] | 昨天（或 --date） | 较前日 + 较上周同期 | | 门店对齐周报 | python scripts/generate_store_weekly.py --shop X [--brand Y] | 自然周（周一~周期末） | 较上周 + 同比 | | 门店对齐月报 | python scripts/generate_store_monthly.py --shop X [--brand Y] | 自然月 | 较上月 | | 品牌日报 | python scripts/generate_brand_daily.py --brand <客户品牌> | 昨天 | 较上周同期 | | 品牌周报 | python scripts/generate_brand_weekly.py --brand <客户品牌> | 自然周 | 较上周 | | 品牌月报 | python scripts/generate_brand_report.py --brand <客户品牌> | 自然月 | 较上月 | | 门店单平台日报 | python scripts/generate_platform_daily.py --shop X --platform P | 昨天（或 --date） | 较上周同期 | | 门店单平台周报 | python scripts/generate_platform_weekly.py --shop X --platform P | 自然周 | 较上周 | | 门店单平台月报 | python scripts/generate_platform_monthly.py --shop X --platform P | 自然月 | 较上月 | | 近N天分析 | python scripts/generate_store_weekly.py --shop X --days N（品牌：--brand X --days N；平台：--shop X --platform P --days N） | 昨日往前推 N 天 | 往前推 N 天 | | 自定义日期范围 | 对应周报脚本 + --start YYYYMMDD --end YYYYMMDD | [start, end] | 往前推同样天数 |

generate_platform_*（单平台）：--shop/--shop-id + --platform 均必填；该报表是单一平台独立视图（无「总→分」对比/分平台表/分平台主拖累诊断），保留商圈收入排行+核心指标+利润+流量漏斗+推广+评价+复购+取消+AI诊断。 --brand 必填规则：仅品牌报表（generate_brand_*）必填（不传提示指定并退出）；单店报表可选（仅同名精确过滤；--shop 匹配到多家跨品牌门店时脚本会提示补品牌）。品牌名 = 客户提示词中的品牌，禁止用示例名替代。 输出文件（HTML / AI分析.md）生成在当前工作目录，诊断文件在 scripts/ 目录。 门店定位：--shop <关键词>（模糊匹配）或 --shop-id <shopUniqueKey|平台门店ID>（精确），二选一必填。 工作流调整（两步取数）：①先 search_shops() 取 shopUniqueKey → ②再用 --shop-id 传 shopUniqueKey 调用脚本（更稳定，避免名称模糊匹配导致错店）

5.2 🚫 零硬编码 · 全部由用户提示词驱动

脚本内不存在任何固定时间、固定门店名、固定品牌名，所有报表均按当次调用参数生成：

| 维度 | 数据来源 | 说明 | |------|---------|------| | 门店 | --shop <关键词> | 单店报表必填；取值 = 客户提示词中的门店名（如"XX门店"→ --shop XX门店） | | 品牌 | --brand <品牌名> | 单店可选（精确过滤）、品牌报表必填；取值 = 客户提示词中的品牌名（如"XX品牌"→ --brand XX品牌） | | 平台 | --platform <平台> | 仅单平台报表必填（美团外卖/淘宝闪购/京东外卖） | | 日期 | 自动计算 或 --date YYYYMMDD | 日报=昨天、周报=上一完整自然周、月报=上完整月；--date 指定周期末（日报=当日、周报=周期末、月报=所在月） | | 近N天 | --days N | 周期 = [昨日-(N-1), 昨日] 共 N 天；对比期 = 再往前推 N 天；用周报模板 | | 自定义日期范围 | --start YYYYMMDD --end YYYYMMDD | 周期 = [start, end]；对比期 = 再往前推同样天数；同比 = 2 倍天数；同样走周报模板（含日趋势/周期汇总/环比） | | 对比口径 | 自动 | 较前日/上周/上月 + 同比，随报表类型自动切换 |

AI 执行规则（强制）：用户提示词中出现门店名 → 填入 --shop；出现品牌名 → 填入 --brand（单店报表可选，仅精确过滤；品牌报表必须）；出现平台名（美团/淘宝/京东等）→ 映射为 --platform（见 5.3 ①）；出现时间词（昨天/本周/上月等）→ 决定报表类型与是否加 --date；出现 "近N天/最近N天/N天数据"（N=3/7/14/30 等）→ 按昨日往前推 N 天，用周报模板并加 --days N。禁止用任何示例名替代用户提示词中的名称；用户未提品牌时：单店报表直接不传 --brand 正常生成；仅当是品牌报表且未给品牌名时，先确认品牌名再运行。

5.3 🧭 提示词解析速查（用户问法 → 参数）· 含近N天智能路由

① 平台别名映射（用户提到平台 → --platform 值）：

| 用户说 | 标准平台名（--platform） | |--------|------------------------| | 美团 / 美团外卖 / 美团的 | 美团外卖 | | 淘宝 / 淘宝闪购 / 闪购 / 淘鲜达 | 淘宝闪购 | | 京东 / 京东外卖 | 京东外卖 | | 饿了么 / 饿了么外卖 | 淘宝闪购（统一口径：饿了么并入淘宝闪购，数据同源） |

② 时间词全映射（用户说时间 → 报表类型 / 周期）：

| 用户说 | 处理 | 周期 | |--------|------|------| | 今天 / 今日 / 当天 / 实时 / 现在 / 目前数据 | ① 实时优先：先调 realtime 接口（品牌→query_realtime_summary；单店/门店→query_realtime_list）拿当天实时数据；② 实时无数据（返回空）→ 回退日报（默认昨日） | 实时（当天） | | 昨天 / 数据怎么样（未给时间） | 日报（默认昨日；当天数据未出全） | 单日 | | 前天 | 日报 + --date <前天日期> | 单日 | | 本周 / 这周 / 上周 / 星期 | 周报（上一完整自然周 周一~周日） | 自然周 | | 本月 / 这个月 / 上月 / 月度总结 | 月报（上一完整自然月） | 自然月 | | 去年同期 / 同比 / 和去年比 | 对应报表（对比期自动含同比口径） | 自动 | | 近N天 / 最近N天 / 过去N天 / N天数据 | 周报模板 + --days N（见下表） | [昨日-(N-1), 昨日] |

③ 近N天口语数字映射：

| 用户说 | --days 值 | |--------|----------| | 近3天 / 最近3天 | 3 | | 近一周 / 最近7天 / 7天数据 | 7 | | 近半个月 / 近14天 | 14 | | 近一个月 / 近30天 / 月度近期 | 30 | | 近两个月 / 近60天 | 60 |

④ 门店 + 品牌 / 平台组合路由：

| 用户说 | 路由命令 | |--------|---------| | "XX品牌的XX门店 昨天怎么样" | 门店对齐日报 + --shop XX门店 --brand XX品牌（品牌作精确过滤） | | "XX门店 美团 近7天" | 平台周报 + --shop XX门店 --platform 美团外卖 --days 7 | | "XX品牌 这个月怎么样" | 品牌月报 + --brand XX品牌 | | "XX品牌 XX门店 美团 昨天" | 平台日报 + --shop XX门店 --brand XX品牌 --platform 美团外卖 |

⑤ 歧义处理（仅意图不明显时确认，意图明确直接生成）：

核心原则：能用最少信息确定唯一报表 → 直接生成，不确认；存在多种合理解读 → 才确认。

✅ 意图明确 → 直接生成（不问）——以下情况参数自足，立即运行：

  • 有明确门店名 + 时间（"XX门店昨天怎么样"）→ 单店日报
  • 有明确品牌 + 时间（"XX品牌上周数据"）→ 品牌周报
  • 有门店 + 平台 + 时间（"XX门店美团近7天"）→ 单平台周报 + --days 7
  • 有明确品牌/门店 + "直接出/不用问/随便" → 用最合理默认（品牌整体 / 单店 + 昨日）并注明假设

⚠️ 意图不明显 → 先确认（禁止擅自默认）——存在多种合理解读时，不要自行假设后直接出报表：

  • 只说品牌/品类词 + "数据怎么样/怎么样/看看"（如"XX品牌数据怎么样"）——未明确是品牌整体还是某单店、未给日期
  • 只说"分析一下XX"而未给任何时间词（"分析一下XX品牌"→ 品牌 or 门店？哪一天？）
  • 只说时间词（"这周数据"）但没给门店/品牌维度
  • 品牌/门店名模糊匹配多家 → 需要澄清（如"文山店"可能有多平台）

确认清单（一次性问清 2 个参数）：

  1. 维度：品牌整体？还是某家具体门店？（品牌 → --brand；单店 → --shop）
  2. 日期范围：昨天 / 近7天 / 本周 / 本月 / 自定义区间？

标准确认话术示例：

"XX品牌"匹配到品牌 XX品牌（802 家门店）。请问要分析： ① 品牌整体 还是 某家具体门店（如XX门店）？ ② 哪个日期范围：昨日 / 近7天 / 本周 / 本月？

确认后路由：维度（品牌→generate_brand_* / 门店→generate_store_* 或单平台 --platform）× 日期（昨天→日报 / 近N天→周报+--days N / 本周本月→周报月报 / 自定义→--start --end）。 其他歧义：品牌报表未给品牌名 → 先确认；--shop 模糊匹配多家 → 补 --brand 或 --shop-id；品牌+门店+平台同时出现 → 平台报表优先（单平台口径信息最全）。

⑥ 近N天智能路由细则：识别 近N天/最近N天/过去N天/N天数据（N=3/7/14/30…）→ 加 --days N，用周报模板（含日趋势/周期汇总/环比对比）；周期=[昨日-(N-1), 昨日]，对比期=再往前推 N 天；近30天/近1个月同样用 --days 30（周报模板，非月报）；"近N天"未给门店/品牌 → 按⑤先确认维度。示例：generate_store_weekly.py --shop "XX门店" --days 7、generate_platform_weekly.py --shop "XX门店" --platform 美团外卖 --days 14。

判断规则：先按 门店 / 品牌 / 平台 定位维度，再按 时间词（昨天→日报、这周→周报、本月→月报、近N天→周报模板+--days N）定报表；只问"怎么样/数据"未给时间时，默认日报并询问周期。 品牌名 = 客户提示中的品牌（"分析XX品牌"的 XX），不是示例默认值。

🧩 需求拆解逻辑（强制 · 接收需求第一动作）

任何需求进 AI 前必须先做"5 步拆解"，再决定是直接生成 / 拆分执行 / 反问确认。

Step 1: 关键信息提取（4 个核心字段）

| 字段 | 提取目标 | 示例 | |---|---|---| | 时间 | 标准化日期 / 周期 | 昨天→2026-08-19 / 近7天→[8/13,8/19] / 本周→上一自然周 | | 主体 | 品牌名 / 门店名 | XX品牌（品牌）/ XX门店（门店） | | 维度 | 单平台 / 多平台 / N 平台并列 | 美团外卖（单） / 美团+淘宝（2 个） / 3 个平台并列 | | 指标 + TOP | 收入/订单/复购/评分 等 + 取值 | 收入前 10 / 订单前三 / 评分后 5 |

Step 2: 多平台并列识别（核心 · 易错点）

| 用户说 | 识别 | 正确做法 | 错误做法 | |---|---|---|---| | "3 个平台收入前10" | 3 个并列查询 | 美团前 10 + 淘宝前 10 + 京东前 10（3 个独立表） | ❌ 汇总所有平台后取前 10 | | "美团和淘宝 昨天订单" | 2 个并列查询 | 美团订单榜 + 淘宝订单榜（2 个独立表） | ❌ 取两平台均值/合并 | | "所有平台收入排名" | 全部 3 平台并列 | 美团+淘宝+京东 各一表 | ❌ 跨平台对比后取 TOP | | "美团外卖"（单平台） | 单查询 | 一张表 | — | | "3 个外卖平台分别统计" | 关键词「分别」触发并列 | 3 个独立表 | ❌ 1 个汇总表 |

⚠️ 关键判断信号：3 个/N 个/所有/全部/分别/各平台/每个平台 + 排名/前 N/排行 → 必拆分为 N 个独立子查询。

Step 3: TOP N 识别

  • 「前 10/前 20/前三/前五」→ --top N（默认 10，未指定 TOP 时也用 10）
  • 「前 1/最高/榜首」→ --top 1
  • 「全部/所有门店」→ 不限 Top（按所有门店）

Step 4: 时间标准化

| 用户说 | 实际日期 | |---|---| | 昨天 / 昨日 / 数据怎么样 | 当日 - 1（如 2026-08-19） | | 前天 | 当日 - 2 | | 大前天 | 当日 - 3 | | 今天 / 实时 | 当日 | | 本周 / 这周 | 上一完整自然周（周一~周日） | | 上周 / 上周 X | 再往前一自然周 | | 本月 / 这个月 | 上一完整自然月 | | 上月 | 再往前一自然月 | | 近 7 天 / 近一周 | [当日-7, 当日-1] | | 近 30 天 / 近一个月 | [当日-30, 当日-1] |

Step 5: 拆解确认 / 执行

  • 拆解结果在回复开头显式列出（例：用户问"昨日XX品牌 3 个平台收入前 10"）： 
    需求拆解：
① 时间：昨日（2026-08-19）
② 主体：XX品牌（品牌）
③ 维度：3 平台并列 → 拆 3 个子查询
④ 指标：商家实收
⑤ TOP：前 10
子任务：
- 美团外卖·XX品牌·20260819·收入 TOP10
- 淘宝闪购·XX品牌·20260819·收入 TOP10
- 京东外卖·XX品牌·20260819·收入 TOP10
  • 拆解后并行执行：3 平台一次拉齐（接口已支持 brand_shop_query 按 platform 拆分），避免分多次串行
  • 输出对齐：每个平台独立一张排行表，表头标注「[平台名] · [品牌] · [日期] · 收入 TOP N」

拆解示例集（覆盖 80% 场景）

| 用户原话 | 拆解后子任务 | |---|---| | "昨日 XX品牌 3 个平台收入前 10" | 3 个独立查询：美团前 10 / 淘宝前 10 / 京东前 10 | | "上周各平台订单对比" | 3 个独立查询：上周美团订单 + 上周淘宝订单 + 上周京东订单（同时输出对比表） | | "XX品牌近 7 天哪个门店评分最低" | 1 个查询：XX品牌周报（--days 7）+ 评分排序 | | "XX门店美团近 7 天进店转化" | 1 个查询：XX门店美团周报 + --days 7 | | "昨天 XX品牌 总共多少收入" | 1 个查询：XX品牌日报（含分平台汇总） | | "美团+淘宝 XX门店上周对比" | 2 个查询：XX门店美团周报 + XX门店淘宝周报（不能合并） |

6️⃣ 核心工作流（一键分析诊断闭环）

① 生成报表数据  → 运行 generate_* 脚本（命令见 5.1）→ HTML（AI 区为规则诊断占位）+ *_AI分析.md（规则版）
② AI 深度诊断   → 读取报表数据/诊断数据 → 写 ai_diagnosis_{门店/品牌}_{类型}.json（scripts/ 目录）
③ 回填重跑      → 再次运行同一脚本 → 自动读取诊断文件 → 覆盖规则诊断
④ 对话内交付    → 五段式文字分析（图表由 HTML 卡片渲染，见「7️⃣」） + present_files 打开 HTML

6.1 一键生成报表

运行命令见 5.1。产出（当前工作目录）：

  • {报表名}.html（可视化报表，AI 区为规则诊断占位）
  • {报表名}_AI分析.md（五段式文字版，总览/亮点/问题&方案/行动建议/一句话结论；AI 诊断回填后自动生成 AI 深度版）

6.2 AI 深度诊断 + JSON 文件

读取 HTML 关键板块（KPI/分平台/商圈/趋势）+ scripts/diagnostic_data.json，按「9️⃣ AI 深度分析」6 层框架拆解，写诊断文件：

{
  "score": 88,
  "grade": "优秀",
  "verdict": "综合结论（数据+对比+定性判断）",
  "opportunities": ["亮点1（含数据）", "亮点2"],
  "risks": [["问题1（含数据）", "方案1"], ["问题2", "方案2"]],
  "report_date": "20260809"
}

report_date 强制匹配：日报=CUR_DATE、周报/月报=CUR_END_S、近N天=CUR_END_S——必须与报表周期末一致，否则回填时被跳过。

6.3 回填 AI 诊断

再次运行同一脚本 → 自动读取 JSON → 校验 report_date → 匹配则覆盖规则诊断（HTML AI 区 + _AI分析.md），不匹配则跳过。

流程记忆点：

  • 首次运行（规则占位）→ AI 读数据写 JSON → 重跑（自动回填 AI 版）
  • 已有诊断且日期匹配 → 只需跑一次即出最终版
  • 诊断日期不匹配 → 自动跳过，回退规则诊断（防跨日期/跨周期误回填）

6.4 🆕 AI 自动生成优化方案 JSON（⑥ 优化方案 · 三要素精简版）

新流程：AI 读取 diagnostic_data.json → 按 schema 生成 ai_plan_*.json → render_diagnosis.py --ai-plan 渲染到⑥ 优化方案卡（完全替换默认规则 issues）

核心设计（二要素精简版）：⑥ 优化方案只展示 问题+方案 二要素，去掉所有数据/根因/预期标注，聚焦商家最关心的"问题是什么、怎么解决"。关键数据已隐含在 title 里（如"下单转化严重落后：17.23% vs 22.45%"），无需重复展示。

JSON Schema（ai_optimize_plan/二要素极简版）

{
  "schema": "ai_optimize_plan/二要素极简版",
  "shop": "XX品牌(金峰店)",
  "platform": "淘宝闪购",
  "period": "8月17日 ~ 8月23日（近7天）",
  "generated_at": "2026-08-24 14:00",
  "health_score": 55,
  "summary": "健康分 55（待优化）· 实收 ¥1,951 · 评分 4.9...",
  "items": [
    {
      "prio": "P0",
      "title": "下单转化严重落后：17.23% vs 均值 22.45%（-5.22pp）",
      "sol": "① 套餐重设 3-4 个引流套餐；② 福利区上架天天神券；③ 减配改可选加价；④ 餐盒费≤1元",
      "source": "ai"
    }
  ]
}

字段约束（推荐 · widget 30KB 上限自动裁剪兜底）

| 字段 | 含义 | 推荐长度 | 超限处理 | |---|---|---|---| | prio | 优先级（P0→立即行动 / P1/P2→本周优化） | 必填 | 默认 P2 | | title | 问题（含关键数据对比，自带"问题是什么"） | ≤ 60 字符 | 截断 + … | | sol | 方案（具体可执行步骤） | ≤ 140 字符 | 截断 + … | | source | 默认 "ai" | — | 显示 🤖 AI 徽章 |

精简说明：相比早期版本进一步去掉 data 字段。商家阅读 ⑥ 卡片时最关注两件套：① 这是什么问题 ② 怎么解决。关键数据已隐含在 title 文本里（"下单转化严重落后：17.23% vs 22.45%"），不需单独展示。

命令（AI 一键渲染）

# 1) AI 写 ai_plan_{门店}_{平台}_{周期}.json（scripts/ 目录）
# 2) 一键渲染：取数 + 判定 + 渲染 widget（套固定模板 + ai-plan 数据）
python scripts/render_diagnosis.py \
    --shop "金峰店" \
    --platform "淘宝闪购" \
    --days 7 \
    --ai-plan scripts/ai_plan_taobao_jinfeng_7d.json \
    --fetch --widget

与默认规则版对比

| 模式 | 命令 | ⑥ 优化方案来源 | 核心要素 | |---|---|---|---| | 默认（规则版） | --fetch --widget | 按 dims 判定 + SOLUTION_MAP 映射 | 仅 title + sol | | AI 二要素版 | --fetch --widget --ai-plan xxx.json | JSON items 数组 | 💡 方案（title 含数据 + 方案步骤） |

AI 何时使用 --ai-plan 模式

  • 客户明确要求"深度分析/AI 写方案/精细方案"
  • 需输出含具体数据的方案（非通用 SOLUTION_MAP 占位）
  • 多门店对比需 AI 各自给出针对性方案时

示例文件

scripts/ai_plan_taobao_jinfeng_7d.json（XX品牌·金峰店·淘宝闪购·近7天，6 项优化方案示例 · 二要素精简版）

7️⃣ 输出规范（所有分析强制 · 最高优先级）

7.1 📐 文字版分析输出规范（五段式 · 一切交付的格式基准）

适用范围：9 类标准报表、近N天/自定义区间、接口编排、AI 诊断、任何自定义查询结果。 格式基准：所有文字输出必须采用五段式结构（下方模板）。数据用 markdown 表格落表；图表一律由可视化组件（HTML 卡片）渲染，禁用 Unicode 文本图表。 取数与呈现分离：脚本只输出 markdown 数据表，不生成任何分析文案；五段式由 AI 依据本规范在对话中组织。

① 五段式模板（与 *_AI分析.md 完全一致）：

# {主体}文字版分析 · {品牌/门店}（{场景类型}）
周期：{日期} ｜ {关键评分/合计口径}

## 一、经营总览
- KPI 行：实收 ¥xx ｜ 订单 xx ｜ 单均 ¥xx
- 核心结论句（+ 对比/占比）

| 维度 | 本期 | 对比 | 判断 |
|---|---|---|---|
| ...（数据必须落表） |

## 二、亮点
- **xxx** 实收 ¥xx，占 xx%，为收入贡献第一（含数据）

## 三、问题与解决方案
- **xxx 下滑 ¥xx（-x.x%）** → 💡 方案：按归因链拆解

## 四、行动建议（优先级）
P0｜止血……  P1｜放大/修复……  P2｜监控……

## 五、一句话结论
……

> 由店客多AI外卖运营提供数据服务

② 场景类型命名：标准报表用原类型名（品牌日报/门店周报…）；自定义用「{场景}扩展分析」——如 品牌扩展分析 · XX品牌（收入TOP10）、门店扩展分析 · XX门店（美团vs淘宝双平台对比）。

③ 数据呈现：markdown 表格 + ▲▼（涨/跌/持平）；排名变化 ↑2位/↓1位；KPI 行用 实收 ¥xx ▲8% · 订单 xx ▲5%。红涨绿跌（中国习惯）、金额 ¥ 千分位。

④ 深度完整性（强制 · 与简洁不冲突）：

  • 分平台块标准结构：每平台 5 要素 = ① 实收/订单/占比 ② 环比 ③ 评分 ④ 商圈收入排行（第X/共Y·前X%判断）⑤ 一句话判断；所有平台都展示，不得省略；信息不存在标"无数据"
  • 平台专属指标只能分平台展示（强制）：评分/商圈收入排行/店铺分 = 各平台自有体系，禁止合并/求均值/只展示主平台；平台无该指标时标"无数据"
  • 判断先行：每条信息必须"数据 + 判断"（主因/亮点/风险/下一步），避免数字堆砌
  • 评价场景分平台评分：每平台同时展示「平台展示评分（lastScore）」与「近30日评价均分」双口径，并附菜品/包装/配送分维度评分；缺失维度标"无数据"

④' 评分 / 商圈收入排行 / 店铺分 分平台展示逻辑（强化 · 强制）——三项均为平台专属指标，任何涉及多平台/对齐门店/品牌的分析，必须按下方规则逐平台展示，禁止合并、禁止求均值、禁止只展示主平台、禁止跨平台替代：

| 指标 | 数据源（各平台独立） | 展示口径（强制） | 平台差异 | 无数据时 | |---|---|---|---|---| | 评分 | lastOfShopScore（周期内最新值） | 每平台展示自己的评分；分平台对比行含 pp 对比（如 4.77 ▲0.05pp） | 美团=商家综合体验分；淘宝=综合评分（权重最高指标）；京东有则展示 | 标"无数据" | | 商圈收入排行 | lastOfDateShopRanking / lastOfDatePeerShopNum（指定日期当天，非最新快照） | 每平台展示「第 X / 共 Y + 前 X% 判断」；单平台报表与分平台表都用该平台当天值 | 京东外卖无商圈排名数据（不参与门店等级分布，仅统计美团/淘宝闪购） | 京东 → 标"无数据"；美团/淘宝缺失 → 标"无数据" | | 店铺分 | shopBusinessScore（100 分制） | 每平台展示自己的店铺分 + 等级判定（≥90 优秀/≥80 合格） | 构成两平台不同：美团含不接单率10%/商家评分20%/差评回复10%；淘宝含最低起送价2%/顾客评分4%/在线联系回复率4%/送达准时率10%/商责取消率10%/有效活动丰富度10%/菜单11% | 缺失 → 标"需商家后台确认" |

分平台展示规则（三平台并列时逐平台独立呈现，不得合并）：

  1. 评分：美团 4.77 / 淘宝 4.21 / 京东 4.50 —— 各自展示、各自对比（pp 对比按各平台上周自身值），禁止输出"平均分 4.49"这类合并值
  2. 商圈收入排行：美团 第 1/161 / 淘宝 第 12/80 / 京东 无数据 —— 每平台「第 X/共 Y + 前 X% 判断」（前10%优秀/前30%合格/其余需优化）；京东一律"无数据"，不得用美团/淘宝排名替代
  3. 店铺分：美团 99.0 / 淘宝 85.0 —— 各自展示 + 等级判定；两平台构成不同，判定标准一致（≥90 优秀），但归因时按各自构成拆解（美团的短板是商家评分、淘宝的短板是活动丰富度等，不得套用另一平台构成）

widget / 卡片呈现形态（强制）：

  • 分平台卡：每平台一张卡（或一行），含「评分 + 商圈收入排行 + 店铺分」三要素并排，平台主题色标识（美团黄/淘宝橙/京东红）；三平台独立卡，不合并为一张"总分卡"
  • KPI 卡：展示"评分 / 店铺分"时，若多平台并存 → 拆分为各平台 KPI（如 评分 4.77 只指当前平台；多平台场景用分平台卡呈现）
  • 诊断维度网格：⑦ 店铺分、⑥ 综合评分 按当前诊断平台取值（单平台诊断天然单值）；品牌/多平台分析时逐平台展示

常见错误（必须避免）：

  • ❌ 把美团评分当全平台评分展示
  • ❌ 输出"三平台平均排名/平均店铺分"
  • ❌ 京东无商圈排名时用美团排名补位
  • ❌ 用淘宝店铺分构成解释美团店铺分短板

⑤ 五段式内容长度控制（强制 · 仅约束 widget，不约束 HTML 页面）：

  • 适用范围边界（先分清两种交付物）： | 交付物 | 是什么 | 30KB 限制 | |---|---|---| | widget | 对话内 HTML 片段（show_widget 渲染，非独立文件） | ≤ 30KB 强制 | | HTML 报表页面 | 独立 .html 文件（present_files 打开） | 不受限（可含完整图表库/大表格） |

  • 总大小指引：widget（对话内 HTML 片段）控制在 ≤ 30KB（CSS+HTML+SVG+Logo base64）；超过此阈值即折叠中段细节，保证可渲染；HTML 报表页面（.html 文件）不适用此限制

  • 每段要点数上限（不可越界）：

    | 段 | 上限 | 必含 | 可省 | |---|---|---|---| | ① 经营总览 | KPI 卡 ≤ 6 卡 + 数据表 ≤ 1 个 | 关键 3-4 KPI + 核心结论句 | 衍生指标（毛利率/ROI） | | ② 亮点 | ≤ 3 条 | 每条带数据 + 判断 | 平淡指标 | | ③ 问题与方案 | ≤ 3 条 | 每条"问题（数据）→ 💡 方案"配对 | 无问题的维度 | | ④ 行动建议 | P0 ≤ 3 条 + P1 ≤ 3 条 + P2 ≤ 2 条 | 必须按优先级排序 | 无内容的优先级 | | ⑤ 一句话结论 | 1 行（≤ 50 字） | 数据 + 主因 + 预期 | 无 |

  • 每条要点字数：≤ 30 字（中文字符；超长用列表项/缩写，不堆长句）

  • 图表/可视化：单 widget 内 SVG ≤ 2 个（柱图/折线图），超过则用表格替代

  • 数据表：单 widget 内 table ≤ 3 个（KPI 卡组不计入；超过则合并字段或折叠展开）

  • 检测数据完整度：所有 7 大维度 + KPI 4 卡 + 一句话结论保留；店铺分子项表格可折叠（首屏只显示最低分项）；评价待申诉评价 ≤ 3 条（超过折叠"查看更多"）

  • 超长应急方案：当数据点超量时按优先级裁剪 = ① 一句话结论 + ② KPI 4 卡 + ③ 七维度判定 + ④ P0/P1 行动建议（4 段不裁）；店铺分子项 + 评分分析 + 菜单 中段可折叠（默认折叠详情）

⚠️ 7.2.0 🚨 【强刷规范·强制 2026-08-24】五段式输出 = widget 渲染（无例外）

核心规则：任何 5 段式分析（总览 / 亮点 / 问题&方案 / 行动建议 / 结论）一律以 widget（show_widget）渲染。

❌ 禁止用 markdown 表格 / 纯文本要点 / Unicode 文本图表 代替 widget。

✅ 30KB 限制内做减法，不做替代——保留五段式结构骨架，超长按「4 段不裁 + 中段折叠」裁剪 widget 内中段。

❌ 反例清单（5 类禁止 · 触发即不合规）

| # | 禁止做法 | 替代做法 | |---|---|---| | 1 | 五段式分析只用 markdown 表格落表，无 widget 渲染 | 改用 show_widget 渲染五段式 widget | | 2 | 五段式分析只用 emoji + 短句要点列表（如 ✅ 实收 ¥1928 ▲38%） | 改用 widget 顶部 KPI 卡组（≥23px / 700 / 带对比 pill） | | 3 | 把 widget 里的图表用 ASCII / Unicode 字符画代替（如 ■■■□□ 进度条、▴▴▾▴ 折线） | 改用 SVG 微图（spark line / 柱状 / 饼图）或渐变色块 | | 4 | 30KB 超限后改用 Markdown 折叠而不折叠 widget | 保留 widget，按「4 段不裁 + 中段折叠」裁剪 widget 内中段 | | 5 | 评价 / 趋势 / 对比 / 排行分析等非「诊断」场景用 markdown 表格代替 widget | 一律按「④ 分场景五段式 widget 映射表」渲染为 widget |

✅ 必须 widget 渲染的场景（9 类强制 · 触发词清单）

| # | 场景 | 五段式 widget 形态 | 对应「④ 分场景映射」 | |---|---|---|---| | 1 | 经营总览 | KPI 卡组（3-6 卡）+ 核心结论句 | 实时汇总 / 门店诊断 | | 2 | 亮点 | 亮点卡（绿色左边框 + 数据 + 判断）1-3 条 | 所有场景 | | 3 | 问题与方案 | 问题卡（红/橙左边框 + 💡 方案）1-3 条 | 所有场景 | | 4 | 行动建议 | P0 / P1 / P2 优先级标签卡 | 所有场景 | | 5 | 一句话结论 | 深色结论条 #1f2937 + 黄高亮 #fbbf24 | 所有场景 | | 6 | 评价分析 | 评分大卡 + 分平台评分卡 + Top 菜品卡 | 评价分析 | | 7 | 趋势分析 | KPI 卡组 + SVG 趋势条 | 趋势分析 | | 8 | 多平台对比 | 分平台卡（平台主题色：美团黄 / 淘宝橙 / 京东红） | 分平台对比 | | 9 | 风险扫描报告 | 风险门店红黄绿三色卡组 | TOP 排行 |

触发词识别：用户输入含 分析 / 诊断 / 查看 / 对比 / 走势 / 排行 / 评价 / 扫描 / 汇总 任一关键词 + 数据对象（门店 / 品牌 / 平台 / 品类）→ 必须 widget 渲染五段式，不允许 markdown 替代。

🚫 不需要 widget 渲染的场景（客户需求直接类 · 强制排除）

核心原则：widget 是「数据分析类」输出的展示形态；当客户需求是「直接交付文件/数据/网页」时，不走 widget。

| # | 场景 | 触发词示例 | 正确做法 | |---|---|---|---| | 1 | 下载数据（评价明细 / 订单数据 / 菜品列表 / 推广花费 / 商圈基准等） | "下载XX评价"、"导出订单数据"、"给我推广花费明细" | 直接跑 extend_query.py / chain_business.py 拉数据 → 写 CSV/Excel/JSON 文件 → present_files 交付（无 widget） | | 2 | 生成网页/HTML 页面（品牌周报/月报 / 门店对齐报表 / 自定义展示页） | "生成XX月报网页"、"做一份周报 HTML"、"导出报告" | 直接调用 generate_*_weekly.py / monthly.py 或 chain_business.py → 输出 HTML/Excel 文件 → present_files 交付（无 widget） | | 3 | 批量取数/导出（多家门店取数 / 全品牌汇总 / 跨周期对比） | "把 10 家门店的数据都拉下来"、"导一份全品牌月报" | 批量调用接口 → 输出 Excel/CSV → present_files 交付（无 widget） | | 4 | 申诉资料整理（评价申诉 / 差评申诉 / 图片证据打包） | "整理XX差评申诉材料"、"打包申诉证据" | 调评价接口 + 申诉逻辑 → 输出 Word/PDF/zip → present_files 交付（无 widget） | | 5 | AI Plan 模板生成（为后续 AI 调用准备 plan JSON） | "给我一份 AI plan 模板"、"生成 plan JSON" | 直接输出 JSON 文件或内联 JSON → 不渲染 widget |

判定口诀：

  • 客户要"分析/诊断/查看/对比/走势/排行/评价/扫描/汇总" → widget 强制
  • 客户要"下载/导出/生成网页/批量取数/整理申诉材料/打包" → 直接交付文件，无 widget
  • 强刷规则仅约束"数据分析输出"的展示形态，不约束"文件交付"任务——5段式 widget ≠ 文件交付。

真实案例案例

  • ✅ 分析妈妈的金峰店美团近 7 天经营情况 → render_diagnosis.py --shop-id <uk> --platform 美团外卖 --days 7 --fetch --widget → 渲染五段式 widget（顶部 + KPI + 七维度 + 转化 + 分子项 + 评分 + 方案 + 结论）
  • ❌ 下载妈妈的金峰店美团近 7 天评价明细 → extend_query.py 或 chain_business.py 拉评价明细 → 写 CSV → present_files 交付（无 widget）
  • ❌ 生成妈妈的金峰店美团 8 月月报 → generate_platform_monthly.py --shop ... → 输出 HTML → present_files 交付（无 widget）

✅ 交付前自检 5 条（缺一不可）

  • [ ] ① 五段式结构齐全？（总览 / 亮点 / 问题&方案 / 行动 / 结论，少一段即不合规）
  • [ ] ② widget 渲染？（show_widget 调用已发出，对应 widget_code 已提取，非 markdown 表格）
  • [ ] ③ widget ≤ 30KB？（超限按「4 段不裁 + 中段折叠」裁剪，禁止改 markdown）
  • [ ] ④ 五段组件形态齐全？（① KPI 卡 / ② 绿边亮点卡 / ③ 红橙边问题卡 + 💡 / ④ P0/P1/P2 标签卡 / ⑤ 深色结论条）
  • [ ] ⑤ 样式合规？（纯 inline style + table 布局 + Logo base64 内嵌；禁用 <style> 块 + class 选择器 + grid 布局）

⚠️ 违规后果：未通过自检 5 条中任何一条 → 视为未完成交付，需重新生成 widget。

7.2 📊 对话内输出规范（强制 · 标准交付方式）

一键生成/回填完成后，默认三件套同时交付：文字结论 + 可视化图表 + 打开 HTML 报表页面（present_files）。用户没说也要也——只要生成了 {报表名}.html，本回合就必须 present_files 打开。

严格五段式（对话内所有数据分析强制 · 无例外）：① 经营总览（KPI + 数据落表/可视化）→ ② 亮点 → ③ 问题与解决方案 → ④ 行动建议（P0/P1/P2）→ ⑤ 一句话结论。禁止"数据表格 + 要点"扁平交付；无结构 = 未完成。

五段式 widget 输出（强制 · 对话内 widget 一律按五段式骨架渲染）：任何 widget（HTML 片段 / show_widget）必须自上而下遵循五段式骨架，每段对应固定组件形态，禁止只渲染"数据表格 + 要点"扁平版：

① 五段组件形态表（强制映射）：

| 段 | widget 组件形态（强制） | 判定/内容要点 | |---|---|---| | ① 经营总览 | KPI 卡组（3-6 卡）+ 核心结论句；涉及分平台时内嵌分平台卡（占比条形 + 评分/商圈排行，平台主题色） | 实收/订单/单均必含；结论句带对比 | | ② 亮点 | 亮点卡（绿色左边框 + 数据 + 判断）1-3 条 | 每条 ≤ 30 字，带数据支撑 | | ③ 问题与方案 | 问题卡（红色/橙色左边框 + 问题数据 + 💡 方案）1-3 条配对 | 偏低必挂方案，禁止只给判定 | | ④ 行动建议 | P0/P1/P2 优先级列表（红色 P0 / 橙色 P1 / 灰色 P2 前缀） | 一行概括，不重复 ③ 方案细节 | | ⑤ 一句话结论 | 结论条（深灰底 #1f2937 + 黄高亮 #fbbf24）单行 | 数据 + 主因 + 预期，≤ 50 字 | | 数据来源 | 底部小字（11px #9ca3af 右对齐） | 接口 + 口径说明 |

② 统一样式规格（所有 widget 段强制 · 与诊断配色规范一致）：

  • 整体容器：background:#f5f7fa;padding:24px;color:#1a1a1a;max-width:1080px;margin:0 auto
  • 内容卡：白底 #fff + 1px #e7ebf0 边框 + 圆角 12px + padding 18px 20px + 卡间距 12px
  • 段标题：黄渐变序号块（22×22px，linear-gradient(135deg,#ffc107,#ff9800) 圆角 6px 白字）+ 标题文字 15px/700
  • 判定徽章：绿 #16a34a 优秀 / 蓝 #3b82f6 合格 / 橙 #f59e0b 需优化 / 红 #dc2626 P0 / 灰 #9ca3af 后台确认（白字圆角 10px）
  • KPI 数值：23px/700 黑；涨跌 pill 圆角 6px（红底红字涨 #fef2f2/#dc2626、绿底绿字跌 #f0fdf4/#16a34a——中国习惯红涨绿跌）
  • 亮点/问题卡：左边框 4px（亮点绿 #16a34a / 问题红 #dc2626 或橙 #f59e0b）+ 浅底（#f0fdf4 / #fef2f2 / #fffbeb）
  • P0/P1/P2：左边框 4px（P0 红 #e02e2e / P1 橙 #f59e0b / P2 灰）+ 标签块（24×22px 实色白字）
  • 结论条：深灰底 #1f2937 + 白字 + 高亮黄 #fbbf24 + 圆角 12px + padding 18px 22px

③ 渲染规则（show_widget 兼容性 · 强制）：

  • 纯 inline style + table 布局，禁用 <style> 块 + class 选择器 + grid（widget 渲染器兼容性差）
  • 表格用 <table>（border-collapse:separate + border-spacing 控制间距）；行式信息用 td 内 display:flex
  • 平台 Logo 受 CSP 限制必须 base64 内嵌（scripts/assets/logos/ 转 base64）
  • 每段都渲染：②~④ 无内容时该段省略，但 ① 必含核心 KPI、⑤ 必有一句话结论；禁止把 widget 做成"纯 KPI 卡 + 数据表"的无结构版

④ 分场景五段式 widget 映射（各段放什么）：

| 场景 | ① 经营总览 | ② 亮点 | ③ 问题与方案 | ④ 行动建议 | ⑤ 结论 | |---|---|---|---|---|---| | 门店诊断 | 健康评分大卡 + KPI 4 卡 | 优秀维度卡 | 需优化维度挂方案 | P0/P1 卡 | 深色结论条 | | 实时汇总 | KPI 卡组（实收/订单/单均/佣金） | 环比亮点 | 异常项+方案 | P0/P1/P2 | 一句话 | | TOP 排行 | 榜首大卡 + 榜单表 | 头部集中度亮点 | 尾部门店问题 | 优化建议 | 一句话 | | 分平台对比 | 分平台卡（占比条+评分+商圈） | 领先平台亮点 | 落后平台问题 | P0/P1 卡 | 一句话 | | 趋势分析 | KPI 卡组 + SVG 趋势条 | 峰值/谷值亮点 | 波动异常+方案 | 监控建议 | 一句话 | | 评价分析 | 评分大卡 + 分平台评分卡 | 好评亮点 | 差评标签问题 | 申诉/整改建议 | 一句话 |

⑤ 内容判定优先级（AI 智能筛选）：必提 P0 风险/异常（⚠️ 归零、突降、无效单激增）、显著涨跌（>±10%）、转化/复购短板、头部集中度、评分与商圈排名变化、平台结构突变；可省无变化/非关键数字（折叠进数据表备查）。

  • widget 总大小 ≤ 30KB（含 SVG + Logo base64）——仅约束 widget（对话内 HTML 片段）；HTML 报表页面（.html 文件）不受此限，可包含完整图表库与大表格；超长按 7.1 ⑤「4 段不裁 + 中段折叠」裁剪
  • 参考实现：render_diagnosis.py --widget（build_widget_fixed() 套固定模板 templates/diagnostic_widget_template.html，已修复闭环）已按五段式骨架渲染（顶部渐变条+健康评分大卡→KPI 4 卡→七维度行式→转化 SVG 双图→店铺分子项→评分分析→P0/P1 左边框卡→深色结论）；其余 widget（TOP 排行/对比/趋势）按本表五段式骨架自主组织

AI 智能筛选（强制 · 非全量罗列）：

  • 必提：P0 风险/异常（⚠️ 归零、突降、无效单激增）、显著涨跌（>±10%）、转化/复购短板、头部集中度、评分与商圈排名变化、平台结构突变
  • 可省：无变化/非关键维度的数字（折叠进数据表备查）

下滑时中段插入归因链：实收% ≈ 订单% + 单均% → 订单端拆 曝光% + 转化% → 定性主因 → 分平台逐平台拆解。

平台主题色映射（强制 · 分平台可视化按平台色，不按"主平台红/其余蓝"）：

| 平台 | 主题色 | 备注 | |---|---|---| | 美团外卖 | #FFD100 | 浅底文字用深黄 #E6A700 保证对比度 | | 淘宝闪购 | #FF5000 | 直接使用 | | 京东外卖 | #E1251B | 直接使用 | | 其他/未接入 | #888780 | 中性灰 |

常用图表清单：

  • KPI 概览卡组（6 卡） / 归因拆解+转化漏斗 / 分平台对比（占比条形） / 品牌分档 / 趋势图（日/周）

完整组件清单与场景映射见 docs/输出规范参考.md（按需读）。

9️⃣ 🧠 AI 深度分析（6 层框架 + 运营专家视角 + 诊断规范）

9.1 6 层框架（逐层下钻，不能只看总量）

分析诊断必须按此框架逐层下钻，不能只看总量——每层都要拆到"可行动的主因"：

① 总量层   实收 = 订单 × 单均          → 整体三因子拆解（下滑时必拆）
② 分平台层 每个平台独立拆解：
           实收% ≈ 订单% + 单均%
           订单% ≈ 曝光% + 转化Δ
           叠加评分/商圈排名/推广投放 → 定位"下滑平台 + 平台内下滑因子"
③ 商圈层   自身 vs 商圈均值 vs 前10%    → 倍数（曝光/进店/下单）、转化率 pp、排名
④ 时间层   环比（前日/上周/上月）+ 同比（上周同期/去年）→ 区分短期波动 vs 趋势性下滑
⑤ 结构层   平台占比变化、新老客结构、复购、毛利 → 健康度
⑥ 行动层   按 P0（止血）/ P1（优化）/ P2（放大）给可执行方案

核心方法——下滑归因链（必须逐层定位主因）：

实收下滑 -X% 
  → 拆：订单 -A% + 单均 -B%（谁贡献大谁是主因）
  → 订单下滑再拆：曝光 -C% + 转化 Δpp（流量端 or 承接端）
  → 定位到平台：哪个平台拖累最大？该平台内部又是哪个因子？
  → 结论 + 专属方案（如：京东实收-26.9% = 订单-30%+单均+3%，主因订单→查活动/排名）

规则版扫描器已内置（关键数据问题自动拆解）：

  • 总量三因子 + 同比 + 单均/订单下滑
  • 分平台逐平台拆解（任一平台环比<-5% 即输出：实收%≈订单%+单均%，主因判定，订单≈曝光%+转化Δ）
  • 商圈对比（转化率低于商圈/前10%）、毛利、复购、取消、推广 ROI 阈值扫描

9.2 🎯 外卖运营专家诊断视角

AI 诊断必须站在专业外卖运营角度——不是罗列数据，而是用运营杠杆拆解问题、给可落地的运营动作。核心 6 大杠杆：

① 流量杠杆   曝光量/曝光结构（自然流量 vs 付费 vs 活动位）
             商圈排名（第X/共Y、前10%）、时段覆盖 → 流量是否充足、地位是否稳固
② 转化杠杆   漏斗效率（曝光→进店→下单）
             进店转化率（门头/首图/评分/活动标识）、下单转化率（菜单/价格带/满减/起送价）
③ 客单杠杆   单均实收、凑单设计（加购/套餐/第二份半价）、满减梯度合理性
④ 复购杠杆   复购率、老客占比、会员/储值、评价引导
⑤ 口碑杠杆   评分/好评率、差评标签集中度、评价回复率
⑥ 推广活动杠杆 ROI、占收比、活动档期节奏、预算分配（高转化平台加投）

诊断输出规范（verdict/问题&方案必须体现运营视角）：

| 数据现象 | 外卖运营解读 | 专业运营方案 | |---------|-------------|-------------| | 曝光下滑/排名降 | 流量端失血（自然排名/活动位收缩）| 检查自然排名因子（评分/销量/复购），评估参与平台大促/满减活动回补流量 | | 进店转化率 < 商圈 | 门头/首图/评分展示承接弱 | 首图卖点重构、门头信息对标商圈头部、评分/销量数字外显 | | 下单转化率低 | 菜单结构/价格带/满减梯度不合理 | 调起送价与满减梯度（如 30-20/50-30）、优化品类排序、突出高毛利爆品 | | 单均低 | 客单价结构失衡（缺凑单设计）| 设加购/套餐/第二份半价，提高满减门槛引导凑单 | | 复购低/下滑 | 顾客粘性不足 | 会员/储值活动、复购券（满X减Y限老客）、评价返券 | | 评分低/差评集中 | 口碑风险（标签集中=品类短板）| 针对差评标签集中整改（口味/包装/时长），差评及时回复+补偿 | | ROI 低/占收比高 | 投放效率差/投放过重 | 收缩低效平台预算，聚焦高转化平台与时段加投 |

诊断句式要求：每个问题 = 数据现象 → 运营归因 → 可执行方案（含具体动作/门槛/活动形式），避免"建议优化"类空话。

9.3 诊断深度要求（参考门店月报标准）

  • 📝 verdict：数据 + 环比/同比 + 定性结论（如"回落属短期波动而非结构恶化"）
  • 🟢 亮点 4-6 条：盈利结构 / 平台均衡 / 转化率优势 / 商圈地位 / 履约 / 口碑
  • 🔴 问题&方案 4-6 组配对：每条问题带具体方案（归因拆解：实收%≈订单%+单均%，订单%≈曝光%+转化%）
  • 诊断文件 JSON 结构：见「6.2 步骤②」；文件命名 ai_diagnosis_{门店/品牌}_{daily/weekly/monthly}.json，report_date 必须匹配报表日期（日报=CUR_DATE、周报/月报=CUR_END_S；近N天=CUR_END_S），不匹配自动跳过回退规则诊断，防跨日期/跨周期误回填

1️⃣1️⃣ 数据口径（关键 · 口径识别三问为唯一权威，8️⃣/AGENTS.md 只引用不重复）

口径识别三问（任何分析取数前必过 · 强制）：

  • 第一问 · 视角（主体）：客户要的是哪个视角？判定信号与默认值—— | 视角 | 判定信号（客户怎么说） | 数据口径 | 对比基准 | |---|---|---|---| | 对齐门店视角 | "XX门店/这家店/该店"（只提店名，未指定平台）→ 默认 | shopIdType=2 该物理门店全平台合并（美团+淘宝+京东） | 该店全平台整体 vs 上周/上月 | | 单门店视角 | "XX门店 美团/淘宝/闪购上"（店名 + 指定了平台） | shopIdType=1 该平台上的这家店 | 该店自己所在商圈均值（各店不同） | | 品牌视角 | "XX品牌/整体/全部门店/品牌门店" | summary 汇总 / 多门店 list 聚合 | 品牌均值 / 平台大盘 / 品牌内部对标 | 规则：提店名未提平台→对齐门店（默认）；提了平台→单门店；提了品牌→品牌；视角不明确（店 vs 品牌、哪个平台都不确定）→ 必须先问，禁止默认。深度分析结论必须归属正确：对齐=全平台整体、单门店=该平台该店、品牌=整体；不得混用（不得用全平台合并掩盖单平台问题、不得用品牌均值掩盖单店问题、不得把单店结论上升为品牌结论）。
  • 第二问 · 字段粒度：① 字段是门店级 / 平台级 / 品牌级？② 客户要的是哪个？③ 有无多粒度近似字段？禁止默认选一种。常见粒度对照： | 字段 | 粒度 | 常见错误 | |---|---|---| | orderConversionBusinessCircleAvg 等商圈均值字段 | 门店级（该门店自己所在商圈的均值，各店不同） | ❌ 当平台统一值用（实测各店商圈 15.58%~38.71% 差异巨大） | | shopRanking/peerShopNum 商圈排名 | 门店级（该店所在商圈的排名） | ❌ 当平台整体排名 | | validReceipts 等经营指标（shopIdType=1） | 平台门店级（单平台单店） | ❌ 混入全平台合并值（shopIdType=2） | | consumption 门店推广花费 | 门店级（该平台该店） | ❌ 当 CPC/魔方分项（promotionExpenses/cubeCost） | | summary 接口指标 | 品牌/汇总级 | ❌ 当门店级数据用 | 粒度规律（不靠记、靠推导）：字段名含 BusinessCircle → 门店级（该店所在商圈，逐店不同）；含 shopRanking/peerShopNum → 门店级；consumption/promotionExpenses/cubeCost → 门店级推广分项；summary 接口返回 → 品牌级；粒度由"字段语义+接口归属"决定，不由名称里的 Avg/合计 决定。
  • 第三问 · 商圈/对比基准：
    • 商圈对比 = 每店各自商圈（强制）：涉及"门店 vs 商圈"（下单率/进店转化/曝光对比）时，必须用该门店自己所在商圈的均值（list 接口 orderConversionBusinessCircleAvg 等字段随记录返回，各店不同），禁止用"平台平均商圈值"当所有门店的基准——那是错误口径（曾把美团平台平均 24.04% 当全部门店商圈基准，导致误判 86 家）。批量门店分析时商圈字段搭进 query_history_list 一次带全（2 次调用），不要逐店/逐平台另查 daily。
    • "vs 平台/大盘" → 平台级汇总；"vs 品牌" → 品牌均值。仅客户明确要对比时才引入均值口径。
  • 财务口径（v124）：财务估算毛利 = 估算财务净毛利 + 门店推广花费；财务估算净毛利 = 估算财务净毛利；毛利率/净毛利率 = 对应毛利 ÷ 财务收入（未扣自动充）。页面不出现英文字段名（billProfitCpc/billRevenueNotAuto 等仅公式注释，公式只在利润板块用纯中文展示）
  • 评分构成：从评价明细统计（过滤 invalidType 无效后：好评4-5星/中评3星/差评1-2星），与负面标签同源；评价总数行标注「有效 X 条 · 无效 Y 条」
  • 评分双口径（评价分析必须区分）：① 平台展示评分 = 明细的 lastScore（平台计算、带历史权重、滞后于近期口碑）；② 近30日评价均分 = 有效评价 commentScore 的算术平均（反映近期真实口碑）。两口径差异大时是危险信号（如展示分 4.7 但近30日均分 3.82），必须同时呈现并解释背离；分维度评分 = 菜品 orderCommentScore / 包装 packingScore / 配送 deliveryCommentScore（0 值视为未评，跳过不计）
  • 负面标签（容错双轨，强制）：评价明细的负面标签字段为 labels（EVALUATE_HEADERS 已映射「评价标签」）。接口可能返回、也可能不返回该字段（实测 evaluate_detail 当前不携带，全平台全记录均无），处理规则：
    • ① 若明细含 labels → 直接用平台真实标签归因（比人工归类准确），按标签统计条数，输出标注"来源：平台评价标签"
    • ② 若明细无 labels → 回退为差评内容（commentScore≤2）人工归类（如肉质/酱汁/份量/配送/售后主题），输出必须注明"平台未返回标签，按差评内容归类"，不得假装是平台标签
    • ③ 聚合脚本需做字段存在性检查（'labels' in record），禁止假定一定有或一定没有；仅统计有效评价（排除删除/不计入评分）
  • 导出列 JSON 已源头解析（强制）：评价明细 CSV 中「点赞菜品/点踩菜品/评价图片/订单详情」等 JSON 字段由脚本 _json_to_text 在导出时自动解析为可读文本（字符串列表"、"分隔；订单详情"名称×数量"），导出文件不出现原始 JSON；AI 聚合评价时直接读 CSV 文本字段，无需二次解析
  • 申诉成功评价列表：评价板块含「⚖️ 申诉成功评价」（appealSuccess==2），展示评分/平台/内容
  • 商圈排名：list 接口（shopIdType=1）单店形式获取，已并入 QUERY_CODES 一次查询（summary 0 调用）
  • 商圈流量对比：daily 接口 + shopIdType=1；周报/月报取周期汇总（量字段求和、比率字段日均）
  • 评分：周期内最新（lastOfShopScore），分平台对比行含评分 pp
  • 营业天数：日实收>0 天数（月报分母按自然月天数）
  • 单平台查询优化：门店单平台报表只查 shopIdType=1 分平台数据（当期/环比/同比 3 次），跳过被覆盖的全平台汇总查询

1️⃣2️⃣ 接口异常处理（chain_business.py 内置）

| 状态 | 处理 | |------|------| | 200 | 正常返回 | | 401 | 打印「请到【店客多 AI 技能中心】https://ka.diankeduo.net/#/crayfish/index 获取有效 Token」+ 抛 RuntimeError | | 429 | 打印「今日调用次数已达上限，隔天自动恢复」+ 抛 RuntimeError | | 其他 | 打印状态码 + 响应体；网络异常打印接口地址 |

1️⃣3️⃣ 📋 9 报表分析·诊断场景（只讲"分析什么 / 诊断看什么"，命令见 5️⃣）

门店对齐报表

| 报表 | 用户问法（触发示例） | 分析重点 | AI 诊断关注点 | |------|--------------------|---------|--------------| | 门店对齐日报 | "XX门店昨天数据怎么样" / "帮我看看XX门店今天的经营" / "XX门店数据怎么样"（当天语境）| 当日实收/订单/单均、较前日+较上周同比、分平台异动、商圈排名日变化 | ① 实收环比下滑 → 三因子拆解（实收≈订单+单均，订单≈曝光+转化）② 分平台主拖累（<-5%）③ 转化率 vs 商圈均值/前10% ④ 单日评分/差评 | | 门店对齐周报 | "XX门店这周/上周怎么样" / "分析下XX门店本周经营" | 自然周汇总 vs 上周、日趋势节奏（周末效应）、分平台均衡度、商圈地位周变化 | ① 周度环比趋势 ② 趋势异常日（骤降/骤升定位）③ 平台结构偏移 ④ 复购与推广效率周对比 | | 门店对齐月报 | "XX门店这个月/上个月数据怎么样" / "这个月XX门店表现如何、月度总结" | 月汇总 vs 上月、30日复购、全勤天数、商圈排名月变化、客单价 | ① 月环比大涨/大跌归因 ② 复购健康度（粘性）③ 商圈地位变动（排名升降）④ 毛利结构与客单价 |

门店单平台报表（单平台口径）

| 报表 | 用户问法（触发示例） | 分析重点 | AI 诊断关注点 | |------|--------------------|---------|--------------| | 门店单平台日报 | "XX门店美团昨天数据怎么样" / "XX门店在美团的表现" | 该平台单日实收/订单/单均、商圈收入排行（第X/共Y）、商圈流量对比（均值/前10%）、单平台转化率 | ① 该平台实收环比下滑归因（订单/单均拆解）② 商圈排名日变化（↑↓位）③ 转化率 vs 商圈均值/前10% ④ 该平台评分/差评 | | 门店单平台周报 | "XX门店美团这周怎么样" / "XX门店在美团周度分析" | 该平台周汇总 vs 上周、日趋势、商圈排名周变化、单平台复购/推广 | ① 周环比趋势 ② 商圈地位周变化（排名升降）③ 该平台转化/复购健康度 | | 门店单平台月报 | "XX门店美团这个月怎么样" / "XX门店美团月度总结" | 该平台月汇总 vs 上月、商圈排名月变化、客单价、毛利结构 | ① 月环比大涨/大跌归因 ② 商圈地位变动 ③ 该平台毛利与客单价 |

品牌报表（全品牌汇总）

| 报表 | 用户问法（触发示例） | 分析重点 | AI 诊断关注点 | |------|--------------------|---------|--------------| | 品牌日报 | "XX品牌昨天怎么样" / "全品牌今天数据" | 全品牌单日实收/订单/单均、平台结构、当日异动 | ① 单日大幅异动（活动效应/闭店/系统问题）② 单均与转化率当日水平 ③ 平台集中度风险 | | 品牌周报 | "XX品牌这周怎么样" / "品牌周经营分析/周度会议" | 品牌周汇总 vs 上周、门店等级分布（商圈前10%）、TOP/下滑门店、新店进度 | ① TOP 门店亮点提炼复制 ② 下滑门店定位止损 ③ 新店爬坡管理 ④ 品类毛利与复购 | | 品牌月报 | "XX品牌这个月怎么样" / "品牌月度总结/扩张决策" | 月汇总 vs 上月、新增门店数、城市分布、门店等级结构、单店盈利分布 | ① 扩张节奏是否健康 ② 单店盈利分布（长尾/集中）③ 新店爬坡期占比 ④ 客单价与转化提升空间 |

场景选择速查（用户问法 → 报表）

"XX门店数据怎么样 / XX门店昨天(今天)怎么样"   → 门店对齐日报
"XX门店这周/上周怎么样"                      → 门店对齐周报
"XX门店这个月/上个月怎么样 / 月度总结"        → 门店对齐月报
"XX门店 美团 昨天/这周/这个月怎么样"          → 门店单平台 日/周/月报（--platform 美团外卖）
"XX品牌 昨天(今天)数据怎么样 / 全品牌数据"    → 品牌日报
"XX品牌 这周怎么样 / 品牌周经营会议"          → 品牌周报
"XX品牌 这个月怎么样 / 品牌月度总结"          → 品牌月报
"XX品牌 XX门店 分析一下 / 看XX门店经营细节"   → 门店对齐系列（含商圈对比/分平台明细）
"看XX品牌健康度/扩张/门店分布"               → 品牌系列（含门店等级/城市分布）
"XX门店 近7天数据 / XX品牌 近3天经营"        → 近N天分析（周报模板 + --days N）
"XX门店 8月1日到8月10日数据" / "XX品牌 7月1日~7月15日分析" → 自定义日期范围分析（周报模板 + --start --end）

1️⃣4️⃣ 🔬 门店诊断（美团 / 淘宝闪购 · 按平台路由）

场景归属：本场景是「2️⃣ 一键优先路由」的场景②（平台门店诊断）——诊断有专属取数（generate_platform_diagnose.py 独立脚本）与判定流程（平台诊断文档七维度），不属 9 类报表、不现场编排；任何"诊断门店"类需求必须走本节流程。

触发：客户说"诊断XX门店 / 帮我诊断店铺" → 按平台路由：提到美团 → 美团诊断逻辑；提到淘宝/闪购/饿了么（饿了么并入淘宝闪购）→ 淘宝诊断逻辑；未指定平台 → 美团优先（诊断体系最全）。

数据获取（先取数，拿不到才引导）：

  1. 一键取数（独立诊断脚本 · 与周报完全分离）：python scripts/generate_platform_diagnose.py --shop X --platform <美团外卖/淘宝闪购> --days 7（仅 5 次接口：当期+上期分平台列表 ×2 + 评价明细 + 店铺分子项 shop_score_head + 商圈基准 daily；不查同比/日趋势/不生成 HTML——诊断只需环比与七维度数据；实测耗时 ≈2s；输出 diagnostic_data.json 含 biz_cmp 商圈均值/前10% + score_analysis 评分分析）；用户指定周期（近30天/本月等）按指定 1.5 一键 widget 渲染（对话内首选 · 修复版）：python scripts/render_diagnosis.py --shop X --platform <美团外卖/淘宝闪购> --days 7 --fetch --widget —— 一条命令闭环（自动取数 generate_platform_diagnose.py → 读 diagnostic_data.json 七维度判定 → 套固定模板 scripts/templates/diagnostic_widget_template.html 渲染五段式 widget），通过 ===WIDGET_BEGIN===/===WIDGET_END=== sentinel 输出到 stdout。AI 直接提取片段 → show_widget 渲染到对话内（无需写 HTML 文件）。分两步时：① generate_platform_diagnose.py --shop X --platform P --days 7 取数导出 → ② render_diagnosis.py --widget 渲染（--shop 缺省自动从 diagnostic_data.json 读门店）。诊断与周报完全分离：诊断流程只输出 widget（不生成 HTML 文件），周报流程只生成 HTML+md——按需选用，不混合。
  2. 判定 = 直接读 scripts/diagnostic_data.json：summary（转化率/评分/店铺分 shopBusinessScore/复购/新老客占比）+ biz.plat_rank（收入排名/商家数/店铺分）+ biz_cmp（商圈均值与前10%门槛）+ shop_score_head（分子项明细补齐：美团/淘宝自动调用 query_shop_score_head，含 items 子项与 coverage_note；接口空 → 商家后台核对）+ neg_*（差评标签）+ earliestOpenDate/firstOpenTime/openDays（门店开业信息，已修复：从 list 接口 shopInfo.beginTime 字段提取；接口实际未返回独立的 firstOpenTime/earliestOpenDate 字段——但 shopInfo.beginTime 字段真实可用，格式 YYYY-MM-DD HH:MM:SS；脚本已解析并计算 openDays（基于诊断周期末日期））+ dish_stats（点踩/点赞菜品：接口当前未返回 criticFoodList/praiseFoodList，脚本保留字段键并打 has_critic/has_praise/note，渲染端按 dish_has_data 切换"待接口修复"提示 vs 实际菜品列表）+ evaluations（评价明细原始数据保留，便于后续追溯）→ 按对应平台诊断文档七维度阈值逐项判定，无需再读 HTML 或现场检索。字段先读后取（强制）：读取 JSON 后先打印 list(d.keys()) 与 list(d['summary'].keys())，只按实际存在的键取值，禁止凭记忆写字段名（真实事故：曾用 repeatRate 取值而实际字段为 sevenRepeatReta，导致复购误判"无数据"）；判定某维度"无数据"时依据 summary_missing 字段（脚本已记录接口未返回的字段清单）或确认键存在且值确实为 0，禁止仅因取值打印为空而判"无数据"。口径唯一（强制）：③ 下单转化率一律用 summary.orderConversionRate（进店→下单）对比 biz_cmp.<平台>.orderConversionRateAvg / top_ocr，禁止用 comprehensiveConversionRate（综合转化率是派生指标，勿混） 2.6 结论兜底：当 AI 未写 ai_diagnosis_*.json（verdict 字段为空）时，render_diagnosis.py 自动按 dims 评分生成 rule-based 一句话结论（数据 + 主因 + 预期），不再显示"AI 结论待补充"占位；有 AI verdict 时优先用 AI 版。 2.5 一键渲染（效率优先 · 判定+报告自动产出）：python scripts/render_diagnosis.py --shop X --platform P --days N [--out 目录] [--fetch] [--widget] [--no-ai]——--fetch 一条命令闭环（自动取数 + 判定 + 渲染，无需先跑取数）；--widget 输出对话内五段式 widget 片段（套固定模板，配 --fetch 一步闭环）；七维度阈值已代码化（与两平台诊断逻辑文档对齐：排名前10%优秀/曝光超均值合格/转化对比商圈/复购≥30优秀≥20合格/评分≥4.8优秀≥4.6合格/店铺分≥95优秀≥90合格/名称格式），读 diagnostic_data.json + ai_diagnosis_* 后自动判定 + 套 templates/diagnostic_template.html 渲染，输出：① 完整版 HTML ② 对话版 fragment（适配对话内渲染规范）③ 控制台一行式结论（供五段式组织）。--shop 可省（自动从诊断数据读取，规避全/半角括号差异）。AI 只需审核判定 + 微调 ai_diagnosis JSON，不再手写 HTML。诊断三步闭环：取数（1）→ 一键渲染（2.5）→ present_files / 对话内渲染；--fetch 可合并为两步。模板全页样式统一（卡片/徽章/KPI/表格/间距 6 套规范 + 评价板块紧凑诊断结论形态）见 AGENTS.md「诊断渲染与配色规范」
  3. 可判定维度（用接口数据）：① 同行收入排名 ② 曝光总体 ③ 下单转化率 = orderConversionRate（进店→下单；≠ 综合转化率 comprehensiveConversionRate）（总体/新老客）④ 入店转化率（总体/新老客）⑤ 复购率（总体/新老客）⑥ 综合评分 = 门店评分（接口 shopScore 直接判定，≥4.8 优秀 / ≥4.6 合格；子项权重公式作为优化建议参考） ⑦ 店铺名称合理性（用 search_shops 返回的「平台门店名称 shopAliasName」直接诊断，无需后台；平台门店名称才是平台上真实展示、影响搜索与进店的名称，店客多内部名 shopName 不作判定依据）——按「品牌+品类+（门店）」格式判定（见各平台诊断文档「名称合理性诊断」）；门店开业信息 = 独立展示项（非判定维度）：已修复——数据源从 list 接口 shopInfo.beginTime（格式 YYYY-MM-DD HH:MM:SS）提取 earliestOpenDate/firstOpenTime/openDays（基于诊断周期末计算），渲染端按 openDays≤30 标「新店 🆕」徽章（仅标识不判优劣，见各平台诊断文档「门店开业信息」）

诊断判定字段映射表（七维度 × 字段 × 对比基准 · 强制）：下方为通用版总纲；两平台各自的字段明细（含平台专属字段与口径）以 美团门店诊断逻辑.md / 淘宝门店诊断逻辑.md 顶部「0️⃣ 诊断判定字段映射表」为准，判定时按对应平台文档查表取数。

| 维度 | 判定字段（diagnostic_data.json 路径） | 对比基准（biz_cmp） | 无数据时 | |---|---|---|---| | ① 收入排名 | biz.plat_rank.<平台>.shopRanking / peerShopNum | 前10% | — | | ② 曝光 | summary.showPeopleNum（新老客：newExposeIndividualsNum/oldExposeIndividualsNum） | showPeopleNumAvg / top_show | 平台无商圈 → 标注无数据 | | ②' 流量结构（美团·曝光口径） | summary.natureShow / payShow / showTimes——自然曝光占比=natureShow÷showTimes、付费曝光占比=payShow÷showTimes（曝光次数口径） | 以商家后台「流量来源」为准（自然≥60%；付费>40% 过度依赖） | 缺失或两源合计<60% → 商家后台 | | ③ 下单转化 | summary.orderConversionRate（新老客：newOrderConversionRate/oldOrderConversionRate） | orderConversionRateAvg / top_ocr | summary_missing | | ④ 入店转化 | summary.businessClickRate（新老客：newBusinessClickRate/oldBusinessClickRate） | businessClickRateAvg / top_bcr | summary_missing | | ⑤ 复购 | summary.sevenRepeatReta（判定字段=近7日复购）+ sevenRepeatUser（30日 thirtyRepeatReta 仅参考展示）+ 新老客占比 newOrderPeopleRatio/oldOrderPeopleRatio | 无商圈基准（绝对值参考：≥30% 优秀 / ≥20% 合格 / <20% 需优化） | summary_missing | | ⑥ 综合评分 | summary.shopScore（好评率 goodEvaluateRate/非常差评率 veryBadEvaluationRate） | ≥4.8 优秀 / ≥4.6 合格 / <4.6 需优化 | — | | ⑦ 店铺分 | summary.shopBusinessScore | ≥95 优秀 / ≥90 合格 / <90 需优化 | 缺失 → 商家后台 | | ⑧ 名称 | shopAliasName（平台门店名称） | 品牌+品类+（门店） | — |

新老客拆分判定（强制）：③④ 必须看新老客拆分——新客转化显著低于老客时（如某店：新客下单约 10% vs 老客约 39%），问题定性为「新客承接弱」，方案聚焦新客活动（新客立减/首单券/新客专享套餐），不能只看总体转化率；总体低于商圈均值但新老客均接近基准时，才归因于菜单/价格带。 ⑤ 复购判定一律用近 7 日复购（sevenRepeatReta）；30 日复购（thirtyRepeatReta）仅作参考展示，不得用作判定字段。

  1. 需引导排查维度（接口无数据 → 引导用户到商家后台查看后回填）：
    • 店铺分（100 分制 ≥95 优秀 / ≥90 合格；总分子项接口有则判，无则引导商家后台「门店管理/店铺分」；店铺分构成两平台不同，见各平台文档）
    • 自然/付费流量占比 → 引导「经营数据/推广后台 → 流量来源」
    • 商家配置项（菜品 SKU/分组/福利区/明厨亮灶/海报/店招/橱窗/公告/餐盒费/减配金额等）→ 引导「门店装修/菜品管理」逐一排查

两平台诊断区别对照（重要，判定时按平台选用）：

| 区别点 | 美团外卖 | 淘宝闪购 | |---|---|---| | 评分维度命名 | 商家综合体验分 | 综合评分（最重要的指标） | | 综合评分首子项（权重30%） | 商品满意度 | 口味满意度 | | 店铺分构成 | 含不接单率10%/商家评分20%/差评回复10% | 含最低起送价2%/顾客评分4%/在线联系回复率4%/送达准时率10%/商责取消率10%/有效活动丰富度10%/菜单11% | | 下单转化检测 | 多「菜品分组名称≤8字符」项 | 无该检测项 | | 官方功能清单 | 11 个（含优惠券） | 10 个（无优惠券） | | 活动/功能体系 | 平台独立：活动名称/可用活动按美团后台活动中心为准（天天神券/神枪手等美团系活动） | 平台独立：活动按淘宝闪购后台活动中心为准（勿套用美团活动名） | | 综合评分判定 | = 门店评分 ≥4.6 合格 | = 门店评分 ≥4.6 合格（一致） |

诊断输出：按 7 大维度逐项给「优秀 / 合格 / 需要优化」判定 + 数据支撑 + 建议（配置类给"建议有/建议X"）；接口判不了的维度明确标注"需商家后台确认"并列出排查项，不得凭空判定；结尾附「推荐平台官方功能」名称清单（只给功能名，按平台清单）。

⚠️ 偏低必挂方案（强制）：凡判定为「需要优化」或「合格偏低」的维度，必须自动挂接对应解决方案——严格按各平台文档「十、诊断结果→解决方案映射」执行（含可调用的分析能力如 评价分析/推广诊断/差评申诉/自动回复，及平台功能名），不得只给判定不给方案、禁止 AI 自创或空泛建议（如"按运营杠杆整改"类占位）。代码已固化：render_diagnosis.py 内置 SOLUTION_MAP（与两平台文档「十」映射表逐条对齐），规则版问题卡自动挂接；AI 深度版 risks 的「→ 方案：」内容原样呈现。判定「优秀」的维度可跳过。

诊断卡片形态（强制 · 对话内渲染）：信息量不减的完整五段式，六段齐全、禁止极简砍信息（如只给七维度网格）：① 标题+周期行 → ② 维度判定网格（7格：收入排名/曝光/下单转化/入店转化（含店铺名称子项）/复购/综合评分/店铺分，优秀绿/需优化红/需关注琥珀）→ ③ 优秀维度（数据判定）→ ④ 需优化维度挂方案 → ⑤ 行动建议 P0/P1/P2 → ⑥ 一句话结论+数据来源。开业信息放周期行尾（· 开业 {日期}（约{时长}），openDays≤30 标「新店」）。 表现方式（强制）：诊断默认以「对话内 HTML 展示页/widget」渲染——配色/版式/页面结构/分平台展示/widet 固定模板详见 docs/输出规范参考.md「🎨 诊断渲染规范（完整版）」（含 6 套设计系统 + 14 块页面结构 + diagnostic_widget_template.html 55 占位符 + 分平台展示规则 + 全半角括号坑）；诊断页不要用 var(--color-background-*) 系统变量版式。 不设 无障碍标题（用户要求：直接显示诊断报告正文即可，省略无障碍标题）。 ③ 下单转化格必须显示 orderConversionRate 正确值（如 27.2% 优秀）；综合转化率 comprehensiveConversionRate（如 0.81%）只作④入店转化维度的成因解释，禁止填入③、禁止出现在"需优化"区。

完整判定标准：见同目录 美团门店诊断逻辑.md / 淘宝门店诊断逻辑.md（七维度全部阈值 + 检测项 + 综合评分/店铺分公式与子项权重 + 官方功能表）。