xPilot v0.2 原型数据实现路径分类（规则 vs LLM）

最后更新：2026-05-01
适用范围：Web (xpilot-prototype.html) + App (App/xpilot-app.html) + 3D 地图 (store.html)

一、目的

xPilot v0.2 Web/App 原型展示的数据当前均为内联 mock。进入工程化阶段前，本文按字段粒度标注每一条展示数据的：

• 类别（A/B/C）：实现路径
• 数据源：上游接口
• 计算方式：A 给数学公式，B/C 指向 §七 详细实现逻辑

便于：

• 数据团队按"计算方式"列直接对接接口、写聚合 SQL
• AI 工程团队按 §七 LLM 调用点清单逐条对接 prompt + 上下文
• 产品/PM 评估每个 LLM 调用点的价值与成本

二、分类框架

2.1 B 类实现逻辑要素

每个 B 类调用点的实现包含 5 要素：

1. 触发条件：何时调（每日预生成 / 实时事件触发 / 用户主动）
2. 输入上下文：从哪些表/字段/时间窗拼装数据 JSON
3. Prompt 模板：System prompt（角色 + 风格约束）+ User prompt（动态数据 + 输出格式要求）
4. 输出格式：受约束的输出（字数/句数/结构），便于前端直接渲染
5. 模型选择：根据上下文长度和质量要求选 Haiku / Sonnet / Opus

→ 详细见 §七 B 类清单（B#1 – B#12）

2.2 C 类实现逻辑要素

每个 C 类位置的实现包含 5 要素：

1. 触发规则：明确阈值或事件（如 oos>8% / 品质问题数>3 / 执行率<70%）
2. 要素提取：规则/CV 提取的结构化字段（如 risk_type、severity、details）
3. LLM 用途：将结构化要素转为自然语言（5-15 字短句 / 标题 / 详细解释）
4. 降级方案：纯规则模板 fallback（LLM 失败时仍有内容显示）
5. 缓存策略：结果建议缓存（输入要素相同则复用，节省 token）

→ 详细见 §七 C 类清单（C1 – C6）

三、数据源清单

来自 ANS_TRUST 元数据声明 + 业务推断：

四、字段级分类（Web 端）

1. 顶部导航

2. 实时仪表盘 — 总部·品类经理（page-battle-hq）

2.1 KPI Bar（5 张可点卡片）

2.2 Leaflet 世界地图

2.3 门店详情弹窗（5 KPI section）

2.4 AI 经营洞察面板（中间）

2.5 右侧 Tab — 品类健康度（8 项）

2.6 右侧 Tab — 促销实时追踪（4 项）

2.7 右侧 Tab — 供应商（5 家）

3. 实时仪表盘 — 店长（page-battle-manager）

3.1 KPI Bar（5 张可点卡片）

3.2 3D 门店地图（store.html iframe）

3.3 AI 经营洞察（10 条品类×区域级）

3.4 右侧 Tab — 品类速览（7 项）

3.5 右侧 Tab — 团队

3.6 右侧 Tab — 任务中心

4. 实时仪表盘 — 店员（page-battle-staff）

4.1 KPI Bar（蔬果区限定 2 张）

4.2 3D 地图

4.3 AI 任务洞察（10 条，店员日常 12 类）

字段结构同 2.4 / 3.3，分类映射相同（result A，cause B → §七 B#3，advice B → §七 B#4）。

4.4 今日成绩（renderTodayScore）

4.5 我的排班（本周 7 天）

5. 任务管理 — 总部（page-tasks-hq）

6. 任务管理 — 店长（page-tasks-manager）

7. 任务管理 — 店员（page-tasks-staff）

8. 任务详情弹窗

9. 陈列管理（page-shelf）

10. AI Agent（page-agent）

10.1 4 Tab × 4 题预设（共 16 题）

10.2 AI 回复

10.3 右侧 3D 地图联动

10.4 商品弹窗（点击 marker）

10.5 自由输入

五、字段级分类（App 端）

A1. 角色选择 / 顶部 / 底部导航

A2. 首页 — 店员

A3. 首页 — 店长

A4. 任务列表

A5. 任务详情（7 类型）

A6. Agent 对话

六、洞察规则引擎

本节定义 §三 数据源 与 §七 LLM 调用点 之间的"模式识别"中间层。规则引擎扫描数据、识别异常，输出标准化要素 JSON，作为 §七 B#3/B#4 等 LLM 调用点的输入契约。

6.1 职责定位

• 不调 LLM：纯规则 / 阈值 / CV 模型
• 输出契约：标准化要素 JSON（schema 见 §六.3），是 §七 B 类调用点的输入
• 触发模式：实时事件驱动 / 周期扫描 / 批量分析

6.2 八大规则类别

6.2.1 阈值规则（threshold）

6.2.2 趋势/对比规则（trend）

6.2.3 预测性规则（forecast）

6.2.4 事件型规则（event — 对应 R3.7 的 7 类 IoT 异常）

6.2.5 时间/周期规则（schedule）

6.2.6 CV/图像规则（vision）

对应 §七 C4 任务核验、B#6 陈列异常解释、B#10 陈列差异分析。

6.2.7 关联性规则（correlation）

6.2.8 业务流程规则（workflow）

6.3 标准化输出 Schema（规则引擎 → LLM 的契约）

每条规则触发后，统一输出如下 JSON，供 §七 B 类调用点直接消费：

{
  "rule_id": "OOS_RATE_HIGH",
  "rule_category": "threshold",
  "anomaly_type": "oos_spike",
  "priority": "high",
  "scope": {
    "stores": ["CQ", "WH"],
    "category": "冷冻",
    "area": "冷冻区"
  },
  "current": {
    "value": 530,
    "unit": "SKU",
    "label": "两店缺货 SKU 合计"
  },
  "baseline": {
    "value": 80,
    "unit": "SKU",
    "label": "日均缺货数"
  },
  "delta": "+562%",
  "related_data": {
    "task_系统": {"补货任务认领率": "38%", "未认领任务数": 12},
    "排班": {"该区域今日在岗": "3/5（缺 2）"},
    "近7日趋势": [80, 85, 90, 120, 180, 320, 530],
    "iot": {"AP-03 信号": "弱 2h"}
  },
  "triggered_at": "2026-05-06T09:23:00Z",
  "downstream_llm_calls": ["B#3", "B#4"]
}

字段说明：

6.4 触发调度策略

6.5 与 §七 LLM 调用点的衔接

优先级映射（与 §四.2.4 colorToPriority(ins.c) 对齐）：

降级策略：当 LLM 调用失败时，B#3/B#4 可降级为按 rule_id + current + baseline 走纯模板渲染（不带归因和具体建议），保证用户始终能看到结构化结论。

七、LLM 调用点详细清单

7.1 B 类调用点（必须 LLM）

B#1 · 实时仪表盘 摘要卡 yest（3 视角）

触发条件：每日凌晨 02:00 批量预生成（3 视角 × N 门店 = 一批调用）；用户主动刷新可重新生成。

输入上下文（昨日 snapshot，按视角缩窄）：

{
  "date": "2026-04-30",
  "view": "battle-hq | battle-manager | battle-staff",
  "scope": "全网 | 门店ID | 个人ID",
  "kpi": {
    "sales_total": 4280000, "sales_target_rate": 0.92,
    "traffic": 12480, "conversion": 0.21, "avg_basket": 156
  },
  "category_top_anomaly": [
    {"name":"乳制品","achievement":0.92,"detail":"酸奶 -15%"},
    {"name":"休闲食品","achievement":1.07}
  ],
  "store_anomaly": [
    {"scope":"华东 23 店","event":"酸奶供应链延迟","duration":"昨日"},
    {"scope":"北京 5 店","event":"进口红酒滞销>14天"}
  ],
  "task_summary": {"total":312,"done":268,"overtime":18}
}

Prompt 模板：

[System] 你是 xPilot 零售智能助手。为指定视角生成昨日要点摘要。
风格：客观、数据驱动、避免空话；优先突出异常事件；按视角侧重不同（HQ 看跨店趋势，店长看本店异常，店员看个人完成）。

[User] 视角：{view}
昨日数据：{json}
请输出 1-2 句摘要，控制在 80 字以内：
- 覆盖 1-2 个核心数据指标 + 2-3 个最重要的异常事件
- 不要带"昨日"等前缀（前端会加）
- 避免使用"很好/不错"等主观词

输出：纯文本段落，存入 daily_summary(date, view, scope, content) 表，前端读缓存。

模型：Claude Haiku 4.5（短输入短输出，每日 ~30-50 调用，成本最优）

B#2 · 实时仪表盘 摘要卡 today（3 视角）

触发条件：每日凌晨 06:00（开店前）首次生成；上午每 2h 刷新；触发大事件（缺货率突增/设备故障）即时重生成。

输入上下文：

{
  "date":"today",
  "view":"...","scope":"...",
  "today_realtime": {"sales_累计":..., "traffic_累计":..., "vs_预测":+0.05},
  "forecast": {"客流高峰":"15:00-17:00","预计客流":68},
  "todo": [
    {"task":"T001 冷冻区补货","priority":"urgent","unclaimed":true},
    {"task":"T002 C 区陈列纠正","status":"doing"}
  ],
  "in_progress_alerts":[{"type":"AP-03 信号弱","duration":"2h"}]
}

Prompt 模板：

[System] 同 B#1，但聚焦"今日要做什么"。
[User] 视角：{view}，今日数据：{json}
输出格式：
- 1 句概览今日重点
- 紧接 ① ② ③ 优先级建议（具体到任务/动作/时间窗）
- 总长 100 字以内

输出：纯文本，含 ①②③ 序号；同样存 daily_summary 表，按 date+view+scope+slot(time bucket) 组合主键。

模型：Claude Haiku 4.5

B#3 · AI 洞察 cause（每条 8-10 条 × 3 视角）

触发条件：洞察规则引擎识别异常 → 触发生成（实时）；缓存键 = (异常事件 ID + 触发时间)；同事件 30 分钟内不重生成。

输入上下文：

{
  "anomaly": {
    "type":"oos_spike","scope":["CQ","WH"],"category":"冷冻",
    "current":"两店缺货 SKU 530 个","baseline":"日均 80 个"
  },
  "related": {
    "task_系统":{"补货任务认领率":"38%","未认领任务数":12},
    "排班":{"该区域今日在岗":"3/5（缺 2）"},
    "近7日趋势":[80,85,90,120,180,320,530],
    "iot":{"AP-03 信号":"弱 2h"}
  }
}

Prompt 模板：

[System] 你是零售归因分析助手。基于触发指标和相关数据，给出 1 句话归因（10-30 字）。
要求：
- 找出最可能的根因（不是症状的复述）
- 明确指向人/系统/流程问题
- 不要给建议（建议在 advice 阶段）

[User] 异常：{json.anomaly}
相关数据：{json.related}
归因：（1 句话）

输出：1 句话，10-30 字。

模型：Claude Sonnet 4.6（归因需要逻辑推理，Haiku 偶有偏差）

频次：估算 3 视角 × 10 条 × 大事件触发 ≈ 30-50 调用/日

B#4 · AI 洞察 advice（同 B#3）

触发条件：cause 生成后立即触发（可串联调用，复用上下文）。

输入上下文：B#3 全部输入 + cause 输出 + 资源池

{
  ...B#3..., "cause": "<B#3 输出>",
  "resources": {
    "可调拨人手":[{"from":"华南","count":2}],
    "可触发流程":["紧急补货令","跨区调拨","直派督导"],
    "历史相似案例":[{"action":"直派督导组","效果":"24h 内恢复"}]
  }
}

Prompt 模板：

[System] 基于归因，给出 1-2 句可执行的具体行动建议。
要求：
- 必须包含数字/对象（如"4 人"/"今日 17:00 前"）
- 优先选可立即触发的流程
- 不要"建议关注"等空话

[User] 归因：{cause}
可用资源：{json.resources}
建议：

输出：1-2 句，明确可执行。

模型：Claude Sonnet 4.6

B#5 · 店员今日成绩 AI 评估卡

触发条件：店员当日交班/打卡下班时触发；或店长查看时按需触发。

输入上下文：

{
  "staff_id":"...","date":"today",
  "tasks":{"done":3,"verified":2,"overtime":0,"avg_response":"22min","peer_avg":"28min"},
  "category_impact":{
    "蔬果区缺货率":{"yesterday":0.048,"today":0.028},
    "蔬果区销售":{"vs_baseline":+8640,"orders_count_delta":+18}
  },
  "store_baseline":{"日均销售":312000}
}

Prompt 模板：

[System] 把店员当日工作贡献"翻译"成对门店的实际经营价值（金额 + 1 句解释）。
要求：
- 金额按 (该员工任务影响范围内的销售提升 / 同类基线) 估算（可用客单价 × 单数变化简化）
- 1-2 句叙述：金额 + 主因 + 数字证据
- 不要谄媚（"你真棒"等），只用数据说话

[User] 数据：{json}
输出格式：
你今天的工作让门店多卖了 ¥XXX · {主因 + 数字证据}

输出：1-2 句，含金额 + 归因 + 数字。

模型：Claude Haiku 4.5

频次：每日每店员 1 次（小型门店 30-50/日）

B#6 · 陈列管理 异常详情解释

触发条件：CV 模型识别陈列异常（diff_score>阈值）→ 用户点击异常货架查看详情时按需生成。

输入上下文：CV 输出的差异要素 + 商品信息

{
  "shelf_id":"SHELF-A4",
  "diff_elements":[
    {"sku":"可口可乐 500ml","plan_pos":"层2-槽3","actual_pos":"层2-槽5","type":"位置偏移"},
    {"sku":"百事可乐 500ml","status":"遮挡促销标签","severity":"high"}
  ],
  "category":"饮料","compliance_score":0.79
}

Prompt 模板：

[System] 把 CV 模型的差异要素转为店员能看懂的人话。
要求：
- 1-2 句，按"哪个商品 + 偏离了什么 + 影响"组织
- 30-60 字
- 不要用"diff_score"等技术词

[User] 差异要素：{json}
解释：

模型：Claude Haiku 4.5

B#7 · AI Agent 自由问答（生产态替换 ANSWERS）

触发条件：用户输入或点击预设问题。

输入上下文：

• 用户输入文本
• 当前页面 / 视角上下文（CTX_PAGE_NAME + 选中组件文本）
• 工具集（tool-use）：query_oos_skus / query_sales / query_promotion / create_task / query_inventory / get_pog

Prompt 模板：

[System] 你是 xPilot 零售智能助手。根据用户问题调用合适工具，整理表格 + 自然语言回答。
工具：{tool_definitions}
回答规范：
- 数据型问题：返回表格 + 1-2 句概述 + 建议操作按钮（tool-use 触发 create_task 等）
- 分析型问题：分点叙述 + 数据支撑
- 必须包含可信度行（数据源/时间窗/样本）

[User] 问题：{user_input}
当前页面：{page_context}
组件上下文：{component_text}（可选）

输出：HTML 表格 + 段落 + 操作按钮（按钮 onclick 调用 tool-use 返回的 action）。

模型：Claude Sonnet 4.6（需要 tool-use + 复杂推理）

频次：用户主动触发，无固定频次

B#8 · App 首页 AI 洞察摘要卡（店员/店长 各 2 段）

触发条件：每日凌晨预生成（同 B#1/B#2 共用上下文）；App 启动时拉取。

输入上下文：B#1/B#2 缩短版（移动端字数限制更严）

Prompt 模板：在 B#1/B#2 基础上加约束：

[追加] 控制在 60 字以内（移动端单卡显示）；不带 ①②③ 序号；用流畅段落叙述。

输出：纯文本 60 字内。

模型：Claude Haiku 4.5

B#9 · App 任务详情 · 补货建议

触发条件：补货任务（type=replenishment）创建时触发；任务详情页打开时拉缓存。

输入上下文：

{
  "sku":"西兰花","shelf":"蔬果区A1",
  "current_stock":8,"backstock":50,
  "sales_history_7d":[12,15,14,18,22,20,16],
  "today_so_far":4,"forecast_today":18
}

Prompt 模板：

[System] 基于销量历史和当前库存，给出补货建议。1 句话，含数字。
[User] 数据：{json}
格式：基于近 7 日销量预测，建议补货 X 箱，预计今日销售约 Y 箱。请在 ZZ:ZZ 前完成。

模型：Claude Haiku 4.5

B#10 · App 任务详情 · 陈列差异分析

触发条件：陈列调整任务（type=display-adj）创建时触发；详情页拉缓存。

输入上下文：CV 比对的双图差异要素（同 B#6）。

Prompt 模板：

[System] 1-2 句描述实际 vs 计划的差异。30-60 字。
[User] 差异要素：{json}

模型：Claude Haiku 4.5（也可考虑 VLM 直接对图）

B#11 · App 任务详情 · AI 洞察任务依据

触发条件：洞察类任务（type=insight）创建时触发；详情页拉缓存。

输入上下文：

{
  "category":"乳制品",
  "trend":{"近7日销售":-12%},
  "shelf_finding":{
    "高毛利产品":"安慕希希腊酸奶","当前位置":"底层",
    "低毛利产品":"伊利纯牛奶","当前位置":"视平线层"
  },
  "data_sources":["销售数据","货架识别 AI"]
}

Prompt 模板：

[System] 把数据现象 + 分析结论组织成 2-3 句洞察依据。
要求：
- 第 1 句陈述数据现象（带数字）
- 第 2 句分析原因（视觉/陈列/位置等）
- 第 3 句给出方向（不要给详细步骤，步骤在 C6 模板）

[User] 数据：{json}

模型：Claude Sonnet 4.6

B#12 · App 任务详情 · 预期效果

触发条件：洞察类任务创建时与 B#11 串联调用。

输入上下文：

{
  "category":"乳制品","action":"陈列调整高毛利至视平线",
  "historical_similar":[
    {"category":"饮料","action":"同类","lift":"+12%"},
    {"category":"零食","action":"同类","lift":"+9%"}
  ]
}

Prompt 模板：

[System] 基于历史相似动作的 lift，给出本次预期效果区间。
要求：
- 输出格式："提升 X 品类销售 A-B%"
- A-B 区间不超过 10 个百分点

[User] 数据：{json}

模型：Claude Haiku 4.5

7.2 C 类调用点（规则/CV 触发 + LLM 润色）

C1 · 品类/促销/供应商 risk 短文本（5 处）

触发规则：

• 品类：health<60 OR oos>8% OR 供应链异常事件存在
• 促销：exec<70% OR stock<30%（积压）OR stock>90%（缺货风险）
• 供应商：onTime<80% OR quality>3 OR costTrend>+3%

要素提取（规则识别后输出）：

{"risk_type":"supply_chain_delay","severity":"high","details":{"category":"乳制品","scope":"华东"}}

LLM 输入 + 用途：

[System] 把风险要素转为 10-15 字简短描述。
[User] 要素：{json}
输出：（10-15 字）

降级方案：纯模板 fallback：{risk_type 中文} · {scope}（如"供应链延迟 · 华东"）

缓存策略：(risk_type + severity + details_hash) 24h 缓存

模型：Claude Haiku 4.5

C2 · 洞察标题文案

触发规则：每条洞察 result 字段已生成时触发（可选 LLM 改写，未触发时纯模板）。

要素提取：从 result 解析关键 token（门店/品类/指标/方向/数值）。

模板（默认即可使用，不调 LLM 也可上线）：

{门店} {品类} {指标} {方向} {数值}
例：重庆/武汉 冷冻区 缺货率 超 15%

LLM 用途（可选）：把模板生成的标题润色更精炼（10-20 字），适合标题位字数限制场景。

降级方案：直接用模板。

模型：Claude Haiku 4.5（仅作为可选优化）

C3 · AI Agent 缺货原因列

触发规则：缺货事件，按规则枚举原因类型：

• stock=0 AND last_replenish_at < 24h ago → "未及时补货"
• stock=0 AND no_inbound_in_3d → "商品没有库存"
• stock>0 AND facing_count<min_facing → "排面不足"
• stock>0 AND POS_count_异常 → "数据异常"

要素：4 类枚举值之一。

LLM 用途（可选）：基于 SKU + 上下文把"未及时补货"润色为"今早补货任务漏派"等更具体表述。

降级方案：直接用 4 类枚举文本。

缓存：(sku + reason_type + day) 缓存。

模型：Claude Haiku 4.5

C4 · 任务系统核验判定 + 异常解释

触发规则：task.status='done' AND evidence_uploaded → CV 模型对比拍照与 POG/计划：

• diff_score < 0.1 → 自动通过（verified）
• diff_score >= 0.1 → 不通过，进入 LLM 解释流程

要素提取：CV 输出 {shelf_diff:[{sku,issue}], compliance_score, evidence_quality}

LLM 用途：

[System] CV 判定核验不通过，请给店员说明原因。
[User] 差异：{json}
输出：1-2 句不通过原因 + 1 句改进建议（30-60 字）

降级方案：直接列差异要素（无叙述）。

模型：Claude Haiku 4.5（VLM 也可考虑）

C5 · 商品弹窗 OOS 空置率

触发规则：用户点击 OOS 类商品 marker 时，从 IoT 摄像头拉最新帧，送入 CV 模型。

要素：CV 输出 empty_ratio（0-1）。

LLM 用途：无（此处仅显示数字 + 百分比，不需 LLM）。

说明：分类为 C 是因为 CV 模型本身是 ML，但本字段不调 LLM。如未来要加叙述（"严重空置，建议立即补货"），则升级为 C 类含 LLM。

C6 · App 陈列调整步骤 / AI 洞察执行步骤

触发规则：陈列调整任务 / 洞察任务创建时，按"差异类型"或"行动类型"查模板库。

模板库示例：

• "位置偏移" → "1. 将商品 A 移至 X 位置 / 2. 拍照存档"
• "陈列层级调整" → "1. 高毛利产品移至视平线 / 2. ... / 3. ..."

LLM 用途（可选）：基于具体 SKU/位置把模板槽位填充并润色（如"将可口可乐 500ml 移至 B2货架第1层正中"）。

降级方案：直接用模板（步骤数固定，槽位规则填充）。

缓存：(action_type + sku + target_position) 缓存。

模型：Claude Haiku 4.5

八、统计与结论

8.1 占比估算

8.2 核心结论

1. 75% 数据是规则类，瓶颈在打通上游 14 类接口，LLM 不是主要工作量。

2. LLM 价值集中在两条主线：

   • 叙述化总结（B#1/B#2/B#5/B#8）：多源数据融合成 1-2 句话。预生成模式（每日凌晨批量），降低延迟和 token。
   • 归因 + 建议（B#3/B#4/B#11/B#12）：xPilot 智能性的核心，必须实时生成，每条独立调用便于并发。

3. C 类的关键决策：

   • 风险短句 / 缺货原因 / 步骤模板（C1/C3/C6）可先用规则模板上线，LLM 作为后续优化。
   • 任务核验（C4）依赖 CV 模型质量，独立工程项目。

4. 生产态 vs 原型态的 gap：

   • 原型 ANSWERS 16 条硬编码 → 生产态 LLM + tool-use（库存查询/任务创建/订货等工具）。
   • 原型 cause/advice mock 文本 → 生产态每条洞察独立 prompt + 上下文打包。

8.3 模型选择建议

8.4 工程优先级建议