1688-shop-daily-report

1688-shop-daily-report — 店铺经营日报

🧩 本 Skill 已 workflow 化。标准日报链路由 workflow/1688-shop-daily-report.js 编排执行（意图识别 → 日期解析 → 单店/多店子图 → 行动选择）；本文档是 workflow 的需求源 + 兜底说明书。两者必须保持一致：改动本文档的流程/规范后，需同步到 workflow 的节点与 prompts（尤其是「报告生成规范」「广告分析规范」「输出语言规范」），并重跑双验证。

技能概述

生成1688店铺指定日期的经营日报，展示店铺主要经营数据（GMV、询盘、订单量）、流量数据（UV、PV、CTR、跳失率）、用户数据（新老客买家数、支付金额）分析，并进行异常提醒和经营建议。日报数据T+1更新，最早可查出昨天的日报。

使用场景

• 用户需要查看店铺经营状况
• 生成指定日期的经营日报
• 分析店铺数据趋势和异常
• 触发关键词：日报、经营报告、店铺分析、店铺日报、生成日报

CLI 命令

configure — 配置 AK

# 查看 AK 状态
python3 {baseDir}/cli.py configure
# 设置 AK
python3 {baseDir}/cli.py configure YOUR_AK

配置网关鉴权所需的 AK。所有操作命令都依赖 AK，首次使用前需先配置。

get_bindlist — 获取多店铺绑定列表

python3 {baseDir}/cli.py get_bindlist

获取当前 AK 绑定的所有店铺列表（含各店铺 loginId），用于多店铺场景。

单店铺数据查询

三个数据查询命令，均需传入 --query_date 参数，可选传入 --NEWTON_SHOP_LOGIN_ID 指定店铺：

# 获取交易数据（GMV、订单量、客单价、转化率、询盘数）
python3 {baseDir}/cli.py get_trade_data --query_date  [--NEWTON_SHOP_LOGIN_ID ]

# 获取流量数据（PV、UV、UVCTR、跳出率等）
python3 {baseDir}/cli.py get_traffic_data --query_date  [--NEWTON_SHOP_LOGIN_ID ]

# 获取买家数据（新老买家数、支付金额）
python3 {baseDir}/cli.py get_user_data --query_date  [--NEWTON_SHOP_LOGIN_ID ]

get_ad_report — 广告投放日报数据

python3 {baseDir}/cli.py get_ad_report --query_date  [--NEWTON_SHOP_LOGIN_ID ]

获取指定日期的广告投放汇总数据（含前一天环比、Top3 计划详情）。内部自动查询当天+前一天数据并计算汇总指标。

多店铺模式无需单独调用，get_multi_shop_report 已自动集成广告查询。

get_review_data — 商品评价数据

python3 {baseDir}/cli.py get_review_data --query_date  [--NEWTON_SHOP_LOGIN_ID ]

获取指定日期的商品评价数据，自动按 5 分制分类统计（5星好评、3-4星中评、1-2星差评），收集好差评原因、商品维度汇总。

多店铺模式无需单独调用，get_multi_shop_report 已自动集成评价查询。

get_multi_shop_report — 多店铺日报批量查询

# 首屏标准用法（固定加上这两个参数）：stdout 直接给出基础日报所需的精简数据，完整数据同时落盘备用
python3 {baseDir}/cli.py get_multi_shop_report --query_date  --summary_only --output_file {baseDir}/.tmp/daily_report_<日期>.json

内部自动调用 get_bindlist 获取店铺列表，然后并行查询所有店铺的交易/流量/用户数据（含前一天环比数据），一条命令完成。

单店铺模式复用同一命令，只需额外传 --NEWTON_SHOP_LOGIN_ID；get_trade_data / get_traffic_data / get_user_data 等原子命令仅用于临时补查。

精简输出结构（--summary_only）：每店含 companyName、loginId、error、当日核心指标，以及服务端已算好的日环比（gmvDayOnDay / orderDayOnDay / uvDayOnDay / pvDayOnDay / searchUvDayOnDay / inquiryDayOnDay），外加 prev （前一天的 gmv/orderCount/uv/payConversionRate/bounceRate，作为校验基数）。

⚠️ 环比一律直接用服务端字段，不要自行心算。payConversionRate 只给当日值（转化率环比存在「百分点」与「相对变化率」口径歧义，服务端刻意不算）；需判断转化率走势时用 prev.payConversionRate 直接比对。

读取规范（硬性）：

• 首屏一律直接解析 --summary_only 的 stdout 输出，不再按店铺数量判断是否落盘、也不再读文件。精简输出实测 7 家店约 5.7KB / 4700 字符，单次读取即可读完。
• --output_file 落盘的是完整数据（含 prevDay 全量字段、新老买家、完整 topProducts 等），仅当【深度补充分析】确实需要首屏之外的字段时才读取；首屏阶段不得读取该文件。
• 读取该落盘文件时若一次没读完，必须按行范围（start_line/end_line）分段读到完整 JSON 再解析，全程静默。
• 严禁改用脚本读取：绝不允许为“读文件/绕过截断”而临时编写或内联执行任何 Python / shell 脚本（如 python -c、open().read()、cat 等）。
• 严禁把读取过程说给用户：诸如“文件被截断了”“让我用 Python 脚本完整读取并解析”“正在读取 xxx.json”之类均为内部技术过渡句，一律不得作为可见文字输出。
• 禁止从被截断的输出里手动摘录数字。

query_shop_data — 商家数据自由查询（单条，内置）

python3 {baseDir}/cli.py query_shop_data --data_source  --api_path <接口路径> --params '' [--NEWTON_SHOP_LOGIN_ID ]

单条查询，适用于单店铺模式或临时补查。多店铺场景请使用下方 batch_query_profile_data。

本命令已内置于日报技能，无需调用外部 1688-shop-freedom-query-data 技能。

batch_query_profile_data — Profile 补充数据批量并发查询（⭐ 多店铺首选）

# 方式二（⭐ 跨平台首选，推荐）：把入参写进临时文件再传路径，彻底绕开 shell 引号转义
# 文件内容为 JSON 对象：{"queries": [...], "shop_login_ids": [...]}（可选 "max_workers"）
python3 {baseDir}/cli.py batch_query_profile_data --input_file {baseDir}/.tmp/batch_query_<日期>.json

# 方式一（内联字符串）：仅 bash/zsh 环境可用；Windows cmd.exe 下单引号/双引号会转义失败
python3 {baseDir}/cli.py batch_query_profile_data \
    --queries '<查询规格 JSON 数组>' \
    --shop_login_ids '<店铺 loginId JSON 数组>'

一次 CLI 调用完成所有店铺 × 所有查询类型的并发请求（内部线程池并发，默认 5 线程），避免 Agent 多次顺序调用。

⚠️ 入参方式（硬性）：queries/shop_login_ids 是含中文与双引号的 JSON。默认用 --input_file：先把 {"queries":[...],"shop_login_ids":[...]} 写入 {baseDir}/.tmp/ 下的临时文件（目录会自动创建），再传文件路径。这样在任何终端（含 Windows cmd.exe）都稳，不会因引号转义把 JSON 打乱。仅在明确处于 bash/zsh 环境时才可用内联 --queries/--shop_login_ids 方式。

⚠️ 调用时机（硬性）：本命令属【深度补充】阶段，必须在【基础日报】已作为一条独立可见消息输出之后才能调用；在基础日报可见输出前调用本命令即为流程错误。其返回的原始 JSON 属内部数据，绝不作为可见内容展示给用户（不得“取回完整内容”式地展示原始结果）。

参数说明：

queries 单项格式：

{"label":"商品动销率","data_source":"SYCM","api_path":"portal/core/overview","params":{"dataType":"RECENT_1"}}

返回结构：

{
  "success": true,
  "markdown": "批量查询完成：5 店铺 × 2 查询类型 = 10 次调用，成功 10 / 失败 0",
  "data": {
    "results": {
      "店铺A_loginId": {
        "商品动销率": { "data": {...} },
        "大客户询盘": { "data": {...} }
      }
    },
    "summary": { "total": 10, "success": 10, "failed": 0 }
  }
}

参数说明（通用）

多店铺支持

本技能通过 get_bindlist + NEWTON_SHOP_LOGIN_ID 参数支持多店铺数据查询。

鉴权与身份说明：

• AK（Access Key）：统一从环境变量读取，用于网关签名鉴权。所有店铺共用同一个 AK，无需为每个店铺单独配置或传递不同的 AK。
• loginId：通过 get_bindlist 接口获取，用于标识具体要查询哪个店铺的数据。在调用数据查询命令时，通过 --NEWTON_SHOP_LOGIN_ID 参数传入目标店铺的 loginId 即可切换店铺上下文。

默认行为：查询所有绑定店铺。用户未指定具体店铺时，必须先调用 get_bindlist 获取店铺列表，然后对每个店铺传入其 loginId 分别查询数据，最终汇总输出多店铺对比报告。

• 不传 NEWTON_SHOP_LOGIN_ID：查询当前 AK 绑定的默认店铺（单店铺模式）
• 传入 NEWTON_SHOP_LOGIN_ID：查询指定 loginId 对应店铺的数据

输出语言规范（面向商家，说人话）

本技能的使用者是普通 1688 商家，不是技术人员。所有展示给用户的文字（包括中间过程说明、进度提示、思考/播报、最终日报）都必须通俗友好：

• 一律使用中文：所有面向用户的文字——包括进度提示、过程说明、思考播报（如“正在加载…”“接下来…”）、步骤标题、最终报告——都必须用中文表达，严禁输出英文句子（如 “Now let me load the profile template…”、“Let me run the queries…” 等）。如需说明正在做什么，用中文一句话概括（如“正在根据店铺经营类型准备分析…”）。

• 禁止暴露内部技术术语与实现细节：如 Profile、factory.md / trader.md / integrated.md 等模板文件名、loginId、GMV、UV、PV、get_multi_shop_report / multi_shop_report 等命令名、.tmp、JSON、“落盘”、“阶段判定”、“触发查询1/2”、“活跃店铺筛选”、字段名等，一律不得出现在用户可见文字中。

• 内部处理过程保持安静：读取用户画像、加载模板、判断补充查询、筛选店铺、推断经营阶段等都是内部步骤，不要向用户逐条播报；直接给出最终日报即可。如确需提示进度，用一句中文人话（如“正在汇总各店铺昨天的经营数据…”），而非罗列内部字段与文件名。

• 绝不在报告前输出“分析草稿 / 中间小结”（重要）：生成报告前，严禁把“核心指标选择”“异常阈值”“异常分析”“归因深度”“行动排序”“核心摘要列应为…”以及逐店铺的指标/环比清单等任何分析推理过程作为正文输出；也禁止输出“现在让我生成报告”“Now let me generate the report”之类的过渡句；同样严禁把读取落盘文件的内部动作说出口，如“文件被截断了”“让我用 Python 脚本完整读取并解析”“完整读取日报 JSON 数据”“正在读取 xxx.json”等。这些都是内部思考，只能直接体现在最终日报的探测/异常/行动重点区块里，而不是先播报一遍。正确做法：内部思考完成后，第一句可见输出就是报告标题（如“📊 1688店铺日报 - 日期”）。

• 必须使用中文通俗说法：

  内部术语	面向用户的说法
  GMV	成交额
  UV	访客数
  PV	浏览量
  loginId / 店铺账号	店铺名称（用 companyName 全称）
  询盘	客户咨询
  转化率	成交转化率
  动销率	有销量的商品占比
  落盘 / 读取 JSON	（属内部动作，不向用户提及）
  加载 Profile 模板	读取经营诊断思路
  Profile 补充查询	补充查询经营指标
  Wiki / 知识库	商家知识大脑
  获取绑定店铺列表	查找目标店铺

⚠️ 命令步骤的描述文字同样对商家可见（界面上会逐条列出“执行命令 · XXX”），因此 workflow 里每个 buildBashCommand(...) 的 description 必须是中文人话，不得出现 Profile、exec: python3、命令名、文件名。宁可用笼统的“正在处理数据”，也不能露出内部术语。

生成流程

Profile 字段定义（读取时机：与取数同轮并行；模板文件仍在基础日报之后加载）

🚧 两条时序约束分开记：① Profile 字段（经营模式/身份等，从记忆读取或由输入推断）在发起取数的同一轮并行获取——它决定核心摘要展示哪些列（经营模式 × 阶段 动态选列），必须在基础日报前就绪，但不得为此额外串行等待；② Profile 模板文件（profiles/xxx.md）只影响【深度补充分析】，仍然必须等【基础日报】输出之后才能加载（见 Step 4）。取不到的字段用默认值，绝不阻断。

下表为需要读取的 Profile 字段：

取不到的字段使用默认值，绝不报错。空值越多越接近通用日报。

注意：Profile 字段读取与取数同轮并行（不得串行阻塞取数）；模板文件（profiles/xxx.md）仍在【基础日报】输出之后才加载（见下方流程 Step 4-6）；报告生成规范（格式/阶段/归因/排序）已内联在本文档「报告生成规范」章节，无需读取外部文件。

---

默认模式：多店铺日报（默认推荐）

当用户未指定某个具体店铺时，默认走多店铺模式：

1. 确定报告日期 — 使用用户指定日期，不可以自己调整日期，如未指定默认为昨天。如果要查询今日及未来时间的日报，直接返回当前日期数据为空，终止运行
2. 批量获取多店铺日报数据（与 Profile 字段读取同轮并行） — 执行 get_multi_shop_report --query_date <查询日期> --summary_only --output_file {baseDir}/.tmp/daily_report_<日期>.json，同一轮并行从 Agent 记忆读取 Profile 字段（仅字段，不加载模板文件）。直接解析 stdout 的精简输出即可生成基础日报；落盘文件是给 Step 4 深度补充备用的，首屏不要去读它（命令自动建目录，无需 mkdir）
   • 该命令内部自动调用 get_bindlist 获取店铺列表，并行查询所有店铺的交易/流量/用户数据（含前一天环比数据）
   • 同时自动查询广告投放数据（内置集成，无需额外调用），返回结果中包含 adReport 字段
   • 同时自动查询商品评价数据（内置集成，无需额外调用），返回结果中包含 reviewData 字段
   • 所有查出的店铺即使数据为0也都要展示，注意不要让数据出现幻觉；但 error 非 null 的店铺表示查询失败（服务已自动重试1次仍失败），须标注失败、不得展示为 0
   • 广告查询失败时 adReport 为 null，静默跳过广告板块
   • 评价查询失败时 reviewData 为 null，静默跳过评价板块
3. 生成并输出【基础日报】（首屏，快速，不读模板文件） — 基于 Step 2 已查回的数据，核心摘要列按经营模式 × 经营阶段动态选取（列集见 profiles 模板「核心指标」表，如工贸一体成熟期→成交额/订单量/客单价/老客占比；Profile 字段已在 Step 2 并行读取，阶段按「报告生成规范·经营阶段」用多店均值判定）直接成文，并立即作为一条独立可见消息输出给用户。内容：核心摘要表格（各店铺关键指标 + 环比）+ 广告投放概览 + 评价概览 + 重点数据（涨跌 >10% 的机会/风险）。「今日行动重点」不在本段输出，已移至 Step 6【深度补充分析】末尾（综合补充数据后给出）。要求：
   • 第一句可见输出就是报告标题（📊 1688店铺日报 - 日期），前面不得有任何分析草稿或中间过程
   • 数据展示公司名称全称（companyName），不简称、不篡改；所有查出店铺即使数据为 0 也都要展示；若某店 error 非 null（此时 today/prevDay 为 null），说明该店数据获取失败，须明确标注「数据获取失败，请稍后重试」，绝不可显示为 0 或编造数值
   • 广告/评价数据为空或查询失败时省略对应板块
   • 此段不加载 Profile 模板文件，凭 Step 2 已查回数据与已读取的 Profile 字段直接成文（选列所需的核心指标表如未读到，用通用列：成交额/订单量/访客数/成交转化率）
   • 基础日报作为独立消息输出完毕后，紧接着输出一句独立的简短进度提示「⏳ 正在进行深度补充分析…」，再进入 Step 4
4. 读取 Wiki 背景 + 加载 Profile 模板 + 按 Profile 补充查询（放在【基础日报】输出之后，用于深度补充）
   • 🚧 前置硬门槛（必须遵守）：本步骤的任何动作——读取 Wiki 背景、读取 factory.md/trader.md/integrated.md 任一 Profile 模板、调用 batch_query_profile_data / query_shop_data 补充查询——都必须等到 Step 3【基础日报】已作为一条独立可见消息（以 📊 报告标题开头）输出之后才能开始。在该基础日报可见消息发出之前，严禁读取上述任何文件、严禁调用任何补充查询命令——即使是为了“准备输出”“格式参考”“深度思考”也一律不允许；也禁止输出“让我输出基础日报”“现在生成报告”之类过渡句，第一句可见输出必须直接是报告标题。补充查询返回的原始 JSON 属内部数据，绝不作为可见内容展示（禁止“取回完整内容”式展示原始结果）。
   • Wiki 背景：按 references/wiki-routing-rules.md 执行。多店铺最多读取 3 家，优先选择存在异常指标的店铺，再补充成交额最高且尚未入选的店铺；未获得可靠背景时按空背景继续，不影响后续步骤
   • 并发执行：Wiki 背景读取与 Profile 链路互不依赖。基础日报输出后，将当前轮可同时发起的独立只读调用放在同一轮；不要假定整条 Profile 补充查询链与 Wiki 始终并发。Profile 链路内部仍按“先加载模板、再补充查询”的原顺序执行。进入 Step 5 前等待已发起的 Wiki 与 Profile 结果全部返回
   • 加载模板：根据 经营模式（字段已在取数阶段并行读取）加载对应模板（工厂/生产型→profiles/factory.md、贸易商/分销商→profiles/trader.md、工贸一体（默认）→profiles/integrated.md）；报告生成规范（阶段判定/归因深度/异常阈值/行动排序）已内联在本文档「报告生成规范」章节，直接参照，无需读取外部文件
   • 再补充查询（触发条件命中时执行）：检查 Profile 模板「额外数据预查询」中触发条件命中的查询（跳过标记「多店铺模式跳过」的 AD 查询），使用 batch_query_profile_data 命令一次性并发执行；如某条查询返回空数据则静默跳过：
     1. 从 Step 2 结果中筛选活跃店铺（GMV > 0 或 UV > 0）的 loginId 列表
     2. 从 Profile 模板中提取触发条件命中的查询规格（跳过「多店铺模式跳过」标记的查询）
     3. 调用 batch_query_profile_data --queries '<查询规格数组>' --shop_login_ids '<活跃店铺ID数组>'
     4. 内部自动并发执行所有店铺 × 所有查询，返回汇总结果
   • 若无触发条件命中，则本模式无补充查询数据
5. 推断经营阶段 + Profile 深度分析（内部使用，不输出） — 基于查回数据按「报告生成规范·经营阶段」判定各店铺经营阶段（起步/成长/成熟），结合 Profile 差异化指标（动销率、大客户询盘、渠道结构等）做深度归因，并仅用可用的 Wiki 商家背景补充对已有数据结论的解释。此步所有推理仅在内部完成，绝不向用户播报，也绝不展示阶段名称/判定逻辑
6. 输出【深度补充分析】+【今日行动重点】（追加一段独立消息，紧接进度提示之后） — 把 Step 4 补充查询数据 + Profile 差异化指标解读 + 可用的 Wiki 商家背景 + 深度归因，以及综合基础数据与补充数据得出的「今日行动重点」，作为一段独立的「🔍 深度补充分析」消息追加输出（今日行动重点放在本段末尾）。要求：
   • 只讲基础日报里没有的新信息（Profile 差异化指标 + 补充查询结果 + 可用的 Wiki 商家背景），不重复基础日报内容
   • 归因深度：按 身份 × 阶段 矩阵控制（详见「报告生成规范·归因深度」）
   • 行动建议排序：优先匹配「希望牛顿帮我做」字段 > 数据异常触发 > 模板默认方向
   • Wiki 使用边界：每条归因和行动建议都必须至少有一项非 Wiki 数据依据，依据只能来自基础日报、广告、评价或 Profile 补充数据；只有 Wiki 背景支持的结论或行动必须省略
   • 即使无补充查询命中、也无额外差异化洞察，本段仍必须输出「今日行动重点」（此时可仅基于基础数据给出）；只有 Profile 差异化解读/深度归因这类补充内容可省略，不强行凑内容
7. ⏸️ 行动选择（仅在【基础日报】+【深度补充】都输出完毕后） — 综合两段的行动重点，加载 {baseDir}/references/interaction-specs.md，随后触发 select_action 交互。在两段内容都输出之前，禁止加载 interaction-specs.md、禁止触发 select_action、禁止弹出任何确认/选择卡片

单店铺模式

当用户明确指定了某个店铺时，复用与多店铺同一套并发管线，仅把查询范围限定到该店铺（通过 --NEWTON_SHOP_LOGIN_ID）：

1. 确定报告日期 — 同上
2. 定位目标店铺并取数（与 Profile 字段读取同轮并行） — 先调用 get_bindlist 找到用户所指店铺对应的 loginId，再执行 get_multi_shop_report --query_date <查询日期> --NEWTON_SHOP_LOGIN_ID <该店 loginId> --summary_only --output_file {baseDir}/.tmp/daily_report_<日期>.json，同轮并行读取 Profile 字段（仅字段，不加载模板文件）
   • 传入 --NEWTON_SHOP_LOGIN_ID 后，命令内部只查该店铺，并发查询其交易/流量/用户（含前一天环比）+ 广告 + 评价，返回结构与多店铺一致（shops 数组仅含该店一条，并附带 adReport、reviewData）
   • 广告/评价查询失败时对应字段为 null，静默跳过，不影响日报主体
   • 输出为精简结构，直接解析 stdout 即可；落盘的完整数据仅在 Step 4 深度补充需要首屏之外字段时才读取
3. 生成并输出【基础日报】（首屏，快速，不读模板文件） — 基于 Step 2 数据，核心摘要列按经营模式 × 该店阶段动态选取（Profile 字段已并行读取；拿不到列集用通用列：成交额/订单量/访客数/成交转化率）直接成文并立即作为一条独立可见消息输出：核心摘要 + 广告投放概览 + 评价概览 + 重点数据（涨跌 >10% 的机会/风险）。「今日行动重点」不在本段输出，已移至 Step 6【深度补充分析】末尾。第一句可见输出就是报告标题，前面不得有分析草稿；此段不加载 Profile 模板文件。输出完毕后紧接着输出一句独立简短进度提示「⏳ 正在进行深度补充分析…」，再进入 Step 4。
4. 读取 Wiki 背景 + 加载 Profile 模板 + 按 Profile 补充查询（放在【基础日报】输出之后，用于深度补充）
   • 🚧 前置硬门槛（必须遵守）：本步骤的任何动作——读取 Wiki 背景、读取 factory.md/trader.md/integrated.md 任一 Profile 模板、调用 batch_query_profile_data / query_shop_data 补充查询——都必须等到 Step 3【基础日报】已作为一条独立可见消息（以 📊 报告标题开头）输出之后才能开始。在该基础日报可见消息发出之前，严禁读取上述任何文件、严禁调用任何补充查询命令——即使是为了“准备输出”“格式参考”“深度思考”也一律不允许；也禁止输出“让我输出基础日报”“现在生成报告”之类过渡句，第一句可见输出必须直接是报告标题。补充查询返回的原始 JSON 属内部数据，绝不作为可见内容展示（禁止“取回完整内容”式展示原始结果）。
   • Wiki 背景：按 references/wiki-routing-rules.md 执行，只读取当前目标店铺；未获得可靠背景时按空背景继续，不影响后续步骤
   • 并发执行：Wiki 背景读取与 Profile 链路互不依赖。基础日报输出后，将当前轮可同时发起的独立只读调用放在同一轮；不要假定整条 Profile 补充查询链与 Wiki 始终并发。Profile 链路内部仍按“先加载模板、再补充查询”的原顺序执行。进入 Step 5 前等待已发起的 Wiki 与 Profile 结果全部返回
   • 加载模板：根据 经营模式（字段已在取数阶段并行读取）加载对应模板（factory / trader / integrated.md 之一）；报告生成规范见本文档「报告生成规范」章节，无需读取外部文件
   • 再补充查询（触发条件命中时执行）：单店铺可直接用 query_shop_data 调用（传入 loginId），也可用 batch_query_profile_data --shop_login_ids '[""]' 一次性执行多条查询；无触发则跳过
5. 推断经营阶段 + Profile 深度分析（内部使用，不输出） — 基于当日数据按「报告生成规范·经营阶段」判定阶段，结合 Profile 差异化指标和评价数据做深度归因、识别差评风险，并仅用可用的 Wiki 商家背景补充对已有数据结论的解释。仅在内部完成，绝不向用户播报，也不展示阶段名称
6. 输出【深度补充分析】+【今日行动重点】（追加一段独立消息，紧接进度提示之后） — 把补充查询数据 + Profile 差异化解读 + 可用的 Wiki 商家背景 + 深度归因，以及综合基础与补充数据得出的「今日行动重点」（放在本段末尾），作为独立「🔍 深度补充分析」段追加输出：
   • 只讲基础日报没有的新信息，不重复
   • 归因深度：按 身份 × 阶段 矩阵控制
   • 行动建议排序：同多店铺模式
   • Wiki 使用边界：每条归因和行动建议都必须至少有一项非 Wiki 数据依据，依据只能来自基础日报、广告、评价或 Profile 补充数据；只有 Wiki 背景支持的结论或行动必须省略
   • 即使无补充查询命中、也无额外洞察，本段仍必须输出「今日行动重点」（可仅基于基础数据给出）；只有 Profile 解读/归因等补充内容可省略
7. ⏸️ 行动选择（仅在【基础日报】+【深度补充】都输出完毕后） — 综合两段行动重点，加载 {baseDir}/references/interaction-specs.md，触发 select_action 交互，根据行动重点动态生成选项。两段内容输出前，禁止加载 interaction-specs.md、禁止触发 select_action、禁止弹卡

报告生成规范（格式 / 阶段 / 归因 / 排序）

本节是查数据之后、生成报告的统一参考（原 report-guide.md 已内联至此，无需读取任何外部文件）。核心摘要展示哪些列、异常阈值、行动方向由 profiles/{factory|trader|integrated}.md × 下方「经营阶段」动态决定。 用语规范：报告给普通商家看，表头与正文一律用中文通俗词，禁止出现 GMV/UV/PV/loginId/ROI/JSON 等英文缩写。对照：成交额、访客数、浏览量、投产比、店铺名称（用 companyName 全称）。 两段式：①【基础日报】核心摘要列按经营模式 × 阶段动态选取（Profile 字段与取数并行读取，不拖首屏；模板文件不加载）；②【深度补充分析】追加在后，展示 Profile 差异化指标（动销率/大客户询盘/渠道结构等）× 阶段的解读，末尾附「今日行动重点」。

一、报告模板

多店铺（字数：老板 400-600 / 运营 600-800）：

# 📊 1688店铺日报 - {日期}
## 店铺范围
本次分析 {x} 家店铺：{A}、{B}…    （≤5 全列；>5 用"A、B、C 等共 x 家"）
## 经营总览
{一句话：整体情况 + 重点店铺 + 需关注问题}
## 一、核心摘要
| 店铺 | {指标A} | {指标B} | {指标C} | {指标D} |
（列由 Profile 核心指标 × 阶段决定；括号内日环比用 +/-%，无基数则省略括号，转化率仅当日值；表格禁用任何 emoji）
## 二、广告投放
消耗 {金额} | 曝光 {数}({%}) | 点击 {数}({%}) | 客户咨询 {数}({%}) | 成交 {数} | 投产比 {值}
**Top 计划**：{计划名} 消耗 {金额}，投产比 {值}    （数据为空/失败则省略整段）
## 三、商品评价
新增评价 {数} 条 | 好评率 {%} | 差评率 {%}
**好评关键词**：… ／ **差评关键词**：…    （仅真实评价、过滤系统默认文案；无差评省略差评行；为空省略整段）
## 四、重点数据
### 📈 机会  （仅涨幅 >10% 正向指标）
### ⚠️ 风险  （仅跌幅 >10% 负向指标；零成交在此文字提示）

重点数据的聚合与限量（店铺多时必须遵守）：

• 一店一行：同一店铺的多个异常指标合并在一行（如「某某公司：成交额 +59.3%、订单量 +20.7%、客户咨询 +46.6%」），绝不按「店铺 × 指标」逐条平铺—7 家店平铺可达 40+ 行，必破手机 3-4 屏上限。
• 每板块最多 5 家，按成交额规模降序取前 5 家（大店的 10% 比小店的 300% 更值得关注），超出部分汇总为一句「其余 N 家成交额规模较小，已省略」。不得写成「波动较小」——被省略的小店百分比往往反而更大，那样写是误导。
• 极小基数降噪：|日环比| ≥ 300%（翻 3 倍以上）时百分比对商家无阅读价值，改用「前一天值 → 当日值」的绝对值表述（如「成交额 73 → 7984」），绝不输出 +10836.71% 这类数字。

多店铺归因一律「简洁型」（每异常 ≤1 句结论 +1 层拆解，不论身份）；行动标注针对哪个店铺。 ❌ 不逐店写完整日报、不重复正常指标、不长篇解释差异、不把机会与风险混列。

单店铺（字数：老板 200-350 / 运营 300-500）：板块同上，核心摘要改为纵向表 | 指标 | 当日 | 日环比 | 周环比 |；归因深度按下方「身份 × 阶段」矩阵。

单店纵向表的两条规则：

• 指标列全：纵向表每个指标一行、不受屏幕宽度限制，因此列出全部可用指标（成交额/订单量/访客数/客户咨询/成交转化率/客单价/老客占比/询盘转化率），按 Profile × 阶段的关注度排序（关注的在前）。多店横向表反之，受宽度限制只取 4-5 列。
• 不展环比的指标用空单元格，不用 "-"：转化率按规范仅看当日值，其环比格留空；"-" 仅用于表示“无数据”，两者混用会让商家以为数据缺失。周环比整列无数据（上周同日取数失败）时直接省掉该列。

二、深度补充分析（追加段，紧接进度提示后）

## 🔍 深度补充分析
- **{Profile 差异化指标}**：{数值}（{环比/对比}）— {1 句洞察}
- **{补充查询结果：动销率/大客户咨询/渠道结构}**：{数据} — {1 句洞察}
### 今日行动重点
1. **{行动}** - {结合数据的 1 句说明，标注针对店铺}

只讲基础日报没有的新信息、不重复；即使无补充数据，也必须输出「今日行动重点」（可仅基于基础数据），行动 3-5 条、禁止长期规划。

三、异常识别阈值（Profile 无法加载时的通用 fallback）

零成交（成交额=0/订单=0）在风险板块文字提示；表格数据一律不加 emoji，涨跌只用 +/-%；机会与风险必须分开。

四、经营阶段自动推断（内部用，绝不展示阶段名）

取当日数据（单店）或多店均值判定：

规则冲突取较高阶段；多店各店独立判定。阶段仅供内部决定指标选取/阈值松紧/归因深度，绝不在报告表格或正文出现阶段名称或判定逻辑。

五、归因深度 = 身份 × 阶段

• 极简：1 句结论 + 1 条行动
• 简洁：1 句结论 + 1 层拆解（渠道/品类）
• 摘要：结论 + 关键交叉维度
• 教学：结论 + 具体操作步骤 ①②③
• 拆解：结论 + 按渠道/品类/时段分层
• 深度：结论 + 多维交叉 + 策略建议

默认身份 = 老板（偏结论、偏短）；多店铺一律用简洁型。

六、行动建议排序

优先级：①「希望牛顿帮我做」字段（最高）＞ ② 当日数据异常对应技能 ＞ ③ Profile 默认方向。取 TOP 3-5 条。

具体触发词→技能映射、选项文案与卡片构造见 interaction-specs.md（仅在两段都输出后加载）。

七、字段映射与环比

核心指标中文名 ↔ API 字段对照见 capabilities.md；常用派生指标：老客占比 = 老买家数/（新买家数+老买家数）、询盘转化率 = 订单量/询盘数×100%、动销率 = pullSalesItemCnt/itemCnt×100%、复购率取补充查询 overview 的 oldCustomerPurchaseRate。

环比均由服务端用真实原值自算（Agent 直接取用，不要心算）：

• 日环比：gmvDayOnDay / orderDayOnDay / uvDayOnDay / pvDayOnDay / searchUvDayOnDay / inquiryDayOnDay
• 周环比：gmvWeekOnWeek / orderWeekOnWeek / uvWeekOnWeek / pvWeekOnWeek / searchUvWeekOnWeek / inquiryWeekOnWeek / avgPriceWeekOnWeek（均为平铺字段，不是嵌套对象）
• 转化率不算环比（百分比的环比有「百分点」与「相对变化率」两种口径，差 10 倍以上）；需判断走势时用 prev.payConversionRate / weekAgo.payConversionRate 原值直接比对

⚠️ 接口自带的环比预计算字段不可信，已实测定案：同一接口对同一家店返回「订单量日环比（%）」=0、「询盘数日环比（%）」=0，而真实值分别是 +20.72% / +46.55%；周环比同理（orderWeekOnWeek 各店全为 0，而 GMV周环比 各店不同、确为真值）。因此服务端额外查询上周同日（queryDate-7）自算周环比；交叉验证：自算的成交额周环比与接口值完全一致（43.84 = 43.84），口径无偏差。

自算后 0 是有效值（真的持平），不能当无数据；prev/weekAgo 基数为 0 时环比为 null，展示 "-"。如不需周环比，可加 --no_week_on_week 省下 1/3 接口调用量。

八、空值 Fallback

经营模式空 → 工贸一体（integrated）；身份空 → 老板；利润来源空 → 薄利多销（关注访客数与获客成本）；目标客户/供应周期/起订量/其他能力/希望牛顿帮我做 空 → 不做对应维度细分。核心原则：空值越多越接近通用日报（绝不出错），信息越全越个性化。

报告严格禁止

❌ 不设"交易分析/流量分析/用户分析"独立章节；❌ 不做表格外的详细数据罗列；❌ 不长篇理论/解释；❌ 不加"数据来源/生成时间"等元信息；❌ 表格数据禁用任何 emoji（🚀📈📉等），涨跌只用 +/-%；❌ 禁长期建议、战略规划、重复分析、冗长表格；❌ 总长度控制在手机 3-4 屏内。

行动选择交互

日报输出完成后，必须触发 select_action 交互，根据报告中"今日行动重点"的内容动态生成可执行的行动选项卡片。

完整的行动关键词映射表、构造规则、数据结构示例、用户选择后的处理逻辑请查阅 references/interaction-specs.md。

⏰ 严格时序（必须遵守）：

1. 先输出【基础日报】正文（不含今日行动重点），作为一条独立可见消息
2. 紧接着输出一句独立的简短进度提示：⏳ 正在进行深度补充分析…
3. 再输出【深度补充分析】段（末尾含「今日行动重点」，始终输出），作为紧随其后的独立消息
4. 两段都输出完毕后，才加载 interaction-specs.md
5. 最后才触发 select_action 弹出选择卡

❌ 绝不允许：在【基础日报】输出之前就加载 interaction-specs.md 或弹卡；也绝不允许在没有基础日报的情况下直接弹出确认/选择卡。

核心要点：

• 选项根据当天日报实际行动重点动态生成，不是固定的
• 数量 2-6 个，按优先级排序
• 用户选择后直接调用对应技能，无需再次输入触发词

安全声明

异常处理

任何命令输出 success: false 时：

1. 先输出 markdown 字段（已包含用户可读的错误描述）
2. 再根据关键词追加引导：

环境变量（.env）

项目根目录的 .env 文件存储 skill 基础信息，供埋点上报等模块读取。发布到不同环境时可直接替换该文件中的变量值。

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

埋点上报

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

• 实现位置：scripts/_tracker.py → report_skill_usage()，在 cli.py 的 main() 中每次命令执行后自动调用

• 上报接口：POST /api/alibaba.1688.report.skills.usage/1.0.0

• 上报参数：

  参数	值来源	说明
  apiName	固定 null	固定传 null
  skillsName	.env SKILL_NAME	skill 名称
  version	.env SKILL_VERSION	skill 版本号
  scene	固定 CLI	固定值
  channel	.env SKILL_CHANNEL	发布渠道

• 失败处理：上报失败静默忽略，不影响主流程

输出格式

采用标准 JSON 输出，层级扁平化。核心结构：

• success: bool — 是否成功
• markdown: string — 用户可读摘要
• data: object — 业务数据（含 shops[]、adReport、reviewData 等）

特殊值处理规则：

• 所有环比均由服务端计算（gmvDayOnDay / orderDayOnDay / uvDayOnDay / pvDayOnDay / searchUvDayOnDay / inquiryDayOnDay），其中订单/询盘/流量类已用两天原始值补算，直接取用，不要自行心算
• 环比字段为 null 表示前一天基数为 0（无法计算百分比变化），展示时省略括号；此时可用精简输出的 prev.* 与当日值直接比对判断趋势
• prev 块（gmv/orderCount/uv/payConversionRate/bounceRate）是交叉校验基数：环比看起来异常时用它校对，不要把它当作展示内容
• payConversionRate 仅展示当日值；需说明转化率走势时用「从 X% 降到 Y%」的说法，绝不自行换算成百分比变化率
• error 字段：null=成功，非 null=该店铺查询失败原因（服务层已自动重试 1 次仍失败）。此时该店所有指标均为 null，绝不可当作 0 或编造数值展示，须向用户明确标注该店「数据获取失败，请稍后重试」

字段含义速查：各字段含义见 references/capabilities.md 对应章节（交易→get_trade_data、流量→get_traffic_data、买家→get_user_data、广告→get_ad_report）

使用原则

1. 必须查询真实数据：通过 bash 执行脚本获取真实数据，不要编造
2. 日期格式：YYYY-MM-DD，如用户未指定日期，默认使用昨日。如果要查询今日及以后的日报，直接返回当前日期数据还未回收，终止运行
3. 默认多店铺：用户未指定具体店铺时，使用 get_multi_shop_report 一次性查询所有绑定店铺进行对比分析
4. 单店铺指定：用户明确指定了某个店铺时，先用 get_bindlist 取得该店 loginId，再走 get_multi_shop_report --NEWTON_SHOP_LOGIN_ID 复用同一套并发管线；get_trade_data / get_traffic_data / get_user_data 等原子命令保留用于临时补查
5. 并行执行：get_multi_shop_report 内部已把 N 店 × 2 天 × 3 接口 + 广告 + 评价全部并发执行（单店/多店同一套管线），无需 Agent 再手动并行编排
6. 精简输出：字数由身份决定（老板偏短，运营标准），具体见「报告生成规范·报告模板」
7. 禁止内容：长期建议、战略规划、重复分析、冗长表格
8. 此技能为只读操作，不会修改任何数据
9. 面向商家说人话：使用者是普通商家，展示给用户的文字禁止出现技术术语和内部实现（详见「输出语言规范」），内部处理过程不逐条播报

广告投放数据

日报每次生成时自动查询广告数据，已集成为内置能力，无需调用外部技能。

详细返回结构、字段说明、展示规则请查阅 references/capabilities.md 中「get_ad_report」章节。

• 多店铺模式：get_multi_shop_report 自动集成，结果在 adReport 字段
• 单店铺模式：get_multi_shop_report --NEWTON_SHOP_LOGIN_ID 已按该店集成广告数据；如需单独补查可调用 get_ad_report --query_date --NEWTON_SHOP_LOGIN_ID
• 广告数据为空（hasData=false）或查询失败时，省略广告板块

广告分析规范（生成日报广告板块与行动建议时必须遵守）

1. 🚫 禁止建议「暂停/关停/停投」任何广告计划：对低效计划一律采用「把预算再分配到投产比更高的计划/产品上」的话术，强调预算再分配而非停投
2. 品牌类广告不能仅看投产比：品牌类计划（如品牌专区、品牌展示、SKA 专属定制方案等）天然投产比偏低，核心价值在提升品牌曝光与人群触达；评价此类计划需结合曝光量、点击率综合判断，不得仅因投产比低就判定效果差
3. 预算下限提醒：单个广告产品日预算一般不低于 100 元，过低会投放不出去（竞价失败、曝光不足）；建议降预算时不得低于该下限，并主动提醒
4. 亏损预警须点名到计划：整体或单计划投产比 <1（成交额低于消耗）时，必须在风险板块显式预警，并附具体计划名称 + 消耗/成交额差值，禁止只报一个总数；消耗 >0 但成交额 =0 的计划展示「无成交」，不展示投产比数值
5. 同名计划聚合展示：托管类解决方案会返回多条同名子计划记录，topPlans 已在服务端按计划名称合并累加后重算投产比；分析和展示一律以合并后的计划维度呈现，禁止把同一方案拆成多行
6. 建议动作三要素：给出广告类行动建议时尽量包含操作路径（1688 卖家中心入口）、建议动作（调价/换关键词/调时段/优化创意等）与预期效果（如「点击率预计提升 10-20%」），并按优先级排序

商品评价数据

日报每次生成时自动查询当日评价数据，已集成为内置能力，无需调用外部技能。

• 多店铺模式：get_multi_shop_report 自动集成，结果在 reviewData 字段
• 单店铺模式：get_multi_shop_report --NEWTON_SHOP_LOGIN_ID 已按该店集成评价数据；如需单独补查可调用 get_review_data --query_date --NEWTON_SHOP_LOGIN_ID
• 评价数据为空（hasData=false）或查询失败时，省略评价板块
• 评分分类：5星=好评、3-4星=中评、1-2星=差评
• 自动收集好差评关键原因（去重后最多各 5 条）

执行前置（分阶段加载）

⚠️ 注意：所有文档均位于 {baseDir}/references/ 目录下，本项目没有 {baseDir}/capabilities/ 目录。

阶段零：技能触发时

• 直接确定报告日期并发起取数；Profile 字段（记忆）与取数同轮并行读取，不得为读字段单独占一轮。模板文件与阶段规则仍后移到【基础日报】输出之后（见阶段三）

阶段一：执行命令前（可选，仅在需要原子命令补查时）

⚠️ 单店铺与多店铺标准流程均使用 get_multi_shop_report 一条命令完成所有查询，通常无需加载此文档；仅当要用 get_trade_data 等原子命令临时补查时才需查阅。

• 阅读 {baseDir}/references/capabilities.md 了解各命令返回字段和数据结构

阶段二：生成【基础日报】时（无需读取任何文件）

• 核心摘要列按经营模式 × 阶段动态选取（Profile 字段已在阶段零并行读取；阶段按「报告生成规范·经营阶段」判定），不加载 Profile 模板文件；拿不到列集时用通用列（成交额/订单量/访客数/成交转化率）兜底（报告生成规范已内联在本文档，无需读取外部文件）

阶段三：【基础日报】输出之后（深度补充：Wiki 背景 + Profile + 补充查询）

⚠️ 必须先把【基础日报】输出给用户，才加载以下文档做深度补充。

• 根据经营模式加载对应 {baseDir}/references/profiles/{factory|trader|integrated}.md（Profile 字段已在阶段零并行读取；报告生成规范——阶段判定/归因深度/异常阈值/行动排序——已内联在「报告生成规范」章节，无需再读取文件；即上方流程 Step 4-6）
• 需要补充商家背景时：阅读 references/wiki-routing-rules.md，按其中规则决定是否调用 Wiki 模型工具

阶段四：【深度补充分析】也输出之后（构造行动选项时）

⚠️ 必须先把基础日报 + 深度补充都输出给用户，才能加载本文档；禁止提前加载。

• 构造行动选项时：阅读 {baseDir}/references/interaction-specs.md 了解交互组件结构