小鹏汽车综合数据监控 Skill

目标

本 Skill 用于获取小鹏汽车的综合数据，持续集成各市场、各维度的指标。目前已包含以下两大模块（其他数据待补充）：

• 第一部分 · 中国市场交付周期：查询指定小鹏车型各配置版本的交付周期信息（单位：周）。数据来源：小鹏官方商城 API（store.xiaopeng.com）。
• 第二部分 · 欧洲市场纯电动车日更数据：监控 XPENG 在欧洲披露日更数据国家的 BEV 每日上牌/交付销量，输出最近 12 个月的日更明细与环比对比，含工作日口径的当月 vs 上月对比。数据来源：eu-evs.com。

所有网络请求通过 scripts/ 目录下的 Node.js 脚本执行（node <script>.js），不使用 Python、curl 或其他方式。脚本目录：scripts/（相对于 skill 根目录）。

执行前先确定命中功能

收到用户问题后，先根据用户问题和上下文判断需要命中的功能列表，再根据命中的功能列表获取对应的数据。不要无差别地执行所有脚本。

功能命中规则：

功能	命中条件（满足任一即可）
第一部分 · 中国交付周期	用户提到交付周期、交付时间、提车周期、提车时间、等几周、交付等待、订车到提车、中国/国内交付等；或指定了具体车型（如 G6、GX、M03、P7）并询问交付相关话题
第二部分 · 欧洲日更数据	用户提到欧洲销量、欧洲交付、欧洲上牌、海外销量、BEV 注册量、XPeng Europe、EU sales 等；或询问小鹏在海外/欧洲的市场表现

• 如果只命中一个功能，直接执行对应部分的流程。
• 如果同时命中两个功能（如"小鹏国内交付周期和欧洲销量怎么样"），分别执行两个部分的流程，各自独立获取数据后汇总展示。
• 如果无法确定命中哪个功能，使用 AskUserQuestion 询问用户想查看哪类数据。

---

全局执行铁律（适用于所有数据获取）

以下规则优先级最高，凌驾于各部分的具体流程之上，任何阶段都必须遵守：

1. 所有 HTTP 请求一律通过 scripts/ 下的 Node.js 脚本发起，严禁使用 curl、Python、WebFetch、WebSearch、Bash 直接拼接 URL 或任何其他方式直接请求数据源。数据源的反爬策略、登录态、cookie 管理全部封装在脚本内，绕过脚本会导致 bot 检测触发、账号被封或拿到不一致的数据。
2. 脚本失败只能"重跑同一脚本"或"把错误原样上报"，不得改用替代手段。即脚本返回 ERROR|... 或非零退出码时，允许间隔片刻后重跑同一脚本（最多 2~3 次）；重跑仍失败则将错误信息转述给用户并停止，不得临时起意用 curl/WebFetch/Python 重新请求。
3. 瞬时网络错误脚本已内置重试（socket hang up、ECONNRESET、连接超时等会在脚本内部退避重试 3 次），agent 不需要、也不应该对瞬时网络错误自行编排重试逻辑；只有当脚本输出明确的 ERROR|... 时才需要 agent 介入。
4. 判断脚本是否可用，只看 stdout：正常数据、LOGIN_REQUIRED、ERROR|... 都在 stdout。不要因为 stderr 有输出或退出码非零就认定脚本不可用。
5. 所有数据输出必须使用 markdown 表格（强制）：向用户展示任何数值型数据（销量、交付周期、环比、日均、占比等）时，一律用 markdown 表格呈现，禁止用纯文字段落、行内罗列或代码块逐行输出数据。每个表格必须有表头和分隔行。只有非数值的结论性分析（如「④/⑤ 综合分析」的文字洞察）可以用列表或段落。此规则无例外——如果数据适合二维呈现（如「车型 × 月份」），表格是唯一正确形式。

---

第一部分：中国市场交付周期数据

脚本列表

脚本文件	用途	用法
fetch_car_series.js	获取全部车型列表	node fetch_car_series.js
fetch_car_versions.js	获取指定车型的配置版本列表	node fetch_car_versions.js <carSeriesCode>
fetch_delivery_period.js	查询指定配置的交付周期	见下方详细说明

fetch_delivery_period.js 用法

该脚本根据车型类型使用不同的 API 策略：

模式	用法	适用车型	输出格式
Case 1 单版本	node fetch_delivery_period.js <carVersionCode> <carSeriesCode>	GX、M03、P7 系列	OK|min|max|carName
Case 2 单版本	node fetch_delivery_period.js <carVersionCode> <carSeriesCode>	其他车型	OK|min|max|carName
Case 2 批量	node fetch_delivery_period.js <carSeriesCode> --all	其他车型（推荐）	versionCode|OK|min|max|carName（每行一个版本）

脚本自动根据 carSeriesCode 判断使用 Case 1 还是 Case 2。

流程步骤

步骤一：获取全部车型列表

运行 scripts/fetch_car_series.js，解析输出获取全部车型列表。

输出格式（每行一个）：序号|carSeriesCode|carSeriesName

步骤二：识别用户想监控的车型

根据用户的问题识别用户想要监控哪几个（一个或多个）carSeriesCode。匹配时支持用户说车型名称（如"G6"）或完整名称（如"2026款G6"），做模糊匹配。

如果用户没有提供具体车型，或提供的车型名无法匹配，则使用 AskUserQuestion 工具展示全部车型列表并让用户选择：

序号	carSeriesCode	carSeriesName
1	GX	GX
2	M03_2026	M03
...	...	...

请告诉我您想查询哪些车型的交付周期？可以提供车型名称或序号，支持多个（如：1,3,5 或 GX,G7）。

步骤三：获取每个车型的配置版本列表

针对用户选中的每个 carSeriesCode，运行 scripts/fetch_car_versions.js <carSeriesCode>。

输出格式（每行一个）：carVersionCode|carVersionName

步骤四：查询每个配置版本的交付周期

根据车型是否为 GX/M03/P7 系列，使用不同的查询方式。脚本会根据 carSeriesCode 自动判断。

Case 1：GX/M03/P7 系列车型

针对每个 carVersionCode，运行：

node scripts/fetch_delivery_period.js <carVersionCode> <carSeriesCode>

脚本内部逻辑：

1. 请求 listSpecGroupAndSpecList?carVersionSn=${carVersionCode} 获取可选配置规格列表
2. 遍历每个配置组，在 specList 中找到 isDefault=1 的默认规格，收集其 carSpecificationCode
3. 组成排序后的 carSpecificationCode 列表，作为该车型的默认配置规格（列表可以为空，表示无默认选中配置）
4. 请求 listCarInfoList?carVersionSn=${carVersionCode} 获取 SKU 列表
5. 对每个 SKU，提取其 specList 中所有 specCode 组成列表并排序
6. 找到 specCode 列表与默认配置列表完全匹配的 SKU（应唯一）
7. 输出该 SKU 的 minDeliveryPeriod、maxDeliveryPeriod 和 carName

输出格式：OK|minDeliveryPeriod|maxDeliveryPeriod|carName 或 NO_DATA|0|0| 或 ERROR|0|0|

Case 2：其他车型

推荐方式（批量查询）： 运行一次即可获取该车型所有版本的交付周期：

node scripts/fetch_delivery_period.js <carSeriesCode> --all

脚本内部逻辑：

1. 请求 allInOne?carSeriesSn=${carSeriesCode} 获取全部数据
2. 从响应中提取 carSpecGroupVoMap（配置规格）和 carInfoVoMap（SKU 信息），两者均以 carVersionCode 为 key
3. 对每个 carVersionCode：
   • 从 carSpecGroupVoMap 中找到默认配置规格（同 Case 1 的匹配逻辑）
   • 从 carInfoVoMap 中找到匹配的 SKU
   • 输出该版本的交付周期

输出格式（每行一个版本）：carVersionCode|OK|minDeliveryPeriod|maxDeliveryPeriod|carName 或 carVersionCode|NO_DATA|0|0|

备选方式（单版本查询）： 也可按版本逐一查询：

node scripts/fetch_delivery_period.js <carVersionCode> <carSeriesCode>

输出格式同 Case 1：OK|minDeliveryPeriod|maxDeliveryPeriod|carName 或 NO_DATA|0|0| 或 ERROR|0|0|

如何选择 Case

脚本自动判断，规则如下：

• Case 1：carSeriesCode 以 GX、M03、P7（不区分大小写）开头
• Case 2：其他所有车型

步骤五：输出结果

以表格形式输出每个车型下的交付周期。脚本输出中最后一个 | 后的字段即为 carName，必须将完整的 carName 原样输出到表格的"车辆名称"列，不得省略或截断。

车型	配置版本	车辆名称	最短交付周期	最长交付周期
GX	1585 四驱 Max	GX 1585 四驱 Max 仰望绿	4周	6周
GX	665 Max	GX 665 Max 星云白	6周	8周

执行约束

1. 严格遵守流程：按步骤一至步骤五顺序执行，不跳过任何步骤。
2. 单位为周：交付周期单位是周，不要理解为"天"或做任何转换。
3. 默认配置匹配：交付周期取默认配置规格对应 SKU 的数据，不是取 SKU 列表第一个元素。
4. 统一使用 Node.js 脚本：所有请求通过 scripts/ 下的脚本执行，不使用 curl 或 Python。
5. Case 2 优先批量：对于非 GX/M03/P7 车型，优先使用 --all 模式一次获取全部版本，减少 API 请求次数。
6. 容错：某个车型请求失败时，输出该车型查询失败，继续查询其他车型，不中断整个流程。
7. 完整输出 carName：脚本输出的最后一个字段是 carName，输出表格时必须将其完整填入"车辆名称"列，不得省略、截断或简写。

异常处理

异常场景	处理方式
脚本执行报错（socket hang up / 网络错误 / 非零退出码）	先重跑同一脚本 2~3 次（间隔片刻）；仍失败则将错误转述给用户并停止。严禁改用 curl/Python/WebFetch 等替代方式（见「全局执行铁律」）
navigationBar API 请求失败	报告网络错误，无法继续
用户提供的车型不在列表中	提示用户重新选择，展示完整列表
配置页 HTML 中未找到版本信息	该车型输出"暂无配置信息"
listSpecGroupAndSpecList / allInOne API 返回失败	该配置输出"查询失败"，继续其他配置
listCarInfoList API 返回空 data	该配置输出"N/A"
默认配置未匹配到任何 SKU	该配置输出"N/A"
listCarInfoList API 请求失败	该配置输出"查询失败"，继续其他配置

---

第二部分：欧洲市场纯电动车日更数据

数据来源

eu-evs.com（欧洲纯电动车 BEV 注册量数据）。

重要范围说明： ALL_DAILY 视图仅汇总披露日更数据的少数欧洲国家（并非全欧洲）。也就是说，本 Skill 输出的欧洲销量数据只覆盖这些日更国家，不能代表 XPeng 在整个欧洲市场的全貌，也不应直接解读为「欧洲总销量」。

URL 模板：https://eu-evs.com/brands/XPENG/ALL_DAILY/Models-Daily/Year/${year}

页面返回 HTML 表格（id=latestDateTable），包含每个日期各车型的注册量。

脚本列表

脚本文件	用途	用法
xpeng_eu_daily.js	获取最近 12 个月每日各车型交付销量明细，支持 JSON 和 markdown 报告两种输出（--report 含 ①②③④ 四个表格模块）	node xpeng_eu_daily.js [year] [--report] [--email <email> --password <password>]

xpeng_eu_daily.js 说明

获取指定年份的数据，自动找到最新日期，从最新月开始往前取满 12 个月，返回每个月每个日期的各车型明细和日汇总。

用法：

node scripts/xpeng_eu_daily.js [year]                  # 输出 JSON（含 daily/monthly_full/monthly_partial）
node scripts/xpeng_eu_daily.js [year] --report         # 输出 markdown 报告（①②③④ 表格，默认入口）
node scripts/xpeng_eu_daily.js [year] --email <email> --password <password>

• year 可选，默认当前年份
• --report 输出 4 个 markdown 表格模块（① 月度环比 / ② 全月总销量 / ③ 车型明细 / ④ 工作日销量对比），供 LLM 直接展示并附加 ⑤ 综合分析；默认入口优先用此模式

④ 工作日销量对比口径：当前月 vs 上个自然月，范围 1 日 ~ T-2（T = 脚本运行日；最近两天数据可能未上报完整，故截到 T-2）。仅统计工作日（周一~周五），两月按「第 n 个工作日」对齐（跳过周六日，与日历日期无关），输出 2 个表：逐工作日对比表（两月日期、销量、差异）+ 日均汇总表（工作日数、合计、日均、差异与百分比）。缺数据的工作日按 0 处理（节假日/未上报）。

• --email / --password 可选，用于登录 eu-evs.com（见下方登录流程）

跨年处理（自动）：12 个月通常跨越两个自然年（如最新月为 2026-06，则范围为 2025-07 至 2026-06），脚本自动获取所需年份并合并。

登录态与 bot 检测：eu-evs.com 对未登录 / 被判定为 bot / 会话失效的请求会 302 重定向到各种页面（已观察到 /bots、/login、/onlyNamed 等，后续可能继续变化）。由于成功的数据请求固定返回 200，脚本对数据页的任何 302 都视为需要登录，不再枚举重定向目标。处理逻辑如下：

1. 首先尝试直接请求数据页（复用 scripts/.eu-session.json 中已保存的会话）
2. 如果被拦截（302）且未提供凭据，向 stdout 输出 LOGIN_REQUIRED（退出码 2）
3. 如果提供了 --email 和 --password，自动执行登录流程（GET /login 获取 CSRF token → POST /login 提交凭据），登录后自动重试
4. 登录成功后，会话 cookie 保存到 scripts/.eu-session.json，后续运行自动复用
5. 初始取数和跨年取数两个阶段共用同一套拦截处理；已登录过则不重复登录

JSON 模式输出格式（不加 --report 时，stdout 输出单行紧凑 JSON）：

{
  "meta": {
    "latest_date": "YYYY-MM-DD",        // 最新数据日期
    "latest_day": D,                     // 最新日期是几号（PARTIAL 截止日）
    "partial_range": "1-D",              // PARTIAL 对比范围
    "models": ["车型1", ...],            // 基准车型列表（车型名可能含逗号如 "P7,P7I"）
    "months": ["YYYY-MM", ...]           // 12 个月，正序（最旧在前）
  },
  "daily": [                             // 每日明细，每个日期一个对象
    {"date":"YYYY-MM-DD","month":"YYYY-MM","sales":{"车型1":N,...},"total":N},
    ...
  ],
  "monthly_full": [                      // 全月汇总（该月所有有数据日期累加）
    {"month":"YYYY-MM","days":N,"sales":{...},"total":N},
    ...
  ],
  "monthly_partial": [                   // 同范围汇总（仅 day ≤ latest_day，跨月公平对比用）
    {"month":"YYYY-MM","days":N,"range":"1-D","sales":{...},"total":N},
    ...
  ]
}

关键说明：

• 车型用 JSON 键：通过 sales.G6、sales["P7,P7I"] 访问，彻底避免列错位。
• 预汇总已内置：monthly_partial 直接给出每月 1-D 范围累加，做环比无需手动累加；monthly_full 用于全月对比；daily 用于单日/趋势分析。
• 跨年车型对齐：以输入年份的车型列表（meta.models）为基准，跨年数据中缺失车型补 0，新增车型仅当出现在基准列表中才显示。

流程步骤

步骤一：运行 daily 脚本（默认 --report 模式）

默认运行 node scripts/xpeng_eu_daily.js --report（当前年份），直接获取 ①②③④ 四个 markdown 表格模块。如果用户指定了年份（如"查看 2025 年数据"），传入年份参数：node scripts/xpeng_eu_daily.js 2025 --report。

何时用 JSON 模式（不加 --report）：用户有非默认需求（某车型长期趋势、单日异常定位、工作日/周末分析、同比对比等），需要基于 daily / monthly_full 灵活计算时，去掉 --report 运行获取 JSON。

步骤一·补充：处理 LOGIN_REQUIRED（必须检测）

检测规则（强制）：每次运行 xpeng_eu_daily.js 后，必须检查 stdout 是否包含 LOGIN_REQUIRED。这是脚本要求 agent 介入获取凭据的唯一信号，不得当成普通错误直接结束，必须走下面的询问流程。

信号特征：

• 出现在 stdout（不是 stderr，不要只看 stderr 或退出码）
• 退出码为 2（仅作辅助，以 stdout 字符串为准）
• 可能在初始取数阶段或跨年取数阶段出现，任意阶段出现都同样处理

触发场景：eu-evs.com 将数据页请求 302 重定向到其他页面（/bots、/login、/onlyNamed 等），都意味着需要登录。脚本对数据页的任何 302 都视为需要登录。

处理步骤：

1. 使用 AskUserQuestion 询问用户的 eu-evs.com 账号邮箱和密码，并在提示中明确告知用户：
   • 凭据用途与隐私承诺：邮箱和密码仅用于本次登录 eu-evs.com，不会上传到任何第三方或其他服务器，请放心提供。
   • 注册安全建议：如尚未注册，建议在 eu-evs.com 注册时不要使用自己的常用密码，可使用独立的临时密码，避免主密码泄露风险。
2. 如果用户反馈尚未注册，告知用户前往 https://eu-evs.com/register 注册（再次提醒不要使用常用密码），注册完成后提供邮箱和密码
3. 拿到凭据后重新运行脚本，追加 --email <email> --password <password> 参数
4. 登录成功后会话会自动保存（.eu-session.json），后续运行无需再传凭据

兼容兜底：若脚本输出 ERROR|BOT_BLOCKED_year_* 或其他含 BLOCKED 字样的错误，也按 LOGIN_REQUIRED 同样流程处理。

步骤一·补充二：处理其他异常（原样上报）

脚本的所有信号（正常数据、LOGIN_REQUIRED、ERROR|...）统一输出到 stdout。运行脚本后，按以下优先级判断：

1. stdout 包含 LOGIN_REQUIRED → 走上方「处理 LOGIN_REQUIRED」流程，询问账密。
2. stdout 包含 ERROR|LOGIN_FAILED（凭据错误）→ 告知用户邮箱或密码不正确，重新获取凭据后用 --email/--password 重试。
3. stdout 包含其他 ERROR|...（如 ERROR|HTTP_503_year_2026、ERROR|PARSE_FAILED_year_2025、ERROR|no_data_for_year_2025、ERROR|CSRF_TOKEN_NOT_FOUND 等）→ 将 | 后的具体错误信息原样转述给用户，说明当前无法获取数据及原因，不要静默吞掉，也不要自行臆造原因。例如：
   • ERROR|HTTP_503_year_2026 → 「eu-evs.com 返回 503，服务暂时不可用，建议稍后重试」
   • ERROR|PARSE_FAILED_year_2025 → 「2025 年数据页面结构解析失败，数据源可能已变更」
   • ERROR|no_data_for_year_2025 → 「2025 年暂无数据」

判断顺序很重要：先确认是否为 LOGIN_REQUIRED，再确认是否为 LOGIN_FAILED，最后才是其他 ERROR。

脚本返回数据后，按以下规则完成展示与分析。

步骤二：展示 ①②③④ 表格 + 生成 ⑤ 综合分析

①②③④ 表格：原样展示脚本输出

输出必须包含范围说明： 在展示 ①②③④ 表格前后，需明确注明「以下数据仅覆盖披露日更数据的少数欧洲国家，并非 XPeng 全欧洲总销量」。该说明是必填项，不得省略，以免误导用户将数据解读为欧洲整体销量。

--report 模式输出的 4 个 markdown 表格模块（① 月度环比对比 / ② 全月总销量 / ③ 各车型销量明细 / ④ 工作日销量对比）已由脚本预计算并格式化完成，LLM 原样展示即可，不要重新计算或改写表格数据。

脚本内部已处理：

• 环比变化量与百分比的 +/- 符号、四舍五入（保留 1 位小数）、分母为 0 标 N/A
• 当前月"月未结束"的标注
• 车型顺序按 meta.models 固定，0 值保留
• ④ 工作日口径：1 日 ~ T-2 截止、周末剔除、两月第 n 个工作日对齐、缺数据补 0

⑤ 综合分析：LLM 生成 4 条核心洞察

基于 ①②③④ 表格的数据，输出 4 条核心洞察，建议覆盖以下维度：

1. 整体趋势：当前月环比方向与幅度，是否延续上月走势
2. 主力车型：销量最高的 1–2 个车型及其贡献率、环比表现
3. 异动车型：环比变化最显著的车型（新投放放量、大幅增长或下滑）
4. 结构性变化：新车型出现、产品组合迁移、市场份额相关的信号；结合 ④ 工作日日均对比判断真实经营节奏（剔除周末干扰、避开未上报完整的最近两天）

分析必须具体引用数字（如「G6 当前月 535 辆，环比 +19.2%，贡献增量的 X%」），避免空泛描述。

步骤三：按需扩展（JSON 模式）

当用户需求超出默认模块时，运行无 --report 版本获取 JSON，根据下表选择数据层级灵活计算：

需求	使用数据
月度环比（1-D 同范围）	monthly_partial
月度全月对比	monthly_full
某车型长期趋势	monthly_full[].sales.<车型> 或 monthly_partial[].sales.<车型>
同比/季度对比	基于 monthly_full 或 monthly_partial 灵活组合
单日异常定位	daily（含每日每个车型明细）
工作日 vs 周末分析	daily（从 date 推导星期）

执行约束

1. 默认入口用 --report，不要手动计算 ①②③④：--report 模式输出的 4 个表格模块已由脚本完成所有计算与格式化（环比变化量、百分比、车型对齐、"月未结束"标注、工作日对齐），LLM 原样展示即可，不要重新计算或改写表格数据。只有步骤三的按需扩展场景才需要从 JSON 手动计算，此时优先用 monthly_partial/monthly_full，不要从 daily 累加。
2. 按需扩展的输出也必须用表格：从 JSON 手动计算的任何数值结果（单日明细、工作日/周末分析、同比对比等），同样必须以 markdown 表格呈现，禁止行内罗列数值（见「全局执行铁律」第 5 条）。
3. PARTIAL 才是公平对比：最新月尚未结束，必须用「1 号到最新日」的数据与历史月同范围对比（即 monthly_partial），不能用全月数据（monthly_full）对比。
4. 日销量可为 0 或缺失：部分日期（如周末）可能没有数据，daily 数组中不会出现这些日期，这是正常现象；monthly_full/monthly_partial 的 days 字段反映实际有数据的天数。
5. 车型可能变化：不同年份车型列表可能不同（如 2026 年新增 M03、P7+、X9、F30），脚本已自动对齐，展示时以 meta.models 为准。
6. 单位为辆：数值为注册量（辆），不是百分比或份额。
7. 百分比计算：分母为 0 时不计算百分比，标注为 N/A。

异常处理

总则：脚本所有信号（正常数据、LOGIN_REQUIRED、ERROR|...）统一输出到 stdout，agent 只需检查 stdout 即可判断后续动作，无需看 stderr 或退出码。判断优先级：LOGIN_REQUIRED → LOGIN_FAILED → 瞬时网络错误 → 其他 ERROR → 正常数据。遇到任何失败都只能重跑脚本或上报错误，不得改用 curl/Python/WebFetch 等替代方式（见「全局执行铁律」）。

stdout 信号	含义	处理方式
LOGIN_REQUIRED	数据页返回 302（未登录 / bot 拦截 / 会话失效，重定向到 /bots、/login、/onlyNamed 等）	必须使用 AskUserQuestion 询问 eu-evs.com 账号密码；未注册则引导到 https://eu-evs.com/register 注册；拿到凭据后用 --email/--password 重新运行。不得当成错误直接结束
`ERROR	LOGIN_FAILED`	邮箱或密码不正确
`ERROR	BOT_BLOCKED_year_*或其他含BLOCKED`	拦截信号兼容兜底
`ERROR	HTTP_<code>year<y>`	eu-evs.com 返回非预期状态码
`ERROR	PARSE_FAILED_year_<y>`	HTML 表格解析失败
`ERROR	no_data_for_year_<y>`	指定年份无数据
`ERROR	CSRF_TOKEN_NOT_FOUND`	登录页结构变更，取不到 token
`ERROR	LOGIN_HTTP_<code>`	登录接口异常
`ERROR	socket hang up/ERROR	connect ECONNRESET.../ERROR
其他 `ERROR	<msg>`	未列举的异常
会话过期（已保存 session 失效）	脚本会再次输出 LOGIN_REQUIRED	重新走登录流程
最新月无数据（月初第一天）	输出结果可能为空	提示用户数据尚未更新