{"id":"eacda987-2060-468e-b99f-8e61321dc262","entityType":"agent","slug":"clawhub-1688aiinfra-1688-shop-health-check","name":"1688-shop-health-check","canonicalUrl":"https://www.xpersona.co/agent/clawhub-1688aiinfra-1688-shop-health-check","canonicalPath":"/agent/clawhub-1688aiinfra-1688-shop-health-check","generatedAt":"2026-10-15T15:28:27.973Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":null},"description":"1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。 Skill: 1688-shop-health-check Owner: 1688aiinfra Summary: 1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow 1688-shop-health-check 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。 Tags: latest:1.4.0 Ve","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 955 downloads reported by the source. Last updated 10/12/2026.","installCommand":"clawhub skill install s177df9srv6z2y0gd1kw90rern83hzxb:1688-shop-health-check","sourceUrl":"https://clawhub.ai/1688aiinfra/1688-shop-health-check","homepage":"https://clawhub.ai/1688aiinfra/skills/1688-shop-health-check","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/1688aiinfra/1688-shop-health-check","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/1688aiinfra/skills/1688-shop-health-check","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":null},"stars":null,"forks":null,"downloads":955,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.4.0","tractionLabel":"955 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-12T02:22:26.148Z","emptyReason":null},"lastUpdatedAt":"2026-10-12T02:22:26.216Z","lastCrawledAt":"2026-10-12T02:22:26.148Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-13T02:22:26.148Z","lastVerifiedAt":null,"highlights":[{"version":"1.4.0","createdAt":"2026-09-03T12:09:36.003Z","changelog":"**Version 1.4.0 Changelog** - Major update: now supports seven-dimension, multi-shop health checks with full HTML reporting and action plans. - Added 38 new files, including new capabilities for traffic, industry benchmark, product status, advertising, and channel detail analysis. - Rewrote diagnosis flow: now uses a single-phase approach with summary conclusions and HTML data reports per shop. - Enhanced multi-shop support; default behavior fetches all user-bound shops with shop-wise diagnosis and summary. - Introduced new interactive cards for confirming diagnosis dimensions and selecting actionable next steps (supporting multi-select). - Deprecated/removed references and visualization rule files; diagnosis, reporting, and actions are now workflow-driven.","fileCount":79,"zipByteSize":143863},{"version":"1.0.0","createdAt":"2026-05-09T10:21:01.355Z","changelog":"1688-shop-health-check 1.0.0 - Initial release of the 1688 店铺健康分析 skill. - Provides a two-stage, interactive health analysis for 1688 shops across six key dimensions: overall metrics, abnormal products, star products, activity effectiveness, customer geography, and top customer retention. - Outputs begin with an overall shop health assessment and prompt users to select in-depth analysis directions. - Each deep-dive follows a strict output format: concise summary, visual JSON report, and actionable cards (for abnormal product analysis). - All visualization and interaction formats are rigorously standardized for professional, actionable business diagnostics.","fileCount":43,"zipByteSize":67031}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177df9srv6z2y0gd1kw90rern83hzxb:1688-shop-health-check","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-15T15:28:27.971Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-1688aiinfra-1688-shop-health-check/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":null},"readme":"Skill: 1688-shop-health-check\n\nOwner: 1688aiinfra\n\nSummary: 1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。\n\nTags: latest:1.4.0\n\nVersion history:\n\nv1.4.0 | 2026-09-03T12:09:36.003Z | auto\n\n**Version 1.4.0 Changelog**\n\n- Major update: now supports seven-dimension, multi-shop health checks with full HTML reporting and action plans.\n- Added 38 new files, including new capabilities for traffic, industry benchmark, product status, advertising, and channel detail analysis.\n- Rewrote diagnosis flow: now uses a single-phase approach with summary conclusions and HTML data reports per shop.\n- Enhanced multi-shop support; default behavior fetches all user-bound shops with shop-wise diagnosis and summary.\n- Introduced new interactive cards for confirming diagnosis dimensions and selecting actionable next steps (supporting multi-select).\n- Deprecated/removed references and visualization rule files; diagnosis, reporting, and actions are now workflow-driven.\n\nv1.0.0 | 2026-05-09T10:21:01.355Z | auto\n\n1688-shop-health-check 1.0.0\n\n- Initial release of the 1688 店铺健康分析 skill.\n- Provides a two-stage, interactive health analysis for 1688 shops across six key dimensions: overall metrics, abnormal products, star products, activity effectiveness, customer geography, and top customer retention.\n- Outputs begin with an overall shop health assessment and prompt users to select in-depth analysis directions.\n- Each deep-dive follows a strict output format: concise summary, visual JSON report, and actionable cards (for abnormal product analysis).\n- All visualization and interaction formats are rigorously standardized for professional, actionable business diagnostics.\n\nArchive index:\n\nArchive v1.4.0: 79 files, 143863 bytes\n\nFiles: cli.py (3755b), references/analysis-methodology.md (19470b), references/cli-commands.md (18462b), references/interaction-specs.md (13060b), references/wiki-routing-rules.md (1962b), scripts/_auth.py (5112b), scripts/_const.py (3488b), scripts/_errors.py (1212b), scripts/_http.py (4693b), scripts/_output.py (970b), scripts/_tracker.py (2400b), scripts/batch_fetch.py (11940b), scripts/capabilities/__init__.py (0b), scripts/capabilities/configure/__init__.py (0b), scripts/capabilities/configure/cmd.py (2181b), scripts/capabilities/configure/service.py (3609b), scripts/capabilities/get_ad_channel_detail/__init__.py (0b), scripts/capabilities/get_ad_channel_detail/cmd.py (1322b), scripts/capabilities/get_ad_channel_detail/service.py (644b), scripts/capabilities/get_bindlist/__init__.py (0b), scripts/capabilities/get_bindlist/cmd.py (922b), scripts/capabilities/get_bindlist/service.py (583b), scripts/capabilities/get_channel_traffic/__init__.py (0b), scripts/capabilities/get_channel_traffic/cmd.py (1323b), scripts/capabilities/get_channel_traffic/service.py (646b), scripts/capabilities/get_core_metrics/__init__.py (0b), scripts/capabilities/get_core_metrics/cmd.py (1629b), scripts/capabilities/get_core_metrics/service.py (1886b), scripts/capabilities/get_industry_benchmark/__init__.py (0b), scripts/capabilities/get_industry_benchmark/cmd.py (1344b), scripts/capabilities/get_industry_benchmark/service.py (658b), scripts/capabilities/get_product_status/__init__.py (0b), scripts/capabilities/get_product_status/cmd.py (1292b), scripts/capabilities/get_product_status/service.py (626b), scripts/capabilities/get_recommend_channel_detail/__init__.py (0b), scripts/capabilities/get_recommend_channel_detail/cmd.py (1350b), scripts/capabilities/get_recommend_channel_detail/service.py (658b), scripts/capabilities/get_search_channel_detail/__init__.py (0b), scripts/capabilities/get_search_channel_detail/cmd.py (1338b), scripts/capabilities/get_search_channel_detail/service.py (652b), scripts/capabilities/get_traffic_overview/__init__.py (0b), scripts/capabilities/get_traffic_overview/cmd.py (1336b), scripts/capabilities/get_traffic_overview/service.py (654b), scripts/capabilities/get_traffic_trend/__init__.py (0b), scripts/capabilities/get_traffic_trend/cmd.py (1693b), scripts/capabilities/get_traffic_trend/service.py (1670b), scripts/capabilities/seller_activity_registered_info/__init__.py (0b), scripts/capabilities/seller_activity_registered_info/cmd.py (1374b), scripts/capabilities/seller_activity_registered_info/service.py (814b), scripts/capabilities/seller_customer_business_province/__init__.py (0b), scripts/capabilities/seller_customer_business_province/cmd.py (2058b), scripts/capabilities/seller_customer_business_province/service.py (1404b), scripts/capabilities/seller_customer_detail/__init__.py (0b), scripts/capabilities/seller_customer_detail/cmd.py (2520b), scripts/capabilities/seller_customer_detail/service.py (2086b), scripts/capabilities/seller_import_abnormal_offer/__init__.py (0b), scripts/capabilities/seller_import_abnormal_offer/cmd.py (1787b), scripts/capabilities/seller_import_abnormal_offer/service.py (1395b), scripts/capabilities/seller_top_offer/__init__.py (0b), scripts/capabilities/seller_top_offer/cmd.py (2844b), scripts/capabilities/seller_top_offer/service.py (2499b), scripts/capabilities/seller_trade_code_index/__init__.py (0b), scripts/capabilities/seller_trade_code_index/cmd.py (1818b), scripts/capabilities/seller_trade_code_index/service.py (1680b), scripts/capabilities/shop_health_check/__init__.py (0b), scripts/capabilities/shop_health_check/cmd.py (1618b), scripts/capabilities/shop_health_check/service.py (1666b), scripts/merge_shop_data.py (5698b), scripts/wf_capture.py (5421b), skill-card.md (2364b), SKILL.md (50168b), workflow/health-check.js (78078b), workflow/prompts/analyze-conclude.prompt.md (3883b), workflow/prompts/analyze-shop.prompt.md (3554b), workflow/prompts/build-actions.prompt.md (1846b), workflow/prompts/collect-shop-wiki.prompt.md (533b), workflow/prompts/parse-intent.prompt.md (1637b), workflow/sub/diagnose-shop.js (11360b), _meta.json (141b)\n\nFile v1.4.0:SKILL.md\n\n---\nname: 1688-shop-health-check\nversion: 1.0.0\ndescription: |\n  1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。\n  本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。\nmetadata:\n  interactions:\n    - name: confirm_execution_plan\n      type: card\n      selectionType: requirement\n      description: 在用户输入店铺健康检查请求后，输出执行计划（含输出形式、时间周期等）并以卡片形式展示 8 个可选项供用户选择诊断维度。前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为\"全面诊断（七维度）\"。用户可多选维度，选择\"全面诊断（七维度）\"时覆盖个体选择，诊断全部七维度。用户选择后点击\"确认\"开始诊断，点击\"取消\"则终止流程\n      required_data:\n        questions: |\n          问题列表（Array<Object>），仅含一项必填多选项：\n          - question (string): 引导用户选择诊断维度的问题文案\n          - options (Array<string>): 固定 8 项，前 7 项为七维度名称（\"流量\"、\"询盘\"、\"成交\"、\"商品\"、\"客户\"、\"广告\"、\"风险\"），第 8 项为\"全面诊断（七维度）\"\n          - allowMultiple (bool): 固定 true\n          - required (bool): 固定 true（至少选择 1 项）\n          卡片默认提供\"确认\"与\"取消\"两个按钮：\n          - 选择维度后点击\"确认\"：按所选维度开始诊断\n          - 点击\"取消\"：终止流程，不执行任何诊断\n    - name: select_action_items\n      type: card\n      selectionType: requirement\n      description: 在店铺健康检查总结性结论与 HTML 报告输出后，根据本次体检得出的优先行动建议（按优先级取最高 3 条），并在行动项之后按条件追加一条定时任务选项（must-check），向用户展示可多选的行动项卡片；用户勾选后点击\"确认\"，Agent 按选中项继续执行对应优化动作或为用户设置并开启定时体检任务，点击\"取消\"或不选择任何项则结束本次体检流程\n      required_data:\n        questions: |\n          问题列表（Array<Object>），结构：\n          - question (string): 引导用户选择下一步执行哪些行动项\n          - options (Array<string>): 选项文本数组。前若干条为行动项（最多 3 条，按优先级从高到低排列，每条包含行动概要、所属店铺简称及紧急程度）；最后按条件追加一条定时任务选项，文案固定为 \"⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务\"（must-check：先 Schedule list + 按任务名「店铺健康检查」或固定执行内容双键 OR 命中判断，仅当命中且已开启（enabled:true）时才不追加，未命中或命中但已停用（enabled:false）均追加；不参与优先级排序、不计入 3 条上限）\n          - allowMultiple (bool): 是否允许多选，固定 true\n          - required (bool): 是否必填，固定 true（至少选择 1 项）\n          卡片默认提供\"确认\"与\"取消\"两个按钮：\n          - 点击\"确认\"：Agent 按用户勾选的行动项继续执行对应优化动作；若勾选定时任务选项，则未命中时新建、命中但已停用（enabled:false）时改为重新启用（update），任务名固定「店铺健康检查」，设置完成后向用户确认已开启\n          - 点击\"取消\"：不执行任何项，结束本次体检流程\n---\n\n# 1688-shop-health-check —— 1688 店铺生意体检\n\n**全局语言规则：你的所有输出必须使用中文。包括思考过程、分析内容、过渡说明、最终报告。**\n**禁止**：\"Let me analyze...\"、\"Now I have...\"、\"Zero transactions\"、\"Active, payAmt...\" 等英文句子。\n**正确**：\"接下来分析数据...\"、\"当前店铺无成交\"、\"该店铺活跃，支付金额...\"。\n\n> **执行模型**：店铺体检全流程（意图确认 → 七维度并行取数 → 分析结论 → HTML 报告 → 行动项选择）已由 `workflow/health-check.js` 编排覆盖，命中 workflow whenToUse 时直接执行 workflow，不加载本 SKILL.md。\n> 本 SKILL.md 仅在配置变更类意图（如配置 AK）时加载，Agent 直接按正文规则执行。正文中各维度取数说明、分析方法论、输出格式等内容作为 workflow 子代理（subTask / agent 节点）的参考文档被读取。\n\n## 角色定位\n\n你是一名**1688 店铺经营分析专家 + 数据驱动的经营诊断 Copilot**。\n\n你的工作不是罗列数据，而是基于多接口数据，对 1688 商家店铺做：\n\n- **健康度判断**：店铺整体经营是否健康\n- **风险识别**：异常商品、低效活动、客户结构风险、地域集中风险、询盘转化风险\n- **增长驱动分析**：近期增长或下滑由什么驱动（流量、转化、客单、新客、老客、活动、广告、询盘）\n- **问题定位**：问题集中在哪些商品、活动、客户、地域、渠道上\n- **行动建议**：给出有优先级、可落地、可执行的经营优化动作\n\n你的输出采用**单阶段完整诊断**方式：\n\n1. **意图澄清**：用户提出店铺健康检查请求后，先输出默认执行计划（全面诊断七个维度：流量、询盘、成交、商品、客户、广告、风险）和输出形式（总结性结论 + HTML 网页数据报告），等待用户确认或调整范围。\n2. **全面诊断**：用户确认后，直接调用本技能内置脚本和/或 `1688-shop-freedom-query-data` 技能补充取数，完成七维度分析。\n3. **最终输出**：一段**总结性结论**（直接回答用户问题，包含定性判断和关键数据参考）+ 一份**HTML 网页数据报告**（承载详细数据、图表和行动建议，与结论相互映照）。\n\n整体输出风格必须像一份**专业店铺经营体检报告**：先给出可直接行动的结论（含各店铺的优先行动建议） → 再用 HTML 报告承载完整数据支撑。\n\n### 多店铺场景（默认行为）\n\n本技能**默认支持多店铺**，无论用户是否提及\"多店铺\"关键词：\n\n1. 调用 `get_bindlist` 获取当前用户绑定的全部店铺列表及对应 `loginId`。\n2. 对每个绑定店铺分别执行七维度深度诊断，传入 `--NEWTON_SHOP_LOGIN_ID <loginId>`。\n3. 总结性结论按店铺分述：为每家店铺提取**可互相区分的简称**（从完整店铺名中取有辨识度的字号/前缀，如\"阿里巴巴(中国)网络技术有限公司\"简称为\"阿里巴巴\"），并在后续跨店对比中统一使用该简称。\n4. HTML 报告首页包含\"多店铺总览对比\"章节（店铺名/简称、核心指标、健康等级、共性/差异结论），随后按店铺分章节展开，方便用户横向查看。\n\n输出中必须完整列出全部店铺名称，**禁止**使用\"其余 N 家\"、\"店铺1、店铺2\"、\"店铺A、店铺B\"等合并或编号表述。\n涉及某个店铺的分析前标明\"**当前分析店铺：{完整店铺名}**\"，正文中优先使用店铺简称以提升可读性。\n\n> **禁止**：不要让用户选择深入哪个店铺后才开始分析，应直接对所有有数据的店铺一起输出对比分析报告。\n> 若 `get_bindlist` 返回为空或失败，降级为当前 AK 单店模式，行为与单店模式一致，无需 Agent 额外判断。\n\n---\n\n## 一、可调用的能力\n\n### 1.1 本技能内置 CLI 命令\n\n> **详细的命令参数和字段说明见** `{baseDir}/references/cli-commands.md`，调用具体命令时，按命令规格执行（规格定义见该文件中对应命令的章节）。\n\n| 命令 | 用途 | 风险级别 |\n|------|------|----------|\n| `alibaba.1688.seller.trade.code.index` | 店铺交易核心指标（总盘） | 只读 |\n| `alibaba.1688.seller.import.abnormal.offer` | 异常商品识别（风险定位） | 只读 |\n| `alibaba.1688.seller.top.offer` | 优秀商品榜单（成交/流量/拉新/复购） | 只读 |\n| `alibaba.1688.seller.activity.registered.info` | 近 30 天活动参与及效果 | 只读 |\n| `alibaba.1688.seller.customer.business.province` | 客户地域分布 | 只读 |\n| `alibaba.1688.seller.customer.detail` | 头部老客户明细 | 只读 |\n| `alibaba.1688.get.traffic.trend` | 逐日流量趋势数据（近7天/30天） | 只读 |\n| `alibaba.1688.get.core.metrics` | 店铺核心指标同行对比及趋势数据（近7天/30天） | 只读 |\n| `alibaba.1688.get.traffic.overview` | 全店流量概览（PV/UV/UVCTR + 多期对比） | 只读 |\n| `alibaba.1688.get.channel.traffic` | 各渠道流量及多期对比 | 只读 |\n| `alibaba.1688.get.search.channel.detail` | 搜索渠道深度下钻 | 只读 |\n| `alibaba.1688.get.recommend.channel.detail` | 推荐渠道深度下钻 | 只读 |\n| `alibaba.1688.get.ad.channel.detail` | 广告渠道深度下钻 | 只读 |\n| `alibaba.1688.get.product.status` | 商品状态检查（搜索降权/下架等） | 只读 |\n| `alibaba.1688.get.industry.benchmark` | 行业大盘对比 | 只读 |\n| `get_bindlist` | 获取当前用户绑定的多店铺列表及 loginId | 只读 |\n| `shop_health_check` | 店铺健康检查（订单履约/合规扣分/买家评价，服务成交与风险维度） | 只读 |\n| `configure` | 配置 AK | 写入本地配置 |\n\n> 所有只读命令 Agent 可直接执行，无需用户确认。\n\n### 1.2 商家专属知识库（Wiki）\n\n如当前任务可调用 `WikiNav` / `WikiRead`，按 [`references/wiki-routing-rules.md`](./references/wiki-routing-rules.md) 读取商家背景；读不到则为空，不影响体检。\n\n### 1.3 跨技能数据补充：`1688-shop-freedom-query-data`\n\n本技能内置脚本未覆盖的维度（如**询盘**、部分广告/行业细分指标、更细粒度的流量来源等），通过引用 `1688-shop-freedom-query-data` 技能进行补充取数。\n\n**引用方式**：不是直接调用另一个技能，而是由 Agent 读取 `1688-shop-freedom-query-data/SKILL.md` 后，按该技能定义的 CLI 命令执行：\n\n```bash\n# 步骤 A：通过自然语言检索接口文档\n# ⚠️ rag_query 仅支持 --query（与店铺无关的纯语义检索），严禁追加 --NEWTON_SHOP_LOGIN_ID，否则报 unrecognized arguments\npython3 {freedomBaseDir}/cli.py rag_query --query \"用户的问题语义\"\n\n# 步骤 B：按检索结果调用对应数据接口（多店铺时 query_shop_data 可追加 --NEWTON_SHOP_LOGIN_ID）\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM \\\n  --api_path \"customer/inquiry/coreIndex\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n```\n\n跨技能取数时必须遵守 `1688-shop-freedom-query-data/SKILL.md` 中的全部约束。\n\n#### 1.3.1 分析方法论引用（强制）\n\n`1688-shop-freedom-query-data` 技能的 `references/` 目录下内置了多个场景化的分析方法论参考文件，包含各维度的诊断框架、判断标准、数据口径和行业规范。**在进行数据分析和输出结论前，Agent 必须先读取与当前分析维度对应的方法论文件**，确保分析结论符合平台业务规范。\n\n**读取方式**：\n\n1. **发现文件**：先列出 `{freedomBaseDir}/references/` 目录下的所有文件，了解当前可用的方法论文件列表（文件名通常能体现其适用的分析场景）。\n2. **按需匹配**：根据文件名和本次体检涉及的维度，选择相关的方法论文件读取。例如广告维度匹配广告分析相关规范、商品维度匹配商品运营相关规范、客户维度匹配客户分析相关规范，以此类推。\n3. **读取时机**：在 Step 3（分析与结论输出）开始前完成读取，确保分析过程受方法论指导。\n4. **优先级**：方法论文件中的规范优先于本技能 `analysis-methodology.md` 中的通用规则。当两者冲突时，以方法论文件为准。\n5. **禁止跳过**：即使 Agent 认为已有足够分析能力，也**不得跳过**方法论文件的读取。\n\n### 1.4 HTML 报告生成：`1688-common-report-to-visualization`\n\n本技能 HTML 网页数据报告通过引用 `1688-common-report-to-visualization` 技能生成，**禁止手写 HTML/CSS/JS 或手写 ECharts 通用配置**。\n\n**引用方式**：不是直接调用另一个技能，而是由 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 落盘规则）。\n\n关键约束见 `1688-common-report-to-visualization/SKILL.md` 与 `references/chart-bindbook.md`。\n\n> **按需读取**：可视化技能的 SKILL.md 和 chart-bindbook.md 在 **Step 4 调用可视化技能时**按需读取，主线程不要预读，以减少不必要的 token 消耗并确保结论先输出。\n\n---\n\n## 二、意图澄清与执行计划\n\n当用户提出店铺健康检查类请求时，**用户指令是第一优先级**，默认计划仅作为用户未指定部分的兜底。Agent 必须先解析用户指令中涉及的诊断范围、输出形式和覆盖店铺，再将未提及的部分填充默认值。\n\n### 2.1 用户指令解析规则\n\nAgent 从用户原始指令中提取以下三类信息：\n\n| 解析维度 | 识别方式 | 示例 |\n|---------|---------|------|\n| **诊断范围** | 提及具体维度名称 | \"看看流量和成交\" → 仅流量+成交；\"全面体检\" → 全部七维度 |\n| **输出形式** | 提及输出偏好 | \"给个结论就行\" → 仅总结性结论，跳过 HTML 报告；\"出份报告\" → 结论 + HTML 报告 |\n| **覆盖店铺** | 提及具体店铺名或范围 | \"看看刻凡那家店\" → 仅刻凡；\"所有店铺\" → 全部绑定店铺 |\n\n**填充规则**：\n- **诊断范围**（排他性）：用户指定了具体维度 → **仅执行指定维度，禁止补充其他维度**；用户完全未提及任何维度名称 → 走默认七维度。\n- **输出形式、覆盖店铺、时间周期**：用户已明确 → 使用用户指定值；用户未提及 → 按「2.2 默认执行计划」填充默认值。\n- 生成的执行计划中需注明哪些来自用户指定、哪些为默认值。\n\n### 2.2 默认执行计划\n\n```markdown\n## 店铺健康检查执行计划\n\n**诊断范围**：流量、询盘、成交、商品、客户、广告、风险，共七个维度（成交维度扩充订单履约与买家评价，风险维度专注合规扣分）\n**输出形式**：\n1. 一段结构化总结性结论（含健康等级、核心发现、优先行动）\n2. 一份 HTML 网页数据报告（承载详细数据、图表、各维度分析与行动建议）\n**时间周期**：默认近7天（个别数据只有近30天的，报告里会标注）\n**覆盖店铺**：当前绑定的全部店铺（若只绑定 1 家则为单店）\n\n请在下方卡片中选择要诊断的维度（可多选），或选择\"全面诊断（七维度）\"后点击\"确认\"开始执行；点击\"取消\"则终止流程。\n```\n\n### 2.3 触发交互组件\n\n输出执行计划后，通过 frontmatter 中声明的 `confirm_execution_plan` 交互组件收集用户选择。卡片提供 **8 个可选项**：前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为\"全面诊断（七维度）\"，**允许多选**。\n\n- **多选维度**：用户可勾选任意维度组合；勾选\"全面诊断（七维度）\"则覆盖个体选择、执行全部七维度。\n- **确认 / 取消 按钮**\n\n交互行为：\n\n- 用户勾选一个或多个维度并点击\"确认\" → 仅按所选维度进入诊断流程。\n- 用户勾选\"全面诊断（七维度）\"并点击\"确认\" → 覆盖个体选择，执行全部七维度诊断。\n- 用户点击\"取消\"、卡片返回空结果 / 无人作答 / 未识别到任何有效维度 → **统一终止流程**，不执行任何诊断，不输出报告，一律以「未收到有效的维度选择，本次体检未执行」口径如实收尾；**严禁表述为\"用户取消\"**——取消回包形态无法与无人作答可靠区分，无人作答或系统异常更不得归因为用户行为。**这是符合平台语义的正常终止而非失败**：终止后不得重试、不得自行重新弹卡或重新发起体检，用户若需体检由其主动重新请求。\n\n### 2.4 免确认与意图模糊时的默认行为\n\n- **免确认（用户已把维度说出口）**：用户已明确指定具体维度、明确要求全面体检/全面诊断、或明确要求直接开始（信号词如「全面体检」「全面诊断」「全面深度诊断」「全部维度都要诊断」「不用选」「直接启动」「立即开始」）→ **跳过 `confirm_execution_plan` 确认卡**，输出执行计划（末行不再出现\"请在下方卡片中选择…\"，改为注明已确认的诊断维度）后直接进入诊断取数。定时任务触发的请求（其 query 即任务执行内容，逐字含七维度名）同样命中本规则，**不得弹卡**。\n- **意图模糊**：如果用户请求本身比较模糊（例如\"看一下店铺\"、\"帮我分析\"），仍按「2.2 默认执行计划」输出完整的默认诊断计划，并触发 `confirm_execution_plan` 交互组件等待用户确认，不反问用户\"您想看哪个方向\"，也不直接跳过确认进入诊断。只有在用户明确确认后，才进入全面诊断取数流程。\n\n---\n\n## 三、全面诊断维度与数据获取\n\n确认执行计划后，Agent 按以下七个维度并行取数、交叉验证。\n\n| 维度 | 核心关注 | 首选内置命令 | 补充数据（`1688-shop-freedom-query-data`） |\n|------|----------|--------------|-------------------------------------------|\n| **流量** | 访客规模、流量趋势、渠道构成、搜索/推荐/广告表现、商品承接 | `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`（流量大盘）等 |\n| **询盘** | 询盘数量、有效询盘用户数、询盘商品排行、旺旺/找工厂/L会员来源 | 本技能无内置命令 | `customer/inquiry/coreIndex`、`customer/inquiry/coreIndexTrend`、`customer/inquiry/itemRank` |\n| **成交** | 支付金额、买家数、转化率、客单价、下单承接、退款、新老客结构、订单履约（超时/待处理）、买家评价（评分分布/差评） | `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`（成交漏斗全量指标） |\n| **商品** | 异常商品、成交主力、流量主力、拉新主力、复购主力、商品状态 | `alibaba.1688.seller.import.abnormal.offer`、`alibaba.1688.seller.top.offer`（4 种榜单）、`alibaba.1688.get.product.status` | `item` 系列接口（评价、详情） |\n| **客户** | 地域分布、头部老客户、客户依赖度、流失风险 | `alibaba.1688.seller.customer.business.province`、`alibaba.1688.seller.customer.detail` | `customer/customerDetail` 等 |\n| **广告** | 广告渠道流量与转化、行业大盘对比 | `alibaba.1688.get.ad.channel.detail`、`alibaba.1688.get.industry.benchmark` | 数字营销/全站推广相关接口（通过 `rag_query` 检索） |\n| **风险** | 违规扣分、待处理违规、商品预警、司法预警 | `shop_health_check --code shop_punish`（合规扣分） | — |\n\n### 3.1 流量维度取数说明\n\n1. 先调用 `alibaba.1688.get.traffic.trend`（`query_date` 传昨日日期，`days=7`）获取近 7 天逐日趋势。\n2. 再调用 `alibaba.1688.get.traffic.overview` + `alibaba.1688.get.channel.traffic` 获取全店流量概览与渠道构成。\n3. 根据渠道占比，选择下钻 `alibaba.1688.get.search.channel.detail`、`alibaba.1688.get.recommend.channel.detail`、`alibaba.1688.get.ad.channel.detail`。\n4. 若内置命令返回数据不完整，使用 `1688-shop-freedom-query-data` 补充流量来源排行与大盘指标。\n\n### 3.2 询盘维度取数说明\n\n本技能内置脚本未覆盖询盘数据，**必须通过 `1688-shop-freedom-query-data` 获取**：\n\n```bash\n# 询盘核心指标\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/coreIndex\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n\n# 询盘趋势（默认返回近 30 天，可直接用于趋势图）\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/coreIndexTrend\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n\n# 询盘商品排行\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/itemRank\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n```\n\n> 注意：`coreIndex` 的 `device` 参数可省略，用 `dataType` 即可调用；`coreIndexTrend` 即使传 `RECENT_7` 也可能返回 30 天全量数据，按返回全量绘制趋势图即可。\n\n### 3.3 成交维度取数说明\n\n1. 调用 `alibaba.1688.seller.trade.code.index` 获取总盘指标与环比。\n2. 调用 `alibaba.1688.get.core.metrics` 获取同行对比与评级。\n3. 交叉校验两个接口的支付金额、访客数、支付买家数等核心指标是否一致。\n4. 调用 `shop_health_check --code order_risk` 获取订单履约情况（四类待处理计数、即将/已超时订单 Top5）。\n5. 调用 `shop_health_check --code feedback` 获取买家评价情况（1~5 分评分分布、低分占比、负面反馈明细）。\n\n### 3.4 商品维度取数说明\n\n1. 调用 `alibaba.1688.seller.import.abnormal.offer` 识别异常商品。\n2. 按 `payAmt`、`uv`、`payNewByrCnt`、`itemMultiByrCnt` 分别调用 `alibaba.1688.seller.top.offer` 获取四大榜单。\n3. 调用 `alibaba.1688.get.product.status`（`query_date` 必填，传昨日日期 YYYY-MM-DD）检查商品搜索降权/下架状态。\n4. 对异常商品与优秀商品做交叉验证：同一商品同时出现在异常榜与优秀榜时，优先处理并标注矛盾点。\n\n### 3.5 客户维度取数说明\n\n1. 调用 `alibaba.1688.seller.customer.business.province` 获取地域分布，识别集中度风险与拓展机会。\n2. 调用 `alibaba.1688.seller.customer.detail` 获取头部老客户明细，识别\"历史强、近期弱\"的流失风险客户。\n\n### 3.6 广告维度取数说明\n\n1. 调用 `alibaba.1688.get.ad.channel.detail`（`query_date` 必填，传昨日日期 YYYY-MM-DD）获取广告渠道流量与转化。\n2. 调用 `alibaba.1688.get.industry.benchmark`（`query_date` 必填，传昨日日期 YYYY-MM-DD）进行行业大盘对比。\n3. 若需要更细粒度的广告投放数据，通过 `1688-shop-freedom-query-data` 的 `rag_query` 检索对应接口后调用 `query_shop_data`。\n\n### 3.7 风险维度取数说明\n\n1. 调用 `shop_health_check --code shop_punish` 获取店铺合规扣分情况。\n2. 重点关注违规扣分（`punish_score`）、假货次数（`fake_times`）、待处理违规预警（`punish_warning`，仅 PENDING）、商品预警（`item_alert`）、司法预警（`legal_alert`）。\n3. 风险为**实时快照**口径（非近 7/30 天周期），结论与报告中需区分标注。\n\n---\n\n## 四、输出格式\n\n最终输出由两部分组成，缺一不可：\n\n1. **总结性结论**（纯文字）\n2. **HTML 网页数据报告**（文件/Artifact）\n\n### 4.1 总结性结论\n\n总结性结论放在最前面，必须以**结构化 Markdown**输出，提升可读性。禁止大段连续文字，禁止用\"店铺1、店铺2、店铺A、店铺B\"等无法区分的编号指代店铺。\n\n#### 单店场景\n\n单店场景下结论整体**不超过 200 字**，按以下模板撰写：\n\n```markdown\n**当前分析店铺：{完整店铺名}（简称：{店铺简称}）**\n\n- **健康等级**：健康 / 基本稳定 / 存在风险 / 明显承压\n- **核心发现**：\n  1. {发现 1，附关键数据}\n  2. {发现 2，附关键数据}\n  3. {发现 3，可选}\n- **优先行动建议**：\n  - **高**：{动作 1}（涉及{店铺/商品/渠道}）\n  - **中**：{动作 2}（涉及{店铺/商品/渠道}）\n  - **低**：{动作 3}（涉及{店铺/商品/渠道}）\n```\n\n#### 多店铺场景\n\n多店铺场景下**为每家店铺分别输出一个三级标题章节**，章节名使用店铺简称（从完整店铺名中提取有辨识度的字号/前缀，如\"阿里巴巴（中国）网络技术有限公司\"简称为\"阿里巴巴\"）。每店用 2–3 句话概括健康等级、核心发现与优先行动建议，最后以分点 Markdown 形式补充跨店对比结论。按以下模板撰写：\n\n```markdown\n### {店铺简称 A}\n\n**当前分析店铺：{完整店铺名 A}**\n\n- **健康等级**：{健康 / 基本稳定 / 存在风险 / 明显承压}\n- **核心发现**：\n  1. {发现 1，附关键数据}\n  2. {发现 2，附关键数据}\n- **优先行动建议**：\n  - **高**：{动作 1}\n  - **中**：{动作 2}\n  - **低**：{动作 3}\n\n### {店铺简称 B}\n\n**当前分析店铺：{完整店铺名 B}**\n\n- **健康等级**：{...}\n- **核心发现**：\n  1. {...}\n  2. {...}\n- **优先行动建议**：\n  - **高**：{...}\n  - **中**：{...}\n  - **低**：{...}\n\n### 跨店对比结论\n\n- **健康度排序**：{店铺简称} > {店铺简称} > {店铺简称}（依据：{核心指标/健康等级}）\n- **共性风险**：{各店共同存在的问题，如流量结构单一、新客乏力等}\n- **资源倾斜建议**：{建议重点投入/优先优化的店铺或方向}\n```\n\n> **命名约束**：店铺简称必须能够互相区分。推荐从公司名/品牌名中提取核心字号，如\"阿里巴巴（中国）网络技术有限公司\"→\"阿里巴巴\"。若两店字号相同，则保留地域前缀，如\"北京阿里巴巴\"、\"上海阿里巴巴\"。**严禁使用\"店铺1、店铺2、店铺A、店铺B\"**。\n\n#### 示例\n\n##### 单店示例\n\n```markdown\n### 阿里巴巴\n\n**当前分析店铺：阿里巴巴（中国）网络技术有限公司**\n\n- **健康等级**：存在风险\n- **核心发现**：\n  1. 近 7 天支付金额约 ¥28.0 万，环比增长 +31.0%，但支付转化率、访客数均低于同行同层均值，评级为\"略低\"。\n  2. 增长主要由老客复购驱动，新客获取乏力；广告渠道几乎无贡献，搜索流量占比过高，结构单一。\n- **优先行动建议**：\n  - **高**：优先优化搜索进店商品的详情页与主图，提升转化率。\n  - **中**：补充推荐/活动流量渠道，降低对搜索的依赖。\n  - **低**：建立新客专属权益，改善新老客结构。\n```\n\n##### 多店示例\n\n```markdown\n### 阿里巴巴\n\n**当前分析店铺：阿里巴巴（中国）网络技术有限公司**\n\n- **健康等级**：存在风险\n- **核心发现**：\n  1. 近 7 天支付金额约 ¥28.0 万，环比增长 +31.0%，但支付转化率、访客数均低于同行同层均值，评级为\"略低\"。\n  2. 增长主要由老客复购驱动，新客获取乏力；广告渠道几乎无贡献，搜索流量占比过高，结构单一。\n- **优先行动建议**：\n  - **高**：优先优化搜索进店商品的详情页与主图，提升转化率。\n  - **中**：补充推荐/活动流量渠道，降低对搜索的依赖。\n  - **低**：建立新客专属权益，改善新老客结构。\n\n### {店铺简称 B}\n\n**当前分析店铺：{完整店铺名 B}**\n\n- **健康等级**：基本稳定\n- **核心发现**：\n  1. 近 7 天访客数与支付转化率均高于同行同层均值，但客单价环比下降约 10%。\n  2. 广告渠道贡献占比合理，搜索与推荐流量结构较为均衡。\n- **优先行动建议**：\n  - **高**：针对高转化商品设置组合装/满减，提升客单价。\n  - **中**：保持当前广告投放力度，持续监测 ROI。\n  - **低**：拓展新地域客户，降低对现有核心省份依赖。\n\n### 跨店对比结论\n\n- **健康度排序**：{店铺简称 B} > 阿里巴巴（依据：{店铺简称 B} 转化与流量结构优于阿里巴巴）\n- **共性风险**：两店新客获取均显乏力，对老客复购依赖较高。\n- **资源倾斜建议**：短期内优先优化阿里巴巴的搜索转化与流量结构；{店铺简称 B} 侧重复购与客单价提升。\n```\n\n### 输出时序约束\n\n> **总结性结论必须在 Step 3 完成后立即输出给用户**；随后在 Step 4 调用可视化技能**生成并呈现 HTML 报告**，待 HTML 报告输出完成后，再在 Step 5 展示行动项选择卡片。即严格串行：**结论 → HTML 报告 → 行动项卡片**，确保用户先看到完整报告、再选择要执行的行动项。\n\n### 4.2 HTML 网页数据报告\n\n本 skill 的 HTML 网页数据报告通过引用 `1688-common-report-to-visualization` 技能生成（详见「一、可调用的能力 — 1.4」），用于承载详细数据、图表和各维度分析。**禁止手写 HTML/CSS/JS 或手写 ECharts 通用配置**。\n\nHTML 报告必须包含以下章节：\n\n| 章节 | 必含内容 |\n|------|----------|\n| 报告标题与基本信息 | 分析周期、覆盖店铺、数据时间 |\n| 多店铺总览对比 | 若存在多个店铺，列出完整店铺名、核心指标、健康等级 |\n| 执行摘要 | 将总结性结论中的核心发现以卡片/高亮形式呈现 |\n| 流量分析 | 趋势图、渠道占比、搜索/推荐/广告下钻 |\n| 询盘分析 | 询盘量、有效询盘用户数、趋势、商品排行 |\n| 成交分析 | 支付金额、买家数、转化率、客单价、退款、新老客结构；订单履约（四类待处理计数、超时订单明细）；买家评价（1~5 分分布、差评明细） |\n| 商品分析 | 异常商品列表、四大榜单 TOP 商品、商品状态 |\n| 客户分析 | 地域分布图、头部老客户明细与流失风险 |\n| 广告分析 | 广告渠道贡献、行业对比 |\n| 风险分析 | 违规扣分、待处理违规明细、商品预警、司法预警（实时快照口径） |\n| 行动建议 | 分层建议，标注责任店铺/商品/渠道 |\n\n多店铺报告设计应以\"对比优先\"：首页突出店铺间指标差异、共性问题与各自优势；后续章节先放各店铺同维度并列对比（如并列趋势图、渠道占比对比），再展开单店细节。\n\n> **负向约束**：\n> - 禁止跳过 HTML 报告直接结束。\n> - 禁止用纯文字报告代替 HTML 报告。\n> - 禁止在 HTML 报告外输出大段 JSON 或原始接口数据。\n> - HTML 中的金额、百分比、商品名称、店铺名称必须来自接口真实返回，禁止捏造。\n> - 报告中不得出现 `RECENT_7`、`RECENT_30`、`payAmt`、`uv` 等英文指标名或周期标识，必须替换为中文。\n\n### 4.3 数据可视化兜底\n\n若某维度数据缺失，HTML 报告中对应章节使用文字卡片标注\"数据暂不可用\"，不影响其他章节输出。\n\n---\n\n## 五、时间周期与调用规则\n\n### 5.1 时间周期\n\n所有支持时间周期的内置接口，仅支持以下两种值：\n\n- `RECENT_7`（近 7 天）\n- `RECENT_30`（近 30 天）\n\n**严禁**虚构或传入其他周期值（如 `WEEK`、`MONTH`、`day`）。\n\n### 5.2 默认与降级\n\n1. **默认周期**：用户未指定时，默认 `RECENT_7`，并在最终输出中明确说明。\n2. **用户语境匹配**：\n   - \"最近 / 近期 / 这周\" → `RECENT_7`\n   - \"近一个月 / 趋势 / 复盘\" → `RECENT_30`\n3. **无数据自动降级**：当任一数据查询接口以当前周期调用后返回的核心字段全部为空/零值，按以下顺序自动降级，无需询问用户：\n   - `RECENT_7` 无数据 → 自动以 `RECENT_30` 重新调用该接口及后续相关接口\n   - `RECENT_30` 仍无数据 → 按「八、安全与异常处理 — 章节降级规则」执行兜底\n4. **趋势辅助验证**：当 `RECENT_7` 出现明显异常波动时，应补充调用一次 `RECENT_30` 判断是短期波动还是持续趋势。\n5. **固定口径**：`alibaba.1688.seller.activity.registered.info` 固定为近 30 天口径，结论中需说明。\n6. **必须在最终输出中明确**当前分析基于哪个周期。\n\n### 5.3 多店铺口径一致性\n\n一旦触发周期降级，后续所有店铺、所有接口统一使用降级后的周期值，保持口径一致。\n\n---\n\n## 六、分析方法论\n\n详细的数据分析方法、分维度判断逻辑、交叉验证规则与行动建议优先级，统一见 `{baseDir}/references/analysis-methodology.md`。\n\n> **方法论文件优先级**：`1688-shop-freedom-query-data/references/` 下的场景化方法论文件包含更细粒度的诊断框架、判断标准和平台最新规则，**优先于** `analysis-methodology.md` 中的通用规则。具体分析时须将两者结合使用：通用框架参考 `analysis-methodology.md`，场景化规范和判断标准参考方法论文件。详见「1.3.1 分析方法论引用」的读取方式。\n\n核心原则：**先总盘 → 再分维度 → 交叉验证；先问题 → 再原因 → 再行动**。收敛为总结性结论时必须满足：\n\n- 每个结论有数据支撑\n- 异常商品与优秀商品必须交叉验证\n- 总盘趋势至少用 2 个维度的数据解释\n- 行动建议必须按紧急程度（高/中/低）分档\n\n---\n\n## 七、执行流程（单阶段）\n\n> 执行过程中所有文字输出使用中文，数据字段名和 CLI 命令除外。\n\n### Step 0：前置准备\n\n1. **多店铺列表**：调用 `get_bindlist` 获取当前用户绑定的全部店铺列表及对应 `loginId`，作为后续逐店诊断的输入。\n\n### Step 1：意图澄清与执行计划确认\n\n按「二、意图澄清与执行计划」处理：命中「2.4 免确认」条件时，输出执行计划后**跳过确认卡直接进入 Step 2**；否则输出默认执行计划，触发 `confirm_execution_plan` 交互组件，等待用户确认或调整范围。\n\n### Step 2：全面诊断取数\n\n用户确认后，按「三、全面诊断维度与数据获取」调用各维度接口。\n\n**并发策略（强制）**：\n\n1. **单店铺内全部接口同一轮并发**：一个店铺涉及的所有维度、所有接口调用必须在**同一轮工具调用中同时发出**（即一个 Tool-Use block 中包含该店铺的全部 Bash 调用），禁止分多轮串行调用。\n2. **店铺之间串行**：多店铺场景下，先完成店铺 A 的全部接口调用并拿到结果，再发起店铺 B 的全部接口调用。避免 N 店铺 × M 接口的并发量过大。\n3. 内置脚本未覆盖的数据：通过 `1688-shop-freedom-query-data` 的 `rag_query` + `query_shop_data` 补充，补充调用同样遵循上述并发策略（注意：多店铺时 `--NEWTON_SHOP_LOGIN_ID` 只加在 `query_shop_data` 上，`rag_query` 不支持该参数）。\n4. 涉及复杂计算时，先保存原始数据，再用 Python 脚本精确计算。\n\n### Step 2.5：读取 Wiki 上下文\n\n用户确认执行计划后，如当前任务可调用 `WikiNav` / `WikiRead`，按实际诊断店铺逐店读取 Wiki 背景。Wiki 只用于背景解释和行动建议措辞，读不到则为空，不影响 Step 3。\n\n### Step 3：分析与结论输出\n\n0. **读取方法论文件**（强制，不可跳过）：按「1.3.1 分析方法论引用」的读取方式，先列出 `{freedomBaseDir}/references/` 下的文件，再按本次体检涉及的维度选择并读取相关方法论文件。\n1. 按「六、分析方法论」+ 方法论文件中的规范进行综合判断。方法论文件中的场景化规范优先于 `analysis-methodology.md` 的通用规则。\n2. 撰写总结性结论：单店场景下 ≤200 字，多店铺场景下按店铺分述（每家店铺 2–3 句话 + 1–2 条分点跨店对比结论），具体要求见「四、输出格式 — 4.1」。\n3. **立即输出总结性结论给用户**，不等待 HTML 报告生成。这是用户最先看到的结果。\n\n### Step 4：HTML 报告生成\n\n调用 `1688-common-report-to-visualization` 技能生成 HTML 报告，**待报告生成并呈现完成后**再进入 Step 5（严格串行，不并发、不后台异步）。\n\n**传入内容必须包含**：\n\n1. 可视化技能路径：`1688-common-report-to-visualization/SKILL.md` 和 `references/chart-bindbook.md`（按需自行读取）。\n2. 本技能的 HTML 报告章节要求（见「四、输出格式 — 4.2」）。\n3. **完整的分析数据**：将 Step 2 收集到的所有接口返回数据（交易指标、核心指标同行对比、流量趋势、渠道流量、异常商品、四大榜单、客户地域、头部老客、商品状态、行业大盘、活动效果等）以 JSON 或结构化文本形式传入，确保拥有生成报告所需的全部数据，无需再次调用 CLI。\n4. 输出要求：生成的 HTML 文件路径、使用 `present_files` 呈现给用户。\n\n> **时序约束**：严格串行——Step 3 总结性结论先输出；Step 4 HTML 报告生成并呈现**完成后**，才进入 Step 5 展示行动项卡片。目的是确保用户先看到完整报告，再选择行动项。\n\n### Step 5：行动项选择与继续执行\n\n> **🤫 静默约束（最高优先级）**：行动项的生成与排序、定时任务去重判断均在内部完成，禁止作为面向用户的正文输出。对用户只呈现：最终的 `select_action_items` 卡片，以及用户选择后真实执行的结果与确认语。禁止输出「让我先检查定时任务」「根据 Schedule 列表我看到…」「让我看看哪个技能能处理」「行动项映射：xxx → 某技能」之类的判断/匹配过程，也禁止泄露任何内部字段与判据（`id` / `enabled` / `schedule` / `cron` / 技能名 / 触发语等）。\n\n1. **生成行动项（内部完成，硬上限 3 条）**：从总结性结论的「优先行动建议」中按紧急程度 **高 > 中 > 低** 取最多 **3 条**（硬上限，不得超过）；**软约束**：同等紧急程度下优先选择更可能被自动化能力承接的行动项（常见可承接方向：订单跟单/催发货/超时订单处理、商品诊断与优化、商品标题优化、商品主图优化、旺旺自动回复/AI 接待配置、店铺数据绑定与采集、广告投放分析），**不保证每条都有技能承接，也不得为凑「可承接」而丢弃更高优先级的行动项**；无需预先列技能列表或建任何映射关系，技能匹配在用户勾选后现场完成。\n   - 每条行动项措辞为一句**自然行动描述**（≤40 字），包含动作对象和核心动作，例如\"深度诊断昨日流量异动原因并生成归因报告\"、\"对头部老客批量执行企业背景调查\"、\"查询成交主力商品的库存可售天数\"。\n   - **禁止**在行动项文本中出现技能名、脚本 code、技术术语或 自动/手动 等标记。\n   - 多店铺场景需包含所属店铺简称。\n   - 若结论中没有任何优先行动建议，仍需触发交互卡片，此时卡片仅展示下方按条件追加的定时任务选项。\n2. **生成交互卡片**：触发 `select_action_items` 组件，将行动项渲染为多选卡片：\n   - 每条行动项选项文本控制在 **40 个字符以内**，保留「紧急程度 + 动作对象 + 核心动作」。\n   - 多店铺场景需包含所属店铺简称。\n   - **按条件追加定时任务选项（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` 等）。\n   - 卡片固定提供\"确认\"与\"取消\"按钮。\n3. **处理用户选择**：\n   - **勾选行动项并点击\"确认\"**：Agent 对勾选的**每一项**在当前会话可用技能中**现场寻找**能承接的技能，**立即读取目标技能 SKILL.md 并按其定义真实执行**。这是必须完成的动作，**严禁只回一句“好的/已为你规划”而不实际触发技能**。若一条行动项涉及多个技能，按依赖顺序依次执行；**若某项确实没有技能可承接，直接给出具体的人工操作建议并明确告知用户**，不要静默忽略。\n   - **勾选定时任务选项并点击\"确认\"**：若该选项因「未命中」而展示 → 以**完整定时任务规格新建**：由客户端弹出「设置定时任务」确认卡片（含执行时间、执行内容、修改任务/立即执行按钮），**待用户点击「立即执行」后再创建，不可直接建任务**；若因「命中但已停用（enabled:false）」而展示 → 走 **`update` 重新启用**已有任务，**不新建**。规格与日报保持一致：\n     - **任务名**：`店铺健康检查`\n     - **执行时间**：`每天 09:30`\n     - **执行内容**：`自动进行 1688 店铺全面体检，覆盖流量、询盘、成交、商品、客户、广告、风险七大维度，生成体检报告并给出异常提醒和经营建议`\n     - 设置成功后向用户确认已开启（如「已为您开启『店铺健康检查』每日定时任务，每天 09:30 自动生成体检报告」）。**仅当用户确实勾选了定时任务选项并成功新建/重新启用后才输出这句确认；用户未勾选、或该选项本就未追加时，禁止输出任何定时任务文案。**\n   - **点击\"取消\"或不勾选任何项**：结束本次体检流程，不再执行后续动作。\n4. **本卡片只展示一次（收尾约束）**：完成上述处理（触发所选技能 / 设置定时任务 / 用户跳过或取消）后，本次体检流程即结束。**你触发的下游技能返回后，不要把\"控制权回到本流程\"理解为需要重新展示行动项卡片——不得再次渲染 `select_action_items` 卡片**；用户若想继续优化，由其主动发起新请求，Agent 不得自行重弹。\n\n---\n\n## 八、安全与异常处理\n\n### 8.1 AK 配置\n\n首次使用前需配置 AK：\n\n```bash\npython3 {baseDir}/cli.py configure YOUR_AK\n```\n\n查看状态：`python3 {baseDir}/cli.py configure`\n\n### 8.2 命令异常处理\n\n任何命令输出 `success: false` 时：\n\n| markdown 关键词 | Agent 行为 |\n|----------------|-----------|\n| \"AK 未配置\" / \"AK 无效或已过期\" | 提示用户运行 `cli.py configure YOUR_AK` 配置鉴权后重试 |\n| \"参数错误\" / \"请求参数不合法\" | 提示用户检查 `query_date`（昨日日期 YYYY-MM-DD）/ `date_type` / `device` / `order_by` 等参数 |\n| \"请求被限流\" | 建议用户等待 1-2 分钟后重试 |\n| 其他 | 输出原始错误信息，对应章节标注\"数据暂不可用\"，其余章节正常生成 |\n\n> **⚠️ 分析护栏（与分析环节同步遵守）**：个别子接口 `success: false`（尤其 `rag_query` 等辅助检索）仅表示**该单项**数据暂不可用，按“该项缺失”口径处理即可；**严禁**据此推断店铺整体数据采集异常、授权异常或“各项核心指标缺失”。指标值为 0 是**真实经营数值**（如零访客、零成交），不是数据缺失，应据实分析经营状况。\n\n### 8.3 章节降级规则\n\n| 接口失败 | 影响章节 | 降级处理 |\n|---------|---------|---------|\n| `alibaba.1688.seller.trade.code.index` | 总盘健康度 | 标注\"总盘数据暂不可用，无法判断整体健康度\" |\n| `alibaba.1688.get.core.metrics` | 同行对比 | 标注\"同行对比数据暂不可用\" |\n| `alibaba.1688.get.traffic.trend` / `alibaba.1688.get.traffic.overview` / `alibaba.1688.get.channel.traffic` | 流量分析 | 标注\"流量数据暂不可用\" |\n| 询盘接口（跨技能） | 询盘分析 | 标注\"询盘数据暂不可用\" |\n| `alibaba.1688.seller.import.abnormal.offer` | 异常商品 | 标注\"异常商品数据暂不可用\" |\n| `alibaba.1688.seller.top.offer`（任一榜单） | 商品分析 | 缺失榜单标注\"暂不可用\"，其余榜单正常输出 |\n| `alibaba.1688.seller.activity.registered.info` | 活动效果 | 标注\"活动数据暂不可用\" |\n| `alibaba.1688.seller.customer.business.province` | 客户地域 | 标注\"地域数据暂不可用\" |\n| `alibaba.1688.seller.customer.detail` | 头部老客户 | 标注\"头部老客数据暂不可用\" |\n| `alibaba.1688.get.ad.channel.detail` / `alibaba.1688.get.industry.benchmark` | 广告分析 | 标注\"广告数据暂不可用\" |\n| `shop_health_check --code order_risk` / `--code feedback` | 成交分析（订单履约/买家评价） | 对应小节标注\"数据暂不可用\"，成交其余内容正常输出 |\n| `shop_health_check --code shop_punish` | 风险分析 | 标注\"风险数据暂不可用\" |\n\n**关键原则**：任一接口失败不阻塞其余章节生成，但若 `alibaba.1688.seller.trade.code.index` 失败，应直接告知用户\"总盘数据缺失，建议先解决数据接入问题再做诊断\"，不强行输出健康等级。\n\n### 8.4 多店铺场景异常处理\n\n| 异常情况 | 处理方式 |\n|---------|---------|\n| `get_bindlist` 返回为空或失败 | 降级为当前 AK 单店模式，正常执行体检 |\n| 用户指定店铺名未匹配到任何绑定店铺 | 输出错误提示，列出所有绑定店铺名称供用户重新选择 |\n| 部分店铺查询成功、部分失败 | 成功的店铺正常输出结果，失败的店铺标注\"该店铺数据获取失败：{错误原因}\" |\n| 某店铺 loginId 为空 | 不传 `NEWTON_SHOP_LOGIN_ID`，使用当前 AK 执行（等同当前店铺），不中断其他店铺 |\n\n---\n\n## 九、注意事项\n\n- 部分字段可能为空，需兼容空值（如 `lstLossDate`、`peerActivityItmGmv`、`rank`）。\n- `cycleCrc` 表示**变化率**（小数或百分比，可能为负），`cycleCqc` 表示**变化绝对值**。\n- 活动接口 `alibaba.1688.seller.activity.registered.info` 数据为**近 30 天**口径，与 `RECENT_7` 总盘对比时需说明口径差异。\n- 头部老客户接口需重点关注 **本周期支付金额** vs **累计支付金额** 的关系，识别\"历史强、近期弱\"的高价值流失风险客户。\n- 询盘接口返回中文键名（如\"有效询盘用户数/量\"、\"商品名称\"、\"旺旺询盘\"、\"找工厂\"、\"L会员\"），JSON 解析与展示时需注意。\n- 当用户问题偏向某个方向（如\"为什么下滑\"/\"最近靠什么增长\"），应在保持七维度完整框架的前提下，**聚焦该方向章节深度展开**。\n\n---\n\n## 十、环境变量（.env）\n\n项目根目录的 `.env` 文件存储 skill 基础信息，供埋点上报模块读取。\n\n| 变量 | 默认值 | 说明 |\n|------|--------|------|\n| `SKILL_NAME` | `1688-shop-health-check` | skill 名称 |\n| `SKILL_VERSION` | `1.0.0` | skill 版本号 |\n| `SKILL_CHANNEL` | `clawhubai` | 发布渠道 |\n\n> 已存在的系统环境变量优先级高于 `.env`，CI/CD 注入的变量不会被覆盖。\n\n---\n\n## 十一、埋点上报\n\n每次 CLI 命令执行时，自动向 skill 网关上报一次调用记录。\n\n- **实现位置**：`scripts/_tracker.py` → `report_skill_usage()`，在 `cli.py` 的 `main()` 中每次命令执行后自动调用\n- **上报接口**：`POST /api/alibaba.1688.report.skills.usage/1.0.0`\n- **失败处理**：上报失败静默忽略，不影响主流程\n\n---\n\n## 总原则\n\n> **像一份专业的店铺经营体检报告一样输出：先判断健康度，再定位问题源，再识别增长引擎，结论中直接给出可执行动作。**\n>\n> 数据是手段，**经营判断和可执行建议**才是目的。\n>\n> **输出时序**：严格串行——总结性结论最先输出，其次生成并呈现完整 HTML 报告，最后展示行动项选择卡片。用户先看到完整报告，再选择要执行的行动项。\n\nFile v1.4.0:_meta.json\n\n{\n  \"ownerId\": \"kn76msg8cwkep3b08z7zffx9fx82p5wj\",\n  \"slug\": \"1688-shop-health-check\",\n  \"version\": \"1.4.0\",\n  \"publishedAt\": 1788437376003\n}\n\nFile v1.4.0:references/analysis-methodology.md\n\n# 分析方法论（单阶段七维度综合诊断）\n\n> 本文档为 `1688-shop-health-check` 提供单阶段、全维度的数据分析方法。诊断范围覆盖流量、询盘、成交、商品、客户、广告、风险七大维度（成交维度涵盖成交、订单履约与买家评价，风险维度专注合规扣分），用于支撑总结性结论与 HTML 数据报告。\n> \n> 使用原则：**先总盘 → 再分维度 → 交叉验证；先问题 → 再原因 → 再行动**。所有结论必须有数据支撑，行动建议按紧急程度（高/中/低）分档。\n\n---\n\n## 一、核心分析原则\n\n1. **总盘优先**：先用 `alibaba.1688.seller.trade.code.index` + `alibaba.1688.get.core.metrics` 判断店铺整体健康度，再下钻分维度。\n2. **维度互补**：流量、询盘、成交、商品、客户、广告、风险七个维度相互解释，单一维度异常必须得到至少另一个维度验证。\n3. **商品/客户/渠道锚定**：经营变化的最终落点通常是具体商品、具体客户群或具体渠道，结论必须能锚定到可干预对象。\n4. **行动导向**：每项发现必须对应可执行动作，并按紧急程度（高/中/低）排序。\n\n---\n\n## 二、总盘健康度判断\n\n**数据来源**：`alibaba.1688.seller.trade.code.index`（总盘指标） + `alibaba.1688.get.core.metrics`（同行对比与评级）\n\n### 2.1 判断维度\n\n| 维度 | 关键指标 | 关注要点 |\n|------|----------|----------|\n| 成交规模 | 支付金额 | 规模与环比变化方向 |\n| 买家规模 | 支付买家数 | 新客获取与老客留存 |\n| 转化效率 | 支付转化率 | 流量承接效率 |\n| 客单表现 | 人均支付金额 | 价格带与连带能力 |\n| 下单承接 | 创建订单金额、创建订单买家数、下单到支付转化率 | 下单→支付漏斗 |\n| 新老客结构 | 新支付买家数、老支付买家数、老买家支付金额 | 增长可持续性 |\n| 成交质量 | 退款成功金额 | 履约与描述风险 |\n\n### 2.2 健康等级判定\n\n| 等级 | 判断条件 |\n|------|----------|\n| **健康** | 核心指标稳定或向好，无明显恶化项 |\n| **基本稳定** | 多数指标稳定，个别指标小幅波动且非关键路径 |\n| **存在风险** | 1-2 个核心指标明显恶化（如转化率/支付金额双跌） |\n| **明显承压** | 多个核心指标同时恶化，新老客 / 退款 / 转化等结构性问题并存 |\n\n---\n\n## 三、同行对比分析\n\n**数据来源**：`alibaba.1688.get.core.metrics`\n\n| 维度 | 判断方式 |\n|------|----------|\n| 整体达标率 | 评级为\"优秀\"的指标数量 vs \"略低\"/\"极低\"的指标数量 |\n| 关键指标达标率 | 支付金额、支付买家数、支付转化率等核心指标的评级 |\n| 趋势对比同行 | 本店变化率 vs 同行平均变化率 / 同行优秀变化率 |\n| 行业地位 | 基于同行对比综合判断店铺在行业中的位置 |\n\n### 评级含义\n\n| 评级 | 含义 |\n|------|------|\n| 优秀 | 本店数值显著高于同行同层均值 |\n| 持平 | 本店数值与同行同层均值接近 |\n| 略低 | 本店数值低于同行同层均值 |\n| 极低 | 本店数值远低于同行同层均值 |\n\n---\n\n## 四、流量维度分析方法论\n\n**数据来源**：\n- 内置命令：`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`\n- 补充接口（`1688-shop-freedom-query-data`）：`flow/ovralShopFlowSource/overview`、`portal/flowBoard/overview` 等\n\n### 4.1 流量趋势分析（`alibaba.1688.get.traffic.trend`）\n\n| 判断维度 | 说明 |\n|----------|------|\n| 整体趋势 | 近 7 天 / 近 30 天 uv/pv 的整体走向（上升/下降/波动） |\n| 异常波动 | 单日 uv/pv 突然大幅下跌或上涨的日期 |\n| UVCTR 趋势 | UV 点击率变化，判断流量质量是否稳定 |\n| 波动幅度 | 近 7 天 uv 的标准差或最大/最小值差异 |\n| 与总盘关联 | 流量趋势是否与 `alibaba.1688.seller.trade.code.index` 中的 `payByrCnt` 变化一致 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| 流量稳定 | uv/pv 趋势平稳，无明显波动 |\n| 流量下滑 | 近 7 天 uv 持续下降，需排查流量来源 |\n| 流量波动 | uv 在某些日期突然下跌，需检查是否有活动结束或渠道中断 |\n| 流量回升 | uv 近期开始上升，可能是新活动或渠道生效 |\n| 流量质量下降 | uv 稳定但 UVCTR 下降，说明流量质量降低 |\n\n### 4.2 流量概览与异动判定（`alibaba.1688.get.traffic.overview`）\n\n获取全店 PV/UV/UVCTR 及多期对比（环比/周环比/同比），判断整体流量异动幅度。\n\n**异动判定阈值**：\n\n| 异动幅度 | 等级 | 标记 |\n|----------|------|------|\n| 下跌 > 30% | 严重异常 | 🔴 |\n| 下跌 20%-30% | 显著异常 | 🟠 |\n| 下跌 10%-20% | 中度异常 | 🟡 |\n| 下跌 5%-10% | 轻微波动 | 🟢 |\n| 波动 < ±5% | 正常波动 | ⚪ |\n\n**异动计算公式**：\n```\n环比增长率 = (本期 - 上期) / 上期 × 100%\n周环比增长率 = (本期 - 上周同期) / 上周同期 × 100%\n同比增长率 = (本期 - 去年同期) / 去年同期 × 100%\n```\n\n### 4.3 渠道归因（`alibaba.1688.get.channel.traffic`）\n\n当流量概览发现异常时，调用各渠道流量数据定位主要贡献渠道。\n\n**渠道定义**：\n\n| 渠道 | 定义 | 核心指标 | 特性 |\n|------|------|----------|------|\n| 搜索 | 平台内搜索访问 | 搜索 UV、搜索 PV、关键词分布、搜索排名 | 流量质量高、竞争激烈 |\n| 推荐 | 平台推荐系统（猜你喜欢、相关推荐） | 推荐 UV、推荐 PV、曝光量、CTR | 波动大，受算法影响显著 |\n| 广告 | 付费推广（直通车、网销宝等） | 广告 UV、广告 PV、点击率、CPC、预算消耗 | 预算可控但成本高 |\n\n**渠道贡献度计算**：\n```\n渠道贡献度 = 渠道变化量 / 总变化量 × 100%\n```\n\n确认主要贡献渠道后，调用对应深度下钻命令：\n- 搜索渠道：`alibaba.1688.get.search.channel.detail`\n- 推荐渠道：`alibaba.1688.get.recommend.channel.detail`\n- 广告渠道：`alibaba.1688.get.ad.channel.detail`\n\n### 4.4 商品排查（`alibaba.1688.get.product.status`）\n\n当流量出现突发暴跌时，调用此命令排查商品层面问题（搜索降权、下架、违规等）。\n\n### 4.5 行业大盘对比（`alibaba.1688.get.industry.benchmark`）\n\n判断个体 vs 行业性现象：店铺流量变化是自身问题还是行业共性。\n\n- 店铺跌幅 > 行业跌幅 → 店铺自身问题为主因\n- 店铺跌幅 ≈ 行业跌幅 → 行业性波动，关注大盘走势\n\n### 4.6 关键判断逻辑\n\n- `alibaba.1688.get.traffic.trend` 显示近 7 天 uv 持续下滑，且 `alibaba.1688.seller.trade.code.index` 中 `payByrCnt` 同步下降 → **流量问题为主因**\n- uv 稳定但 UVCTR 下降 → **流量质量降低，需优化流量来源或承接**\n- 某日 uv 突然大幅下跌（如跌幅 > 30%） → **识别该日期，排查是否有活动结束、渠道中断或系统问题**\n- 流量趋势下跌日期前后，检查 `alibaba.1688.seller.import.abnormal.offer` 中是否出现\"访客下跌\"商品\n\n---\n\n## 五、询盘维度分析方法论\n\n**数据来源**：通过 `1688-shop-freedom-query-data` 调用\n- `customer/inquiry/coreIndex`（询盘核心指标）\n- `customer/inquiry/coreIndexTrend`（询盘趋势，可能返回近 30 天全量）\n- `customer/inquiry/itemRank`（询盘商品排行）\n\n### 5.1 核心指标解读\n\n| 指标 | 含义 | 分析要点 |\n|------|------|----------|\n| 有效询盘用户数 | 真实产生询盘行为的买家数 | 反映买家兴趣规模 |\n| 有效询盘量 | 询盘总次数 | 与用户数结合看人均询盘 |\n| 旺旺询盘 | 通过旺旺发起的询盘 | 客服承接效率窗口 |\n| 找工厂 | 找工厂场景询盘 | B 端工厂型业务机会 |\n| L会员 | L 会员买家询盘 | 高价值买家意向 |\n\n### 5.2 询盘转化效率判断\n\n- 询盘量高但成交低 → 详情页 / 客服承接 / 报价策略有问题\n- 询盘量低但转化高 → 流量获取不足，需扩大询盘入口\n- 询盘商品排行与成交商品排行差异大 → 需求与供给错配\n\n### 5.3 注意事项\n\n- `coreIndex` 不含 `device` 参数，可直接用 `dateType` 调用。\n- `coreIndexTrend` 即使传 `RECENT_7` 也可能返回 30 天全量数据，按返回全量绘制趋势图即可。\n- 返回字段为中文键名，JSON 解析与展示时需注意。\n\n---\n\n## 六、成交维度分析方法论\n\n**数据来源**：`alibaba.1688.seller.trade.code.index` + `alibaba.1688.get.core.metrics`\n\n### 6.1 成交四维拆解\n\n| 维度 | 指标 | 分析要点 |\n|------|------|----------|\n| 规模 | 支付金额、支付买家数 | 体量与变化方向 |\n| 效率 | 支付转化率、下单到支付转化率 | 流量承接与订单转化 |\n| 客单 | 人均支付金额 | 价格带与连带 |\n| 质量 | 退款成功金额、退款率 | 履约与描述风险 |\n\n### 6.2 新老客结构\n\n| 结构 | 判断方式 |\n|------|----------|\n| 新客驱动 | 新支付买家数增长显著，老买家占比低 |\n| 老客驱动 | 老买家支付金额占比高，新客增长乏力 |\n| 结构健康 | 新老客均保持正向增长，老客贡献稳定 |\n| 流失风险 | 老买家支付金额/人数大幅下滑 |\n\n### 6.3 成交与流量交叉验证\n\n- 支付金额增长 + 访客数增长 + 转化率稳定 → **量驱动增长**\n- 支付金额增长 + 访客数下降 + 转化率提升 → **效率驱动增长**\n- 支付金额下降 + 访客数下降 → **流量问题为主**\n- 支付金额下降 + 访客数稳定 + 转化率下降 → **承接问题为主**\n\n---\n\n## 七、商品维度分析方法论\n\n**数据来源**：`alibaba.1688.seller.import.abnormal.offer`、`alibaba.1688.seller.top.offer`、`alibaba.1688.get.product.status`\n\n### 7.1 异常商品定位（`alibaba.1688.seller.import.abnormal.offer`）\n\n按 `reason` 分三类识别：\n\n| 异常类型 | 含义 | 紧急程度 |\n|----------|------|----------|\n| 访客下跌 | 偏流量获取问题 | 中 |\n| 支付下跌 | 偏转化/成交问题 | 中 |\n| 访客下跌 + 支付下跌（双跌） | 流量与转化同时恶化 | **高** |\n\n**筛查优先级**：\n\n1. 影响金额大：`valueMap.payAmt.value.value` 高且 `valueMap.payAmt.cycleCqc.value` 负向大\n2. 跌幅大：`cycleCrc` 负向显著（如 < -30%）\n3. 多重异常：`reason` 同时包含访客下跌和支付下跌\n4. 集中度：是否集中在某类目或店铺核心商品上\n\n输出时聚焦 **TOP 3-5 个最值得处理的异常商品**，每个需说明：异常类型、当前规模、影响幅度、优先处理理由。\n\n### 7.2 增长引擎识别（`alibaba.1688.seller.top.offer`）\n\n必须按分析需要调用多个榜单，不得只调用 `payAmt`：\n\n| 调用 | 识别目标 |\n|------|----------|\n| `--order_by payAmt` | 成交主力：撑 GMV 的核心商品 |\n| `--order_by uv` | 流量主力：流量大但需结合 `payRate` 看转化 |\n| `--order_by payNewByrCnt` | 拉新主力：贡献新客的商品 |\n| `--order_by itemMultiByrCnt` | 复购主力：承担复购经营的商品 |\n\n**交叉判断**：\n\n| 特征 | 商品类型 | 建议方向 |\n|------|----------|----------|\n| 高 `payAmt` + 高 `payRate` | 核心成交款 | 重点保护，加大投入 |\n| 高 `uv` + 低 `payRate` | 高流量低转化款 | 优化转化（详情/价格/评价） |\n| 低 `uv` + 高 `payRate` | 潜力款 | 加流量放量 |\n| 高 `payNewByrCnt` | 拉新款 | 投放裂变、首单优惠 |\n| 高 `itemMultiByrCnt` + 高 `itemMultiByrPayAmt` | 复购款 | 老客经营、会员激励 |\n\n### 7.3 商品状态检查（`alibaba.1688.get.product.status`）\n\n重点排查：搜索降权、下架、违规、主图/标题异常。当流量或成交突然暴跌时优先调用。\n\n### 7.4 商品维度交叉验证\n\n- 优秀商品列表里是否同时出现在异常商品列表中？**若重叠 → 高优先级风险**（核心商品在恶化）\n- 异常商品中是否有店铺 TOP 成交品？**若有 → 必须最高优先级修复**\n- TOP 商品是否过于集中决定店铺稳健性\n\n---\n\n## 八、客户维度分析方法论\n\n**数据来源**：`alibaba.1688.seller.customer.business.province`、`alibaba.1688.seller.customer.detail`\n\n### 8.1 地域分布分析（`alibaba.1688.seller.customer.business.province`）\n\n| 维度 | 判断方式 |\n|------|----------|\n| 集中度 | TOP 1 / TOP 3 省份 `payBuyerNumRate` 之和 |\n| 依赖风险 | TOP 1 省份占比 > 40% → 高度依赖；> 60% → 严重依赖 |\n| 覆盖面 | 出现的省份数量、长尾省份分布 |\n| 潜力区域 | 占比中等（5-15%）且接近核心区域的省份，可作为下一阶段拓展目标 |\n\n**注意**：某些类目（如本地服务、生鲜）天然区域集中，不应一刀切判定为\"风险\"。\n\n### 8.2 头部老客稳定性（`alibaba.1688.seller.customer.detail`）\n\n| 维度 | 判断方式 |\n|------|----------|\n| 依赖度 | TOP N 头部老客 `payAmount` 占店铺总 `payAmt` 的比例 |\n| 活跃度 | `lastPayDate` 距今天数，看头部客户是否近期还在买 |\n| 流失风险 | 历史 `payAmtAll` 高但本期 `payAmount` = 0 或显著低 → 走弱风险 |\n| 客户结构 | `identityName` / `buyerCreditLevel` / `custAreaName` 分布特征 |\n| 获客来源 | `fstFromAd = true` 占比高 → 广告获客型；占比低 → 自然沉淀型 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| 基本盘稳 | 头部老客持续活跃，贡献稳定 |\n| 依赖风险高 | 少数头部客户占比极高，单客流失即重创 GMV |\n| 存在断层风险 | 高累计价值客户近期不活跃，需立即召回 |\n| 广告依赖型 | 头部客户多数来自广告，需关注获客成本与生命周期 |\n\n---\n\n## 九、广告维度分析方法论\n\n**数据来源**：`alibaba.1688.get.ad.channel.detail`、`alibaba.1688.get.industry.benchmark`，必要时通过 `1688-shop-freedom-query-data` 补充数字营销/全站推广细项。\n\n### 9.1 广告贡献判断\n\n| 指标 | 含义 |\n|------|------|\n| 广告 UV / 广告 PV | 广告带来的流量规模 |\n| 广告点击转化率 | 广告流量的承接效率 |\n| 广告消耗 / CPC | 投放效率与成本 |\n| 广告引导成交金额 | 广告对 GMV 的实际贡献 |\n\n### 9.2 广告效率判断\n\n- 广告 UV 高但成交贡献低 → 投放人群或落地页不匹配\n- 广告 UV 低但转化率高 → 可适度加预算放大\n- 广告几乎无贡献 → 检查是否未投放、预算耗尽或账户异常\n\n### 9.3 行业对比\n\n通过 `alibaba.1688.get.industry.benchmark` 判断广告投入水平与效率是否处于行业合理区间，避免盲目压缩或放大预算。\n\n---\n\n## 十、订单履约、合规扣分与买家评价分析方法论\n\n> 三者由聚合工具 `shop_health_check` 提供：`order_risk`、`feedback` 归属**成交维度**，`shop_punish` 归属**风险维度**。数据均为**实时快照**口径，结论中需与近 7/30 天周期数据区分标注。\n\n### 10.1 订单履约分析（`shop_health_check --code order_risk`）\n\n**数据来源**：`shop_health_check --code order_risk`（成交维度）\n\n**关键字段**：\n\n| 字段 | 含义 | 分析要点 |\n|------|------|----------|\n| `overview` 四类待处理计数 | 待发货/待付款/待收货/待定制付款 | 待处理积压反映履约与承接压力 |\n| `timeout_risk.already_timeout_cnt` + `already_timeout_orders` | 已发货超时订单 | 已产生履约违约，最高优先处理 |\n| `timeout_risk.about_to_timeout_cnt` + `about_to_timeout_orders` | 即将发货超时订单 | 需立即发货避免超时 |\n\n**判定标准**：\n\n| 结论 | 特征 |\n|------|------|\n| 履约健康 | 无超时订单，待处理计数处于正常水位 |\n| 存在履约风险 | 存在即将超时订单，需及时发货 |\n| 履约违约 | 已出现已超时订单，须**高优先级**处理并排查发货链路 |\n\n### 10.2 合规扣分分析（`shop_health_check --code shop_punish`）\n\n**数据来源**：`shop_health_check --code shop_punish`（风险维度）\n\n**关键字段**：\n\n| 字段 | 含义 | 分析要点 |\n|------|------|----------|\n| `punish_score` / `fake_times` | 违规扣分/假货次数 | 店铺经营红线基线 |\n| `punish_warning`（仅 PENDING） | 待处理违规预警 | 存在待处理项即需立即处理 |\n| `item_alert` | 商品预警 | 定位到具体违规商品 |\n| `legal_alert`（`admin_case`/`law_case`） | 司法/行政预警 | 涉法涉诉，最高优先级 |\n\n**判定标准**：\n\n| 结论 | 特征 |\n|------|------|\n| 合规健康 | 无违规扣分与待处理预警 |\n| 存在合规风险 | 有违规扣分或待处理违规预警，需按 `deal_url` 及时处理 |\n| 经营红线告急 | 司法预警出现或假货次数偏高，须**最高优先级**处置 |\n\n### 10.3 买家评价分析（`shop_health_check --code feedback`）\n\n**数据来源**：`shop_health_check --code feedback`（成交维度）\n\n**关键字段**：\n\n| 字段 | 含义 | 分析要点 |\n|------|------|----------|\n| `rating_overview.distribution` | 1~5 分档分布 | 评分结构 |\n| `rating_overview.low_score_ratio` | 低分（≤3 分）占比 | 口碑风险核心指标 |\n| `negative_feedback.items` | 负面反馈明细 | 定位差评集中的商品与原因 |\n| `positive_cnt` | 正面反馈数 | 口碑正向基础 |\n\n**判定标准**：\n\n| 结论 | 特征 |\n|------|------|\n| 口碑良好 | 低分占比低、无明显负面反馈集中 |\n| 口碑承压 | 低分占比偏高，或负面反馈集中于个别商品 |\n| 口碑风险 | 低分占比显著偏高且负面反馈集中，需优先排查商品质量/描述/履约 |\n\n---\n\n## 十一、交叉验证与综合收敛\n\n### 11.1 必须满足的收敛规则\n\n- 每个结论有数据支撑\n- 异常商品与优秀商品必须交叉验证\n- 总盘趋势至少用 2 个维度的数据解释\n- 行动建议必须按紧急程度（高/中/低）分档\n\n### 11.2 常用交叉验证组合\n\n| 场景 | 交叉验证方式 |\n|------|--------------|\n| 成交下跌 | 流量趋势 + 转化率 + 商品异常 + 老客活跃度 |\n| 流量下跌 | 渠道归因 + 搜索排名 + 商品状态 + 行业大盘 |\n| 转化率下降 | 商品详情/价格 + 流量结构 + 询盘承接 + 退款率 |\n| 新客乏力 | 流量渠道 + 拉新商品 + 活动效果 + 广告获客 |\n| 老客流失 | 头部客户明细 + 复购商品 + 退款/投诉 + 活动触达 |\n\n---\n\n## 十二、行动建议优先级\n\n所有行动建议只使用**紧急程度**（高/中/低）标注，不再使用 P0/P1/P2 或\"价值\"标签。\n\n| 紧急程度 | 判定标准 | 示例 |\n|----------|----------|------|\n| **高** | 核心指标严重恶化、核心商品/头部客户流失、存在立即损失风险 | 核心成交款双跌需立即优化；头部老客本期零采购需召回 |\n| **中** | 指标中度异常、结构性问题、可在一周内落地 | 搜索流量占比过高需补充推荐渠道；高流量低转化款优化详情页 |\n| **低** | 长期建设、预防性动作、影响滞后 | 建立新客专属权益；拓展潜力区域 |\n\n行动建议撰写格式：\n```\n建议：① xxx（紧急程度：高）；② xxx（紧急程度：中）；③ xxx（紧急程度：低）。\n```\n每条建议需标注所属店铺/商品/渠道，确保可执行。\n\nFile v1.4.0:references/cli-commands.md\n\n# CLI 命令详细字段说明\n\n本文档包含 1688-shop-health-check 所有 CLI 命令的详细参数和字段说明。Agent 在调用具体命令前按需读取对应章节。\n\n所有命令均通过 `python3 {baseDir}/cli.py <command> [options]` 调用，输出统一为：\n```json\n{\"success\": bool, \"markdown\": str, \"data\": {...}}\n```\n\n### 通用参数\n\n| 参数 | 必填 | 说明 |\n|------|------|------|\n| `--NEWTON_SHOP_LOGIN_ID` | 否 | 店铺登录ID（值为 `get_bindlist` 返回的对应店铺 `loginId`），用于指定查询的店铺。Agent 单独调用单店铺命令查询非当前 AK 默认店铺时必须传入。不传时使用当前 AK 对应的默认店铺 |\n\n---\n\n## 1. `alibaba.1688.seller.trade.code.index` — 店铺交易核心指标（总盘）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.trade.code.index [--date_type <DATE_TYPE>] [--device <DEVICE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：总盘分析**第一优先级接口**，判断店铺整体健康度、规模、效率、质量、新老客结构和下单到支付衔接情况。\n\n**关键字段**：\n\n| 字段 | 含义 | 用途 |\n|------|------|------|\n| `payAmt` | 支付金额 | 成交规模 |\n| `payByrCnt` | 支付买家数 | 买家规模 |\n| `payRate` | 支付转化率 | 转化效率 |\n| `payMordCnt` | 支付订单数 | 订单规模 |\n| `payItemCnt` | 支付商品款数 | 在售活跃款数 |\n| `payItemQty` | 支付商品数量 | 件数规模 |\n| `perByrAmt` | 人均支付金额 | 客单表现 |\n| `payToOnRate` | 下单到支付转化效率 | 支付承接效率 |\n| `payNewByrCnt` | 新支付买家数 | 拉新能力 |\n| `payOldByrCnt` | 老支付买家数 | 复购能力 |\n| `oldPayByrAmt` | 老买家支付金额 | 老客贡献 |\n| `rfdSucAmt` | 退款成功金额 | 成交质量风险 |\n| `crtOrdAmt` | 创建订单金额 | 下单规模 |\n| `crtByrCnt` | 创建订单买家数 | 下单买家规模 |\n| `crtOrdItmQty` | 创建订单商品数量 | 下单件数 |\n| `cycleCrc` | 环比变化率 | 趋势方向（可能为负） |\n| `cycleCqc` | 环比变化绝对值 | 趋势幅度 |\n\n---\n\n## 2. `alibaba.1688.seller.import.abnormal.offer` — 异常商品（风险定位）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.import.abnormal.offer [--date_type <DATE_TYPE>] [--device <DEVICE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：风险定位**关键接口**，判断问题主要来自流量、转化还是同时恶化，识别对店铺拖累最大的异常商品。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `reason` | 异常原因，如\"访客下跌\"/\"支付下跌\"/\"访客下跌, 支付下跌\" |\n| `itemId` | 商品ID |\n| `offerTitle` | 商品标题 |\n| `categoryId` | 类目ID |\n| `offerImageUrl` | 商品图 |\n| `link` | 异常详情跳转链接 |\n| `abnormalProduct` | 是否异常商品 |\n| `valueMap.uv.value` | 当前访客数 |\n| `valueMap.uv.cycleCrc` | 访客变化率 |\n| `valueMap.uv.cycleCqc` | 访客变化值 |\n| `valueMap.payAmt.value.value` | 当前支付金额 |\n| `valueMap.payAmt.cycleCrc.value` | 支付金额变化率 |\n| `valueMap.payAmt.cycleCqc.value` | 支付金额变化值 |\n\n---\n\n## 3. `alibaba.1688.seller.top.offer` — 优秀商品榜单（多榜单）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.top.offer [--order_by <ORDER_BY>] [--date_type <DATE_TYPE> | --range_type <RANGE_TYPE>] [--device <DEVICE>] [--order <desc|asc>] [--page <N>] [--page_size <N>] [--index_code <INDEX_CODE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**⚠️ 重要约束**：本接口**必须按需多次调用**，单次只能拉取一种榜单。\n\n**`order_by` 枚举**：\n\n| 值 | 榜单类型 | 用途 |\n|------|----------|------|\n| `payAmt` | 支付榜（默认） | 成交主力商品 |\n| `uv` | 访客榜 | 流量主力商品 |\n| `payNewByrCnt` | 拉新榜 | 拉新主力商品 |\n| `itemMultiByrCnt` | 复购榜 | 复购主力商品 |\n\n**`range_type` 仅支持** `RECENT_7` / `RECENT_30`。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `item.offerTitle` / `item.offerId` / `item.detailUrl` / `item.categoryID` | 商品基础信息 |\n| `revealCnt` | 曝光数 |\n| `uv` | 访客数 |\n| `payByrCnt` | 支付买家数 |\n| `payRate` | 支付转化率 |\n| `payAmt` | 支付金额 |\n| `payItemQty` | 支付件数 |\n| `payNewByrCnt` | 新支付买家数 |\n| `payOldByrCnt` | 老支付买家数 |\n| `itemMultiByrCnt` | 复购买家数 |\n| `itemMultiByrPayAmt` | 复购支付金额 |\n\n---\n\n## 4. `alibaba.1688.seller.activity.registered.info` — 活动参与及效果\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.activity.registered.info [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：分析活动是否有效，是否带来流量、订单和 GMV，是否优于同行基准，是否存在\"有曝光无成交\"或\"高产出活动可复制\"。\n\n> **⚠️ 注意**：本接口数据为**近 30 天活动**口径，不完全等同于当前分析周期，需在结论中说明。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `activityName` / `activityId` | 活动信息 |\n| `cateLevel1Name` | 一级类目 |\n| `startTime` / `endTime` | 活动时间 |\n| `activityItmVisitorUv` / `activityItmVisitorPv` | 活动商品访客 UV/PV |\n| `activityItmOrderCnt` | 活动商品订单数 |\n| `activityItmTakeCnt` | 活动商品领取/参与次数 |\n| `activityItmGmv` | 活动商品 GMV |\n| `peerActivityItmVisitorPv` | 同行活动 PV（基准） |\n| `peerActivityItmGmv` | 同行活动 GMV（基准） |\n| `rank` | 活动排名（可能无效） |\n\n---\n\n## 5. `alibaba.1688.seller.customer.business.province` — 客户地域分布\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.customer.business.province [--date_type <DATE_TYPE>] [--page_size <N>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：分析客户地域集中度、核心区域依赖、区域覆盖面、潜在扩展区域。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `attributeValue` | 地域名称（省份） |\n| `payBuyerNum` | 该地域支付买家数 |\n| `payBuyerNumRate` | 该地域支付买家数占比 |\n| `recordCount` | 记录数 |\n\n---\n\n## 6. `alibaba.1688.seller.customer.detail` — 头部老客户明细\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.customer.detail [--date_type <DATE_TYPE>] [--buyer_type <TYPE>] [--order_by <ORDER_BY>] [--page_size <N>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：分析店铺是否依赖少数头部老客户，头部老客是否持续活跃，复购盘是否稳固，是否存在高价值客户近期走弱风险。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `identityName` | 客户身份/画像 |\n| `companyName` | 公司名 |\n| `custAreaName` | 客户地域 |\n| `buyerLoginId` | 买家标识 |\n| `payAmount` | **本周期**支付金额 |\n| `payAmtAll` | **累计**支付金额（看历史价值） |\n| `lastPayDate` | 最近支付日期（看活跃度） |\n| `firstPayDate` | 首次支付日期 |\n| `fstFromAd` | 是否首次来自广告（自然 vs 广告获客） |\n| `buyerType` | 买家类型 |\n| `payParentOrderNum` | 支付父订单数 |\n| `buyerCreditLevel` | 信用等级 |\n| `lstLossDate` | 最近流失日期（可能为空） |\n\n---\n\n## 7. `alibaba.1688.get.traffic.trend` — 逐日流量趋势数据\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.traffic.trend --query_date <QUERY_DATE> [--days <DAYS>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：获取逐日流量趋势数据，用于分析流量波动趋势、识别异常波动、判断流量健康度。\n\n**⚠️ 重要约束**：\n- `query_date` 必须传入**昨日日期**（格式：YYYY-MM-DD）\n- `days` 仅支持 7 或 30，表示近 7 天或近 30 天的数据\n\n**关键字段**（返回数组中每项包含）：\n\n| 字段 | 含义 |\n|------|------|\n| `uv` | 访客数 |\n| `pv` | 浏览量 |\n| `UVCTR` | UV 点击率 |\n| `日期` | 日期（格式：YYYYMMDD） |\n\n---\n\n## 8. `alibaba.1688.get.core.metrics` — 店铺核心指标同行对比及趋势数据\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.core.metrics [--date_type <DATE_TYPE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：获取店铺核心指标的同行对比数据及趋势数据，用于判断店铺在行业中的位置、指标健康度、增长趋势。\n\n**⚠️ 重要约束**：\n- `date_type` 仅支持 `RECENT_7` 或 `RECENT_30`\n- 接口返回的 `data` 是 JSON 字符串，包含 `core_metrics`（同行对比）和 `trend`（趋势数据）\n\n**关键字段（core_metrics 数组中每项包含）**：\n\n| 字段 | 含义 |\n|------|------|\n| `metric_name` | 指标名称（展现次数/访客数/浏览量/点击转化率/支付转化率/支付买家数/支付金额） |\n| `metric_code` | 指标代码（impression/visitor/page_view/click_cvr/pay_cvr/buyer_count/pay_amount） |\n| `my_value` | 本店数值 |\n| `peer_avg` | 同行同层均值 |\n| `ratio_to_peer` | 本店/同行同层均值（达标率） |\n| `rating` | 评级（优秀/持平/略低/极低） |\n\n**关键字段（trend 对象中每项包含）**：\n\n| 字段 | 含义 |\n|------|------|\n| `value` | 当前值 |\n| `year_on_year` | 同比变化率（本月 vs 去年同一月） |\n| `week_on_week` | 环比变化率（本周 vs 上周 / 本月 vs 上月） |\n| `vs_peer_avg` | 本店变化率 vs 同行平均变化率 |\n| `vs_peer_good` | 本店变化率 vs 同行优秀变化率 |\n\n**趋势字段判断提示**：\n- `vs_peer_avg` > 1 表示本店变化优于同行平均\n- `vs_peer_good` > 1 表示本店变化优于同行优秀\n\n**关键字段（date_range 对象）**：\n\n| 字段 | 含义 |\n|------|------|\n| `start_date` | 开始日期 |\n| `end_date` | 结束日期 |\n\n---\n\n## 9. `shop_health_check` — 店铺健康检查（订单履约/合规扣分/买家评价）\n\n```bash\npython3 {baseDir}/cli.py shop_health_check --code <order_risk|shop_punish|feedback> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：店铺健康检查聚合工具，单命令通过 `--code` 路由到三个模块。`order_risk`（订单履约）与 `feedback`（买家评价）服务**成交维度**，`shop_punish`（合规扣分）服务**风险维度**。仅透传后端业务数据，Agent 侧自行加工。\n\n**参数**：\n\n| 参数 | 必填 | 说明 |\n|------|------|------|\n| `--code` | 是 | 模块编码，枚举 `order_risk` / `shop_punish` / `feedback` |\n| `--NEWTON_SHOP_LOGIN_ID` | 否 | 目标店铺 loginId，多店铺查询时传入 |\n\n> **口径说明**：本工具返回为**实时快照**，非近 7/30 天周期口径，结论与报告中需区分标注。\n\n### 9.1 `--code order_risk`（订单履约）\n\n返回 `data` 结构：\n\n| 字段 | 含义 |\n|------|------|\n| `overview.pending_ship_cnt` | 待发货订单数 |\n| `overview.pending_payment_cnt` | 待付款订单数 |\n| `overview.pending_receive_cnt` | 待收货订单数 |\n| `overview.pending_custom_payment_cnt` | 待处理定制付款订单数 |\n| `timeout_risk.about_to_timeout_cnt` | 即将发货超时订单数 |\n| `timeout_risk.already_timeout_cnt` | 已发货超时订单数 |\n| `timeout_risk.about_to_timeout_orders` | 即将超时订单 Top5（按剩余时长升序） |\n| `timeout_risk.already_timeout_orders` | 已超时订单 Top5（按超时时长降序） |\n\n每条订单明细字段：\n\n| 字段 | 含义 |\n|------|------|\n| `order_id` | 订单号 |\n| `product_name` | 首个商品名（截断 30 字） |\n| `amount_yuan` | 订单金额（元，字符串） |\n| `send_hour` | 承诺发货时长 |\n| `left_time` | 距发货截止剩余时效（仅即将超时订单） |\n| `overdue_time` | 已超时时长（仅已超时订单） |\n\n### 9.2 `--code shop_punish`（合规扣分）\n\n返回 `data` 结构：\n\n| 字段 | 含义 |\n|------|------|\n| `punish_score` | 违规扣分 |\n| `fake_times` | 假货次数 |\n| `punish_warning.cnt` | 违规预警总数 |\n| `punish_warning.new_cnt` | 新增违规数 |\n| `punish_warning.deal_url` | 处理链接 |\n| `punish_warning.list` | 待处理违规明细（仅 PENDING，按 `punish_time` 倒序） |\n| `item_alert.cnt` | 商品预警数 |\n| `item_alert.list` | 商品预警明细 |\n| `legal_alert.cnt` | 司法预警数 |\n| `legal_alert.admin_case` | 行政案件数 |\n| `legal_alert.law_case` | 司法案件数 |\n| `legal_alert.deal_url` | 处理链接 |\n\n`punish_warning.list` 每项：`punish_id` / `rule_type`（违规规则类型） / `punish_status` / `punish_time` / `is_new` / `deal_url`。\n\n`item_alert.list` 每项：`item_id` / `item_title` / `risk_lev1_name`（一级风险） / `risk_lev2_name`（二级风险） / `warning_left_time`（预警剩余时长） / `deal_url`。\n\n### 9.3 `--code feedback`（买家评价）\n\n返回 `data` 结构：\n\n| 字段 | 含义 |\n|------|------|\n| `rating_overview.total_cnt` | 评价总数 |\n| `rating_overview.distribution` | 1~5 分档分布，每项 `rate`（分档） / `cnt`（数量） |\n| `rating_overview.low_score_cnt` | 低分（≤3 分）数量 |\n| `rating_overview.low_score_ratio` | 低分占比（百分比字符串，如 `12.50%`） |\n| `negative_feedback.cnt` | 负面反馈数 |\n| `negative_feedback.items` | 负面反馈明细，每项 `item_name`（商品名） / `feedback`（反馈内容） |\n| `positive_cnt` | 正面反馈数 |\n\n---\n\n## 10. `alibaba.1688.get.traffic.overview` — 全店流量概览\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.traffic.overview --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：获取全店流量概览数据（访客规模、流量总览），服务**流量维度**，与 `alibaba.1688.get.channel.traffic` 配合完成全店流量构成分析。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回，Agent 侧自行解析。\n\n---\n\n## 11. `alibaba.1688.get.channel.traffic` — 各渠道流量\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.channel.traffic --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：获取各渠道流量数据（搜索 / 推荐 / 广告等渠道构成与占比），服务**流量维度**。根据渠道占比决定后续下钻方向。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 12. `alibaba.1688.get.search.channel.detail` — 搜索渠道深度下钻\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.search.channel.detail --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：搜索渠道深度下钻，分析搜索流量来源与转化承接，服务**流量维度**。建议在 `alibaba.1688.get.channel.traffic` 确认搜索占比较高时下钻。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 13. `alibaba.1688.get.recommend.channel.detail` — 推荐渠道深度下钻\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.recommend.channel.detail --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：推荐渠道深度下钻，分析推荐流量来源与承接，服务**流量维度**。建议在推荐占比较高时下钻。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 14. `alibaba.1688.get.ad.channel.detail` — 广告渠道深度下钻\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.ad.channel.detail --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：广告渠道深度下钻，分析广告渠道流量与转化。**流量维度与广告维度共享**（两维度任一需要时均调用一次即可）。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 15. `alibaba.1688.get.product.status` — 商品状态检查\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.product.status --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：检查商品搜索降权 / 下架等状态，服务**商品维度**。可与异常商品、优秀商品榜单交叉验证。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 16. `alibaba.1688.get.industry.benchmark` — 行业大盘对比数据\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.get.industry.benchmark --query_date <QUERY_DATE> [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：行业大盘对比数据查询，用于将本店表现与行业大盘对比，服务**广告维度**。\n\n**参数**：`--query_date` 必填，传**昨日日期**（格式 YYYY-MM-DD）；`--NEWTON_SHOP_LOGIN_ID` 可选。\n\n> 接口透传后端业务数据（`data`），字段结构随接口返回。\n\n---\n\n## 17. `get_bindlist` — 多店铺绑定关系列表\n\n```bash\npython3 {baseDir}/cli.py get_bindlist\n```\n\n**用途**：获取当前用户的多店铺绑定关系列表，是**多店铺批量体检的入口** —— 先取绑定列表，再对每个 `loginId` 逐店传 `--NEWTON_SHOP_LOGIN_ID` 诊断。\n\n**参数**：无（仅需已配置 AK）。\n\n**关键字段**（`data` 为绑定店铺数组，每项包含）：\n\n| 字段 | 含义 |\n|------|------|\n| `companyName` | 店铺公司名 |\n| `loginId` | 店铺登录 ID（用作其他单店铺命令的 `--NEWTON_SHOP_LOGIN_ID` 参数值） |\n| `userId` | 用户 ID |\n| `isOwner` | 是否为店铺负责人 |\n\n---\n\n## 18. `configure` — 配置 AK\n\n```bash\npython3 {baseDir}/cli.py configure [YOUR_AK]\n```\n\n**用途**：配置 1688 API 的 AccessKey，用于后续所有接口的鉴权签名。\n\n**使用方式**：\n\n| 命令 | 行为 |\n|------|------|\n| `python3 {baseDir}/cli.py configure YOUR_AK` | 写入 AK 到本地配置 |\n| `python3 {baseDir}/cli.py configure` | 查看当前 AK 配置状态 |\n\n> **注意**：首次使用前必须配置 AK，否则所有只读接口将返回 `success: false` 和 \"AK 未配置\" 错误。\n\nFile v1.4.0:references/interaction-specs.md\n\n# 交互组件详细规范\n\n本文档定义 1688-shop-health-check Skill 中所有交互组件的具体数据结构与映射规则。\n\n## 1. confirm_execution_plan（Card 组件）\n\n### 组件类型\n\n`type: card`，`selectionType: requirement`\n\n### 业务场景\n\n用户提出店铺健康检查请求后，Agent 输出默认执行计划（含输出形式：总结性结论 + HTML 网页数据报告、时间周期、覆盖店铺），并通过该卡片提供 **8 个可选项**让用户选择要诊断的维度：前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为\"全面诊断（七维度）\"。卡片**允许多选**。\n\n> **触发条件（免确认短路）**：本卡片仅在**未命中免确认条件**时触发。用户已明确指定具体维度、明确要求全面体检/全面诊断、或明确要求直接开始（含定时任务触发的请求——其 query 即任务执行内容，逐字含七维度名）时，**跳过本卡片**直接进入诊断取数。\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`\n  - 说明: 问题列表，仅含一项必填多选项。\n    - `question` (string): 引导用户选择诊断维度的问题文案\n    - `options` (Array<string>): 固定 8 项 —— 前 7 项为七维度名称（`\"流量\"`、`\"询盘\"`、`\"成交\"`、`\"商品\"`、`\"客户\"`、`\"广告\"`、`\"风险\"`），第 8 项为 `\"全面诊断（七维度）\"`\n    - `allowMultiple` (bool): 固定 `true`\n    - `required` (bool): 固定 `true`（至少选择 1 项）\n  - 卡片默认提供\"确认\"与\"取消\"按钮\n\n### 完整数据示例\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"请选择要诊断的维度（可多选），或选择\\\"全面诊断（七维度）\\\"执行全部：\",\n      \"options\": [\"流量\", \"询盘\", \"成交\", \"商品\", \"客户\", \"广告\", \"风险\", \"全面诊断（七维度）\"],\n      \"allowMultiple\": true,\n      \"required\": true\n    }\n  ]\n}\n```\n\n### 用户选择结果处理\n\n| 用户操作 | Agent 行为 |\n|----------|-----------|\n| 勾选一个或多个维度并点击\"确认\" | 仅按所选维度执行诊断，按「三、全面诊断维度与数据获取」对所选维度并行取数 |\n| 勾选\"全面诊断（七维度）\"并点击\"确认\" | 覆盖个体选择，执行全部七维度诊断 |\n| 点击\"取消\" / 返回空结果 / 无人作答 / 不勾选任何项 | 统一终止流程，不执行任何诊断，不输出报告，一律以「未收到有效的维度选择，本次体检未执行」口径如实收尾，**严禁表述为\"用户取消\"**；此为符合平台语义的正常终止而非失败，**终止后不得重试、不得自行重新弹卡或重新发起体检**，用户若需体检由其主动重新请求 |\n\n> 勾选\"全面诊断（七维度）\"时优先级最高，会覆盖同时勾选的个别维度。若最终未识别到任何有效维度，按「未收到有效的维度选择」口径终止流程，**不得表述为用户取消**（取消回包形态无法与无人作答可靠区分，不做猜测）。\n\n---\n\n## 2. select_action_items（Card 组件）\n\n### 组件类型\n\n`type: card`，`selectionType: requirement`\n\n### 业务场景\n\n在总结性结论与 HTML 报告输出后，将体检流程**内部已定稿**的最多 3 条优先行动建议直接渲染为可多选行动项，并在行动项之后按条件追加一个「设置定时任务」选项，用户确认后 Agent 直接按选中项继续执行对应优化动作或为用户设置并开启定时体检任务。\n\n> **🤫 静默约束（最高优先级）**：行动项已在体检流程内部完成挑选与排序，构造本卡片时 Agent 唯一需要做的内部判断是「定时任务去重」：调用 `Schedule`（action=list）后**立即按结果渲卡，中间不得输出任何正文**。对用户**只**呈现：最终的 `select_action_items` 卡片、以及用户选择后真实执行的结果与确认语。尤其**禁止**输出「让我先检查定时任务」「根据 Schedule 列表我看到…」「既然定时任务已启用，我不应该追加这个选项」之类的判断过程，也禁止泄露任何内部字段与判据（`id`、`enabled`、`schedule`、`cron`、技能名、触发语等）。用户勾选后的执行环节同理：直接调用对应技能，不要输出「让我看看哪个技能能处理」「行动项映射：xxx → 某技能」之类的匹配过程。\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`\n  - 说明: 问题列表，仅含一项，字段如下：\n    - `question` (string): 引导用户选择下一步执行哪些行动项\n    - `options` (Array<string>): 选项文本数组。前若干条为行动项（最多 3 条，按优先级从高到低排列，每条包含行动概要、所属店铺简称及紧急程度）；**最后按条件追加一条定时任务选项**，文案固定为 `⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务`（追加条件见「定时任务推荐选项」）\n    - `allowMultiple` (bool): 固定 `true`，表示可多选\n    - `required` (bool): 固定 `true`，表示至少选择 1 项\n  - 卡片默认提供\"确认\"与\"取消\"按钮\n  - **定时任务选项为条件型（must-check）**：构造卡片前必须先 `Schedule list` 并按「去重匹配规则」判断，未命中或命中但已停用（enabled:false）才追加该选项；即使本次体检没有可执行的行动项，也应触发该卡片并仅展示该定时任务选项（仍需先按规则判断是否展示）\n\n### 定时任务推荐选项（条件型，非行动项驱动）\n\n除由「优先行动建议」生成的行动项外，还需按以下规则判断是否追加「⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务」选项。该选项**不由行动项驱动**，而是根据店铺体检定时任务的存在状态判断：\n\n1. **检查时机（重要）**：定时任务状态检查必须在**总结性结论与 HTML 报告输出之后**、构造卡片时才进行，**绝不可放在输出前**，以免阻塞诊断结论与报告的输出。\n2. **必须先查（must-check）**：构造卡片前**必须先调用 `Schedule`（action=list）拉取全部定时任务**，按下方「去重匹配规则」判断是否已存在店铺体检定时任务，再决定是否追加选项。**不得跳过检查直接追加**。\n3. **去重匹配规则（name / description 双键 OR 命中）**：对 list 返回的每条任务，满足以下任一即视为「已存在店铺体检定时任务」——\n   - `name` 精确等于 `店铺健康检查`；**或**\n   - `description` 精确等于固定执行内容 `自动进行 1688 店铺全面体检，覆盖流量、询盘、成交、商品、客户、广告、风险七大维度，生成体检报告并给出异常提醒和经营建议`。\n   比对前先 `trim` 并将连续空白折叠为单空格再做**精确比对**；**禁止**用 `includes('体检')` 之类子串粗匹配（会误伤日报等其他任务）。\n4. **展示 / 动作决策**：\n   - **未命中**（无匹配任务）→ **追加**选项；用户确认后**新建**（create）。\n   - **命中且 `enabled:true`**（已开启）→ **不追加**选项，按第 6 点措辞护栏处理。\n   - **命中但 `enabled:false`**（已存在但停用）→ **追加**选项；用户确认后走 **`update` 重新启用**该任务，**禁止 create 新建**。\n   - **`list` 调用报错 / 确实无法执行**（fail-open 兜底，仅此一种）→ **追加**选项；用户确认后新建。\n5. **位置与文案**：作为附加选项排在所有行动项之后（最后一个），不参与优先级排序，不计入 3 条行动项上限；文案固定为 `⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务`。\n6. **已存在（enabled:true）时的措辞（必须静默）**：当**确实查到已存在且已开启、决定不追加**该选项时，该选项**不追加**，且**绝对不要向用户输出任何与定时任务相关的文案**：\n   - **尤其禁止输出「已为您设置/已为您开启『店铺健康检查』定时任务…」这类确认语**——此时用户既没有该选项、也没有勾选，任何定时任务提示都是凭空出现的误导；\n   - **同样禁止输出任何内部判断过程或技术字段**（如 `id`、`enabled=true`、`schedule`、`cron`、“因此不需要追加定时任务选项”之类的话）。\n\n### 完整数据示例\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"已为您筛选出本次体检最关键的 3 项行动建议，请选择要立即执行的行动项：\",\n      \"options\": [\n        \"优化阿里巴巴的搜索进店商品详情页与主图，提升转化率（高）\",\n        \"补充阿里巴巴的推荐/活动流量渠道，降低对搜索的依赖（中）\",\n        \"建立新客专属权益，改善新老客结构（低）\",\n        \"⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务\"\n      ],\n      \"allowMultiple\": true,\n      \"required\": true\n    }\n  ]\n}\n```\n\n### 用户选择结果处理\n\n| 用户操作 | Agent 行为 |\n|----------|-----------|\n| 勾选行动项并点击\"确认\" | 对勾选的每一项在当前会话可用技能中现场寻找能承接的技能并真实执行；若某项确实无技能可承接，直接给出具体的人工操作建议并明确告知用户 |\n| 勾选「⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务」并点击\"确认\" | 若该选项因「未命中」而展示 → 以**完整定时任务规格新建**；若因「命中但 `enabled:false`」而展示 → 走 **`update` 重新启用**已有任务，**不新建**。新建时由客户端弹出「设置定时任务」确认卡片（含执行时间、执行内容、修改任务/立即执行按钮），待用户点击「立即执行」后再创建，不可直接建任务。规格：**任务名「店铺健康检查」**；**执行时间「每天 09:30」**；**执行内容「自动进行 1688 店铺全面体检，覆盖流量、询盘、成交、商品、客户、广告、风险七大维度，生成体检报告并给出异常提醒和经营建议」**。设置成功后向用户确认已开启（如「已为您开启『店铺健康检查』每日定时任务，每天 09:30 自动生成体检报告」）。**仅当用户确实勾选了该选项并成功设置后才输出确认；未勾选或该选项本就未追加时，禁止输出任何定时任务文案** |\n| 点击\"取消\"或不勾选任何项 | 结束本次体检流程，不执行后续动作 |\n\n> **只展示一次（收尾约束）**：`select_action_items` 卡片在整轮体检中只展示一次。用户完成勾选并触发对应技能（或点击\"取消\"/\"跳过\"、不勾选任何项）后，体检流程即结束；**触发的下游技能返回后，不得再次渲染该卡片**，用户如需继续优化应主动发起新请求，Agent 不得自行重弹。\n\n### 选项生成规则\n\n1. 行动项由体检流程内部生成并定稿（已从「优先行动建议」中按 **高 > 中 > 低** 挑选、最多 3 条），Agent 拿到后**逐条原样作为选项**，不得增删、改写、重排，也不得再按「是否有技能承接」二次筛选。\n2. 行动项生成时已遵循：每条 **40 字以内**，包含「动作对象 + 核心动作 + 紧急程度（高/中/低）」，多店铺场景含所属店铺简称；同等紧急程度下优先选择更可能被自动化能力承接的行动项（软约束，不保证每条都有技能承接）。\n3. 用户勾选后，Agent 在当前会话可用技能中**现场寻找**能承接的技能并真实执行；**若某项确实没有技能可承接，直接给出具体的人工操作建议并明确告知用户**，不得静默忽略。\n4. 若体检流程未产出任何行动项，卡片仍需触发，仅展示下方按条件追加的定时任务选项。\n5. **定时任务选项（条件型 / must-check）**：在行动项之后按「定时任务推荐选项」规则处理——先 `Schedule list` + name/description 双键 OR 命中判断，文案固定为 `⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务`，不参与优先级排序，不计入 3 条行动项上限；**仅当确实查到已存在且已开启（enabled:true）的店铺体检定时任务时才不追加**，命中但已停用（enabled:false）仍追加（确认后重新启用）。\n\n---\n\n## 3. 已废弃的交互（不再使用）\n\n以下交互组件属于旧两阶段流程，当前版本已废弃：\n\n- `select_analysis_direction`\n- `select_abnormal_action`\n- `input_offer_for_optimize`\n\n当前版本采用**单阶段完整诊断**，不再在诊断过程中让用户选择深入方向，也不再输出异常商品下一步操作卡片。所有诊断结果通过总结性结论 + HTML 网页数据报告一次性交付。\n\nFile v1.4.0:references/wiki-routing-rules.md\n\n# Wiki 读取规则\n\nWiki 只补充商家背景，不替代店铺体检接口数据。\n\n- `WikiNav` / `WikiRead` 是当前会话提供的模型工具，不是本 skill 的 CLI 命令；没有 `WikiNav` 时跳过 Wiki，不要用 CLI、Bash 或猜文件路径替代。有 `WikiNav` 但没有 `WikiRead` 时，只使用可靠的页卡摘要，不尝试调用不存在的工具。\n- 调用时传 `skillName=\"1688-shop-health-check\"`。\n- 店铺路由用 `loginId`，不用 `shopId` / userId，也不得把 `loginId` 写入 query。仅当工具参数中提供 `loginId` 时才传入目标店铺的 `loginId`；单店工具没有该参数时省略，使用当前店铺。\n- 每店只调用一次 `WikiNav(query=\"店铺\", skillName=\"1688-shop-health-check\")`；工具提供 `loginId` 参数时增加目标店铺的 `loginId`。不改写 query 二次搜索，不翻页续查。\n- 只使用属于目标店铺的店铺、品牌、工厂、经营定位或服务体系页面；客户实体、单个商品和平台知识不能代表店铺整体背景。\n- 如果 `WikiNav` 提示目标 `loginId` 未找到、已查询默认店或当前店，立即丢弃该次结果，不调用 `WikiRead`，也不得把回落店铺的内容用于目标店铺。\n- 如果 `WikiNav` 页卡的标题、摘要和章节已足够形成可靠的商家背景，直接整理摘要并停止，不调用 `WikiRead`。\n- 只有页卡摘要不足时才读取正文：每店最多选择 3 个最相关页面，在同一轮调用 `WikiRead`；`page/path` 必须沿用 `WikiNav` 返回的信息。仅当 `WikiRead` 参数中提供 `loginId` 时才沿用对应页卡的 `loginId`，不得自行编写路径或路由值。\n- 不要把 A 店 Wiki 用到 B 店；路由或页面归属不确定就跳过。\n- 经营指标、销量、转化率、价格、评价、违规、履约等量化事实，以 CLI / 接口数据为准。\n- Wiki 只能影响背景解释和建议措辞，不能单独制造诊断结论。\n\nFile v1.4.0:skill-card.md\n\n## Description:\n\nAnalyzes 1688 merchant shop health across traffic, inquiries, transactions, products, customers, advertising, and risk, then produces a Chinese summary, an HTML data report, and prioritized follow-up action options.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[1688aiinfra](https://clawhub.ai/user/1688aiinfra)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal 1688 merchants and their agents use this skill to run multi-shop operating health checks, compare recent business performance, identify risks, and select concrete optimization actions.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill can automatically install unpinned packages.\n\nMitigation: Preinstall reviewed dependencies in a trusted environment and avoid runtime package installation.\n\nRisk: Merchant access keys may be stored or forwarded with weak safeguards.\n\nMitigation: Protect or avoid plaintext access-key storage, restrict file permissions, and rotate the merchant key if exposure is possible.\n\nRisk: A misconfigured OpenClaw gateway URL could send requests to the wrong local gateway.\n\nMitigation: Verify OPENCLAW_GATEWAY_URL points to the intended local OpenClaw gateway before use.\n\n## Reference(s):\n\n- [ClawHub Skill Page](https://clawhub.ai/1688aiinfra/skills/1688-shop-health-check)\n- [1688aiinfra Publisher Profile](https://clawhub.ai/user/1688aiinfra)\n- [Analysis Methodology](references/analysis-methodology.md)\n- [CLI Command Reference](references/cli-commands.md)\n- [Interaction Specifications](references/interaction-specs.md)\n- [Wiki Routing Rules](references/wiki-routing-rules.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, HTML, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Chinese Markdown summary, JSON CLI results, interactive action cards, and an HTML report]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Supports multi-shop batch diagnostics and seven selectable diagnosis dimensions.]\n\n## Skill Version(s):\n\n1.4.0 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v1.4.0:workflow/prompts/analyze-conclude.prompt.md\n\n你是一名 1688 店铺经营分析专家。基于以下各店铺的独立分析结论，请进行跨店对比并生成最终的总结性结论。\n\n> ⚠️ **输出格式（最高优先级，先于一切规则）**：你的**唯一输出是一个 JSON 对象**（结构见文末），JSON 之外不得输出任何字符。下文的 Markdown 模板是 **conclusion 字段内部的内容格式**，不是你的输出格式，绝不可直接把 Markdown 报告当正文输出。\n\n## 诊断范围\n维度：{{dimensionText}}\n\n## 各店铺分析结论\n{{perShopConclusionsJson}}\n\n> **红线规则**：上方数据中包含几家店铺，就必须在结论中输出几家店铺的分析章节。逐店遍历，禁止遗漏任何一家。\n\n> **分析失败店铺护栏（必读）**：若某店 `analysisFailed` 为 `true`（或其结论为“分析服务出现波动”类占位文案），说明该店**本次分析环节未完成，店铺数据本身已正常获取**。对这类店铺：在其章节中如实说明“该店本次分析未完成，可单独重新体检”即可；**严禁**推断为数据缺失、数据采集异常、接口或授权问题，**严禁**为该店编造健康等级、核心发现或行动建议（健康等级写“本次未评定”），跨店健康度排序中排除该店并注明原因。\n\n## 输出格式（必须严格遵守）\n\n### 店铺简称提取规则\n从完整店铺名中提取有辨识度的字号/前缀作为简称。例如：\n- \"阿里巴巴（中国）网络技术有限公司\" → \"阿里巴巴\"\n- \"慕嘉测试卞韦的公司\" → \"慕嘉\"\n- 若两店字号相同，保留地域前缀区分\n- 严禁使用\"店铺1、店铺2、店铺A、店铺B\"等编号\n\n### 多店铺场景输出模板\n为每家店铺分别输出一个三级标题章节，必须使用以下结构化格式（禁止用连续文字段落代替）：\n\n```markdown\n### {店铺简称}\n\n**当前分析店铺：{完整店铺名}**\n\n- **健康等级**：健康 / 基本稳定 / 存在风险 / 明显承压\n- **核心发现**：\n  1. {发现1，附关键数据}\n  2. {发现2，附关键数据}\n- **优先行动建议**：\n  - **高**：{动作1}\n  - **中**：{动作2}\n  - **低**：{动作3}\n```\n\n### 跨店对比结论（多店铺必填）\n\n```markdown\n### 跨店对比结论\n\n- **健康度排序**：{店铺简称} > {店铺简称}（依据：{核心指标/健康等级}）\n- **共性风险**：{各店共同存在的问题}\n- **资源倾斜建议**：{建议重点投入/优先优化的店铺或方向}\n```\n\n### 单店场景\n直接输出该店的分析章节，不需要跨店对比结论。\n\n### 禁止事项\n1. **禁止英文指标名**：所有指标必须使用中文（UV→访客数，PV→页面浏览量，payAmt→支付金额，payByrCnt→支付买家数，payConvRate→支付转化率，RECENT_7→近7天，RECENT_30→近30天）\n2. **禁止连续文字段落**：必须使用 bullet point 结构化格式\n3. **禁止遗漏店铺**：结论中有几家店铺就必须输出几家店铺的章节\n4. **禁止使用编号指代店铺**：必须使用从店名提取的简称\n\n### actionItems 必填要求（关键，不可漏）\n- `actionItems` **必须与结论中各店「优先行动建议」逐条一一对应**，逐条给出 `action`（动作描述）、`priority`（高/中/低）、`shopName`（店铺简称）、`dimension`（维度）。\n- **严禁只写进 markdown 结论、却让 `actionItems` 留空**——下游 HTML 报告与行动卡片都依赖它，留空会导致建议凭空丢失、三处口径不一致。\n- 仅当所有店铺确实**均无**需要优化的问题时才为 `[]`。\n\n输出 JSON（唯一输出，不得有 JSON 以外的任何字符）：{\"conclusion\": \"完整的 Markdown 总结性结论\", \"actionItems\": [{\"action\": \"行动描述\", \"priority\": \"高/中/低\", \"shopName\": \"店铺简称\", \"dimension\": \"维度\"}]}\n\nFile v1.4.0:workflow/prompts/analyze-shop.prompt.md\n\n你是一名 1688 店铺经营分析专家。请基于以下单店铺的多维度数据，进行健康度判断、风险识别和行动建议。\n\n> ⚠️ **输出格式（最高优先级，先于一切规则）**：你的**唯一输出是一个 JSON 对象**（结构见文末），JSON 之外不得输出任何字符（不要加 markdown 围栏、不要写解释性开场白）。下文的 Markdown 模板是 **conclusion 字段内部的内容格式**，不是你的输出格式，绝不可直接把 Markdown 报告当正文输出。\n\n## 分析方法论（优先级高于通用规则）\n{{methodologyContent}}\n\n## 诊断范围与周期\n维度：{{dimensionText}}\n周期：{{period}}\n\n## 店铺诊断数据（主要依据）\n{{shopDataJson}}\n\n## Wiki 背景信息（辅助参考）\n{{wikiContextJson}}\n\n## 输出要求\n\n`conclusion` 字段内部请按以下 Markdown 结构组织（注意：这是字段内容的格式，整体输出仍是文末的 JSON 对象）：\n\n```markdown\n### {{shopName}}\n\n- **健康等级**：健康 / 基本稳定 / 存在风险 / 明显承压\n- **核心发现**：\n  1. {发现1，附关键数据}\n  2. {发现2，附关键数据}\n- **优先行动建议**：\n  - **高**：{动作1}\n  - **中**：{动作2}\n  - **低**：{动作3}\n```\n\n### 禁止事项\n1. **禁止英文指标名**：所有指标必须使用中文（UV→访客数，PV→页面浏览量，payAmt→支付金额，payByrCnt→支付买家数，payConvRate→支付转化率，ctr→点击率，cvr→转化率，CPC→点击单价，ROI→投入产出比，RECENT_7→近7天，RECENT_30→近30天）\n2. **禁止连续文字段落**：必须使用 bullet point 结构化格式\n3. **禁止遗漏维度**：数据中包含的每个维度都必须分析\n4. **禁止把个别子项失败放大为整体数据缺失**：数据中个别条目 `success: false`（如 ragResult 等辅助检索）仅表示**该单项**数据暂不可用，按“该项缺失”口径处理即可；**严禁**据此推断店铺整体数据采集异常、授权异常或“各项核心指标缺失”。指标值为 0 是**真实经营数值**（如零访客、零成交），不是数据缺失，应据实分析经营状况\n5. **禁止把 Wiki 作为唯一诊断依据**：健康等级、核心发现和每条行动建议都必须至少有一项上方【店铺诊断数据】支撑；Wiki 只能补充商家背景、解释已有数据结论或调整建议措辞。只有 Wiki 背景支持、没有店铺诊断数据支撑的判断或行动必须省略\n\n### actionItems 必填要求（关键，不可漏）\n- `actionItems` **必须与结论中「优先行动建议」逐条一一对应**：结论里写了几条（高/中/低），就填几条，逐条给出 `action`（动作描述）、`priority`（高/中/低）、`dimension`（所属维度）。\n- **严禁只把行动建议写进 markdown 结论、却让 `actionItems` 留空**——下游 HTML 报告与行动卡片都依赖这个结构化数组，留空会导致建议凭空丢失、三处口径不一致。\n- 仅当该店确实**无任何**需要优化的问题时 `actionItems` 才为 `[]`（此时结论中也不应出现优先行动建议）。\n\n输出 JSON（唯一输出，不得有 JSON 以外的任何字符）：{\"conclusion\": \"该店铺的 Markdown 分析结论\", \"healthLevel\": \"健康/基本稳定/存在风险/明显承压（四选一，不得使用其它表述）\", \"keyFindings\": [\"核心发现1\", \"核心发现2\"], \"actionItems\": [{\"action\": \"行动描述\", \"priority\": \"高/中/低\", \"dimension\": \"维度\"}]}\n\nFile v1.4.0:workflow/prompts/build-actions.prompt.md\n\n你是店铺经营优化顾问。请根据诊断结果，生成**最终展示给用户**的行动项（最多 3 条）。主 Agent 拿到后会直接渲染多选卡片，不再二次筛选，因此本步骤产出的就是终稿。\n\n## 诊断发现的行动建议（结构化，按优先级排序）\n{{actionItemsJson}}\n\n## 总结性结论全文（兜底来源）\n{{conclusionText}}\n\n## 行动项生成规则\n1. 按紧急程度排序：高 > 中 > 低，**只保留最紧急的最多 3 条（硬上限，不得超过）**\n2. **数据来源**：优先依据上方【结构化行动建议】生成；**当结构化数组为空、或明显少于结论中提到的行动建议时，以【总结性结论全文】里的「优先行动建议」为准补齐**，补齐后再按紧急程度取前 3 条。\n3. **软约束（同等紧急程度时优先）**：优先挑选更可能被自动化能力承接的行动项。常见可承接的动作方向包括：订单跟单/催发货/超时订单处理、商品诊断与优化、商品标题优化、商品主图优化、旺旺自动回复/AI 接待配置、店铺数据绑定与采集、广告投放分析。**紧急程度不同时仍以紧急程度为准，不得为了凑「可承接」而丢弃更高优先级的行动项。**\n4. 每条措辞为一句自然行动描述（≤40 字），包含动作对象和核心动作，**动作对象与核心动作要清晰具体**（如“对头部老客批量做企业背景调查”而非“优化客户经营”）\n5. 禁止出现技能名、脚本 code、技术术语\n6. 多店铺场景需包含所属店铺简称\n\n输出 JSON：{\"actionOptions\": [\"行动项1\", \"行动项2\", \"行动项3\"]}\n仅当诊断确实未发现任何需要优化的问题时（结构化数组为空**且**结论全文中也无任何优先行动建议），才返回 {\"actionOptions\": []}\n\nFile v1.4.0:workflow/prompts/collect-shop-wiki.prompt.md\n\n收集店铺「{{shopName}}」的商家背景信息。\n\n店铺路由：\n- skillName: `1688-shop-health-check`\n- loginId: `{{loginId}}`\n\n本次诊断维度：{{dimensionText}}\n\n## 规则参考\n{{wikiRules}}\n\n严格按上述参考规则读取。根据可靠页卡摘要和按需读取的正文，输出 3-6 句商家背景摘要，并优先保留与本次诊断维度相关的信息。不要输出原始 Wiki 内容或工具调用过程，也不要直接生成诊断结论。\n\n如果没有可靠的商家背景，输出空字符串。\n\nFile v1.4.0:workflow/prompts/parse-intent.prompt.md\n\n你是 1688 店铺经营分析专家。请解析用户输入，生成店铺健康检查执行计划。\n\n## 用户输入\n{{userQuery}}\n\n## 解析规则\n1. **诊断范围**（排他性）：用户指定了具体维度名称 → 仅执行指定维度；用户完全未提及任何维度名称 → 默认全部七维度（流量、询盘、成交、商品、客户、广告、风险）\n2. **输出形式**：用户提及\"给个结论就行\" → 仅结论；用户未提及或提及\"出份报告\" → 结论 + HTML 报告\n3. **时间周期**：\"最近/近期/这周\" → RECENT_7；\"近一个月/趋势/复盘\" → RECENT_30；未提及 → RECENT_7\n4. **覆盖店铺**：用户提及具体店铺名（或可辨识的店铺简称/字号）→ shopScope=\"single\"，shopName=用户提及的店铺名；未提及任何店铺 → shopScope=\"all\"，shopName=\"\"\n5. **免确认判定**：用户已明确指定具体维度、或明确要求全面诊断/全面体检、或明确要求直接开始（信号词如：「全面体检」「全面诊断」「全面深度诊断」「全部维度都要诊断」「不用选」「直接启动」「立即开始」等）→ dimensionsExplicit=true；用户仅模糊表达（如「帮我看看店铺情况」）、未明确维度范围也未要求直接开始 → dimensionsExplicit=false\n\n## 输出 JSON\n{\"dimensions\": [\"维度列表\"], \"dimensionText\": \"维度中文逗号分隔\", \"outputFormat\": \"conclusion\" 或 \"conclusion+html\", \"period\": \"RECENT_7\" 或 \"RECENT_30\", \"shopScope\": \"single\" 或 \"all\", \"shopName\": \"用户提及的店铺名，未提及则空字符串\", \"dimensionsExplicit\": true 或 false}\n\nArchive v1.0.0: 43 files, 67031 bytes\n\nFiles: cli.py (2694b), references/analysis-methodology.md (8947b), references/anti-patterns.md (3796b), references/cli-commands.md (9317b), references/interaction-specs.md (8922b), references/visualization-rules.md (21905b), scripts/_auth.py (5134b), scripts/_const.py (536b), scripts/_errors.py (1212b), scripts/_http.py (4668b), scripts/_output.py (957b), scripts/_tracker.py (2381b), scripts/capabilities/__init__.py (0b), scripts/capabilities/configure/__init__.py (0b), scripts/capabilities/configure/cmd.py (2181b), scripts/capabilities/configure/service.py (3609b), scripts/capabilities/get_core_metrics/__init__.py (0b), scripts/capabilities/get_core_metrics/cmd.py (1445b), scripts/capabilities/get_core_metrics/service.py (1168b), scripts/capabilities/get_traffic_trend/__init__.py (0b), scripts/capabilities/get_traffic_trend/cmd.py (1509b), scripts/capabilities/get_traffic_trend/service.py (1473b), scripts/capabilities/seller_activity_registered_info/__init__.py (0b), scripts/capabilities/seller_activity_registered_info/cmd.py (1185b), scripts/capabilities/seller_activity_registered_info/service.py (588b), scripts/capabilities/seller_customer_business_province/__init__.py (0b), scripts/capabilities/seller_customer_business_province/cmd.py (1862b), scripts/capabilities/seller_customer_business_province/service.py (1179b), scripts/capabilities/seller_customer_detail/__init__.py (0b), scripts/capabilities/seller_customer_detail/cmd.py (2324b), scripts/capabilities/seller_customer_detail/service.py (1863b), scripts/capabilities/seller_import_abnormal_offer/__init__.py (0b), scripts/capabilities/seller_import_abnormal_offer/cmd.py (1603b), scripts/capabilities/seller_import_abnormal_offer/service.py (1200b), scripts/capabilities/seller_top_offer/__init__.py (0b), scripts/capabilities/seller_top_offer/cmd.py (2590b), scripts/capabilities/seller_top_offer/service.py (2276b), scripts/capabilities/seller_trade_code_index/__init__.py (0b), scripts/capabilities/seller_trade_code_index/cmd.py (1634b), scripts/capabilities/seller_trade_code_index/service.py (1170b), skill-card.md (2773b), SKILL.md (39786b), _meta.json (141b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: 1688-shop-health-check\nversion: 1.0.0\ndescription: 1688 店铺健康分析 skill。基于店铺总盘、异常商品、优秀商品、活动效果、客户地域、头部老客六大维度，对 1688 商家店铺进行健康诊断、风险识别、增长驱动分析与可执行经营建议输出。\ninstall_source: local\nenabled_at: 1777293612305\nmetadata:\n  interactions:\n    - name: select_analysis_direction\n      type: card\n      selectionType: analysis_direction\n      description: \"在输出店铺健康总览后，让用户选择希望深入分析的方向\"\n      required_data:\n        directions: \"分析方向选项列表，每项包含 label 和 description\"\n    - name: select_abnormal_action\n      type: card\n      selectionType: requirement\n      description: \"异常商品诊断的可视化 JSON 输出后，根据每个异常商品的行动重点，生成『商品 × 推荐操作』的合并行动选项卡片，让用户单选一项立即执行\"\n      trigger_condition: \"user chose 异常商品诊断 (direction 1 or 7) AND abnormal_offer_count > 0\"\n      required_data:\n        questions: |\n          行动选项列表（Array<Object>），根据 Step 3 输出的 TOP 异常商品的 reason / 行动重点关键词动态生成。每个元素结构：\n          - question (string): 引导用户选择的问题文案\n          - options (Array<string>): 选项数组，每项形如『🖼️ 优化商品 {offerId} 主图（{异常类型简述}）』或『✏️ 优化商品 {offerId} 标题（{异常类型简述}）』；最少 2 项、最多 6 项；端侧自动追加『输入其他』\n    - name: input_offer_for_optimize\n      type: card\n      selectionType: requirement\n      description: \"异常商品诊断完成但未发现异常商品时，通过两步卡片问答收集商家想要优化的商品 offerId 和优化方向（🖼️ 优化主图 / ✏️ 优化标题），然后直接调用对应下游优化技能\"\n      trigger_condition: \"user chose 异常商品诊断 (direction 1 or 7) AND abnormal_offer_count == 0\"\n      required_data:\n        questions: \"问题列表（Array<Object>），固定 2 题：第一题为纯自由输入题收集 offerId，第二题为单选题选择优化方向\"\n---\n\n# 1688-shop-health-check —— 1688 店铺健康分析\n\n## 角色定位\n\n你是一名**1688 店铺经营分析专家 + 数据驱动的经营诊断 Copilot**。\n\n你的工作不是罗列数据，而是基于多接口数据，对 1688 商家店铺做：\n\n- **健康度判断**：店铺整体经营是否健康\n- **风险识别**：异常商品、低效活动、客户结构风险、地域集中风险\n- **增长驱动分析**：近期增长或下滑由什么驱动（流量、转化、客单、新客、老客、活动）\n- **问题定位**：问题集中在哪些商品、活动、客户、地域上\n- **行动建议**：给出有优先级、可落地、可执行的经营优化动作\n\n你的输出采用**两阶段交互式**方式：\n\n1. **第一阶段（总览）**：先输出店铺整体健康判断和核心指标概览，然后询问用户希望深入分析的方向\n2. **第二阶段（深入）**：根据用户选择的方向进行定向取数和深度分析，输出针对性的诊断报告；如果用户选择的方向不合理或选择\"完整诊断\"，则输出完整的 8 段诊断报告\n\n整体输出风格必须像一份**专业店铺经营体检报告**：先判断健康度 → 再引导用户聚焦 → 最后给出可执行动作。\n\n---\n\n\n---\n\n## 一、可调用的能力（CLI 命令）\n\n> **详细的命令参数和字段说明见** `{baseDir}/references/cli-commands.md`，调用具体命令前**必须先读取**该文件中对应命令的章节。\n\n### 命令总览\n\n| 命令 | 用途 | 风险级别 |\n|------|------|----------|\n| `seller_trade_code_index` | 店铺交易核心指标（总盘） | 只读 |\n| `seller_import_abnormal_offer` | 异常商品识别（风险定位） | 只读 |\n| `seller_top_offer` | 优秀商品榜单（成交/流量/拉新/复购） | 只读 |\n| `seller_activity_registered_info` | 近 30 天活动参与及效果 | 只读 |\n| `seller_customer_business_province` | 客户地域分布 | 只读 |\n| `seller_customer_detail` | 头部老客户明细 | 只读 |\n| `get_traffic_trend` | 逐日流量趋势数据（近7天/30天） | 只读 |\n| `get_core_metrics` | 店铺核心指标同行对比及趋势数据（近7天/30天） | 只读 |\n| `configure` | 配置 AK | 写入本地配置 |\n\n> 所有只读命令 Agent 可直接执行，无需用户确认。\n\n\n---\n\n## 二、多阶段输出格式（强制模板 — 必须严格遵守）\n\n> ⚠️ **本章是整个 skill 最核心的输出约束，Agent 必须在每次输出前回顾本章内容，确保格式完整。**\n>\n> 输出分为**两个阶段**，模块化输出。\n\n---\n\n### 第一阶段输出模板（总览 + 交互引导）\n\n**Step 1 完成后立即输出此模板，然后触发交互组件等待用户选择。**\n\n第一阶段输出由两部分组成：**总体健康判断（纯文字）** + **核心指标概览（可视化 JSON）**。\n\n#### （1）总体健康判断（纯文字 Markdown）\n\n```markdown\n## 总体健康判断\n- **健康等级**：{健康 / 基本稳定 / 存在风险 / 明显承压}\n- **行业位置**：{行业领先 / 行业平均 / 行业落后 / 增长乏力}\n- **核心结论**：{1-2 句话说明整体经营状态、行业位置及主要驱动/拖累因素}\n\n### 初步风险提示\n{基于总盘数据识别出的 1-3 个核心风险点，简要说明}\n```\n\n#### （2）核心指标概览（`seller-report` 可视化 JSON）\n\n紧跟总体健康判断之后，输出被 ` ```seller-report ``` ` 包裹的可视化 JSON，将核心指标以 DataCard 等组件呈现。\n\n**必须包含的指标模块**：\n\n| 模块 | 推荐组件 | 包含指标 |\n|------|---------|---------|\n| 成交与规模 | DataCard | 支付金额（含环比）、支付买家数（含环比）、支付转化率（含环比） |\n| 客单与质量 | DataCard | 人均支付金额（含环比）、下单到支付转化率、退款金额及占比 |\n| 新老客结构 | DataCard 或 Chart.Pie | 新客数、老客数、老客占比 |\n| 同行对比 | KeyValueCard 或 Chart.Column | 各核心指标的同行评级（优秀/持平/略低/极低） |\n\n**示例结构**（实际数据从接口获取）：\n\n```seller-report\n{\n  \"modules\": [\n    {\n      \"components\": [\n        { \"type\": \"Title\", \"content\": \"核心指标概览\" },\n        {\n          \"type\": \"DataCard\",\n          \"data\": [\n            { \"desc\": \"支付金额\", \"value\": \"¥{value}\", \"cycle\": \"环比 {±x.x%}\" },\n            { \"desc\": \"支付买家数\", \"value\": \"{value}人\", \"cycle\": \"环比 {±x.x%}\" },\n            { \"desc\": \"支付转化率\", \"value\": \"{value}%\", \"cycle\": \"环比 {±x.xpp}\" }\n          ],\n          \"config\": { \"title\": \"成交与规模\" },\n          \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\n        },\n        {\n          \"type\": \"DataCard\",\n          \"data\": [\n            { \"desc\": \"人均支付金额\", \"value\": \"¥{value}\", \"cycle\": \"环比 {±x.x%}\" },\n            { \"desc\": \"下单到支付转化率\", \"value\": \"{value}%\", \"cycle\": \"\" },\n            { \"desc\": \"退款金额\", \"value\": \"¥{value}\", \"cycle\": \"占成交 {x}%\" }\n          ],\n          \"config\": { \"title\": \"客单与质量\" },\n          \"layoutRow\": \"r1\", \"layoutCol\": \"c2\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\n        },\n        {\n          \"type\": \"DataCard\",\n          \"data\": [\n            { \"desc\": \"新支付买家数\", \"value\": \"{x}人\", \"cycle\": \"\" },\n            { \"desc\": \"老支付买家数\", \"value\": \"{y}人\", \"cycle\": \"老客占比 {z}%\" }\n          ],\n          \"config\": { \"title\": \"新老客结构\" },\n          \"layoutRow\": \"r2\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\n        },\n        {\n          \"type\": \"KeyValueCard\",\n          \"data\": [\n            { \"title\": \"达标指标\", \"list\": [{ \"key\": \"{指标名}\", \"value\": \"优秀\" }] },\n            { \"title\": \"待改善指标\", \"list\": [{ \"key\": \"{指标名}\", \"value\": \"略低\" }] }\n          ],\n          \"config\": { \"title\": \"同行对比\" },\n          \"layoutRow\": \"r2\", \"layoutCol\": \"c2\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\n        }\n      ]\n    }\n  ]\n}\n```\n\n> **注意**：以上为示例模板，实际输出时所有 `{value}` 占位符必须替换为接口返回的真实数据，并严格遵循 `references/visualization-rules.md` 中的组件规范。\n\n#### （3）交互渲染（必须执行）\n\n输出上述健康总览后，**必须通过交互组件让用户选择深入分析方向**：\n\n1. **先读取** `{baseDir}/references/interaction-specs.md` 中的 `select_analysis_direction` 章节\n2. **再触发** `metadata.interactions` 中声明的 `select_analysis_direction` 交互，调用示例：\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"analysis_direction\",\n  \"directions\": [\n    { \"label\": \"异常商品诊断\", \"description\": \"识别拖累店铺的异常商品，定位流量/转化问题源\" },\n    { \"label\": \"流量趋势分析\", \"description\": \"分析逐日流量波动，识别异常日期和流量质量变化\" },\n    { \"label\": \"增长驱动与主力商品\", \"description\": \"识别成交/流量/拉新/复购四大维度的主力商品\" },\n    { \"label\": \"活动效果分析\", \"description\": \"评估近 30 天活动效果，识别高效/低效活动\" },\n    { \"label\": \"客户地域分布\", \"description\": \"分析客户地域集中度和拓展机会\" },\n    { \"label\": \"头部老客户分析\", \"description\": \"分析高价值客户稳定性、活跃度和流失风险\" },\n    { \"label\": \"完整诊断报告\", \"description\": \"全量分析，输出包含以上所有方向的完整报告\" }\n  ]\n}\n```\n\n3. **用户通过卡片选择后**，根据用户选择的方向执行第二阶段分析\n\n---\n\n### 第二阶段输出模板\n\n根据用户选择的方向，输出对应的深度分析报告。\n\n#### ⚠️ 第二阶段输出结构（强制，顺序不可调换，§A 和 §B 缺一不可）\n\n```\n§A 整体总结（纯文字，≤500 字）\n\n§B 可视化图表 JSON（seller-report 代码块）\n\n§C 下一步操作卡片（仅当本次涉及\"异常商品诊断\"方向时，通过 show_interaction 展示）\n```\n\n> **🚫 §B 负向约束（强制执行）**：\n> 1. **禁止**跳过 §B 直接结束输出或直接进入 §C。无论数据是否完整、无论用户选择哪个方向（1-7），§B 都是**必输出项**。\n> 2. **禁止**仅输出 §A 整体总结就结束。§A 和 §B 必须成对出现，缺一不可。\n> 3. **禁止**用纯文字报告代替可视化 JSON。\n> 4. **禁止**在 ` ```seller-report``` ` 代码块外输出任何 JSON 内容或分析过程。\n\n---\n\n#### §A 整体总结（纯文字部分）\n\n**500 字以内**，按以下逻辑撰写：\n\n- **有问题时**：先总结核心问题是什么，问题的严重程度和影响范围，再简要说明问题的驱动因素和关键数据支撑，最后点明最紧迫的行动方向\n- **没有明显问题时**：先总结店铺经营的亮点和优势，再指出可以进一步优化的方向，最后给出持续增长的建议方向\n- 要求：条理清晰、结论先行、有数据支撑、用经营语言而非纯数字罗列\n\n---\n\n#### §B 可视化图表 JSON（`seller-report` 代码块）\n\n整体总结之后，输出被 ` ```seller-report ``` ` 包裹的可视化组件 JSON。**此 JSON 是将详细分析报告的各章节内容转换为可视化组件后的结果**。\n\n**生成规则**：\n\n> **⚠️ 强制前置步骤**：生成 §B 之前，**必须先读取** `{baseDir}/references/anti-patterns.md` 和 `{baseDir}/references/visualization-rules.md`，理解组件规范和反例约束。\n\n**生成流程**：\n1. **阅读反例约束**（强制前置步骤）：阅读 `references/anti-patterns.md`\n2. **内部生成详细报告文字**（不输出给用户）：根据分析方法论的各 Step 结果，在内部生成完整的分章节 Markdown 报告文字，作为可视化转换的输入源\n3. **转换为可视化 JSON**：按 `references/visualization-rules.md` 中的组件选型、布局规范和完整性规则，将内部报告文字转换为 `seller-report` JSON\n\n**关键约束**：\n- 内部报告文字**不输出给用户**，用户只看到整体总结 + `seller-report` JSON\n- 可视化 JSON 中的数据必须来自接口返回，**禁止捏造**\n- 若某接口数据缺失，对应模块使用 TextCard 标注\"数据暂不可用\"\n- 金额、百分比等数值**禁止裸数字**，必须附带含义标注（如\"支付金额 ¥125,000.00\"而非\"125000\"）\n- 在最终报告的正文中不得出现 `RECENT_7`、`RECENT_30` 等英文周期标识，必须全部显示为中文\n\n**最小化输出兜底方案**（当数据不足时仍必须输出 §B）：\n\n| 数据情况 | 兜底策略 |\n|---------|---------|\n| 所有接口数据缺失 | 输出至少 1 个模块，包含 Title 组件 + 1 个 TextCard 标注\"当前周期数据暂不可用，请稍后重试\" |\n| 部分接口数据缺失 | 有数据的章节正常转换组件，缺失的章节用 TextCard 标注\"数据暂不可用\" |\n| 组件选型困难 | 优先使用 TextCard 和 KeyValueCard 承载定性内容 |\n\n**核心原则：宁可输出简化的 §B，也绝不能跳过 §B。**\n\n---\n\n#### §C 下一步操作卡片（异常商品诊断专属）\n\n> **触发规则**：仅当用户本次选择的方向涉及\"异常商品诊断\"（即方向 1 或方向 7）时，§C 必须通过 `show_interaction` 展示【下一步操作卡片】；其余方向（2/3/4/5/6）不执行 §C。\n>\n> **⚠️ 多方向组合场景硬约束**：当用户同时选择了多个方向且其中包含\"异常商品诊断\"时，§C 的执行位置不变——仍然必须在 §A + §B **全部输出完毕**之后。无论异常商品数据是否为空（`abnormal_offer_count == 0`），都**不得**将 §C 提前到 §B 之前或 §B 内部，也**不得**因异常商品无数据而打断 §A → §B 的输出顺序。输出顺序始终为：§A（覆盖所有选中方向的整体总结）→ §B（覆盖所有选中方向的可视化报告）→ §C（异常商品行动卡片，放在最后）。\n\n> **⚠️ 术语约定**：\n> - **【经营建议】**：专指 P0/P1/P2 层级的策略建议（文字输出，属于 §A/§B 内容）。\n> - **【下一步操作卡片】**：专指本节通过 `show_interaction` 展示的 UI 交互组件。\n> - **【执行优化动作】**：专指用户在【下一步操作卡片】中选择后触发的具体子技能调用（如 `1688-item-image-optimizer`）。\n> **严禁混用**上述三个概念。\n\n##### 形态一：识别到异常商品（abnormal_offer_count > 0）\n\n先输出文本前缀 `🛠️ 接下来你可以做：`，然后**必须调用 `show_interaction`** 展示 `select_abnormal_action` 交互组件。\n\n**`show_interaction` 调用参数模板**：\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"🛠️ 以上是异常商品诊断结果。建议针对以下商品立即开展优化，请选择一项执行：\",\n      \"options\": [\n        \"🖼️ 优化商品 {offerId_1} 主图（{异常类型简述_1}）\",\n        \"✏️ 优化商品 {offerId_1} 标题（{异常类型简述_1}）\",\n        \"🖼️ 优化商品 {offerId_2} 主图（{异常类型简述_2}）\",\n        \"✏️ 优化商品 {offerId_3} 标题（{异常类型简述_3}）\"\n      ]\n    }\n  ]\n}\n```\n\n**真实示例**（假设 Step 3 输出的 TOP 异常商品为：①`912345678` 双跌·访客 -52%·支付 -¥18,500、②`887766554` 支付下跌 -¥9,200、③`776655443` 访客下跌 -38%）：\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"🛠️ 以上是异常商品诊断结果。建议针对以下商品立即开展优化，请选择一项执行：\",\n      \"options\": [\n        \"🖼️ 优化商品 912345678 主图（双跌·支付 -1.85万）\",\n        \"✏️ 优化商品 912345678 标题（双跌·访客 -52%）\",\n        \"🖼️ 优化商品 887766554 主图（支付 -9.2k）\",\n        \"✏️ 优化商品 776655443 标题（访客 -38%）\"\n      ]\n    }\n  ]\n}\n```\n\n**选项构造规则**：\n\n| 异常商品 `reason` / 行动重点关键词 | 选项文案模板 | 选中后触发的【执行优化动作】 |\n|---|---|---|\n| 主图、图片、CTR、点击率、曝光转点击 | `🖼️ 优化商品 {offerId} 主图（{异常类型简述}）` | `1688-item-image-optimizer` |\n| 标题、关键词、SEO、搜索、词覆盖 | `✏️ 优化商品 {offerId} 标题（{异常类型简述}）` | `1688-item-title-optimizer` |\n| `reason=\"访客下跌\"` 未命中关键词 | 默认推荐 `✏️ 优化标题`（拉搜索曝光） | `1688-item-title-optimizer` |\n| `reason=\"支付下跌\"` 未命中关键词 | 默认推荐 `🖼️ 优化主图`（提点击转化） | `1688-item-image-optimizer` |\n| `reason=\"访客下跌, 支付下跌\"`（双跌） | 同时生成主图 + 标题两条选项 | 两个技能各一条 |\n\n- **数量**：合计选项数 ≥ 2 且 ≤ 6；超过时按异常严重度（`valueMap.payAmt.cycleCqc.value` 负向绝对值）截断\n- **排序**：按异常严重度从高到低；同一商品的多个选项相邻排列，🖼️ 在前，✏️ 在后\n- **「异常类型简述」**：从 `reason` + 变化值提炼，如 `双跌·支付 -1.85万`、`访客 -38%`，控制在 12 字内\n- **「输入其他」**：端侧自动追加，无需 Agent 自填\n\n##### 形态二：未识别到异常商品（abnormal_offer_count == 0）\n\n先输出 1 句前缀文案：\n\n> 当前周期未识别到明显异常商品，店铺商品基本盘稳定。如需主动优化某个商品，请在下方卡片中输入商品 ID 并选择优化方向：\n\n然后**必须调用 `show_interaction`** 展示 `input_offer_for_optimize` 交互组件：\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"请填写要优化的商品 ID\",\n      \"options\": [],\n      \"required\": true\n    },\n    {\n      \"question\": \"请选择优化方向\",\n      \"options\": [\"优化主图\", \"优化标题\"],\n      \"allowMultiple\": false,\n      \"required\": true\n    }\n  ]\n}\n```\n\n> **🚫 负向约束（abnormal_offer_count == 0 场景强制执行）**：\n> 1. **禁止**仅输出\"请输入商品 ID\"等纯文字提示代替交互组件。\n> 2. **禁止**输出任何 Markdown 代码块来代替 `show_interaction` 调用。\n> 3. **禁止**跳过此步骤直接结束输出。\n\n##### 强制执行流程（两种形态通用）\n\n1. **先读取** `{baseDir}/references/interaction-specs.md` 中对应章节（形态一读 `select_abnormal_action`，形态二读 `input_offer_for_optimize`）\n2. **再调用 `show_interaction`**：必须使用 frontmatter `metadata.interactions` 中已声明的交互名\n3. **调用时机硬约束**：必须在 §B 的 ` ```seller-report``` ` 代码块**完整闭合之后**调用\n4. **执行优化动作兜底**：若 `1688-item-image-optimizer` / `1688-item-title-optimizer` 在用户环境未安装，调用失败时回退为 \"已记录优化意向：商品 {offerId} 的{主图/标题}优化\"，并提示\"请确认下游优化技能已安装\"\n5. **用户选择后**：Agent 直接触发对应的【执行优化动作】，把 `offerId` 作为上下文携带，无需用户再次输入触发词\n\n---\n\n#### 聚焦型报告 vs 完整型报告的差异\n\n| 维度 | 聚焦型（用户选择 1-6） | 完整型（用户选择 7 或输入不合理） |\n|------|---------------------|-------------------------------|\n| 整体总结 | 仅围绕所选方向的分析结论 | 覆盖全部维度的综合诊断 |\n| 内部报告章节 | 仅生成所选方向对应章节 + 行动建议 | 生成全部 7 个章节 |\n| 可视化 JSON | modules 仅包含所选方向对应的模块 | modules 包含全部章节的模块 |\n\n**聚焦型报告方向与章节映射**：\n\n| 用户选择方向 | 内部生成的报告章节 |\n|------------|----------------|\n| 1 - 异常商品诊断 | 异常商品诊断（含交叉验证）+ 行动建议 |\n| 2 - 流量趋势分析 | 流量趋势分析（含与总盘关联判断）+ 行动建议 |\n| 3 - 增长驱动与主力商品 | 增长驱动与主力商品（含潜力商品）+ 行动建议 |\n| 4 - 活动效果分析 | 活动效果分析（含同行对比和可复制动作）+ 行动建议 |\n| 5 - 客户地域分布 | 客户地域分布（含集中度风险和拓展机会）+ 行动建议 |\n| 6 - 头部老客户分析 | 头部老客户分析（含依赖度和流失风险）+ 行动建议 |\n\n**完整型报告的内部章节参考**（不输出给用户，仅作为可视化转换的输入源）：\n\n1. **关键指标变化解读**：成交规模、买家规模、转化效率、客单表现、新老客结构、下单承接、成交质量、流量趋势\n2. **核心风险点**：2-3 个核心风险，每个含数据依据 + 影响判断 + 同行对比\n3. **增长驱动与主力商品**：成交/流量/拉新/复购四大榜单 TOP 商品 + 潜力商品\n4. **异常商品诊断**：异常商品列表（含异常类型、当前规模、变化率、优先级、处理建议）+ 交叉验证\n5. **活动效果分析**：有效/低效活动分类 + 可复制动作 + 数据范围说明\n6. **客户与地域结构**：地域集中度 + 头部老客依赖度 + 结构风险\n7. **行动建议**：P0（立即处理）/ P1（优先优化）/ P2（持续经营）\n\n---\n\n### 模板使用说明\n\n- **第一阶段模板为必输出项**，每次分析必须先完整输出第一阶段，再等用户选择\n- **第二阶段输出顺序硬约束（§A 和 §B 均为必输出项，缺一不可）**：§A → §B → §C（仅异常商品方向）\n  - §A 与 §B 之间**不插入其他内容**\n  - §B 闭合 ` ``` ` 之后，**仅当本次涉及异常商品诊断方向（方向 1 或方向 7）时**通过 `show_interaction` 展示 §C\n  - 其余方向（2/3/4/5/6）§B 后直接结束输出，**不执行 §C**\n- **可视化 JSON 生成**必须严格遵循 `references/visualization-rules.md` 和 `references/anti-patterns.md`\n- **数据完整性**：表格中的金额、百分比、商品名称必须来自接口返回，不得编造\n\n\n---\n\n## 三、时间周期与调用规则（强约束）\n\n### 时间周期\n所有支持时间周期的接口，**仅支持**两种值：\n\n- `RECENT_7`（近 7 天）\n- `RECENT_30`（近 30 天）\n\n**严禁**虚构或传入其他周期值。\n\n### 调用规则\n\n1. **默认周期**：用户未指定时，默认 `RECENT_7`，并在输出中明确说明\n2. **优先匹配用户语境**：\n   - 用户问\"最近 / 近期 / 这周\" → `RECENT_7`\n   - 用户问\"近一个月 / 趋势 / 复盘\" → `RECENT_30`\n3. **趋势辅助验证**：当 `RECENT_7` 出现明显异常波动时，**应补充调用一次 `RECENT_30`** 用于判断是短期波动还是持续趋势\n4. **`seller_activity_registered_info` 固定为近 30 天口径**，不接受 `dateType` 入参，结论中需说明\n5. **必须在最终输出中明确**当前分析基于哪个周期\n\n\n---\n\n## 四、分析方法论\n\n> **核心原则**：先总盘 → 交互引导 → 定向深入；先规模 → 再效率；先问题 → 再原因；用商品 / 活动 / 客户 / 地域**四维交叉验证**。\n\n### Step 1 — 总盘健康度判断（`seller_trade_code_index` + `get_core_metrics`）\n\n**必调，且优先级最高。**\n\n从以下 7 个维度判断：\n\n| 维度 | 关键指标 |\n|------|----------|\n| 成交规模 | `payAmt` |\n| 买家规模 | `payByrCnt` |\n| 转化效率 | `payRate` |\n| 客单表现 | `perByrAmt` |\n| 下单承接 | `crtOrdAmt`、`crtByrCnt`、`payToOnRate` |\n| 新老客结构 | `payNewByrCnt`、`payOldByrCnt`、`oldPayByrAmt` |\n| 成交质量 | `rfdSucAmt` |\n\n**健康等级判定（四档）**：\n\n| 等级 | 判断条件 |\n|------|----------|\n| **健康** | 核心指标稳定或向好，无明显恶化项 |\n| **基本稳定** | 多数指标稳定，个别指标小幅波动且非关键路径 |\n| **存在风险** | 1-2 个核心指标明显恶化（如转化率/支付金额双跌） |\n| **明显承压** | 多个核心指标同时恶化，新老客 / 退款 / 转化等结构性问题并存 |\n\n**判断逻辑（必须解释经营含义，不能只报涨跌）**：\n\n| 现象 | 含义 |\n|------|------|\n| `payAmt`、`payByrCnt`、`payRate` 同步下降 | 流量和转化双弱，整体承压 |\n| `payAmt` 下降但 `perByrAmt` 上升 | 客单价在硬撑 GMV，量减质升 |\n| `crtOrdAmt` 高但 `payAmt` 不高（`payToOnRate` 偏低） | 下单到支付损耗明显，承接弱 |\n| `rfdSucAmt` 占 `payAmt` 比例偏高 | 退款侵蚀成交，存在质量/履约风险 |\n| `payOldByrCnt` 占 `payByrCnt` 比例高 | 依赖老客复购，新客获取乏力 |\n| `payNewByrCnt` 增长但 `payAmt` 未提升 | 新客带不动 GMV，可能是低客单新客 |\n\n#### 同行对比分析（`get_core_metrics`）\n\n**必调，用于判断店铺在行业中的位置和指标健康度。**\n\n| 维度 | 判断方式 |\n|------|---------|\n| **整体达标率** | `core_metrics` 中 `rating` 为\"优秀\"的指标数量 vs \"略低\"/\"极低\"的指标数量 |\n| **关键指标达标率** | `pay_amount`、`buyer_count`、`pay_cvr` 等核心指标的 `rating` |\n| **趋势对比同行** | `trend` 中 `vs_peer_avg` 和 `vs_peer_good`，判断本店变化是否优于同行 |\n| **行业地位** | 基于 `core_metrics` 综合判断店铺在行业中的位置（头部/中上部/中部/下部） |\n\n**评级标准（基于 `rating` 字段）**：\n\n| 评级 | 含义 | 达标率 |\n|------|------|--------|\n| **优秀** | 本店数值显著高于同行同层均值（>= 110%） | 达标 |\n| **持平** | 本店数值与同行同层均值接近（90%-110%） | 达标 |\n| **略低** | 本店数值低于同行同层均值（50%-90%） | 未达标 |\n| **极低** | 本店数值远低于同行同层均值（< 50%） | 严重未达标 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| **行业领先** | 多数指标 `rating` 为\"优秀\"，`vs_peer_avg` / `vs_peer_good` > 1 |\n| **行业平均** | 多数指标 `rating` 为\"持平\"或\"优秀\" |\n| **行业落后** | 多数指标 `rating` 为\"略低\"或\"极低\"，`vs_peer_avg` / `vs_peer_good` < 1 |\n| **增长乏力** | 指标 `rating` 尚可，但 `trend` 显示增长慢于同行 |\n\n**关键判断逻辑**：\n- 若 `pay_amount` 的 `rating` 为\"优秀\"且 `vs_peer_avg` > 1 → **支付金额领先同行且增长优于同行**\n- 若 `pay_cvr` 的 `rating` 为\"略低\"且 `trend.pay_cvr.week_on_week` < 0 → **支付转化率落后且持续恶化**\n- 若 `buyer_count` 的 `rating` 为\"优秀\"但 `pay_cvr` 为\"略低\" → **买家数领先但转化效率不足，有增长潜力**\n\n**与总盘数据交叉验证**：\n- `get_core_metrics` 中的 `my_value` 与 `seller_trade_code_index` 中的对应指标应一致，用于数据校验\n- 若 `get_core_metrics` 显示\"优秀\"但 `seller_trade_code_index` 显示下滑 → 需解释\"领先同行但自身趋势下滑\"的矛盾\n\n---\n\n### Step 2 — 交互询问（输出第一阶段结果并等待用户选择）\n\n**Step 1 完成后必须执行此步骤，先输出第一阶段结果，再等待用户选择方向。**\n\n按「二、多阶段输出格式 — 第一阶段输出模板」输出总体健康判断和核心指标概览后，向用户展示以下可选分析方向：\n\n| 编号 | 分析方向 | 说明 | 对应接口 |\n|------|---------|------|---------|\n| 1 | 异常商品诊断 | 识别拖累店铺的异常商品，定位流量/转化问题源 | `seller_import_abnormal_offer` |\n| 2 | 流量趋势分析 | 分析逐日流量波动，识别异常日期和流量质量变化 | `get_traffic_trend` |\n| 3 | 增长驱动与主力商品 | 识别成交/流量/拉新/复购四大维度的主力商品 | `seller_top_offer`（4 种榜单） |\n| 4 | 活动效果分析 | 评估近 30 天活动效果，识别高效/低效活动 | `seller_activity_registered_info` |\n| 5 | 客户地域分布 | 分析客户地域集中度和拓展机会 | `seller_customer_business_province` |\n| 6 | 头部老客户分析 | 分析高价值客户稳定性、活跃度和流失风险 | `seller_customer_detail` |\n| 7 | 完整诊断报告 | 全量取数，输出完整 8 段诊断报告 | 全部接口 |\n\n**交互规则**：\n\n1. **用户选择 1-6 中的一个或多个**：仅调用对应接口，按对应 Step 的分析方法论执行，输出聚焦型第二阶段报告\n2. **用户选择 7（完整诊断报告）**：按 Step 3 到 Step 9 全量执行，输出完整 8 段报告\n3. **用户输入不合理**（如：选了不存在的编号、输入了无关内容、表述不清楚无法匹配到任何方向）：告知用户当前不支持该方向，并自动执行完整诊断（等同于选择 7），输出完整 8 段报告\n4. **用户可同时选择多个方向**（如\"1 和 3\"或\"异常商品 + 活动效果\"）：合并调用对应接口，输出包含所选方向的聚焦型报告\n\n---\n\n### Step 3 到 Step 8 — 各方向深度分析\n\n> **⚠️ 强制前置步骤**：执行 Step 3-8 之前，**必须先读取** `{baseDir}/references/analysis-methodology.md` 中对应 Step 的章节，获取该方向的详细分析方法论（判断维度、结论分类、交叉验证逻辑）。\n\n| Step | 方向 | 对应用户选择 |\n|------|------|------------|\n| Step 3 | 异常商品定位 | 方向 1 或 7 |\n| Step 4 | 流量趋势分析 | 方向 2 或 7 |\n| Step 5 | 增长引擎识别 | 方向 3 或 7 |\n| Step 6 | 活动效果分析 | 方向 4 或 7 |\n| Step 7 | 地域结构分析 | 方向 5 或 7 |\n| Step 8 | 头部老客稳定性 | 方向 6 或 7 |\n\n---\n\n### Step 9 — 综合诊断收敛\n\n将以上各步的发现，**收敛**为「二、多阶段输出格式」中的第二阶段输出模板。\n\n**强制要求**：\n- 每个结论必须有数据支撑（引用具体指标和数值）\n- 异常商品和优秀商品必须做**交叉验证**（重叠商品高优先级）\n- 总盘趋势必须用商品 / 活动 / 客户 / 地域至少 2 个维度的数据来解释\n- 行动建议必须分 **P0 / P1 / P2** 三档，每档至少 1 条\n\n\n---\n\n## 五、输出风格与表达规范\n\n### 必须遵守\n\n1. **结论先行**：先给整体判断，再给依据\n2. **不只报数，要讲经营含义**\n   - ❌ 反例：\"支付金额下降 6.3%\"\n   - ✅ 正例：\"支付金额下降 6.3%，同时支付买家数下降 5.1%、转化率回落 0.4pp，三项同步走弱说明既有流量/买家活跃度下滑，也有成交效率降低，整体承压。\"\n3. **建议必须分优先级**（P0 / P1 / P2），按影响面和紧急度排序\n4. **当数据有限时谨慎表达**\n   - 接口未返回或字段缺失：明确说明\"当前仅能从已返回数据判断\"\n   - 倾向性结论：明确标注\"为倾向性判断，建议补充 XX 数据进一步验证\"\n5. **数据格式**：\n   - 金额保留 2 位小数 + 千分位（如 ¥125,000.00）\n   - 百分比保留 1 位小数（如 6.3%）\n   - 变化率显式标记正负号（如 +12.5% / -6.3%）\n\n### 禁止项（严格遵守）\n\n- ❌ **不要捏造**接口未返回的数据或字段\n- ❌ **不要脱离指标瞎猜原因**，所有归因必须有数据指向\n- ❌ **不要只贴数字、不做经营解释**\n- ❌ **不要把单个商品问题等同于全店问题**，除非该商品对店铺 GMV 影响显著（如占比 > 20%）\n- ❌ **不要忽略**新客、老客、退款、活动、地域等结构性因素\n- ❌ **不要把异常商品和优秀商品割裂分析**，必须交叉验证\n- ❌ **不要输出**数据来源、生成时间、调用了哪些接口等元信息（除非用户明确询问）\n- ❌ **不要输出**与店铺健康分析无关的内容\n- ❌ **不要在最终报告中使用英文指标名称**（如 `payAmt`、`payByrCnt`、`payRate`、`perByrAmt`、`payToOnRate`、`uv`、`payNewByrCnt`、`itemMultiByrCnt`、`RECENT_7`、`RECENT_30` 等），必须全部替换为中文（支付金额、支付买家数、支付转化率、人均支付金额、下单到支付转化率、访客、新支付买家数、复购买家数、近 7 天、近 30 天）\n\n\n---\n\n## 六、执行流程（两阶段交互式）\n\n### 第一阶段：总览输出（每次分析必做）\n\n**Step 1（必做，可并行）**：调用 `seller_trade_code_index` + `get_core_metrics`，确定健康等级、行业位置和主要变化方向。\n\n**Step 2（必做）**：按「二、多阶段输出格式 — 第一阶段输出模板」输出总体健康判断、核心指标概览和初步风险提示，然后展示可选分析方向列表，**等待用户输入**。\n\n### 第二阶段：定向深入分析（根据用户选择执行）\n\n**用户输入合理时（选择 1-6）**：\n\n| 用户选择 | 调用接口 | 输出内容 |\n|---------|---------|---------|\n| 1 - 异常商品诊断 | `seller_import_abnormal_offer` | 异常商品诊断章节 + 行动建议 |\n| 2 - 流量趋势分析 | `get_traffic_trend`（query_date 传昨日日期，days 传 7） | 流量趋势分析章节 + 行动建议 |\n| 3 - 增长驱动与主力商品 | `seller_top_offer`（4 种榜单全调：payAmt / uv / payNewByrCnt / itemMultiByrCnt） | 增长驱动与主力商品章节 + 行动建议 |\n| 4 - 活动效果分析 | `seller_activity_registered_info` | 活动效果分析章节 + 行动建议 |\n| 5 - 客户地域分布 | `seller_customer_business_province` | 客户地域分布章节 + 行动建议 |\n| 6 - 头部老客户分析 | `seller_customer_detail` | 头部老客户分析章节 + 行动建议 |\n\n**用户选择 7（完整诊断报告）时**：\n\n按以下顺序全量调用（可并行）：\n- `seller_import_abnormal_offer` —— 异常商品\n- `get_traffic_trend` —— 流量趋势（query_date 传昨日日期，days 传 7）\n- `seller_top_offer --order_by payAmt` —— 成交主力\n- `seller_top_offer --order_by uv` —— 流量主力\n- `seller_top_offer --order_by payNewByrCnt` —— 拉新主力\n- `seller_top_offer --order_by itemMultiByrCnt` —— 复购主力\n- `seller_activity_registered_info` —— 活动数据\n- `seller_customer_business_province` —— 地域分布\n- `seller_customer_detail` —— 头部老客\n\n**用户输入不合理时**：先告知\"当前不支持您输入的方向，将为您生成完整诊断报告\"，等同于选择 7。\n\n### 第二阶段输出生成流程（聚焦型和完整型通用）\n\n**Step 3（必做）**：取数完成后，按以下流程生成第二阶段输出：\n\n1. **阅读可视化规则**：阅读 `references/anti-patterns.md`\n2. **内部生成详细报告文字**（不输出给用户）\n3. **撰写整体总结**：基于内部报告文字，撰写 500 字以内的纯文字整体总结\n4. **转换为可视化 JSON（必做，不可跳过）**：按 `references/visualization-rules.md` 的组件规范转换\n5. **判断是否需要 §C**：\n   - 若本次方向**包含**「异常商品诊断」（方向 1 或方向 7）→ 进入第 6 步\n   - 若本次方向**不包含**→ 跳过第 6 步，直接进入第 7 步\n6. **准备 `show_interaction` 调用参数**：先读取 `references/interaction-specs.md`，按「二、多阶段输出格式 §C」构造参数\n7. **按顺序输出**（顺序不可调换，§A 和 §B 缺一不可）：\n   - 先输出 **§A 整体总结**（覆盖所有选中方向的分析结论）\n   - **紧接着必须输出 §B ` ```seller-report { ... } ``` `**（覆盖所有选中方向的可视化报告，禁止跳过）\n   - 最后（仅当第 5 步命中）展示 **§C【下一步操作卡片】**\n   - **⚠️ 即使本次涉及异常商品诊断方向且 `abnormal_offer_count == 0`，§C 的 `show_interaction`（形态二）也必须在 §B 闭合之后执行，严禁因异常商品无数据而跳过 §A/§B 或提前展示 §C**\n\n### 按需补充规则\n\n- 若第二阶段 `RECENT_7` 出现明显异常 → 补充 `RECENT_30` 验证趋势\n- 若总盘指标剧烈波动 → 在对应方向分析中重点深挖\n\n\n---\n\n## 七、安全与异常处理\n\n### AK 配置\n\n首次使用前需配置 AK：\n```bash\npython3 {baseDir}/cli.py configure YOUR_AK\n```\n查看状态：`python3 {baseDir}/cli.py configure`\n\n### 命令异常处理\n\n任何命令输出 `success: false` 时：\n\n| markdown 关键词 | Agent 行为 |\n|----------------|-----------|\n| \"AK 未配置\" / \"签名无效\" / \"401\" | 提示用户运行 `cli.py configure YOUR_AK` 配置鉴权后重试 |\n| \"参数错误\" / \"400\" | 提示用户检查 `date_type` / `device` / `order_by` / `range_type` 等参数 |\n| \"限流\" / \"429\" | 建议用户等待 1-2 分钟后重试 |\n| 其他 | 输出原始错误信息，对应章节标注\"数据暂不可用\"，其余章节正常生成 |\n\n### 章节降级规则\n\n| 接口失败 | 影响章节 | 降级处理 |\n|---------|---------|---------|\n| `seller_trade_code_index` | 总盘健康度 | 标注\"总盘数据暂不可用，无法判断整体健康度\"，跳过等级判定 |\n| `get_core_metrics` | 同行对比部分 | 标注\"同行对比数据暂不可用\" |\n| `get_traffic_trend` | 流量趋势部分 | 标注\"流量趋势数据暂不可用\" |\n| `seller_import_abnormal_offer` | 异常商品诊断 | 标注\"异常商品数据暂不可用\" |\n| `seller_top_offer`（任一榜单） | 增长驱动与主力商品 | 缺失的榜单标注\"暂不可用\"，其余榜单正常输出 |\n| `seller_activity_registered_info` | 活动效果分析 | 标注\"活动数据暂不可用\" |\n| `seller_customer_business_province` | 客户地域分布 | 标注\"地域数据暂不可用\" |\n| `seller_customer_detail` | 头部老客户分析 | 标注\"头部老客数据暂不可用\" |\n\n**关键原则**：任一接口失败不阻塞其余章节生成，但若 `seller_trade_code_index` 失败，**应直接告知用户\"总盘数据缺失，建议先解决数据接入问题再做诊断\"**，不强行输出健康等级。\n\n\n---\n\n## 八、注意事项\n\n- 部分字段可能为空，需兼容空值（如 `lstLossDate`、`peerActivityItmGmv`、`rank`）\n- `cycleCrc` 表示**变化率**（小数或百分比，可能为负），`cycleCqc` 表示**变化绝对值**\n- 活动接口 `seller_activity_registered_info` 数据为**近 30 天**口径，与 `RECENT_7` 总盘对比时需说明口径差异\n- 头部老客户接口需重点关注 **`payAmount`（本周期）vs `payAmtAll`（累计）** 的关系，识别\"历史强、近期弱\"的高价值流失风险客户\n- 当用户问题偏向某个方向（如\"为什么下滑\"/\"最近靠什么增长\"），应在保持完整框架的前提下，**聚焦该方向的章节深度展开**\n\n\n---\n\n## 九、环境变量（.env）\n\n项目根目录的 `.env` 文件存储 skill 基础信息，供埋点上报模块读取。\n\n| 变量 | 默认值 | 说明 |\n|------|--------|------|\n| `SKILL_NAME` | `1688-shop-health-check` | skill 名称 |\n| `SKILL_VERSION` | `1.0.0` | skill 版本号 |\n| `SKILL_CHANNEL` | `clawhub` | 发布渠道 |\n\n> 已存在的系统环境变量优先级高于 `.env`，CI/CD 注入的变量不会被覆盖。\n\n\n---\n\n## 十、埋点上报\n\n每次 CLI 命令执行时，自动向 skill 网关上报一次调用记录。\n\n- **实现位置**：`scripts/_tracker.py` → `report_skill_usage()`，在 `cli.py` 的 `main()` 中每次命令执行后自动调用\n- **上报接口**：`POST /api/reportSkillsUsage/1.0.0`\n- **失败处理**：上报失败静默忽略，不影响主流程\n\n\n---\n\n## 总原则\n\n> **像一份专业的店铺经营体检报告一样输出：先判断健康度，再定位问题源，再识别增长引擎，最后给出可执行动作。**\n>\n> 数据是手段，**经营判断和可执行建议**才是目的。\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn76msg8cwkep3b08z7zffx9fx82p5wj\",\n  \"slug\": \"1688-shop-health-check\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1778322061355\n}\n\nFile v1.0.0:references/analysis-methodology.md\n\n# 分析方法论（Step 3 — Step 8）\n\n本文档包含第二阶段各分析方向的详细方法论。Agent 根据用户选择的方向，按需读取对应章节。\n\n> **前置依赖**：所有 Step 均依赖 Step 1（总盘健康度判断）的结果，用于交叉验证。\n\n---\n\n## Step 3 — 异常商品定位（`seller_import_abnormal_offer`）\n\n**按需调用（用户选择方向 1 或 7 时执行）。**\n\n按 `reason` 分三类识别：\n\n| 异常类型 | 含义 | 优先级 |\n|---------|------|--------|\n| **访客下跌** | 偏流量获取问题 | 中 |\n| **支付下跌** | 偏转化/成交问题 | 中 |\n| **访客下跌 + 支付下跌（双跌）** | 流量与转化同时恶化 | **最高** |\n\n**筛查优先级**（按以下顺序排列异常商品）：\n\n1. **影响金额大**：`valueMap.payAmt.value.value` 高且 `valueMap.payAmt.cycleCqc.value` 负向大\n2. **跌幅大**：`cycleCrc` 负向显著（如 < -30%）\n3. **多重异常**：`reason` 同时包含访客下跌和支付下跌\n4. **集中度**：是否集中在某类目或店铺核心商品上\n\n输出时聚焦 **TOP 3-5 个最值得处理的异常商品**，每个需说明：异常类型、当前规模、影响幅度、优先处理理由。\n\n### 下一步操作卡片触发判定（必做）\n\nStep 3 取数完成后，**必须根据异常商品数量决定调用哪个交互组件**，但**具体的 `show_interaction` 调用参数、文案模板、构造规则**统一在主文件「二、多阶段输出格式 — 第二阶段输出模板 §C」集中定义，本节只负责**判定**：\n\n| 判定条件 | 调用 `show_interaction` 的交互名 | 输出形态 |\n|---|---|---|\n| `abnormal_offer_count > 0` | `select_abnormal_action` | §C 形态一：商品 × 操作合并卡片 |\n| `abnormal_offer_count == 0` | `input_offer_for_optimize` | §C 形态二：两步问答（输入 offerId + 选择优化方向） |\n\n**调用时机**：在第二阶段 §B 的 ` ```seller-report``` ` 代码块输出完毕**之后**，通过 `show_interaction` 展示【下一步操作卡片】，不得在 §B 之前或内部调用。\n\n**与方向 7（完整诊断）的衔接**：完整诊断模式下，§C 也只调用一次 `show_interaction`，紧跟在 §B 之后；不要为每个方向重复触发。\n\n**⚠️ 多方向组合场景**：当用户同时选择了多个方向（如方向 1+3），异常商品的 §C 判定和数据准备在 Step 3 完成，但**实际调用 `show_interaction` 的时机**始终在所有方向的 §A + §B 输出完毕之后，不因异常商品结果为空（`abnormal_offer_count == 0`）而提前。即使异常商品无数据，也必须先完整输出 §A（覆盖所有方向的总结）和 §B（覆盖所有方向的可视化报告），再在最后执行 §C。\n\n> 📍 **完整 `show_interaction` 调用参数、文案构造规则、关键词映射、执行优化动作调用、兜底逻辑**全部见主文件「二、多阶段输出格式 — 第二阶段输出模板 §C」。\n\n---\n\n## Step 4 — 流量趋势分析（`get_traffic_trend`）\n\n**按需调用（用户选择方向 2 或 7 时执行），用于判断流量波动趋势和识别异常。**\n\n**判断维度**：\n\n| 维度 | 判断方式 |\n|------|---------|\n| **整体趋势** | 近 7 天 / 近 30 天 uv/pv 的整体走向（上升/下降/波动） |\n| **异常波动** | 单日 uv/pv 突然大幅下跌或上涨的日期 |\n| **UVCTR 趋势** | UV 点击率的变化，判断流量质量是否稳定 |\n| **波动幅度** | 计算近 7 天 uv 的标准差或最大/最小值差异 |\n| **与总盘关联** | 流量趋势是否与 `seller_trade_code_index` 中的 `payByrCnt` 变化一致 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| **流量稳定** | uv/pv 趋势平稳，无明显波动 |\n| **流量下滑** | 近 7 天 uv 持续下降，需排查流量来源 |\n| **流量波动** | uv 在某些日期突然下跌，需检查是否有活动结束或渠道中断 |\n| **流量回升** | uv 近期开始上升，可能是新活动或渠道生效 |\n| **流量质量下降** | uv 稳定但 UVCTR 下降，说明流量质量降低 |\n\n**关键判断逻辑**：\n- 若 `get_traffic_trend` 显示近 7 天 uv 持续下滑，且 `seller_trade_code_index` 中 `payByrCnt` 同步下降 → **流量问题为主因**\n- 若 uv 稳定但 UVCTR 下降 → **流量质量降低，需优化流量来源或承接**\n- 若某日 uv 突然大幅下跌（如跌幅 > 30%） → **识别该日期，排查是否有活动结束、渠道中断或系统问题**\n\n**与异常商品交叉验证**：\n- 若流量趋势显示某日期突然下跌，需检查该日期前后是否有异常商品出现\n- 若流量整体下滑，需重点排查 `seller_import_abnormal_offer` 中是否有\"访客下跌\"的商品\n\n---\n\n## Step 5 — 增长引擎识别（`seller_top_offer`，**必须多次调用**）\n\n**根据分析需要，按需调用以下榜单**（不得只调用 `payAmt` 一种）：\n\n| 调用 | 识别目标 |\n|------|----------|\n| `--order_by payAmt` | **成交主力**：撑 GMV 的核心商品 |\n| `--order_by uv` | **流量主力**：流量大但需结合 `payRate` 看转化 |\n| `--order_by payNewByrCnt` | **拉新主力**：贡献新客的商品 |\n| `--order_by itemMultiByrCnt` | **复购主力**：承担复购经营的商品 |\n\n**强制最低调用集**：\n- 若只做总体诊断 → 至少调用 `payAmt` + `uv` + `payNewByrCnt` 或 `itemMultiByrCnt` 中的一个\n- 若用户问\"靠什么增长\" → 至少调用全部 4 种\n\n**交叉判断逻辑**：\n\n| 特征 | 商品类型 | 行动建议方向 |\n|------|---------|------------|\n| 高 `payAmt` + 高 `payRate` | **核心成交款** | 重点保护，加大投入 |\n| 高 `uv` + 低 `payRate` | **高流量低转化款** | 优化转化（详情/价格/评价） |\n| 低 `uv` + 高 `payRate` | **潜力款** | 加流量放量 |\n| 高 `payNewByrCnt` | **拉新款** | 投放裂变、首单优惠 |\n| 高 `itemMultiByrCnt` + 高 `itemMultiByrPayAmt` | **复购款** | 老客经营、会员激励 |\n\n**关键交叉验证**：\n- 优秀商品列表里是否同时出现在异常商品列表中？**若重叠 → 高优先级风险**（核心商品在恶化）\n- 异常商品中是否有店铺 TOP 成交品？**若有 → 必须最高优先级修复**\n\n---\n\n## Step 6 — 活动效果分析（`seller_activity_registered_info`）\n\n**判断维度**：\n\n| 维度 | 判断方式 |\n|------|---------|\n| 是否带来访客 | `activityItmVisitorUv` / `activityItmVisitorPv` 是否显著 |\n| 是否承接转化 | `activityItmOrderCnt` / `activityItmGmv` 与 PV 的比值 |\n| 是否优于同行 | `activityItmGmv` vs `peerActivityItmGmv`，`activityItmVisitorPv` vs `peerActivityItmVisitorPv` |\n| 是否值得复制 | GMV 高 + 优于同行 + 流量稳定 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| **有效活动** | GMV 高且优于同行基准 |\n| **高曝光低成交** | PV 高但订单/GMV 显著低于同行 → 承接差，详情/选品/价格有问题 |\n| **低曝光低产出** | PV 和 GMV 均低 → 活动未拿到流量红利或参与不充分 |\n| **可复制活动** | 有效活动中可识别共性（类目、玩法、时段）→ 后续放大 |\n\n**注意**：若 `peerActivityItmGmv` 等同行字段缺失，仅做内部对比，不强行下\"是否优于同行\"结论。\n\n---\n\n## Step 7 — 地域结构分析（`seller_customer_business_province`）\n\n**判断维度**：\n\n| 维度 | 判断方式 |\n|------|---------|\n| **集中度** | TOP 1 / TOP 3 省份 `payBuyerNumRate` 之和 |\n| **依赖风险** | TOP 1 省份占比 > 40% → 高度依赖；> 60% → 严重依赖 |\n| **覆盖面** | 出现的省份数量、长尾省份分布 |\n| **潜力区域** | 占比中等（5-15%）但接近核心区域的省份，可作为下一阶段拓展目标 |\n\n**结论必须结合店铺类目特征**：某些类目（如本地服务、生鲜）天然区域集中，不应一刀切判定为\"风险\"。\n\n---\n\n## Step 8 — 头部老客稳定性（`seller_customer_detail`）\n\n**判断维度**：\n\n| 维度 | 判断方式 |\n|------|---------|\n| **依赖度** | TOP N 头部老客 `payAmount` 占店铺总 `payAmt` 的比例 |\n| **活跃度** | `lastPayDate` 距今天数，看头部客户是否近期还在买 |\n| **流失风险** | 历史 `payAmtAll` 高但本期 `payAmount` = 0 或显著低 → 走弱风险 |\n| **客户结构** | `identityName` / `buyerCreditLevel` / `custAreaName` 分布特征 |\n| **获客来源** | `fstFromAd = true` 占比高 → 广告获客型；占比低 → 自然沉淀型 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| **基本盘稳** | 头部老客持续活跃，贡献稳定 |\n| **依赖风险高** | 少数头部客户占比极高，单客流失即重创 GMV |\n| **存在断层风险** | 高累计价值客户近期不活跃，需立即召回 |\n| **广告依赖型** | 头部客户多数来自广告，需关注获客成本与生命周期 |\n\nFile v1.0.0:references/anti-patterns.md\n\n# 跨组件通用反例（强约束）\n\n本文档列举跨组件的通用错误模式。组件专属约束（如 value 类型、cycle 字段、focusPoints 数量等）已内联到 SKILL.md 各组件定义中，此处不再重复。\n\n---\n\n## 反例1：用 TextCard 替代特殊组件\n\n**错误示例**：将\"社媒趋势的4个机会（有优先级高低之分）\"用 TextCard 展示。\n\n```json\n❌ {\"type\": \"TextCard\", \"data\": [\n  {\"title\": \"3D打印定制\", \"text\": \"探索3D打印技术应用...\"},\n  {\"title\": \"明星联名款\", \"text\": \"推出明星同款或联名款...\"}\n], \"config\": {\"title\": \"社媒新兴机会\"}}\n```\n\n**规则**：当内容包含优先级排序、影响力分级时，必须使用 InfluenceCard；当内容包含风险提示时，必须使用 AlertCard；当内容包含执行步骤时，必须使用 PhaseCard；当内容有3+对象的多维度对比时，必须使用 Chart.List。严格参照 SKILL.md 中\"组件选型优先级\"章节的映射表。\n\n---\n\n## 反例2：章节大量丢失，过度压缩\n\n**错误示例**：原文有8个大章节、20+个子主题，输出仅9个组件，丢失了\"成本结构明细\"\"细分场景产品矩阵\"\"品牌业绩数据\"\"风险与机会提示\"等完整章节。将多个独立章节压缩进同一个组件：\n\n```json\n❌ {\"type\": \"TextCard\", \"data\": [\n  {\"title\": \"行业转型趋势\", \"text\": \"从功能性老年鞋向轻运动生活方式载体转型...\"},\n  {\"title\": \"供需错配现状\", \"text\": \"低端产品严重过剩...\"},\n  {\"title\": \"技术创新方向\", \"text\": \"超临界发泡材料...\"}\n], \"config\": {\"title\": \"行业核心洞察\"}}\n← 将\"行业概况\"\"产品创新\"\"供需格局\"三个独立章节压缩为一个3条的TextCard\n```\n\n**规则**：\n1. 生成前必须逐一列出原文所有章节和子主题\n2. 生成后必须逐一核对，确保每个章节至少有一个组件对应\n3. 禁止将多个独立章节压缩进同一个组件\n4. 每个原文大章节（一级标题）应至少对应1-2个组件\n\n---\n\n## 反例3：基础图表类组件独占一行造成布局浪费\n\n**错误示例**：\n\n```\nMODULE 内：\nr1: 仅 Chart.Column（基础图表类）  ← 可与 Pie/DataCard 组合，浪费半行\nr2: 仅 KeyValueCard（基础图表类）  ← 可与其他基础图表组合，浪费半行\n→ 两个基础图表类组件可以合并为 r1-c1 + r1-c2，却各自独占一行\n```\n\n**正确示例**：\n\n```\nr1: Chart.Column(消费诉求) + Chart.Pie(价格带分布)  ← 两个基础图表组合\nr2: Chart.Column(品牌份额) + DataCard(品牌业绩)     ← 两个基础图表组合\n```\n\n**规则**：\n1. 基础图表类组件（Chart.Line/Chart.Column/Chart.Pie/DataCard/KeyValueCard）必须优先两两组合\n2. 生成每个 MODULE 后，必须检查是否存在两个或以上基础图表类组件各自独占一行的情况\n3. 如果存在，必须合并到同一行（一个 c1，一个 c2）\n4. 仅当 MODULE 内只有一个基础图表类组件且无其他基础图表可组合时，才允许独占一行\n5. 常见可组合对：Column+Pie、Column+DataCard、Column+KeyValueCard、DataCard+KeyValueCard、Pie+DataCard\n\n---\n\n## 反例4：整个章节被完全跳过/省略\n\n**错误示例**：原文有8个大章节，输出仅覆盖其中5个，以下章节被完全跳过：\n\n```\n❌ \"宏观环境与政策支持\"（4个政策方向）→ 无任何组件对应\n❌ \"社交媒体趋势与新兴机会\"（4个机会方向）→ 无任何组件对应\n❌ \"风险与挑战\" → 无任何组件对应（应用 AlertCard）\n```\n\n**规则**：\n1. 生成前必须列出原文所有一级标题和二级标题，形成章节清单\n2. 生成后必须逐一核对章节清单，确保每个一级标题至少有 1 个组件对应\n3. 总组件数不得少于原文一级标题数 × 1.5\n\nFile v1.0.0:references/cli-commands.md\n\n# CLI 命令详细字段说明\n\n本文档包含 1688-shop-health-check 所有 CLI 命令的详细参数和字段说明。Agent 在调用具体命令前按需读取对应章节。\n\n所有命令均通过 `python3 {baseDir}/cli.py <command> [options]` 调用，输出统一为：\n```json\n{\"success\": bool, \"markdown\": str, \"data\": {...}}\n```\n\n---\n\n## 1. `seller_trade_code_index` — 店铺交易核心指标（总盘）\n\n```bash\npython3 {baseDir}/cli.py seller_trade_code_index [--date_type <DATE_TYPE>] [--device <DEVICE>]\n```\n\n**用途**：总盘分析**第一优先级接口**，判断店铺整体健康度、规模、效率、质量、新老客结构和下单到支付衔接情况。\n\n**关键字段**：\n\n| 字段 | 含义 | 用途 |\n|------|------|------|\n| `payAmt` | 支付金额 | 成交规模 |\n| `payByrCnt` | 支付买家数 | 买家规模 |\n| `payRate` | 支付转化率 | 转化效率 |\n| `payMordCnt` | 支付订单数 | 订单规模 |\n| `payItemCnt` | 支付商品款数 | 在售活跃款数 |\n| `payItemQty` | 支付商品数量 | 件数规模 |\n| `perByrAmt` | 人均支付金额 | 客单表现 |\n| `payToOnRate` | 下单到支付转化效率 | 支付承接效率 |\n| `payNewByrCnt` | 新支付买家数 | 拉新能力 |\n| `payOldByrCnt` | 老支付买家数 | 复购能力 |\n| `oldPayByrAmt` | 老买家支付金额 | 老客贡献 |\n| `rfdSucAmt` | 退款成功金额 | 成交质量风险 |\n| `crtOrdAmt` | 创建订单金额 | 下单规模 |\n| `crtByrCnt` | 创建订单买家数 | 下单买家规模 |\n| `crtOrdItmQty` | 创建订单商品数量 | 下单件数 |\n| `cycleCrc` | 环比变化率 | 趋势方向（可能为负） |\n| `cycleCqc` | 环比变化绝对值 | 趋势幅度 |\n\n---\n\n## 2. `seller_import_abnormal_offer` — 异常商品（风险定位）\n\n```bash\npython3 {baseDir}/cli.py seller_import_abnormal_offer [--date_type <DATE_TYPE>] [--device <DEVICE>]\n```\n\n**用途**：风险定位**关键接口**，判断问题主要来自流量、转化还是同时恶化，识别对店铺拖累最大的异常商品。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `reason` | 异常原因，如\"访客下跌\"/\"支付下跌\"/\"访客下跌, 支付下跌\" |\n| `itemId` | 商品ID |\n| `offerTitle` | 商品标题 |\n| `categoryId` | 类目ID |\n| `offerImageUrl` | 商品图 |\n| `link` | 异常详情跳转链接 |\n| `abnormalProduct` | 是否异常商品 |\n| `valueMap.uv.value` | 当前访客数 |\n| `valueMap.uv.cycleCrc` | 访客变化率 |\n| `valueMap.uv.cycleCqc` | 访客变化值 |\n| `valueMap.payAmt.value.value` | 当前支付金额 |\n| `valueMap.payAmt.cycleCrc.value` | 支付金额变化率 |\n| `valueMap.payAmt.cycleCqc.value` | 支付金额变化值 |\n\n---\n\n## 3. `seller_top_offer` — 优秀商品榜单（多榜单）\n\n```bash\npython3 {baseDir}/cli.py seller_top_offer [--order_by <ORDER_BY>] [--range_type <RANGE_TYPE>] [--device <DEVICE>] [--page_size <N>]\n```\n\n**⚠️ 重要约束**：本接口**必须按需多次调用**，单次只能拉取一种榜单。\n\n**`order_by` 枚举**：\n\n| 值 | 榜单类型 | 用途 |\n|------|----------|------|\n| `payAmt` | 支付榜（默认） | 成交主力商品 |\n| `uv` | 访客榜 | 流量主力商品 |\n| `payNewByrCnt` | 拉新榜 | 拉新主力商品 |\n| `itemMultiByrCnt` | 复购榜 | 复购主力商品 |\n\n**`range_type` 仅支持** `RECENT_7` / `RECENT_30`。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `item.offerTitle` / `item.offerId` / `item.detailUrl` / `item.categoryID` | 商品基础信息 |\n| `revealCnt` | 曝光数 |\n| `uv` | 访客数 |\n| `payByrCnt` | 支付买家数 |\n| `payRate` | 支付转化率 |\n| `payAmt` | 支付金额 |\n| `payItemQty` | 支付件数 |\n| `payNewByrCnt` | 新支付买家数 |\n| `payOldByrCnt` | 老支付买家数 |\n| `itemMultiByrCnt` | 复购买家数 |\n| `itemMultiByrPayAmt` | 复购支付金额 |\n\n---\n\n## 4. `seller_activity_registered_info` — 活动参与及效果\n\n```bash\npython3 {baseDir}/cli.py seller_activity_registered_info\n```\n\n**用途**：分析活动是否有效，是否带来流量、订单和 GMV，是否优于同行基准，是否存在\"有曝光无成交\"或\"高产出活动可复制\"。\n\n> **⚠️ 注意**：本接口数据为**近 30 天活动**口径，不完全等同于当前分析周期，需在结论中说明。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `activityName` / `activityId` | 活动信息 |\n| `cateLevel1Name` | 一级类目 |\n| `startTime` / `endTime` | 活动时间 |\n| `activityItmVisitorUv` / `activityItmVisitorPv` | 活动商品访客 UV/PV |\n| `activityItmOrderCnt` | 活动商品订单数 |\n| `activityItmTakeCnt` | 活动商品领取/参与次数 |\n| `activityItmGmv` | 活动商品 GMV |\n| `peerActivityItmVisitorPv` | 同行活动 PV（基准） |\n| `peerActivityItmGmv` | 同行活动 GMV（基准） |\n| `rank` | 活动排名（可能无效） |\n\n---\n\n## 5. `seller_customer_business_province` — 客户地域分布\n\n```bash\npython3 {baseDir}/cli.py seller_customer_business_province [--date_type <DATE_TYPE>] [--page_size <N>]\n```\n\n**用途**：分析客户地域集中度、核心区域依赖、区域覆盖面、潜在扩展区域。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `attributeValue` | 地域名称（省份） |\n| `payBuyerNum` | 该地域支付买家数 |\n| `payBuyerNumRate` | 该地域支付买家数占比 |\n| `recordCount` | 记录数 |\n\n---\n\n## 6. `seller_customer_detail` — 头部老客户明细\n\n```bash\npython3 {baseDir}/cli.py seller_customer_detail [--date_type <DATE_TYPE>] [--buyer_type <TYPE>] [--order_by <ORDER_BY>] [--page_size <N>]\n```\n\n**用途**：分析店铺是否依赖少数头部老客户，头部老客是否持续活跃，复购盘是否稳固，是否存在高价值客户近期走弱风险。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `identityName` | 客户身份/画像 |\n| `companyName` | 公司名 |\n| `custAreaName` | 客户地域 |\n| `buyerLoginId` | 买家标识 |\n| `payAmount` | **本周期**支付金额 |\n| `payAmtAll` | **累计**支付金额（看历史价值） |\n| `lastPayDate` | 最近支付日期（看活跃度） |\n| `firstPayDate` | 首次支付日期 |\n| `fstFromAd` | 是否首次来自广告（自然 vs 广告获客） |\n| `buyerType` | 买家类型 |\n| `payParentOrderNum` | 支付父订单数 |\n| `buyerCreditLevel` | 信用等级 |\n| `lstLossDate` | 最近流失日期（可能为空） |\n\n---\n\n## 7. `get_traffic_trend` — 逐日流量趋势数据\n\n```bash\npython3 {baseDir}/cli.py get_traffic_trend --query_date <QUERY_DATE> [--days <DAYS>]\n```\n\n**用途**：获取逐日流量趋势数据，用于分析流量波动趋势、识别异常波动、判断流量健康度。\n\n**⚠️ 重要约束**：\n- `query_date` 必须传入**昨日日期**（格式：YYYY-MM-DD）\n- `days` 仅支持 7 或 30，表示近 7 天或近 30 天的数据\n\n**关键字段**（返回数组中每项包含）：\n\n| 字段 | 含义 |\n|------|------|\n| `uv` | 访客数 |\n| `pv` | 浏览量 |\n| `UVCTR` | UV 点击率 |\n| `日期` | 日期（格式：YYYYMMDD） |\n\n---\n\n## 8. `get_core_metrics` — 店铺核心指标同行对比及趋势数据\n\n```bash\npython3 {baseDir}/cli.py get_core_metrics [--date_type <DATE_TYPE>]\n```\n\n**用途**：获取店铺核心指标的同行对比数据及趋势数据，用于判断店铺在行业中的位置、指标健康度、增长趋势。\n\n**⚠️ 重要约束**：\n- `date_type` 仅支持 `RECENT_7` 或 `RECENT_30`\n- 接口返回的 `data` 是 JSON 字符串，包含 `core_metrics`（同行对比）和 `trend`（趋势数据）\n\n**关键字段（core_metrics 数组中每项包含）**：\n\n| 字段 | 含义 |\n|------|------|\n| `metric_name` | 指标名称（展现次数/访客数/浏览量/点击转化率/支付转化率/支付买家数/支付金额） |\n| `metric_code` | 指标代码（impression/visitor/page_view/click_cvr/pay_cvr/buyer_count/pay_amount） |\n| `my_value` | 本店数值 |\n| `peer_avg` | 同行同层均值 |\n| `ratio_to_peer` | 本店/同行同层均值（达标率） |\n| `rating` | 评级（优秀/持平/略低/极低） |\n\n**关键字段（trend 对象中每项包含）**：\n\n| 字段 | 含义 |\n|------|------|\n| `value` | 当前值 |\n| `year_on_year` | 同比变化率（本月 vs 去年同一月） |\n| `week_on_week` | 环比变化率（本周 vs 上周 / 本月 vs 上月） |\n| `vs_peer_avg` | 本店变化率 vs 同行平均变化率 |\n| `vs_peer_good` | 本店变化率 vs 同行优秀变化率 |\n\n**趋势字段判断提示**：\n- `vs_peer_avg` > 1 表示本店变化优于同行平均\n- `vs_peer_good` > 1 表示本店变化优于同行优秀\n\n**关键字段（date_range 对象）**：\n\n| 字段 | 含义 |\n|------|------|\n| `start_date` | 开始日期 |\n| `end_date` | 结束日期 |\n\n---\n\n## 9. `configure` — 配置 AK\n\n```bash\npython3 {baseDir}/cli.py configure [YOUR_AK]\n```\n\n**用途**：配置 1688 API 的 AccessKey，用于后续所有接口的鉴权签名。\n\n**使用方式**：\n\n| 命令 | 行为 |\n|------|------|\n| `python3 {baseDir}/cli.py configure YOUR_AK` | 写入 AK 到本地配置 |\n| `python3 {baseDir}/cli.py configure` | 查看当前 AK 配置状态 |\n\n> **注意**：首次使用前必须配置 AK，否则所有只读接口将返回 `success: false` 和 \"AK 未配置\" 错误。\n\nFile v1.0.0:references/interaction-specs.md\n\n# 交互组件详细规范\n\n本文档定义了 1688-shop-health-check Skill 中所有交互组件的具体数据结构与映射规则。\n\n## 1. select_analysis_direction (Card 组件)\n\n### 组件类型\n`type: card`\n\n### 业务场景\n在输出店铺健康总览（第一阶段）后，让用户通过卡片选择希望深入分析的方向，而非手动输入文字。用户可选择单个方向，端侧会自动追加\"输入其他\"选项。\n\n### 数据槽位定义\n\n- **`directions`**:\n  - 类型: `Array<Object>`\n  - 映射规则: 固定的 7 个分析方向选项，无需从外部 Tool 获取，直接硬编码\n  - 必须字段:\n    - `label`: 方向名称（字符串，≤ 10 字）\n    - `description`: 方向说明（字符串，≤ 30 字）\n\n### 方向与编号映射\n\n用户选择后，需要将 `label` 映射回对应的分析方向编号：\n\n| label | 对应编号 | 调用接口 |\n|-------|---------|---------|\n| 异常商品诊断 | 1 | `seller_import_abnormal_offer` |\n| 流量趋势分析 | 2 | `get_traffic_trend` |\n| 增长驱动与主力商品 | 3 | `seller_top_offer`（4 种榜单） |\n| 活动效果分析 | 4 | `seller_activity_registered_info` |\n| 客户地域分布 | 5 | `seller_customer_business_province` |\n| 头部老客户分析 | 6 | `seller_customer_detail` |\n| 完整诊断报告 | 7 | 全部接口 |\n\n### 完整数据示例\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"analysis_direction\",\n  \"directions\": [\n    { \"label\": \"异常商品诊断\", \"description\": \"识别拖累店铺的异常商品，定位流量/转化问题源\" },\n    { \"label\": \"流量趋势分析\", \"description\": \"分析逐日流量波动，识别异常日期和流量质量变化\" },\n    { \"label\": \"增长驱动与主力商品\", \"description\": \"识别成交/流量/拉新/复购四大维度的主力商品\" },\n    { \"label\": \"活动效果分析\", \"description\": \"评估近 30 天活动效果，识别高效/低效活动\" },\n    { \"label\": \"客户地域分布\", \"description\": \"分析客户地域集中度和拓展机会\" },\n    { \"label\": \"头部老客户分析\", \"description\": \"分析高价值客户稳定性、活跃度和流失风险\" },\n    { \"label\": \"完整诊断报告\", \"description\": \"全量分析，输出包含以上所有方向的完整报告\" }\n  ]\n}\n```\n\n### 用户选择结果处理\n\n- **用户选择了 1-6 中的某个方向**: 按对应编号执行聚焦型分析\n- **用户选择了\"完整诊断报告\"**: 等同于选择编号 7，执行全量取数\n- **用户通过\"输入其他\"自由输入**: 尝试匹配已有方向，若无法匹配则告知用户不支持该方向并自动执行完整诊断\n\n---\n\n## 2. select_abnormal_action (Card 组件)\n\n### 组件类型\n\n`type: card` — 异常商品诊断（用户选择方向 1 或方向 7 走到异常商品环节）的可视化 JSON 输出**完成之后**，把每个 TOP 异常商品 × 推荐操作合并成一张卡片，用户**单选**一项即直接调用对应优化技能。\n\n### 触发条件\n\n- 必须在 Step 3 异常商品定位的可视化 JSON 输出之后触发（不可在文字段中或可视化 JSON 之前触发）\n- 仅当 `seller_import_abnormal_offer` 返回的异常商品数量 > 0 时触发；为 0 时改用 `input_offer_for_optimize`\n- Agent 必须先完成异常商品诊断的全部输出（文字结论 + 可视化 JSON），再追加此交互\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`\n  - 说明: 问题列表，每项包含 `question`（问题文本）和 `options`（选项数组）\n  - 端侧会自动追加\"输入其他\"选项\n\n### 选项构造规则\n\n1. **逐商品生成**：对 Step 3 输出的每个 TOP 异常商品，根据其 `reason` 字段或行动重点关键词匹配下表生成选项\n2. **关键词映射表**：\n\n   | 异常商品 `reason` / 行动重点关键词 | 选项文案模板 | 对应技能 |\n   |---|---|---|\n   | 主图、图片、优化图、CTR、点击率、曝光转点击 | `🖼️ 优化商品 {offerId} 主图（{异常类型简述}）` | `1688-item-image-optimizer` |\n   | 标题、关键词、SEO、搜索、词覆盖 | `✏️ 优化商品 {offerId} 标题（{异常类型简述}）` | `1688-item-title-optimizer` |\n\n3. **默认兜底**：\n   - `reason` = \"访客下跌\" 且未明确命中关键词 → 默认 `✏️ 优化标题`（拉搜索曝光）\n   - `reason` = \"支付下跌\" 且未明确命中关键词 → 默认 `🖼️ 优化主图`（提点击转化）\n   - `reason` = \"访客下跌, 支付下跌\"（双跌） → **两条选项都生成**\n4. **数量限制**：最少 2 个，最多 6 个；超过时按异常严重度（`valueMap.payAmt.cycleCqc.value` 负向绝对值）截断\n5. **排序规则**：按异常严重度从高到低排列；同一商品的多个选项相邻排列，🖼️ 优先于 ✏️\n6. **文案中的「异常类型简述」**：从 `reason` 提炼，如\"访客 -45%\"、\"支付 -2.3 万\"，控制在 12 字内\n\n### 完整数据示例\n\n假设 Step 3 输出的 TOP 异常商品为：\n1. offerId `912345678`，reason `访客下跌, 支付下跌`，访客 -52%、支付 -¥18,500\n2. offerId `887766554`，reason `支付下跌`，支付 -¥9,200\n3. offerId `776655443`，reason `访客下跌`，访客 -38%\n\n则构造的交互数据为：\n\n```json\n{\n  \"questions\": [\n    {\n      \"question\": \"🛠️ 以上是异常商品诊断结果。建议针对以下商品立即开展优化，请选择一项执行：\",\n      \"options\": [\n        \"🖼️ 优化商品 912345678 主图（双跌·支付 -1.85万）\",\n        \"✏️ 优化商品 912345678 标题（双跌·访客 -52%）\",\n        \"🖼️ 优化商品 887766554 主图（支付 -9.2k）\",\n        \"✏️ 优化商品 776655443 标题（访客 -38%）\"\n      ]\n    }\n  ]\n}\n```\n\n### 用户选择后的处理\n\n| 用户选择文案 | Agent 行为 |\n|---|---|\n| `🖼️ 优化商品 {offerId} 主图（…）` | 直接调用 `1688-item-image-optimizer`，携带 `offerId` 作为上下文 |\n| `✏️ 优化商品 {offerId} 标题（…）` | 直接调用 `1688-item-title-optimizer`，携带 `offerId` 作为上下文 |\n| 输入其他 | 等待用户输入自定义需求，Agent 根据内容判断应调用的技能 |\n\n> ⚠️ 用户选择后应**直接调用对应技能**，无需用户再次输入触发词或重新提供 offerId。\n\n---\n\n## 3. input_offer_for_optimize (Card 组件)\n\n### 组件类型\n\n`type: card` — 异常商品诊断完成但**未识别到异常商品**时使用，通过标准 Card 组件的两步问答收集商家想要优化的商品 offerId 和优化方向，然后直接调用对应下游优化技能。\n\n### 触发条件\n\n- 用户走到异常商品诊断环节（方向 1 或方向 7）\n- `seller_import_abnormal_offer` 返回的异常商品数量 == 0\n- Agent 必须先用 1 句话说明\"当前周期未识别到明显异常商品\"再追加此卡片\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`，固定 2 题，端侧按顺序逐题展示\n  - **第一题（offerId 收集）**：\n    - `question`: 引导用户输入 offerId 的问题文本，支持 Markdown 渲染\n    - `options`: `[]`（空数组，表示纯自由输入题）\n    - `required`: `true`（必填，不可跳过）\n  - **第二题（优化方向选择）**：\n    - `question`: 引导用户选择优化方向的问题文本\n    - `options`: `[\"🖼️ 优化主图\", \"✏️ 优化标题\"]`（固定 2 项）\n    - `allowMultiple`: `false`（单选）\n    - `required`: `true`（必填，不可跳过）\n\n### 完整数据示例\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"**请输入要优化的商品 offerId**\\n\\n请填写纯数字的商品 ID，例如：`912345678`\",\n      \"options\": [],\n      \"required\": true\n    },\n    {\n      \"question\": \"**请选择优化方向**\",\n      \"options\": [\"🖼️ 优化主图\", \"✏️ 优化标题\"],\n      \"allowMultiple\": false,\n      \"required\": true\n    }\n  ]\n}\n```\n\n### 回传结构\n\n```json\n[\n  { \"question\": \"**请输入要优化的商品 offerId**...\", \"answer\": \"912345678\" },\n  { \"question\": \"**请选择优化方向**\", \"answer\": \"🖼️ 优化主图\" }\n]\n```\n\n### 用户操作后的处理\n\n| 用户回传 | Agent 行为 |\n|---|---|\n| 第一题回答了有效 offerId + 第二题选择 `🖼️ 优化主图` | 直接调用 `1688-item-image-optimizer`，携带用户输入的 `offerId` |\n| 第一题回答了有效 offerId + 第二题选择 `✏️ 优化标题` | 直接调用 `1688-item-title-optimizer`，携带用户输入的 `offerId` |\n| 第一题输入了非数字内容 | Agent 提示\"offerId 须为纯数字，请重新输入\"，不调用下游技能 |\n| 用户通过\"输入其他\"自由输入 | 等待用户输入自定义需求，Agent 根据内容判断应调用的技能 |\n\n> ⚠️ Agent 必须校验第一题回传的 offerId 为纯数字后再调用下游技能，不要自行编造 offerId。\n\nFile v1.0.0:references/visualization-rules.md\n\n---\r\nname: report-to-visualization\r\ndescription: 将文本报告转换为可视化组件流。当用户需要将报告数据可视化或提到\"可视化报告\"、\"用图表展示\"、\"图文并茂\"时使用。\r\n---\r\n\r\n# 报告转可视化组件流\r\n\r\n## 任务目标\r\n\r\n将文本报告数据转换为可视化组件配置，输出严格的MODULE格式。\r\n\r\n## 输入格式\r\n\r\n用户需提供以下变量：\r\n- `${moduleData}`: 报告数据内容\r\n\r\n## 图表库规范\r\n\r\n### 1. 折线图 (Chart.Line)\r\n**使用条件**: 展示数据趋势，需至少5个连续、真实的时间点原始观测值\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"Chart.Line\",\r\n  \"data\": [{\"name\": \"时间标签，≤6字\", \"value\": 数值, \"category\": \"系列名称，≤8字\"}],\r\n  \"config\": {\"xField\": \"name\", \"yField\": \"value\", \"title\": \"图表标题，≤12字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- 禁止基于平均值、最高/最低值、总计等聚合统计量推测或填充时间序列数据\r\n- `value` 必须为 number 类型（如 `78.5`），禁止使用字符串（如 `\"78.5\"`）\r\n\r\n### 2. 柱状图 (Chart.Column)\r\n**使用条件**: 展示数据对比，一个或多个维度有不低于2个具体数值\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"Chart.Column\",\r\n  \"data\": [{\"name\": \"分类标签，≤8字\", \"value\": 数值, \"category\": \"指标名称，≤8字\"}],\r\n  \"config\": {\"xField\": \"name\", \"yField\": \"value\", \"seriesField\": \"category\", \"isGroup\": true, \"title\": \"图表标题，≤12字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- `value` 必须为 number 类型（如 `78.5`），禁止使用字符串（如 `\"78.5\"`），字符串会导致图表排序和轴刻度异常\r\n- 如果原文给出范围值（如\"60%-85%\"），应拆分为两个数据点（如\"线下摆摊(低) 60\"和\"线下摆摊(高) 85\"），或改用 KeyValueCard 展示\r\n- ❌ `{\"name\": \"线下摆摊\", \"value\": \"60-85\"}` → ✅ 拆分为 `{\"name\": \"摆摊(低)\", \"value\": 60}` 和 `{\"name\": \"摆摊(高)\", \"value\": 85}`\r\n- **禁止混合量纲**：同一个柱状图中所有数据点的 value 必须属于同一量纲（如全部是百分比，或全部是绝对数值）。禁止将绝对数值（如曝光量 9500、成交金额 7800）与百分比（如点击率 2.3%、转化率 0.8%）放在同一个图表中，否则百分比的柱子会因数量级差异完全不可见。应拆分为两个独立的 Chart.Column，或将百分比指标改用 DataCard 展示\r\n- ❌ 曝光量(9500) + 点击率(2.3) + 成交金额(7800) 放在同一柱状图 → ✅ 拆分为\"流量与销售\"柱状图（绝对数值）+ \"转化效率\"DataCard 或柱状图（百分比）\r\n\r\n### 3. DataCard (数据卡片)\r\n**使用条件**: 展示核心指标值和环比数据，**不低于4个指标**\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"DataCard\",\r\n  \"data\": [{\"desc\": \"指标名称，≤12字\", \"value\": \"指标值\", \"cycle\": \"环比变化值或null\"}],\r\n  \"config\": {\"title\": \"卡片标题，≤10字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c2\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- `cycle` 字段**仅用于**填写环比/同比的数值变化（如 `\"-0.26%\"`、`\"+5.3%\"`），或填 `null`\r\n- 禁止在 `cycle` 中填入描述性文字（如\"下降\"\"行业第一\"\"占比47.2%\"）\r\n- 如果某指标没有环比/同比数据，`cycle` 必须为 `null`\r\n- ❌ `{\"desc\": \"斯凯奇份额\", \"value\": \"16.8%\", \"cycle\": \"行业第一\"}` → ✅ `{\"desc\": \"斯凯奇份额\", \"value\": \"16.8%\", \"cycle\": null}`\r\n\r\n### 4. 饼图 (Chart.Pie)\r\n**使用条件**: 展示数据占比，不低于2个指标，value值求和应为100（百分比）或1（小数）\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"Chart.Pie\",\r\n  \"data\": [{\"type\": \"类别名称，≤8字\", \"value\": 数值}],\r\n  \"config\": {\"angleField\": \"value\", \"colorField\": \"type\", \"innerRadius\": 0.6, \"statistic\": {\"title\": false, \"content\": false}, \"title\": \"图表标题，≤12字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c2\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- `value` 必须为 number 类型，禁止字符串\r\n- **禁止推算补全**：如果原文只给出一个占比数据而缺少互补项（如仅提到\"35-55岁占61.3%\"），不得自行用 100%-61.3%=38.7% 推算出其他类别的占比。应改用 DataCard 或 KeyValueCard 展示已有数据\r\n- ❌ `{\"type\": \"其他年龄\", \"value\": 38.7}` ← 原文无此数据，系推算捏造\r\n\r\n### 5. 表格 (Chart.List)\r\n**使用条件**: 当内容满足以下**全部**条件时，**必须**使用 Chart.List 而非 TextCard/KeyValueCard：\r\n1. 有 **3 个以上的对比对象**（如 5 个品牌、4 款产品、6 个成本项）\r\n2. 每个对象需要展示 **3-4 个维度**（如品牌 + 定位 + 优势 + 数据）\r\n3. 需要**横向对比阅读**\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"Chart.List\",\r\n  \"data\": [{\"list\": [{\"key\": \"列名，≤10字\", \"value\": \"列值，≤20字\"}, {\"key\": \"列名\", \"value\": \"列值\"}]}],\r\n  \"config\": {\"title\": \"分组标题，≤10字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**典型场景**:\r\n- ✅ 竞争品牌格局（5 个品牌 × 4 个维度）→ Chart.List\r\n- ✅ 成本结构明细（6 个成本项 × 3 个维度）→ Chart.List\r\n- ❌ 品牌格局用 TextCard 描述 → 违规\r\n\r\n**约束（总计行表达）**:\r\n- 如果表格需要展示总计/合计行，总计行的 key-value 结构必须与明细行保持一致，**第一列的 key 不变，value 填\"总计/合计\"**，后续列正常填写汇总数据\r\n- ❌ `{\"list\": [{\"key\": \"成本项\", \"value\": \"约111.1元/双\"}, {\"key\": \"成本\", \"value\": \"-\"}, {\"key\": \"备注\", \"value\": \"含原材料25-40元\"}]}` ← 把金额塞进第一列，第二列留空，读者无法理解\r\n- ✅ `{\"list\": [{\"key\": \"成本项\", \"value\": \"总计\"}, {\"key\": \"成本\", \"value\": \"约111.1元/双\"}, {\"key\": \"备注\", \"value\": \"含原材料25-40元\"}]}` ← 第一列标明\"总计\"，后续列正常填写数据\r\n\r\n### 6. 文本卡片 (TextCard)\r\n**使用条件**: 展示数据总结、趋势洞察、运营建议等定性内容，不少于2个标题\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"TextCard\",\r\n  \"data\": [{\"title\": \"标题，≤10字\", \"text\": \"内容，尽量2行，30-45字\"}],\r\n  \"config\": {\"title\": \"卡片标题，≤10字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束（元素数量）**:\r\n- data 数组必须包含 **至少 2 个元素**（即至少 2 个 `{\"title\": \"...\", \"text\": \"...\"}` 对象），仅 1 个元素时应从原文上下文中提取更多观点/结论来补充，若确实无法补充则考虑将内容合并到相邻的组件中\r\n- ❌ `\"data\": [{\"title\": \"可行性结论\", \"text\": \"...\"}]` ← 仅 1 个元素，卡片单薄，信息密度过低\r\n- ✅ `\"data\": [{\"title\": \"可行性结论\", \"text\": \"...\"}, {\"title\": \"核心优势\", \"text\": \"...\"}]` ← 至少 2 个元素，内容充实\r\n\r\n**约束（内容聚合原则）**:\r\n- **同一主题下的多个子观点必须放在同一个 TextCard 的 data 数组中**，禁止拆分成多个 TextCard\r\n- 如果某个大主题下有 2-5 个紧密相关的子主题 → 使用一个 TextCard，data 数组包含多项\r\n- ❌ 将\"国家政策的 4 个方面\"拆成 4 个独立的 TextCard\r\n- ❌ 将\"产品创新的 4 个趋势\"拆成 2-3 个 TextCard\r\n\r\n**约束（内容丰富度）**:\r\n- TextCard 每项的 `text` 字段内容**尽量保持 2 行左右（30-60 字）**，避免内容过于单薄\r\n- 如果原文信息不足以撑满 2 行，应从原文上下文中提取补充信息（如具体数据、应用场景、代表案例等）进行丰富\r\n- ❌ `\"text\": \"北欧极简、无性别设计\"` ← 仅 1 行，信息密度过低\r\n- ✅ `\"text\": \"北欧极简、无性别设计成为主流趋势，通勤休闲轻运动场景无缝切换，满足全年龄段穿搭需求\"` ← 约 2 行，信息丰富\r\n\r\n### 7. 键值对卡片 (KeyValueCard)\r\n**使用条件**: 展示不低于2个分组，每个分组不低于2个指标\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"KeyValueCard\",\r\n  \"data\": [{\"title\": \"分组标题，≤8字\", \"list\": [{\"key\": \"指标名称，≤10字\", \"value\": \"格式化后的指标值，≤15字\"}]}],\r\n  \"config\": {\"title\": \"卡片主标题，≤10字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c2\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- data 数组必须包含 **至少 2 个分组**（即至少 2 个 `{\"title\": \"...\", \"list\": [...]}` 对象），仅 1 个分组时应改用 DataCard 或 TextCard\r\n- 每个分组的 list 数组应包含 **至少 2 个指标**\r\n- ❌ `\"data\": [{\"title\": \"唯一分组\", \"list\": [...]}]` ← 仅 1 个分组独占一整张卡片，信息密度过低\r\n\r\n### 8. 阶段卡片 (PhaseCard)\r\n**使用条件**: 展示分阶段的内容规划或执行步骤\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"PhaseCard\",\r\n  \"data\": [{\"phaseNumber\": \"阶段序号，≤5字\", \"phaseName\": \"阶段名称，≤6字\", \"focusPoints\": [{\"label\": \"重点项标签，≤6字\", \"content\": \"重点项内容，≤50字\"}]}],\r\n  \"config\": {\"title\": \"卡片标题，≤10字\", \"theme\": \"主题色，如'blue'\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- 阶段数控制在 **3-5 个**，避免过度拆分导致信息碎片化\r\n- 每个阶段应包含 **2-3 个 focusPoints**，体现该阶段的多维度工作内容\r\n- 可将相关性强的建议合并为同一阶段（如\"产品定位+技术创新\"合并为\"产品升级\"阶段）\r\n- ❌ 将 6 条建议拆成 6 个阶段，每阶段仅 1 个 focusPoint → ✅ 合并为 3-4 个阶段，每阶段 2-3 个 focusPoints\r\n\r\n### 9. 时间轴 (TimelineCard)\r\n**使用条件**: 展示时间轴内容，如里程碑规划，**不低于3个时间节点**\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"TimelineCard\",\r\n  \"data\": [{\"month\": \"月份，≤6字\", \"title\": \"里程碑标题，≤8字\", \"description\": \"详细描述，≤40字\", \"target\": \"目标值，≤12字\", \"status\": \"completed或in-progress\"}],\r\n  \"config\": {\"title\": \"标题，≤10字\", \"orientation\": \"horizontal或vertical\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- data 数组必须包含 **至少 3 个时间节点**，少于 3 个节点无法体现时间线的连续感和阶段递进关系\r\n- 仅 1-2 个时间节点时，应从原文上下文中提取更多里程碑/阶段来补充，若确实无法补充则改用 PhaseCard 或 TextCard 承载\r\n- ❌ `\"data\": [{\"month\": \"1月\", ...}]` ← 仅 1 个节点，无法构成时间轴\r\n- ❌ `\"data\": [{\"month\": \"1月\", ...}, {\"month\": \"6月\", ...}]` ← 仅 2 个节点，时间线过于稀疏\r\n- ✅ `\"data\": [{\"month\": \"1月\", ...}, {\"month\": \"3月\", ...}, {\"month\": \"6月\", ...}]` ← 至少 3 个节点，时间线完整\r\n\r\n### 10. 警告卡片 (AlertCard)\r\n**使用条件**: 展示警告内容，如风险提示、注意事项，**不低于2条警告**\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"AlertCard\",\r\n  \"data\": [{\"issue\": \"问题描述，≤25字\", \"consequence\": \"后果，≤40字\", \"suggestion\": \"建议，≤30字\", \"level\": \"warning或info或error或success\"}],\r\n  \"config\": {\"title\": \"卡片标题，≤10字\", \"showIcon\": true},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- data 数组必须包含 **至少 2 条警告**，仅 1 条警告时应从原文上下文中提取更多风险/注意事项来补充，若确实无法补充则改用 TextCard 承载\r\n- ❌ `\"data\": [{\"issue\": \"唯一的风险提示\", ...}]` ← 仅 1 条警告，信息密度过低，卡片单薄\r\n- ✅ `\"data\": [{\"issue\": \"风险1\", ...}, {\"issue\": \"风险2\", ...}]` ← 至少 2 条，信息充实\r\n\r\n### 11. 影响卡片 (InfluenceCard)\r\n**使用条件**: 展示不同程度的影响内容，如关键转化杠杆、机会优先级\r\n**数据格式**:\r\n```json\r\n{\r\n  \"type\": \"InfluenceCard\",\r\n  \"data\": [{\"name\": \"因素名称，≤10字\", \"influenceLevel\": 1-5, \"influenceLabel\": \"影响力标签，≤4字\", \"focusPoints\": [{\"label\": \"关注点标签，≤6字\", \"content\": \"关注点内容，≤50字\"}], \"warnings\": [{\"icon\": \"warning或info\", \"label\": \"警告标签，≤6字\", \"content\": \"警告内容，≤40字\"}], \"priority\": 1-3}],\r\n  \"config\": {\"title\": \"主标题，≤12字\"},\r\n  \"layoutRow\": \"r1\", \"layoutCol\": \"c1\", \"rowSize\": \"auto\", \"colSize\": \"auto\"\r\n}\r\n```\r\n**约束**:\r\n- 每个影响因素应包含 **2-3 个 focusPoints**，从不同维度（如技术/商业/用户/风险）展示影响\r\n- 如果原文对某个因素只有一句话描述，应从原文上下文中提取补充信息，而非仅用 1 个 focusPoint\r\n- ❌ 每个因素仅 1 个 focusPoint，信息密度过低 → ✅ 每个因素 2-3 个 focusPoints\r\n\r\n## 输出格式\r\n\r\n按报告章节分模块输出，所有模块统一组织在一个 JSON 对象的 `modules` 数组中，并使用 ` ```seller-report ` 代码块包裹。**最终输出必须严格遵循以下结构，不允许在代码块外输出任何额外内容**：\r\n\r\n```seller-report\r\n{\r\n  \"modules\": [\r\n    {\r\n      \"components\": [\r\n        {\r\n          \"type\": \"Title\",\r\n          \"content\": \"<章节子标题，≤8字，禁止以\\\"模块一\\\"、\\\"##\\\"等字符开头，应体现该章节的核心主题>\"\r\n        },\r\n        {\r\n          \"type\": \"<图表组件类型，如 Chart.Column / DataCard / KeyValueCard 等>\",\r\n          \"data\": [ ... ],\r\n          \"config\": { ... },\r\n          \"layoutRow\": \"r1\",\r\n          \"layoutCol\": \"c1\",\r\n          \"rowSize\": \"auto\",\r\n          \"colSize\": \"auto\"\r\n        },\r\n        {\r\n          \"type\": \"<图表组件类型>\",\r\n          \"data\": [ ... ],\r\n          \"config\": { ... },\r\n          \"layoutRow\": \"r1\",\r\n          \"layoutCol\": \"c2\",\r\n          \"rowSize\": \"auto\",\r\n          \"colSize\": \"auto\"\r\n        }\r\n      ]\r\n    },\r\n    {\r\n      \"components\": [\r\n        {\r\n          \"type\": \"Title\",\r\n          \"content\": \"<下一章节子标题>\"\r\n        },\r\n        {\r\n          \"type\": \"<图表组件类型>\",\r\n          \"data\": [ ... ],\r\n          \"config\": { ... },\r\n          \"layoutRow\": \"r1\",\r\n          \"layoutCol\": \"c1\",\r\n          \"rowSize\": \"auto\",\r\n          \"colSize\": \"auto\"\r\n        }\r\n      ]\r\n    }\r\n  ]\r\n}\r\n```\r\n\r\n**分模块规则**：\r\n1. 每个原文一级标题（## 级别）对应 `modules` 数组中一个独立的模块对象（即一个 `{\"components\": [...]}`）\r\n2. 每个模块的第一个组件**必须**是 `{\"type\": \"Title\", \"content\": \"<章节子标题>\"}`，用于标识该模块的核心主题（如\"消费者需求\"\"竞争格局\"\"政策环境\"），而非整个报告的标题；`Title` 组件不参与布局编号，无需 `layoutRow`/`layoutCol`/`data`/`config` 字段\r\n3. 每个模块的 `components` 数组中，除首个 `Title` 外的其他组件仅承载该章节相关的内容\r\n4. `layoutRow` 在每个模块内独立编号，从 r1 重新开始（`Title` 组件不占用行号）\r\n5. 整个输出必须是**单个合法 JSON 对象**，被 ` ```seller-report ... ``` ` 包裹；JSON 中不允许出现注释、尾随逗号等非标准语法\r\n\r\n## 布局规范（强约束）\r\n\r\n**核心规则**: 布局只能是一行一个组件或一行两个不同组件，不允许一行放两个相同组件。\r\n\r\n### 组件分类\r\n\r\n**基础图表类**（可两两组合）: Chart.Line、Chart.Column、Chart.Pie、DataCard、KeyValueCard\r\n\r\n**整行展示类**（必须独占一行）: Chart.List、TextCard、PhaseCard、TimelineCard、AlertCard、InfluenceCard\r\n\r\n### 布局分配原则\r\n1. 整行展示类组件必须独占一行\r\n2. 基础图表类组件优先考虑两两组合（如 Column+Pie、Column+KeyValueCard、DataCard+KeyValueCard）\r\n3. layoutRow 从 r1 开始递增，rowSize/colSize 统一用 \"auto\"\r\n4. **禁止浪费**：如果某个模块内存在两个或以上的基础图表类组件各自独占一行，视为布局浪费，必须合并到同一行\r\n5. **布局自检**（生成每个模块后必须检查）：该模块内是否有基础图表类组件可以组合？layoutRow 是否从 r1 连续递增？\r\n6. **禁止连续使用同一图表类型**：在同一个模块内（不计 `Title` 组件），相邻的两个组件不得使用相同的 `type`。如果内容需要多个同类型组件，必须在中间插入一个不同类型的组件来间隔，或将内容合并到同一个组件中\r\n   - ❌ 同一模块内第 1 个组件是 TextCard，第 2 个组件也是 TextCard → 违规，应合并为一个 TextCard 或在中间插入其他类型组件\r\n   - ❌ 同一模块内连续两个 Chart.List → 违规，应合并为一个 Chart.List 或用其他组件间隔\r\n   - ✅ TextCard → KeyValueCard → TextCard（中间有不同类型间隔）\r\n\r\n## 完整性规则（强约束）\r\n\r\n**报告的每一个章节都必须在可视化输出中有对应的组件体现，禁止跳过任何章节。**\r\n\r\n1. **定性内容必须可视化**：产品定位、使用场景、竞争分析等非数字内容，应使用 TextCard、KeyValueCard 等组件承载，不得因\"没有数字\"而跳过\r\n2. **章节覆盖与组件数量**：总组件数不得少于原文一级标题（## 级别）数量的 1.5 倍（如 8 个一级标题至少 12 个组件）。每个一级标题至少有一个组件与之对应\r\n\r\n## 组件选型优先级（强约束）\r\n\r\n当内容符合以下条件时，**必须**使用对应组件，禁止用 TextCard/KeyValueCard 替代：\r\n\r\n| 内容特征 | 必须使用的组件 | 判断标准 |\r\n|---------|--------------|---------|\r\n| 有风险提示、问题警示 | AlertCard | 内容包含\"问题 - 后果 - 建议\"结构 |\r\n| 有执行步骤、阶段规划 | PhaseCard | 内容包含\"第一步/第二步\"或\"阶段 1/阶段 2\" |\r\n| 有影响力分级、优先级排序 | InfluenceCard | 内容包含\"高/中/低影响\"或\"优先级 1/2/3\" |\r\n| 有 3+ 对象的多维度对比 | Chart.List | 内容有 3 个以上对象需要对比多个维度 |\r\n| 有时间节点、里程碑 | TimelineCard | 内容包含具体时间点或时间序列 |\r\n\r\n## 工作流程\r\n\r\n1. **阅读反例约束**（强制前置步骤）: 使用 read_file 工具阅读 `reference/anti-patterns.md` 文件，理解跨组件的通用反例约束。**此步骤不可跳过。**\r\n2. **内部规划**（不输出给用户）: 在内部完成以下规划步骤，**不要将规划过程输出给用户**：\r\n   - 仔细阅读 `${moduleData}`，逐一列出所有一级标题和二级标题，形成章节清单\r\n   - 识别报告核心主体，规划第一个模块的 KeyValueCard 内容\r\n   - 为每个章节选择最合适的组件类型，确保不违反\"禁止连续使用同一图表类型\"约束\r\n   - 逐一对照章节清单，确认覆盖率和组件数量满足要求\r\n   - 按布局分配原则执行布局规划\r\n3. **生成输出**: **最终只输出被 ` ```seller-report ... ``` ` 包裹的单个 JSON 对象**，不输出任何分析过程、章节清单、规划说明等中间内容。用户看到的应该只有这一个 ` ```seller-report ` 代码块。\r\n\r\n## 重要约束\r\n\r\n- 内容严格来自报告数据，禁止捏造数据\r\n- 对于表现不佳的数据，避免\"立即暂停\"\"彻底下架\"\"完全停止\"等极端措辞，采用\"诊断—优化—再决策\"的渐进式策略\r\n- 如果报告数据未提供有效信息，直接返回\"暂无内容\"\r\n- **禁止裸数字**（全局约束，适用于所有组件）：任何展示给用户的数值都必须附带含义标注，让用户无需上下文即可理解该数值代表什么。具体要求：\r\n  - 数值必须包含单位或含义前缀/后缀（如\"销量倍数 ×2.1\"而非\"×2.1\"，\"毛利率 35%\"而非\"35%\"）\r\n  - 如果字段本身的 key/label 已经明确了含义（如 `\"desc\": \"毛利率\", \"value\": \"35%\"`），则 value 中无需重复标注\r\n  - 但如果数值出现在缺乏语义上下文的字段中（如 TimelineCard 的 `target`、DataCard 的 `value`），必须在数值中内嵌含义\r\n  - ❌ `\"target\": \"×2.1\"` ← 无法理解 2.1 是什么的倍数\r\n  - ✅ `\"target\": \"搜索量×2.1\"` 或 `\"target\": \"销量增长2.1倍\"`\r\n  - ❌ `\"value\": \"9500\"` ← 不知道 9500 是什么\r\n  - ✅ `\"value\": \"9500次曝光\"` 或配合 `\"desc\": \"曝光量\"` 使用\r\n\r\n## 输出前自查清单（强约束）\r\n\r\n在输出 ` ```seller-report``` ` 代码块之前，**必须**在内部逐项完成以下自查，全部通过后方可输出：\r\n\r\n| 序号 | 自查项 | 对应规则 |\r\n|------|--------|---------|\r\n| 1 | 是否至少输出了 1 个模块？ | 完整性规则 |\r\n| 2 | 每个模块的第一个组件是否是 `Title` 组件？ | 分模块规则 §2 |\r\n| 3 | 总组件数（不含 Title）是否 ≥ 一级标题数 × 1.5？ | 完整性规则 |\r\n| 4 | 是否有章节被完全跳过、无任何组件对应？ | 完整性规则 |\r\n| 5 | 有风险提示的内容是否使用了 AlertCard？有执行步骤的是否使用了 PhaseCard？有影响力分级的是否使用了 InfluenceCard？ | 组件选型优先级 |\r\n| 6 | 同一模块内是否存在相邻两个组件使用相同 `type` 的情况？ | 禁止连续使用同一图表类型 |\r\n| 7 | 是否存在基础图表类组件可以两两组合却各自独占一行的布局浪费？ | 布局分配原则 §4 |\r\n| 8 | 每个模块的 `layoutRow` 是否从 `r1` 独立编号并连续递增？ | 分模块规则 §4 |\r\n| 9 | 所有数值是否都附带含义标注（无裸数字）？ | 禁止裸数字 |\r\n| 10 | JSON 是否合法（无注释、无尾随逗号、`value` 为 number 类型的字段未误用字符串）？ | 分模块规则 §5、图表约束 |\r\n\r\n**如果以上任一检查项未通过，必须修正后再输出。**\n\nFile v1.0.0:skill-card.md\n\n## Description: <br>\n1688 Shop Health Check helps 1688 merchants assess shop health across core metrics, abnormal products, top products, activity effectiveness, customer geography, and top-customer retention. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[1688aiinfra](https://clawhub.ai/user/1688aiinfra) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\n1688 merchants and commerce operators use this skill to run an interactive shop health diagnostic, identify operational risks, and choose focused follow-up analyses for products, traffic, activities, customer geography, and high-value customers. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill requires a 1688 AccessKey for shop analytics. <br>\nMitigation: Use a least-privileged or dedicated key and install only when the credential access is acceptable. <br>\nRisk: Configuration depends on the intended local gateway endpoint. <br>\nMitigation: Verify OPENCLAW_GATEWAY_URL before running configure. <br>\nRisk: Telemetry may be unsuitable for strict privacy environments. <br>\nMitigation: Review and disable telemetry when required by local policy. <br>\nRisk: Optimizer handoff cards may trigger downstream optimization workflows. <br>\nMitigation: Treat handoff cards as action requests and confirm downstream optimizer skills separately before use. <br>\n\n\n## Reference(s): <br>\n- [ClawHub Skill Page](https://clawhub.ai/1688aiinfra/1688-shop-health-check) <br>\n- [CLI Commands Reference](artifact/references/cli-commands.md) <br>\n- [Analysis Methodology](artifact/references/analysis-methodology.md) <br>\n- [Interaction Specifications](artifact/references/interaction-specs.md) <br>\n- [Visualization Rules](artifact/references/visualization-rules.md) <br>\n- [Anti-Patterns](artifact/references/anti-patterns.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Analysis, Markdown, JSON, Shell commands, Configuration instructions, Guidance] <br>\n**Output Format:** [Markdown diagnostic reports with seller-report JSON visualization blocks and interactive card payloads; CLI commands return JSON with success, markdown, and data fields.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Read-only analytics commands support diagnostics; configure stores a local 1688 AccessKey configuration.] <br>\n\n## Skill Version(s): <br>\n1.0.0 (source: SKILL.md frontmatter and release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: 1688-shop-health-check Owner: 1688aiinfra Summary: 1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow 1688-shop-health-check 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。 Tags: latest:1.4.0 Ve","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"# 步骤 A：通过自然语言检索接口文档\n# ⚠️ rag_query 仅支持 --query（与店铺无关的纯语义检索），严禁追加 --NEWTON_SHOP_LOGIN_ID，否则报 unrecognized arguments\npython3 {freedomBaseDir}/cli.py rag_query --query \"用户的问题语义\"\n\n# 步骤 B：按检索结果调用对应数据接口（多店铺时 query_shop_data 可追加 --NEWTON_SHOP_LOGIN_ID）\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM \\\n  --api_path \"customer/inquiry/coreIndex\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'"},{"language":"markdown","snippet":"## 店铺健康检查执行计划\n\n**诊断范围**：流量、询盘、成交、商品、客户、广告、风险，共七个维度（成交维度扩充订单履约与买家评价，风险维度专注合规扣分）\n**输出形式**：\n1. 一段结构化总结性结论（含健康等级、核心发现、优先行动）\n2. 一份 HTML 网页数据报告（承载详细数据、图表、各维度分析与行动建议）\n**时间周期**：默认近7天（个别数据只有近30天的，报告里会标注）\n**覆盖店铺**：当前绑定的全部店铺（若只绑定 1 家则为单店）\n\n请在下方卡片中选择要诊断的维度（可多选），或选择\"全面诊断（七维度）\"后点击\"确认\"开始执行；点击\"取消\"则终止流程。"},{"language":"bash","snippet":"# 询盘核心指标\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/coreIndex\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n\n# 询盘趋势（默认返回近 30 天，可直接用于趋势图）\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/coreIndexTrend\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'\n\n# 询盘商品排行\npython3 {freedomBaseDir}/cli.py query_shop_data \\\n  --data_source SYCM --api_path \"customer/inquiry/itemRank\" \\\n  --params '{\"dataType\":\"RECENT_7\",\"device\":\"ALL\"}'"},{"language":"markdown","snippet":"**当前分析店铺：{完整店铺名}（简称：{店铺简称}）**\n\n- **健康等级**：健康 / 基本稳定 / 存在风险 / 明显承压\n- **核心发现**：\n  1. {发现 1，附关键数据}\n  2. {发现 2，附关键数据}\n  3. {发现 3，可选}\n- **优先行动建议**：\n  - **高**：{动作 1}（涉及{店铺/商品/渠道}）\n  - **中**：{动作 2}（涉及{店铺/商品/渠道}）\n  - **低**：{动作 3}（涉及{店铺/商品/渠道}）"},{"language":"markdown","snippet":"### {店铺简称 A}\n\n**当前分析店铺：{完整店铺名 A}**\n\n- **健康等级**：{健康 / 基本稳定 / 存在风险 / 明显承压}\n- **核心发现**：\n  1. {发现 1，附关键数据}\n  2. {发现 2，附关键数据}\n- **优先行动建议**：\n  - **高**：{动作 1}\n  - **中**：{动作 2}\n  - **低**：{动作 3}\n\n### {店铺简称 B}\n\n**当前分析店铺：{完整店铺名 B}**\n\n- **健康等级**：{...}\n- **核心发现**：\n  1. {...}\n  2. {...}\n- **优先行动建议**：\n  - **高**：{...}\n  - **中**：{...}\n  - **低**：{...}\n\n### 跨店对比结论\n\n- **健康度排序**：{店铺简称} > {店铺简称} > {店铺简称}（依据：{核心指标/健康等级}）\n- **共性风险**：{各店共同存在的问题，如流量结构单一、新客乏力等}\n- **资源倾斜建议**：{建议重点投入/优先优化的店铺或方向}"},{"language":"markdown","snippet":"### 阿里巴巴\n\n**当前分析店铺：阿里巴巴（中国）网络技术有限公司**\n\n- **健康等级**：存在风险\n- **核心发现**：\n  1. 近 7 天支付金额约 ¥28.0 万，环比增长 +31.0%，但支付转化率、访客数均低于同行同层均值，评级为\"略低\"。\n  2. 增长主要由老客复购驱动，新客获取乏力；广告渠道几乎无贡献，搜索流量占比过高，结构单一。\n- **优先行动建议**：\n  - **高**：优先优化搜索进店商品的详情页与主图，提升转化率。\n  - **中**：补充推荐/活动流量渠道，降低对搜索的依赖。\n  - **低**：建立新客专属权益，改善新老客结构。"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: 1688-shop-health-check\nversion: 1.0.0\ndescription: |\n  1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。\n  本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。\nmetadata:\n  interactions:\n    - name: confirm_execution_plan\n      type: card\n      selectionType: requirement\n      description: 在用户输入店铺健康检查请求后，输出执行计划（含输出形式、时间周期等）并以卡片形式展示 8 个可选项供用户选择诊断维度。前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为\"全面诊断（七维度）\"。用户可多选维度，选择\"全面诊断（七维度）\"时覆盖个体选择，诊断全部七维度。用户选择后点击\"确认\"开始诊断，点击\"取消\"则终止流程\n      required_data:\n        questions: |\n          问题列表（Array<Object>），仅含一项必填多选项：\n          - question (string): 引导用户选择诊断维度的问题文案\n          - options (Array<string>): 固定 8 项，前 7 项为七维度名称（\"流量\"、\"询盘\"、\"成交\"、\"商品\"、\"客户\"、\"广告\"、\"风险\"），第 8 项为\"全面诊断（七维度）\"\n          - allowMultiple (bool): 固定 true\n          - required (bool): 固定 true（至少选择 1 项）\n          卡片默认提供\"确认\"与\"取消\"两个按钮：\n          - 选择维度后点击\"确认\"：按所选维度开始诊断\n          - 点击\"取消\"：终止流程，不执行任何诊断\n    - name: select_action_items\n      type: card\n      selectionType: requirement\n      description: 在店铺健康检查总结性结论与 HTML 报告输出后，根据本次体检得出的优先行动建议（按优先级取最高 3 条），并在行动项之后按条件追加一条定时任务选项（must-check），向用户展示可多选的行动项卡片；用户勾选后点击\"确认\"，Agent 按选中项继续执行对应优化动作或为用户设置并开启定时体检任务，点击\"取消\"或不选择任何项则结束本次体检流程\n      required_data:\n        questions: |\n          问题列表（Array<Object>），结构：\n          - question (string): 引导用户选择下一步执行哪些行动项\n          - options (Array<string>): 选项文本数组。前若干条为行动项（最多 3 条，按优先级从高到低排列，每条包含行动概要、所属店铺简称及紧急程度）；最后按条件追加一条定时任务选项，文案固定为 \"⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务\"（must-check：先 Schedule list + 按任务名「店铺健康检查」或固定执行内容双键 OR 命中判断，仅当命中且已开启（enabled:true）时才不追加，未命中或命中但已停用（enabled:false）均追加；不参与优先级排序、不计入 3 条上限）\n          - allowMultiple (bool): 是否允许多选，固定 true\n          - required (bool): 是否必填，固定 true（至少选择 1 项）\n          卡片默认提供\"确认\"与\"取消\"两个按钮：\n          - 点击\"确认\"：Agent 按用户勾选的行动项继续执行对应优化动作；若勾选定时任务选项，则未命中时新建、命中但已停用（enabled:false）时改为重新启用（update），任务名固定「店铺健康检查」，设置完成后向用户确认已开启\n          - 点击\"取消\"：不执行任何项，结束本次体检流程\n---\n\n# 1688-shop-health-check —— 1688 店铺生意体检\n\n**全局语言规则：你的所有输出必须使用中文。包括思考过程、分析内容、过渡说明、最终报告。**\n**禁止**：\"Let me analyze...\"、\"Now I have...\"、\"Zero transactions\"、\"Active, payAmt...\" 等英文句子。\n**正确**：\"接下来分析数据...\"、\"当前店铺无成交\"、\"该店铺活跃，支付金额...\"。\n\n> **执行模型**：店铺体检全流程（意图确认 → 七维度并行取数 → 分析结论 → HTML 报告 → 行动项选择）已由 `workflow/health-check.js` 编排覆盖，命中 workflow whenToUse 时直接执行 workflow，不加载本 SKILL.md。\n> 本 SKILL.md 仅在配置变更类意图（如配置 AK）时加载，Agent 直接按正文规则执行。正文中各维度取数说明、分析方法论、输出格式等内容作为 workflow 子代理（subTask / agent 节点）的参考文档被读取。\n\n## 角色定位\n\n你是一名**1688 店铺经营分析专家 + 数据驱动的经营诊断 Copilot**。\n\n你的工作不是罗列数据，而是基于多接口数据，对 1688 商家店铺做：\n\n- **健康度判断**：店铺整体经营是否健康\n- **风险识别**：异常商品、低效活动、客户结构风险、地域集中风险、询盘转化风险\n- **增长驱动分析**：近期增长或下滑由什么驱动（流量、转化、客单、新客、老客、活动、广告、询盘）\n- **问题定位**：问题集中在哪些商品、活动、客户、地域、渠道上\n- **行动建议**：给出有优先级、可落地、可执行的经营优化动作\n\n你的输出采用**单阶段完整诊断**方式：\n\n1. **意图澄清**：用户提出店铺健康检查请求后，先输出默认执行计划（全面诊断七个维度：流量、询盘、成交、商品、客户、广告、风险）和输出形式（总结性结论 + HTML 网页数据报告），"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn76msg8cwkep3b08z7zffx9fx82p5wj\",\n  \"slug\": \"1688-shop-health-check\",\n  \"version\": \"1.4.0\",\n  \"publishedAt\": 1788437376003\n}"},{"path":"references/analysis-methodology.md","content":"# 分析方法论（单阶段七维度综合诊断）\n\n> 本文档为 `1688-shop-health-check` 提供单阶段、全维度的数据分析方法。诊断范围覆盖流量、询盘、成交、商品、客户、广告、风险七大维度（成交维度涵盖成交、订单履约与买家评价，风险维度专注合规扣分），用于支撑总结性结论与 HTML 数据报告。\n> \n> 使用原则：**先总盘 → 再分维度 → 交叉验证；先问题 → 再原因 → 再行动**。所有结论必须有数据支撑，行动建议按紧急程度（高/中/低）分档。\n\n---\n\n## 一、核心分析原则\n\n1. **总盘优先**：先用 `alibaba.1688.seller.trade.code.index` + `alibaba.1688.get.core.metrics` 判断店铺整体健康度，再下钻分维度。\n2. **维度互补**：流量、询盘、成交、商品、客户、广告、风险七个维度相互解释，单一维度异常必须得到至少另一个维度验证。\n3. **商品/客户/渠道锚定**：经营变化的最终落点通常是具体商品、具体客户群或具体渠道，结论必须能锚定到可干预对象。\n4. **行动导向**：每项发现必须对应可执行动作，并按紧急程度（高/中/低）排序。\n\n---\n\n## 二、总盘健康度判断\n\n**数据来源**：`alibaba.1688.seller.trade.code.index`（总盘指标） + `alibaba.1688.get.core.metrics`（同行对比与评级）\n\n### 2.1 判断维度\n\n| 维度 | 关键指标 | 关注要点 |\n|------|----------|----------|\n| 成交规模 | 支付金额 | 规模与环比变化方向 |\n| 买家规模 | 支付买家数 | 新客获取与老客留存 |\n| 转化效率 | 支付转化率 | 流量承接效率 |\n| 客单表现 | 人均支付金额 | 价格带与连带能力 |\n| 下单承接 | 创建订单金额、创建订单买家数、下单到支付转化率 | 下单→支付漏斗 |\n| 新老客结构 | 新支付买家数、老支付买家数、老买家支付金额 | 增长可持续性 |\n| 成交质量 | 退款成功金额 | 履约与描述风险 |\n\n### 2.2 健康等级判定\n\n| 等级 | 判断条件 |\n|------|----------|\n| **健康** | 核心指标稳定或向好，无明显恶化项 |\n| **基本稳定** | 多数指标稳定，个别指标小幅波动且非关键路径 |\n| **存在风险** | 1-2 个核心指标明显恶化（如转化率/支付金额双跌） |\n| **明显承压** | 多个核心指标同时恶化，新老客 / 退款 / 转化等结构性问题并存 |\n\n---\n\n## 三、同行对比分析\n\n**数据来源**：`alibaba.1688.get.core.metrics`\n\n| 维度 | 判断方式 |\n|------|----------|\n| 整体达标率 | 评级为\"优秀\"的指标数量 vs \"略低\"/\"极低\"的指标数量 |\n| 关键指标达标率 | 支付金额、支付买家数、支付转化率等核心指标的评级 |\n| 趋势对比同行 | 本店变化率 vs 同行平均变化率 / 同行优秀变化率 |\n| 行业地位 | 基于同行对比综合判断店铺在行业中的位置 |\n\n### 评级含义\n\n| 评级 | 含义 |\n|------|------|\n| 优秀 | 本店数值显著高于同行同层均值 |\n| 持平 | 本店数值与同行同层均值接近 |\n| 略低 | 本店数值低于同行同层均值 |\n| 极低 | 本店数值远低于同行同层均值 |\n\n---\n\n## 四、流量维度分析方法论\n\n**数据来源**：\n- 内置命令：`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`\n- 补充接口（`1688-shop-freedom-query-data`）：`flow/ovralShopFlowSource/overview`、`portal/flowBoard/overview` 等\n\n### 4.1 流量趋势分析（`alibaba.1688.get.traffic.trend`）\n\n| 判断维度 | 说明 |\n|----------|------|\n| 整体趋势 | 近 7 天 / 近 30 天 uv/pv 的整体走向（上升/下降/波动） |\n| 异常波动 | 单日 uv/pv 突然大幅下跌或上涨的日期 |\n| UVCTR 趋势 | UV 点击率变化，判断流量质量是否稳定 |\n| 波动幅度 | 近 7 天 uv 的标准差或最大/最小值差异 |\n| 与总盘关联 | 流量趋势是否与 `alibaba.1688.seller.trade.code.index` 中的 `payByrCnt` 变化一致 |\n\n**结论分类**：\n\n| 结论 | 特征 |\n|------|------|\n| 流量稳定 | uv/pv 趋势平稳，无明显波动 |\n| 流量下滑 | 近 7 天 uv 持续下降，需排查流量来源 |\n| 流量波动 | uv 在某些日期突然下跌，需检查是否有活动结束或渠道中断 |\n| 流量回升 | uv 近期开始上升，可能是新活动或渠道生效 |\n| 流量质量下降 | uv 稳定但 UVCTR 下降，说明流量质量降低 |\n\n### 4.2 流量概览与异动判定（`alibaba.1688.get.traffic.overview`）\n\n获取全店 PV/UV/UVCTR 及多期对比（环比/周环比/同比），判断整体流量异动幅度。\n\n**异动判定阈值**：\n\n| 异动幅度 | 等级 | 标记 |\n|----------|------|------|\n| 下跌 > 30% | 严重异常 | 🔴 |\n| 下跌 20%-30% | 显著异常 | 🟠 |\n| 下跌 10%-20% | 中度异常 | 🟡 |\n| 下跌 5%-10% | 轻微波动 | 🟢 |\n| 波动 < ±5% | 正常波动 | ⚪ |\n\n**异动计算公式**：\n```\n环比增长率 = (本期 - 上期) / 上期 × 100%\n周环比增长率 = (本期 - 上周同期) / 上周同期 × 100%\n同比增长率 = (本期 - 去年同期) / 去年同期 × 100%\n```\n\n### 4.3 渠道归因（`alibaba.1688.get.channel.traffic`）\n\n当流量概览发现异常时，调用各渠道流量数据定位主要贡献渠道。\n\n**渠道定义**：\n\n| 渠道 | 定义 | 核心指标 | 特性 |\n|------|------|----------|------|\n| 搜索 | 平台内搜索访问 | "},{"path":"references/cli-commands.md","content":"# CLI 命令详细字段说明\n\n本文档包含 1688-shop-health-check 所有 CLI 命令的详细参数和字段说明。Agent 在调用具体命令前按需读取对应章节。\n\n所有命令均通过 `python3 {baseDir}/cli.py <command> [options]` 调用，输出统一为：\n```json\n{\"success\": bool, \"markdown\": str, \"data\": {...}}\n```\n\n### 通用参数\n\n| 参数 | 必填 | 说明 |\n|------|------|------|\n| `--NEWTON_SHOP_LOGIN_ID` | 否 | 店铺登录ID（值为 `get_bindlist` 返回的对应店铺 `loginId`），用于指定查询的店铺。Agent 单独调用单店铺命令查询非当前 AK 默认店铺时必须传入。不传时使用当前 AK 对应的默认店铺 |\n\n---\n\n## 1. `alibaba.1688.seller.trade.code.index` — 店铺交易核心指标（总盘）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.trade.code.index [--date_type <DATE_TYPE>] [--device <DEVICE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：总盘分析**第一优先级接口**，判断店铺整体健康度、规模、效率、质量、新老客结构和下单到支付衔接情况。\n\n**关键字段**：\n\n| 字段 | 含义 | 用途 |\n|------|------|------|\n| `payAmt` | 支付金额 | 成交规模 |\n| `payByrCnt` | 支付买家数 | 买家规模 |\n| `payRate` | 支付转化率 | 转化效率 |\n| `payMordCnt` | 支付订单数 | 订单规模 |\n| `payItemCnt` | 支付商品款数 | 在售活跃款数 |\n| `payItemQty` | 支付商品数量 | 件数规模 |\n| `perByrAmt` | 人均支付金额 | 客单表现 |\n| `payToOnRate` | 下单到支付转化效率 | 支付承接效率 |\n| `payNewByrCnt` | 新支付买家数 | 拉新能力 |\n| `payOldByrCnt` | 老支付买家数 | 复购能力 |\n| `oldPayByrAmt` | 老买家支付金额 | 老客贡献 |\n| `rfdSucAmt` | 退款成功金额 | 成交质量风险 |\n| `crtOrdAmt` | 创建订单金额 | 下单规模 |\n| `crtByrCnt` | 创建订单买家数 | 下单买家规模 |\n| `crtOrdItmQty` | 创建订单商品数量 | 下单件数 |\n| `cycleCrc` | 环比变化率 | 趋势方向（可能为负） |\n| `cycleCqc` | 环比变化绝对值 | 趋势幅度 |\n\n---\n\n## 2. `alibaba.1688.seller.import.abnormal.offer` — 异常商品（风险定位）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.import.abnormal.offer [--date_type <DATE_TYPE>] [--device <DEVICE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**用途**：风险定位**关键接口**，判断问题主要来自流量、转化还是同时恶化，识别对店铺拖累最大的异常商品。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `reason` | 异常原因，如\"访客下跌\"/\"支付下跌\"/\"访客下跌, 支付下跌\" |\n| `itemId` | 商品ID |\n| `offerTitle` | 商品标题 |\n| `categoryId` | 类目ID |\n| `offerImageUrl` | 商品图 |\n| `link` | 异常详情跳转链接 |\n| `abnormalProduct` | 是否异常商品 |\n| `valueMap.uv.value` | 当前访客数 |\n| `valueMap.uv.cycleCrc` | 访客变化率 |\n| `valueMap.uv.cycleCqc` | 访客变化值 |\n| `valueMap.payAmt.value.value` | 当前支付金额 |\n| `valueMap.payAmt.cycleCrc.value` | 支付金额变化率 |\n| `valueMap.payAmt.cycleCqc.value` | 支付金额变化值 |\n\n---\n\n## 3. `alibaba.1688.seller.top.offer` — 优秀商品榜单（多榜单）\n\n```bash\npython3 {baseDir}/cli.py alibaba.1688.seller.top.offer [--order_by <ORDER_BY>] [--date_type <DATE_TYPE> | --range_type <RANGE_TYPE>] [--device <DEVICE>] [--order <desc|asc>] [--page <N>] [--page_size <N>] [--index_code <INDEX_CODE>] [--NEWTON_SHOP_LOGIN_ID <LOGIN_ID>]\n```\n\n**⚠️ 重要约束**：本接口**必须按需多次调用**，单次只能拉取一种榜单。\n\n**`order_by` 枚举**：\n\n| 值 | 榜单类型 | 用途 |\n|------|----------|------|\n| `payAmt` | 支付榜（默认） | 成交主力商品 |\n| `uv` | 访客榜 | 流量主力商品 |\n| `payNewByrCnt` | 拉新榜 | 拉新主力商品 |\n| `itemMultiByrCnt` | 复购榜 | 复购主力商品 |\n\n**`range_type` 仅支持** `RECENT_7` / `RECENT_30`。\n\n**关键字段**：\n\n| 字段 | 含义 |\n|------|------|\n| `item.offerTitle` / `item.offerId` / `item.detailUrl` / `item.categoryID` | 商品基础信息 |\n| `revealCnt` | 曝光数 |\n| `uv` | 访客数 |\n| `payByrCnt` | 支付买家数 |\n| `payRate` | 支付转化率 |\n| `payAmt` | 支付金额 |\n| `payItemQty` | 支付件数 |\n| `payNewByrCnt` | 新支付买家数 |\n| `payOldByrCnt` | "},{"path":"references/interaction-specs.md","content":"# 交互组件详细规范\n\n本文档定义 1688-shop-health-check Skill 中所有交互组件的具体数据结构与映射规则。\n\n## 1. confirm_execution_plan（Card 组件）\n\n### 组件类型\n\n`type: card`，`selectionType: requirement`\n\n### 业务场景\n\n用户提出店铺健康检查请求后，Agent 输出默认执行计划（含输出形式：总结性结论 + HTML 网页数据报告、时间周期、覆盖店铺），并通过该卡片提供 **8 个可选项**让用户选择要诊断的维度：前 7 项为七维度名称（流量、询盘、成交、商品、客户、广告、风险），第 8 项为\"全面诊断（七维度）\"。卡片**允许多选**。\n\n> **触发条件（免确认短路）**：本卡片仅在**未命中免确认条件**时触发。用户已明确指定具体维度、明确要求全面体检/全面诊断、或明确要求直接开始（含定时任务触发的请求——其 query 即任务执行内容，逐字含七维度名）时，**跳过本卡片**直接进入诊断取数。\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`\n  - 说明: 问题列表，仅含一项必填多选项。\n    - `question` (string): 引导用户选择诊断维度的问题文案\n    - `options` (Array<string>): 固定 8 项 —— 前 7 项为七维度名称（`\"流量\"`、`\"询盘\"`、`\"成交\"`、`\"商品\"`、`\"客户\"`、`\"广告\"`、`\"风险\"`），第 8 项为 `\"全面诊断（七维度）\"`\n    - `allowMultiple` (bool): 固定 `true`\n    - `required` (bool): 固定 `true`（至少选择 1 项）\n  - 卡片默认提供\"确认\"与\"取消\"按钮\n\n### 完整数据示例\n\n```json\n{\n  \"type\": \"card\",\n  \"selectionType\": \"requirement\",\n  \"questions\": [\n    {\n      \"question\": \"请选择要诊断的维度（可多选），或选择\\\"全面诊断（七维度）\\\"执行全部：\",\n      \"options\": [\"流量\", \"询盘\", \"成交\", \"商品\", \"客户\", \"广告\", \"风险\", \"全面诊断（七维度）\"],\n      \"allowMultiple\": true,\n      \"required\": true\n    }\n  ]\n}\n```\n\n### 用户选择结果处理\n\n| 用户操作 | Agent 行为 |\n|----------|-----------|\n| 勾选一个或多个维度并点击\"确认\" | 仅按所选维度执行诊断，按「三、全面诊断维度与数据获取」对所选维度并行取数 |\n| 勾选\"全面诊断（七维度）\"并点击\"确认\" | 覆盖个体选择，执行全部七维度诊断 |\n| 点击\"取消\" / 返回空结果 / 无人作答 / 不勾选任何项 | 统一终止流程，不执行任何诊断，不输出报告，一律以「未收到有效的维度选择，本次体检未执行」口径如实收尾，**严禁表述为\"用户取消\"**；此为符合平台语义的正常终止而非失败，**终止后不得重试、不得自行重新弹卡或重新发起体检**，用户若需体检由其主动重新请求 |\n\n> 勾选\"全面诊断（七维度）\"时优先级最高，会覆盖同时勾选的个别维度。若最终未识别到任何有效维度，按「未收到有效的维度选择」口径终止流程，**不得表述为用户取消**（取消回包形态无法与无人作答可靠区分，不做猜测）。\n\n---\n\n## 2. select_action_items（Card 组件）\n\n### 组件类型\n\n`type: card`，`selectionType: requirement`\n\n### 业务场景\n\n在总结性结论与 HTML 报告输出后，将体检流程**内部已定稿**的最多 3 条优先行动建议直接渲染为可多选行动项，并在行动项之后按条件追加一个「设置定时任务」选项，用户确认后 Agent 直接按选中项继续执行对应优化动作或为用户设置并开启定时体检任务。\n\n> **🤫 静默约束（最高优先级）**：行动项已在体检流程内部完成挑选与排序，构造本卡片时 Agent 唯一需要做的内部判断是「定时任务去重」：调用 `Schedule`（action=list）后**立即按结果渲卡，中间不得输出任何正文**。对用户**只**呈现：最终的 `select_action_items` 卡片、以及用户选择后真实执行的结果与确认语。尤其**禁止**输出「让我先检查定时任务」「根据 Schedule 列表我看到…」「既然定时任务已启用，我不应该追加这个选项」之类的判断过程，也禁止泄露任何内部字段与判据（`id`、`enabled`、`schedule`、`cron`、技能名、触发语等）。用户勾选后的执行环节同理：直接调用对应技能，不要输出「让我看看哪个技能能处理」「行动项映射：xxx → 某技能」之类的匹配过程。\n\n### 数据槽位定义\n\n- **`questions`**:\n  - 类型: `Array<Object>`\n  - 说明: 问题列表，仅含一项，字段如下：\n    - `question` (string): 引导用户选择下一步执行哪些行动项\n    - `options` (Array<string>): 选项文本数组。前若干条为行动项（最多 3 条，按优先级从高到低排列，每条包含行动概要、所属店铺简称及紧急程度）；**最后按条件追加一条定时任务选项**，文案固定为 `⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务`（追加条件见「定时任务推荐选项」）\n    - `allowMultiple` (bool): 固定 `true`，表示可多选\n    - `required` (bool): 固定 `true`，表示至少选择 1 项\n  - 卡片默认提供\"确认\"与\"取消\"按钮\n  - **定时任务选项为条件型（must-check）**：构造卡片前必须先 `Schedule list` 并按「去重匹配规则」判断，未命中或命中但已停用（enabled:false）才追加该选项；即使本次体检没有可执行的行动项，也应触发该卡片并仅展示该定时任务选项（仍需先按规则判断是否展示）\n\n### 定时任务推荐选项（条件型，非行动项驱动）\n\n除由「优先行动建议」生成的行动项外，还需按以下规则判断是否追加「⏰ 需要我自动帮你的店铺全面体检嘛？点击设置定时任务」选项。该选项**不由行动项驱动**，而是根据店铺体检定时任务的存在状态判断：\n\n1. **检查时机（重要）**：定时任务状态检查必须在**总结性结论与 HTML 报告输出之后**、构造卡片时才进行，**绝不可放在输出前**，以免阻塞诊断结论与报告的输出。\n2. **必须先查（must-check）**：构造卡片前**必须先调用 `Schedule`（action=list）拉取全部定时任务**"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow `1688-shop-health-check` 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。 Skill: 1688-shop-health-check Owner: 1688aiinfra Summary: 1688 店铺生意体检。基于流量、询盘、成交、商品、客户、广告、风险七大维度进行全面健康诊断（成交维度覆盖成交、订单履约与买家评价，风险维度专注合规扣分），输出总结性结论 + HTML 网页数据报告，支持多店铺批量体检；报告后可基于优先行动建议展示可多选交互卡片，继续执行对应优化动作，并可按条件引导用户设置每日定时体检任务。 本 Skill 的完整流程（意图确认 → 七维度诊断 → 结论输出 → HTML 报告 → 行动项选择）已由 workflow 1688-shop-health-check 编排覆盖，命中 whenToUse（店铺体检、健康检查、店铺诊断、店铺分析、经营分析、全面诊断、店铺经营状况、体检报告）时直接执行 workflow，不加载本 SKILL.md。 Tags: latest:1.4.0 Ve","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1004,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-12T02:22:26.216Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-15T15:28:27.973Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}