1688店铺诊断【大泽科技·D-Agent·出品】

概述

1688 店铺诊断

通过 Python 直连 1688 内部 API（生意参谋 + 工作台），采集全量数据并生成结构化 Markdown 诊断报告。

触发条件

用户提到以下关键词时使用本 skill：

• 1688 诊断、店铺诊断、诊断报告、店铺体检
• 1688 数据分析、店铺分析
• 1688 诊断报告生成

⚠️ 执行规则（最高优先级）

本 skill 所有操作必须通过 skill 文件夹内预装的脚本完成，禁止自行编写代码。 工作流程中避免输出思考、执行过程、输出目前执行到了哪一步，只输出给用户的登录二维码图片、报告、首次安装后的提示等必要内容

1. 先看目录：每次执行前，先 ls $SKILL_DIR/scripts/ 确认可用脚本
2. 只用脚本，不写代码：数据采集用 fetch_data.py，诊断报告生成用 generate_diagnosis.py，浏览器管理用 start-browser.sh/.ps1，cookie 管理用 cookie_manager.py。禁止在 chat 中拼接 Python/JS 代码来替代脚本，如果脚本运行有问题再考虑阅读并修复问题
3. 脚本路径始终相对于 $SKILL_DIR：cd $SKILL_DIR && python3 scripts/xxx.py（Windows 用 .python3.cmd 替代 python3）
4. 数据来源只能是 API：报告生成脚本只读取 fetch_data.py 产出的 JSON，禁止自行调用 API 或猜测数据
5. API 无法采集的数据在报告中标注 ⚠️ 需手动补充，不猜测、不编造
6. 登录流程仅在用户明确要求时执行。默认直接跳过登录，导航到工作台和生意参谋抓取数据
7. 违反上述规则的操作无效，必须按脚本流程重新执行

⚠️ Windows 浏览器隔离（必读）

Windows 上必须使用独立 Chromium 便携版，与用户日常 Chrome 完全隔离。

executablePath 指向独立 Chromium，user-data-dir 指向独立目录。

⚠️ 三层强制验证（缺一不可）： 1) CDP 9222 端口有响应；2) $USER_DATA/.openclaw_browser_marker 标记文件存在；3) 进程参数 --user-data-dir 指向独立目录（Windows: C:isolated-profiles1688-agent）。任何一层不通过 → 视为非独立 Chromium → 拒绝连接。任何时候都禁止连接用户 Chrome。

v2 起浏览器不再加载插件。浏览器仅负责登录和 cookie 提取，数据采集全部由 Python api_client.py 直连 API 完成。

一、初始化

⚠️ 安装后第一步：必须立刻执行 setup 初始化（仅需一次）

把 skill 复制/解压到目标位置后，第一步就是跑下面的 setup 脚本。不执行会导致后续脚本无法运行：

BASH复制

# Linux
./scripts/setup.sh

# Windows
.scriptssetup.ps1

这一步会自动完成：下载依赖 → 解压独立 Chromium → 创建嵌入式 Python 3.12 → 创建 cookies/cookies.json 等必要目录。幂等——丢丢了可重跑。

完成后才能进入其他步骤（启动浏览器、采集数据、生成报告等）。

路径约定

$SKILL_DIR = 本 SKILL.md 所在目录。Python 脚本内置跨平台支持（platform.system() 自动检测 Linux/Windows）。

1.1 固定路径（主会话和定时任务必须使用相同实例）

关键规则： 1) 启动前先检查 CDP 9222（Linux curl，Windows curl.exe 避免 PowerShell 别名冲突）；2) 绝不 kill 任何进程；3) 用预打包的 Chromium；4) 凭证从 env 文件读取，禁止硬编码。

1.2 脚本目录

1.3 一键初始化（首次部署执行一次）

# Linux
./scripts/setup.sh
# Windows
.scriptssetup.ps1

Chromium 下载源： npmmirror（淘宝，国内 ~4.5MB/s），自动回退 Google 官方源。

1.4 启动浏览器（仅在 CDP 9222 无响应时执行）

./scripts/start-browser.sh         # Linux
.scriptsstart-browser.ps1        # Windows

逻辑：检查端口 → 已运行则三层验证 → 通过跳过/未通过拒绝（不杀进程）→ 未运行则启动独立 Chromium（独立 --user-data-dir + --disable-sync，无 --load-extension）。绝不连接用户 Chrome。

1.5 Cookie 管理方案

按店铺名 + 过期时间管理 cookie，支持多店铺无需重复登录。

cookies/
├── default.json           # 默认店铺 cookie
├── 福州XX公司.json         # 按店铺名命名
└── 广州YY商贸.json         # 每个文件独立存储

每个 cookie 文件结构：

{
  "store_name": "店铺名",
  "company_name": "从API获取的公司名",
  "saved_at": "保存时间ISO",
  "expires_at": 1234567890,
  "expires_at_iso": "过期时间ISO",
  "cookie_count": 42,
  "cookies": {"name1": "value1", "name2": "value2", ...}
}

cookie 管理命令：

# 列出所有已保存的店铺 cookie
python3 scripts/cookie_manager.py
# Windows: cd $SKILL_DIR; .python3.cmd scripts/cookie_manager.py

cookie 有效期： 1688 登录 cookie 约 6 天，保守取 5 天。过期后 fetch_data.py 会自动检测并触发浏览器重新登录。

MTOP token 自动刷新： _m_h5_tk cookie（MTOP 签名 token）有效期较短。api_client.py 检测到 token 过期时会自动从 API 响应中提取新 token 并重试。

• Cookie 按店铺名存储在 $SKILL_DIR/cookies/{店铺名}.json
• 登录成功后自动保存：login.py 登录成功后导航 sycm → 提取 cookie → 用 loginId 作为临时存储名保存；fetch_data.py 采集后自动迁移为实际 companyName
• 多店铺管理：--select 参数按公司名模糊匹配选择

1.6 📦 初始化产物（不随 skill 导出）

setup.ps1 会自动创建以下文件。这些不是 skill 的组成部分，导出 / 打包 / 备份 / 分享时必须排除：

为什么排除： python3.cmd 只是嵌入式 Python（$SKILL_DIRpython3python.exe）的薄启动器 wrapper（%~dp0 自动定位 skill 根目录）。导出时带它只会污染 bundle；用户首次运行 setup 后会自动生成，丢了也能幂等重建。

登录流程（v6：进程永不退出）

⚠️ 登录必须通过脚本执行，禁止自行编写登录代码。

启动命令（单次启动，单进程长轮询）：

cd $SKILL_DIR && python3 scripts/login.py           # Linux
cd $SKILL_DIR; .python3.cmd scriptslogin.py       # Windows
# 限时（默认无限）
cd $SKILL_DIR && python3 scripts/login.py --max-time 1800

⚡ OpenClaw exec 参数： background=true, timeout=0或留空。错误示例： timeout=30, yieldMs=20000（进程被立刻杀死）。

⛔ v6 硬约束：

1. 进程永不退出：v6 起 login.py 内部循环 "等待 → 超时 → 自动 refresh → 再等待"，除非登录成功或达到 --max-time 上限，绝不 sys.exit。模型侧只需 exec 一次 + 后续多次 poll，无需循环 re-exec。
2. --wait-timeout 默认 100s，硬区间 90s–110s（脚本双向钳制）。1688 服务端二维码静态有效期约 120s，100±10s 是安全刷新窗口。
3. --max-time 默认 0=无限。仅在用户明确说"限时"时才设。

输出标记（v6）：

🟦 图片发送铁律（按当前渠道选择发送方式，不可互换）

核心规则： 二维码图片的发送方式严格依赖当前对话的渠道，两种方式不可互换、不可降级：

错误示例：

• 在飞书对话里写 MEDIA:C:...1688_qrcode.png → 用户看不到图，只看到一串路径文本
• 在原生聊天调用 message 工具 → 该工具是飞书专用，原生渠道会失败

同步推送到 FEISHU_CHAT_ID 群聊：

🟦 持续 poll 铁律（必须同一回合内多次轮询）

核心规则： v6 脚本永不退出、模型侧必须在同一回合内反复 process poll 直到 [LOGIN_SUCCESS] 或 [MAX_TIME_REACHED]，禁止"发完图就觉得回合结束"。

执行清单：

1. exec 启动 login.py（background=true, timeout=0或留空）
2. process poll 检测到 [QR_UPDATED] → 按"图片发送铁律"发图（原生 MEDIA: / 飞书 message），按"群聊同步推送"决定是否再推 FEISHU_CHAT_ID
3. process poll（timeout=30000）→ 检查返回：
   • 新 [QR_UPDATED]：回到第 2 步重新发图
   • [LOGIN_SUCCESS]：成功通知，按用户要求继续
   • [MAX_TIME_REACHED]：报告状态，问用户"续 / 重新发起"
   • 只有轮询心跳（等待登录中... Ns / 100s）：继续 process poll，再等 30s
4. 重复第 3 步直到终止标记出现
5. 登录成功前禁止标 In Progress 完成、禁止说"已完成"/"我先等一下"
6. 提供二维码图片给用户后，禁止"等用户指令"或"等用户发消息"或"等你扫码后继续任务"，必须持续 poll 直到 [LOGIN_SUCCESS] 或 [MAX_TIME_REACHED]。

为什么必须同一回合内持续 poll：

• v6 脚本永不退出，中途"等用户指令"会让用户必须发消息你才会继续轮询，但用户能做的就是等你——死锁
• 每个 [QR_UPDATED] 间隔最多 100s。如果不持续 poll，新二维码生成后没人发给用户，用户扫的就是失效码
• process poll 单次 timeout 最大 30s。一个回合内连续调多次即可覆盖（100s 需要 4 次 30s）

⛔ 模型执行规则 v6（必须 100% 遵守）：

┌─────────────────────────────────────────────────────────┐
│  模型登录监控（v6：单进程长轮询 + 渠道分流）             │
│                                                          │
│  1. exec login.py                                        │
│     （background=true，timeout=0 或留空）                │
│  2. process poll → 检测 [QR_UPDATED]                     │
│                                                          │
│     【图片发送铁律】                                      │
│     ├─ 当前渠道 != "feishu"（原生聊天）                  │
│     │   → 最终回复用 MEDIA:<绝对路径> 单独一行附图        │
│     └─ 当前渠道 == "feishu"（飞书聊天）                  │
│         → 调 message 工具发图（必须；禁止 MEDIA:）        │
│                                                          │
│     【群聊同步推送】                                      │
│     ├─ 当前聊天 == FEISHU_CHAT_ID → 跳过                 │
│     └─ 当前聊天 != FEISHU_CHAT_ID → message 推群聊        │
│                                                          │
│  3. process poll（30s/次）→ 检查                          │
│     ├─ 新 [QR_UPDATED]：回到第 2 步                       │
│     ├─ [LOGIN_SUCCESS]：成功通知，按要求继续             │
│     ├─ [MAX_TIME_REACHED]：报告状态，问用户下一步         │
│     └─ 只有心跳日志：继续 process poll（不要等用户）      │
│  4. 终止条件出现前，禁止标完成、禁止说"已完成"            │
└─────────────────────────────────────────────────────────┘

⛔ 禁止行为清单（违反 → 流程无效）：

底层原理（为何这样设计）：

• 进程永不退出 + [QR_UPDATED] 多次触发 = 模型只需 poll 一次，"提前结束"在物理上不可能
• 渠道-发送方式铁律：原生聊天用 MEDIA:（最终回复附图）；飞书渠道用 message 工具。这两种方式不可互换：MEDIA: 在飞书渠道显示为纯文本路径，不会渲染为图片附件（实测已确认）；message 工具是飞书专用通道，原生聊天用会失败
• 持续 poll 铁律：v6 脚本永不退出，如果模型发完图就停，用户必须发消息你才会继续轮询，但用户能做的就是等——形成死锁。每个 [QR_UPDATED] 间隔最多 100s，必须同一回合内连续 process poll（≤30s/次）才能把新二维码及时发给用户，否则用户扫的永远是过期码
• 双发铁律把"推送飞书群聊"和"推送当前聊天"绑成同一触发条件，模型无法遗漏

脚本执行流程（v6 循环版）：

首次准备：检查浏览器 → 清Cookie+导航+切换扫码登录+截码 → 输出首次 [QR_UPDATED]
主循环（永不退出）：
  等待 wait_timeout 秒（每秒检查 URL，跳 work.1688.com 即登录成功）
  登录成功 → [LOGIN_SUCCESS] → sys.exit(0)
  单次超时 → [TIMEOUT]（不退出）
  检查 max-time：超出 → [MAX_TIME_REACHED] → sys.exit(1)；未超 → refresh + 输出新 [QR_UPDATED] → 回到等待

参数：

⚠️ 为什么 wait_timeout 不能自由设： 1688 二维码静态有效期约 120s。太大（>120s）→ 用户扫到失效码；太小（<60s）→ 频繁 reload + 增加风控概率。90–110s 留 10–30s 给"打开 App → 扫码 → 确认"链路。

二、数据采集与诊断生成流程

Step 1：采集数据（API）

cd $SKILL_DIR; ./python3.cmd scripts/fetch_data.py $env:TEMP/1688_raw_data.json --select "店铺名"

自动：检查cookie → 有效直接用 → 无效则启动浏览器→扫码→提取cookie→Python直连API采集→保存JSON。覆盖：生意参谋 10组API + 工作台 MTOP + winport 旺铺 + 新品成长。

Step 2：CDP DOM 提取（补齐页面渲染数据）

前提：浏览器已运行（start-browser.ps1）

cd $SKILL_DIR; ./python3.cmd scripts/cdp_extract.py $env:TEMP/1688_raw_data.json

自动提取并注入 JSON：

• 客户经营身份分布（sycm /ms/customer/profile recent90，DOM.querySelector）
• 频道配置（work.1688.com 侧边栏 needApplyPerm）
• 店铺基础数据（shop.1688.com 成立时间/回头率/粉丝数）
• 营销状态（营销概览页 + sycm adUv 推断）

Step 3：数据编译 + 大模型按模板生成

cd $SKILL_DIR; ./python3.cmd scripts/compile_report_data.py $env:TEMP/1688_raw_data.json

此命令将原始 JSON 编译为结构化指标 JSON。大模型读取后，严格按下方 报告模板 生成 Markdown 报告。

重要： 报告中的策略分析、结论、建议由大模型根据数据动态撰写，不在 Python 中硬编码。Python 仅负责数据提取与指标计算。

报告默认输出到 $SKILL_DIR/1688_diagnosis_{店铺名}.md。

⚠️ 报告写入后必须运行 UTF-8 完整性检查：

cd $SKILL_DIR; ./python3.cmd scripts/check_utf8.py 1688_diagnosis_{店铺名}.md

退出码 1 表示存在 ufffd 替换字符（多字节截断），必须用 Edit 工具逐行修复后再推进。

Step 4：模型补充诊断

报告生成后，模型可：

1. 审阅报告内容，确认无空值/乱码
2. 补充手动数据（入驻时间、粉丝数、L等级、客户经营身份分布等）
3. 在 ## 七、诊断建议 基础上深化分析

Step 5：生成 HTML 版本

.md 报告（含 Step 4 手动补充）定稿后，必须同步产出同名 .html 供浏览器查看 / 分享 / 打印：

cd $SKILL_DIR; ./python3.cmd scripts/md_to_html.py 1688_diagnosis_{店铺名}.md

输出：1688_diagnosis_{店铺名}.html（同目录，自动以 .html 后缀生成）。

特性：

• 数据源和处理方式不变——只读已生成的 .md，做格式转换
• 1 参数模式：自动从 .md 推导同名 .html（主流程推荐）
• 2 参数模式：可指定不同输出路径
• --title "..." 可自定义页面 title（默认从 h1 提取 + 副标）
• 样式：响应式 / 打印友好 / 表格列分割线 / h1 深色渐变 + 橙色装饰线

⚠️ 报告交付前必须同时存在 .md 和 .html 两份产物。 任何 .md 改动（含 Step 4 补充）后重跑本步骤重生成 .html。

⛔ 报告模板（强制格式，必须逐字遵守）

⛔ 格式铁律：以下模板是唯一合法格式。模型必须严格按此结构生成报告，不得增减章节、改变标题层级、修改表格列名、添加装饰性元素。 数据从编译 JSON 取值；分析/结论/建议由大模型根据数据动态撰写。报告只输出数据和结论，不输出诊断日期、元数据、装饰性分隔线。

必须遵守的格式规则

1. 标题结构： # 公司名 → ## 1688店铺深度诊断报告 → ## 为什么这份诊断值得你认真看完？
2. 章节标题： 每个章节用 ## 0X 标题，下一行必须是 *副标题*（斜体，独立一行）
3. 表格列： 表头不含 emoji 图标，严重程度用文字（如 🔴 高、🔴 极高、🟡 中高），不用 🔴🔴🟡 这种堆积写法
4. 结论格式： 每章诊断表后必须有 **核心结论：** 加粗段落
5. 提示框： > ✅ **关键原则：** ...、> ⚠️ **反面警示：** ...、> 💡 **关键提醒：** ...、> ✅ **时间轴总览：** ...
6. 禁止装饰： 不得在报告中添加 > 诊断日期：、> 数据来源：、> 数据周期： 等元数据行；不得添加任何 emoji 装饰或额外分隔线
7. 总结格式： ## 总结 → ### 核心框架：[副标题] → 表格 → 1 段总结文字
8. 行动格式： ## 立即可执行的3个行动 → - **行动1（时间）：** 描述（3 条，带时间标注）
9. 禁止自创章节： 只能有 6 个正文章节 + 总结 + 行动，不得添加"参考文献""附录""说明"等自创章节
10. 禁止输出店铺链接 / 店铺 URL： 报告任何部分都不出现 店铺链接 xxx.1688.com、shop.1688.com/xxx 之类的描述。数据中的 companyUrl / homepageUrl 字段不输出到报告——该字段仅供上传 HTML 时内部使用，不面向用户展示。

严格模板（逐章锁定）

# {公司名}

## 1688店铺深度诊断报告

## 为什么这份诊断值得你认真看完？

{1 段叙事，150—200 字。包含：入驻时间、主营类目、月支付金额、排名、日均UV、广告状态、回头率。从数据中提取关键矛盾，引出分析的5个维度。}


---

## 01 店铺现状与核心问题诊断

| 诊断维度 | 当前数据 | 问题判定 | 严重程度 |
|---|---|---|---|
| 店铺基础 | {入驻时间、粉丝数、回头率、旺铺分} | {判定} | 🔴 高 / 极高 / 🟡 中高 | 低
| 交易规模 | {7天/月支付金额、排名} | {判定} | 同上 |
| 流量规模 | {7天UV、日均UV、展现} | {判定} | 同上 |
| 转化效率 | {支付转化率、跳失率} | {判定} | 同上 |
| 流量结构 | {付费/免费占比、搜索UV} | {判定} | 同上 |
| 商品动销 | {在线/动销数、新品数} | {判定} | 同上 |
| 搜索排名 | {关键词数据情况} | {判定} | 同上 |
| 服务体验 | {新灯塔分、各子项分} | {判定} | 同上 |
| 客户结构 | {客户数、等级、企业自采占比} | {判定} | 同上 |
| 商品指数 | {新品/人气/超级新品数量} | {判定} | 同上 |

**核心结论：** {1 段约 100 字，总结核心矛盾和优势。}


---

## 02 流量5倍提升与付费免费配比方案

**目标：免费流量占比60%，付费流量占比40%**

### 当前流量结构诊断

{1 段，分析各渠道 UV 和占比，指出核心问题。}

### 阶段一（第1—2个月）：破冰期

| 流量类型 | 目标占比 | 日访客目标 | 投放工具 | 预算建议 |
|---|---|---|---|---|
| 免费流量 | 60% | XXX人/日 | 优化方式 | 0元 |
| 付费流量 | 40% | XXX人/日 | 工具列表 | XX元/日 |

### 阶段二（第3—4个月）：放量期

| 流量类型 | 目标占比 | 日访客目标 | 投放工具 | 预算建议 |
|---|---|---|---|---|
| 免费流量 | 60% | XXX人/日 | 优化方式 | 0元 |
| 付费流量 | 40% | XXX人/日 | 工具列表 | XX元/日 |

### 数字营销三大工具具体配置

**1. 全站推店（预算占比40%）**

目的：{1 句}。操作：{具体操作描述}。核心动作：{监控和优化要点}。

**2. 全站销货（预算占比35%）**

目的：{1 句}。操作：{具体操作描述}。核心动作：{监控和优化要点}。

**3. 精准获客（预算占比25%）**

目的：{1 句}。操作：{具体操作描述}。核心动作：{监控和优化要点}。

> ✅ **关键原则：** {1 段总结}


---

## 03 爆品打造与关键词排名操作

### 爆品筛选逻辑

| 候选商品 | 7天展现 | 7天访客 | 点击转化率 | 支付转化率 | 爆品评级 |
|---|---|---|---|---|---|
| {商品名1} | {展现} | {访客} | {点击率} | {支付率} | ⭐⭐⭐⭐⭐ 首推 |
| {商品名2} | ... | ... | ... | ... | ⭐⭐⭐⭐☆ 次推 |
| {商品名3} | ... | ... | ... | ... | ⭐⭐⭐⭐☆ 次推 |
| {商品名4} | ... | ... | ... | ... | ⭐⭐⭐☆☆ 优化后推 |

### 三款爆品确定

- **爆品A（引流款）：** {品名}——{理由和定价策略}。
- **爆品B（利润款）：** {品名}——{理由和定价策略}。
- **爆品C（差异化款��：** {品名}——{理由和定价策略}。

### 关键词排名操作步骤

**步骤1：关键词诊断与筛选**

{操作描述。从当前排名数据出发，筛选核心大词、精准长尾词。}

**步骤2：标题优化（7天一轮）**

标题公式：{公式}。例：{当前店铺类目的具体例子}。确保标题包含3个以上目标关键词。

**步骤3：商品详情页优化**

{详情页前3屏要求、图片优化规则、工厂实力模块。}

**步骤4：销量与评价积累**

{爆品目标、操作方式、评价跟进流程。}

**步骤5：关键词排名监控与迭代**

{监控频率、排名目标、淘汰和迭代规则。}


---

## 04 客户结构优化与精准转化

### 当前客户画像诊断

{1 段，从客户经营身份提取所有身份占比，分析客户层级和B类买家问题。}

### 优化目标

| 优化维度 | 当前状态 | 目标状态 | 执行动作 |
|---|---|---|---|
| {维度1} | {当前} | {目标} | {动作} |
| {维度2} | {当前} | {目标} | {动作} |
| {维度3} | {当前} | {目标} | {动作} |
| {维度4} | {当前} | {目标} | {动作} |

### 客户分层运营SOP

**第一层：潜力买家（预计占比XX%）**

特征：{描述}。动作：{具体触达和转化手段}。目标：{转化率目标}。

**第二层：兴趣买家（预计占比XX%）**

特征：{描述}。动作：{具体运营手段}。目标：{唤醒率目标}。

**第三层：企业自采（目标占比XX%）**

特征：{描述}。动作：{B类客户专属服务}。目标：{积累目标}。

> ⚠️ **反面警示：** {针对当前客户结构的避坑提醒}


---

## 05 商品采购指数4.0提升计划

### 当前商品指数诊断

{1 段，全部新品/人气新品/超级新品数量 + 高分商品列举 + 差距分析。}

### 采购指数4.0+五大维度诊断与提分方案

1688采购指数4.0评分体系由**口碑、价格、服务、品质、商誉**五大维度加权构成。以下逐一诊断并给出提分方案：

| 维度 | 权重 | 当前问题 | 提分操作 |
|---|---|---|---|
| 口碑 | 高 | {问题} | ① {操作1}<br>② {操作2}<br>③ {操作3} |
| 价格 | 高 | {问题} | ① {操作1}<br>② {操作2}<br>③ {操作3} |
| 服务 | 高 | {问题} | ① {操作1}<br>② {操作2}<br>③ {操作3} |
| 品质 | 高 | {问题} | ① {操作1}<br>② {操作2}<br>③ {操作3} |
| 商誉 | 中高 | {问题} | ① {操作1}<br>② {操作2}<br>③ {操作3} |

### 30天五维提升计划

**Week 1：{主题}**

{具体操作。多维度并行描述。}

**Week 2：{主题}**

{具体操作。}

**Week 3：{主题}**

{具体操作。}

**Week 4：{主题}**

{具体操作。}

> 💡 **关键提醒：** {1 段关键提醒}


---

## 06 平台活动与严选/分销/跨境/定制规划

### 自营配置与行业活动

{1 段，当前基础配置状态 + 活动报名建议 + 需完善项。}

### 各项目规划表

| 项目 | 当前状态 | 目标 | 执行动作 |
|---|---|---|---|
| 1688严选 | {状态} | {目标} | {动作} |
| 分销 | {状态} | {目标} | {动作} |
| 跨境 | {状态} | {目标} | {动作} |
| 定制 | {状态} | {目标} | {动作} |

### 各项目详细执行路径

**1688严选（XX天目标：X款）**

入口：{入口路径}。要求：{门槛条件}。操作：{具体操作}。

**分销（XX天目标：X款）**

入口：{入口路径}。操作：{具体操作}。

**跨境（XX天目标：X款）**

入口：{入口路径}。操作：{具体操作}。

**定制（XX天目标：发布定制服务）**

入口：{入口路径}。操作：{具体操作}。

> ✅ **时间轴总览：** {总结各项目时间线}


---

## 总结

### 核心框架：{副标题}

| 阶段 | 时间 | 核心目标 | 核心动作 |
|---|---|---|---|
| {阶段1} | {时间范围} | {目标} | {动作} |
| {阶段2} | {时间范围} | {目标} | {动作} |
| {阶段3} | {时间范围} | {目标} | {动作} |

{1 段总结，核心数据+路径。}


---

## 立即可执行的3个行动

- **行动1（今天做）：** {具体行动描述}
- **行动2（本周做）：** {具体行动描述}
- **行动3（本月做）：** {具体行动描述}

编写原则

1. 数据驱动：所有数字来自编译 JSON，不编造、不猜测。无法获取的数据标注"无数据"而非跳过
2. 类目适配：模板中的举例必须替换为当前店铺的实际主推品和类目词
3. 时间适配：活动月份和日期根据当前日期动态计算。阶段时间也以当前日期为起点
4. 严重程度判定：流量/交易/动销/搜索 4 个维度始终 🔴 极高；其他维度根据数据实际值判断
5. 严禁装饰：不添加 emoji 装饰线、不添加诊断日期元数据行、不添加"参考文献""附录""数据来源"等自创章节
6. ⚠️ 最重要：完成报告后必须将报告文件路径告知用户，自动调用 scripts/html_uploader.exe <unb> 上传 HTML（<unb> 从 cookies/<店铺名>.json 里取），把返回的 URL 用 Markdown 链接形式发给用户（无需再在聊天里输出报告全文）。如上传失败（FAIL: ...），回退原行为：贴报告全文。详见 scripts/USAGE.md Step 6。

推荐文案（Markdown 链接，可点击跳转）：

   ✅ 【店铺名】 1688 诊断报告已生成
   📊 [👉 点击查看完整报告](https://oss.example.com/D-Agent/{日期}/{店铺ID}/{时间戳}.html)
   - 核心结论：店铺"前台空转、后端裸奔"，30 天补供给、60 天补流量、90 天补客户
   - 包含 6 大维度诊断 + 30 天行动计划
   - 本地路径：`1688_diagnosis_【店铺名】.html`

或简短型：

   报告已生成：[【店铺名】 1688 诊断报告](URL)

禁止： 直接贴裸 URL 不带文案、不贴 Markdown 链接、或在聊天里输出报告全文。

API 数据结构

详细字段说明见 references/api_data_structure.md。

生意参谋（sycm）— 10 组 HTTP GET

工作台（work）— 4 个 MTOP POST + 3 个新增数据源

新增：winport 旺铺数据（zhuangxiu.1688.com GET，无签名）

新增：MTOP moduleasyncservice（店铺详情）

新增：MTOP CDT_6keHWT（新品成长/采购指数）

与 1688-alibaba-data-fetcher skill 的关系

故障排查

注意事项

1. 登录流程仅在用户明确要求时执行
2. ⚠️ 交付前必须模型确认：检查报告内容无 undefined/空值/乱码
3. Python 直连 API：数据采集由 api_client.py 直接调用 1688 内部 API，无需浏览器插件
4. cookie 按实际登录账号管理：cookie 文件以 API 返回的 companyName 自动命名，无需手动指定。5 天内免重复登录。多店铺时用 --select 选择
5. 报告文件名含实际账号名：1688_diagnosis_{company_name}.md，便于区分不同店铺
6. Cookie 有效期：约 5 天（保守值），过期后 fetch_data.py 自动检测并触发重新登录
7. MTOP token 自动刷新：_m_h5_tk 过期时 api_client.py 自动从响应中提取新 token 重试
8. Chromium 必须：独立 Chromium 用于登录，Google Chrome 禁止 CDP 连接
9. 登录流程必须在同一回合内反复轮询：v6 脚本永不退出，模型必须连续 process poll 直到 [LOGIN_SUCCESS] 或 [MAX_TIME_REACHED]，中途发完图就停会死锁 + 用户扫到失效码