理想汽车 · AI 策略产品 · 决策产品 v2.0 · 2026.08

从「全览驾驶舱」到「本周必赢清单」

基于城市部反馈与面试复盘的产品升级：不是推翻数据基建，而是在 S1–S7 引擎之上增加决策层，把「信息全览」收敛为「本周必须先做的 10 件事」。

砍掉 80% 展示，保留 20% 决策项

V1.0 回答「大盘怎么样」→ V2.0 回答「本周先救谁、做什么、谁负责、何时截止、怎么验证」

决策产品思维四路信号打分 AB 实验验证 config.yaml 可调参

V1.0 vs V2.0 · 一屏看懂产品迭代

V1.0 · 区域经营驾驶舱（数据产品）

2026.07 – 08 初 · 0→1 数据基建

680 单元 × 61 字段宽表
S1–S7 十三模块 + 6 类图表 + 双热力图
35 优质 / 98 流失 / 26 PPL 红 / 106 异常
Narrative 翻译 + P1/P2/P3 分派
成功指标：指标覆盖率、图表完整性

680 行输出 6 类图表全览型

→ 打开公开复刻版零售经营驾驶舱

V2.0 · 本周必赢清单（决策产品）

2026.08 · 面试反馈驱动升级

Top 10 门店 × 1 条动作 × 负责人 × 周五截止
分层级配额：一级3 + 二级4 + 三级3（同层内紧急分排序）
四路信号：流失 + PPL 红 + 异常 + 同店 YoY
复合紧急分排序 + 多信号叠加 ×1.25
飞书卡片：确认 / 分派 · Treatment vs Control AB
成功指标：清单执行率 → 锁单转化率

10 家决策 1 条动作 AB 验证

信息量减少 ~98%，决策密度提升

S 业务场景 · 各版本关键调整全景

产品迭代不是推翻 kpi_engine，而是逐版本精调 S1–S7（及 S8 扩展）的方法论、阈值与交付形态。下表按版本列出调整了哪个 S 场景、改了什么、为什么改——面试可直接引用。

版本	调整的 S 场景	关键变更	变更原因 / 业务价值	代码 / 配置入口
方案 V1→V2 建模方案 pivot	S1S2S3 S4S5S6S7	全部场景方法论从 ML（Logistic/XGBoost）调整为指标引擎 + 规则模型：S2 改 Z-score 加权、S4 改阈值引擎、S7 改三层规则（阈值+环比+Z-score）	DC 是聚合数仓、无客户级明细，ML 黑盒不可解释；规则模型可落地、可调参、城市部能看懂	PLAN_V2_LANDING.md diagnosis.py / scenarios.py
V1.0 W1–2 · 0→1	S1S2S3 S4S5S7	13 模块引擎上线；680 单元×61 字段宽表；S1–S7 首版跑通（S6 暂用客流类占位）	0→1 数据基建：把 10+ 分散看板收敛为一张宽表 + 一套口径	build_wide_table.py run_dashboard.py
V1.1 W3	S2Narrative	S2 健康分权重 v2：试驾→锁单 35%、PPL 转化 25%、开启→试驾 15%、退订损耗 15%；新增 bottleneck 卡点标签（如「试驾→锁单弱」）；Narrative v1.1 把指标翻译成人话	线下对齐：销售最关心「试驾能不能锁单」，而非客流规模；V1 只出分数，店长仍不知做什么	config.yaml → health_factors diagnosis.py · narrative.py
V1.2 W4	S6S7	S6 独立引擎：new_product.py 新车爬坡（渗透率/试驾锁单率 vs 老款）；S7 预警分派 A2：5 类病因（渠道/效率/跟进/数据/综合）→ P1/P2/P3 + 责任角色；config.yaml 外置	i6/L6 新品上市需专项追踪；S7 只报警不分派，一线不知道找谁	new_product.py alert_taxonomy.py · config.yaml
V1.3 W5 初	S1YoYS4	A4 同店 YoY：拉 2025-08 历史，输出 net_lock_yoy / store_status_yoy（同店/新店/关店）；S4 B1：DC 无 24H 跟进权限，改用代理指标；双热力图（城市部×车系 + TOP20 门店×车系）	城市部周会必问「同比怎么样」；同店 vs 新店要分开看，否则误判	yoy.py · fetch_yoy_history.py charts.py · config.yaml → yoy
V1.4 W5 中	S8S2	S8 线索层漏斗：leads_funnel.py 从 PB view2486 接入「线索→排程→试驾→锁单」前段，补全 DC 缺失的线索层；宽表新增 8 列（leads_cnt / leads_to_appoint_rate 等）	原漏斗从「客流→商机」开始，邀约环节是最大瓶颈但 DC 无数据；RPA 每日拉 PB 表补齐	leads_funnel.py 影刀 RPA · funnel_probe_*.json
V1.5 W5 末 · 能力升级	S2S3S1	S2/S3 归因升级：attribution.py 拆解净锁单差距到漏斗各环节（如「试驾→锁单拖累 72%」）；risk_radar.py 四维风险扫描；roi.py 量化省时/挽回/避损	城市部不只问「谁差」，还要问「差在哪一环、差多少、挽回值多少」	attribution.py · risk_radar.py · roi.py · ask.py
V2.0 W6 · 决策产品	S2S4S7YoY	不改 S 场景算法，新增 must_win_list 决策层：消费 S2 流失 + S4 PPL 红 + S7 异常 + YoY 下滑四路信号 → 按一级/二级/三级门店分层取 Top N（3+4+3=10）× 1 动作 × 负责人 × 周五截止；Treatment vs Control AB	城市部反馈「680 行看不过来」+ 大店垄断 Top10；从数据产品升级为分层决策产品	must_win_list.py config.yaml → must_win_list
V2.1 W7+ · 规划中	执行回流	飞书卡片「确认/分派」执行率回流 → 迭代 S4 阈值 & must_win 权重；AB 显著性验证 → 锁单转化率	闭环验证：不只「推清单」，还要证明「清单有效」	feishu_card.py · AB 实验

逐场景 · 版本内演进细节（面试深挖用）

S1 锁单绩效达成

模块：atomic_metrics + derived_metrics · 贯穿 V1.0 → V2.0

V1.0：net_lock_order + perf_target 达成率排名，输出城市部净锁单汇总
V1.3：叠加 A4 同店 YoY（net_lock_yoy / net_lock_yoy_rate），区分同店下滑 vs 新店增量
V1.5：attribution.py 拆解「净锁单较基准低 X%，最大拖累环节是 Y」
V2.0：YoY 下滑成为 must_win 第四路信号（weight_yoy_decline=10，阈值 -20%）

S2 漏斗健康度诊断 ⭐ 调整最多

模块：diagnosis.py → compute_s2_health_score()

方案 pivot：Logistic 意向评分 → Z-score 多因子加权（可解释、可调参）
V1.0：6 因子加权，输出 health_score (0–100) + health_level（优质/中等/流失严重）
V1.1 权重 v2：td_to_lock_rate 30%→35%，ppl_conversion 25%，open_to_td_rate 15%；新增 bottleneck 卡点标签（开启→试驾弱 / 试驾→锁单弱 / 退订损耗高）
V1.1：health_thresholds 中等线 40→45（线下复盘：<45 门店已感「明显跑单」）
V1.4：S8 线索层接入后，漏斗从「客流→商机→试驾→锁单」扩展为「线索→排程→试驾→锁单」完整链路
V1.5：attribution 按环节贡献拆解（如城市部 B：试驾→锁单拖累 72%）
V2.0：health_level=「流失严重」→ must_win 信号 #1（weight_churn=30）

S3 渠道结构诊断

模块：scenarios.py → compute_s3_channel_structure()

方案 pivot：Logistic 回归系数 → BCG 矩阵 + DC attribution 归因工具
V1.0：输出 channel_dominant（如「线下地推(50%)」）、channel_diversity 多样性指数
V1.0：识别单一渠道过度依赖（占比 >70%）门店清单
V1.5：attribution 支持按城市部拆解「客流→商机」环节差距
V1.4 协同：S8 PB 渠道 tag（门店/网店/官方/外展/推荐）比 DC ab_* 更细，用于线索层分渠道

S4 PPL 过程管控 ⭐ 阈值迭代最细

模块：diagnosis.py → compute_s4_ppl_alerts()

方案 pivot：Logistic → 5 条阈值规则引擎（红黄绿灰四级）
V1.0：5 规则 — 无长期跟进 / 无效跟进>15% / 高PPL异常 / 退订24H跟进<60% / 试驾质量<70
V1.2：阈值全部外置 config.yaml → ppl_alert.*，支持 --sensitivity 扫描
V1.3 B1：DC 403 无 lock_24h_follow_rate 权限 → 改用「3 天内锁单-跟进间隔」代理指标
参数校准：follow_intensity 0.30（大盘 ~0.5）；long_follow 0.005（大盘 ~2.1%）；min_ppl 200（避免小店误伤）
V2.0：ppl_alert_level=「红」→ must_win 信号 #2（weight_ppl_red=35，最高权重）；PPL 红 + 池子≥200 → pipeline_bonus +10

S5 车型产销结构

模块：scenarios.py → compute_s5_series_analysis()

V1.0：series_role（主力/重要/边缘/无量）、series_efficiency（🚀效率高/🔻效率低/平均水平）
V1.0：识别「⚠️ 单一主力」风险（单车型锁单占比 >60%）
V1.2：series_weights 写入 config.yaml，支撑目标分摊（i6/L6 各 30%）
V2.0：must_win 按 store×series 单元打分，取得分最高车型为「焦点车型」

S6 新车上市诊断 · V1.2 新增独立场景

模块：new_product.py → compute_s6_new_product()

方案 pivot：双 ML 模型 → 趋势曲线 + 大盘同期对标
V1.0：config 中 S6_customer_flow 仅占位（客流类），未独立成场景
V1.2 重构：独立 new_product.py；追踪 X04(i6)/X13(新L8)/X11(新L9)；输出渗透率/试驾锁单率/爬坡 verdict
实例：新 L6 上市 35 天渗透率 76%；新 L9 渗透率 25% 判定「渗透偏低」
飞书卡片：S6 区块单独展示「🚗 新品爬坡」摘要

S7 异常预警 · 从报警到分派到决策

模块：scenarios.py + alert_taxonomy.py + must_win_list.py

方案 pivot：XGBoost → 三层规则（阈值 + 环比 + Z-score）
V1.0：anomaly_level 红/橙/绿；anomaly_msg（如「净锁单日均环比降 59%」）
V1.2 A2：alert_taxonomy 5 类病因分类 → alert_category + alert_owner + alert_priority (P1/P2/P3)
V1.3：接入 prev_df 环比检测（daily_drop 40% / daily_surge 50% / td_lock_rate_drop 8pt）
参数：zscore_threshold 1.8；daily_drop 0.4（城市部：「掉四成必须当天介入」）
V2.0：异常红/橙 → must_win 信号 #3/#4（weight 25/15）；与 S2/S4 叠加 ×1.25

S8 线索层漏斗 · V1.4 新增扩展场景

模块：leads_funnel.py · 数据源 PB view2486（非 DC）

背景：DC 漏斗从「客流→商机」开始，缺线索层；邀约是最大瓶颈但无数据
V1.4：影刀 RPA 每日拉 PB → funnel_probe_*.json → enrich_wide_with_leads() 左连接宽表
新增 8 列：leads_cnt / leads_appoint_cnt / leads_attempt_cnt / leads_lock_cnt + 4 个转化率
业务结果：识别邀约瓶颈，漏斗邀约率 24% → +1.8pp
简历「5 环节漏斗」：线索→排程→试驾→锁单 + DC 后段 = 完整 5 环节

A4 · YoY 同店同比 · V1.3 横切场景模块：yoy.py · 非独立 S 场景，为 S1/S2 提供对比维度
V1.3：拉 2025-08 历史宽表（512 行）；compute_yoy() 输出 net_lock_yoy / store_status_yoy
分类：同店 / 新店/新增 / 关店/停售 / 无变化 — 避免新店冲量掩盖同店下滑
V2.0：同店 + YoY<-20% → must_win 第四路信号

V2.0 决策层 must_win_list · 消费 S2+S4+S7+YoY模块：must_win_list.py · 第 14 个引擎模块（决策层，不改 S 算法）
核心逻辑：四路信号打分 → 复合紧急分 → store_tier 分层 → 各层 Top N 配额 → 绑定 Narrative 动作 → 10 家 Treatment 输出
分层配额：一级（MTD≥10）3 家 · 二级（5–9）4 家 · 三级（2–4）3 家；Control 组同层抽取
算分示例：流失(+30) + PPL红(+35) + 异常橙(+15) = 80 × 1.25(三信号) + 10(pipeline) = 110.0
AB 设计：Treatment Top10 触达 vs Control 接近分数不触达；主指标清单执行率 → 次指标锁单转化率
产品定位：S 场景回答「哪里有问题」→ must_win 回答「本周先救谁、做什么」

↓ 同一套 kpi_engine 底层，上层 +must_win_list 决策模块 ↓

交付形态对比 · 可切换预览

V1 特点： 城市部综合评分 + 分层级标兵/关注 Top10（一级/二级/三级分榜）+ PPL 红警明细 + 异常预警明细 —— 信息完整，但管理者需自行从 680 行中筛选优先级。

原 V1 单文件门店驾驶舱已从作品集移除（避免公开仓库承载门店级明细）。

公开复刻版零售经营驾驶舱 →

V2 特点： 城市经理打开飞书卡片，5 秒内知道本周先督导哪 10 家、做什么、谁负责。对照组 5 家不发清单，用于 AB 验证。

#	层级	门店（脱敏）	焦点车型	紧急分	信号	本周动作	负责人	截止
1	一级	华南 A 店	全新 L9	110.0	流失 · PPL红 · 异常橙	锁单速度骤降，第一时间盘点 pipeline	店长	周五
2	一级	华南 F 店	理想i8	98.5	PPL红 · YoY降	标杆店 i8 试驾转化复盘，复制至二级店	区域经理	周五
3	一级	华南 G 店	L6	92.0	流失 · 异常橙	新品爬坡专项督导	店长	周五
4	二级	华南 B 店	L6	103.8	流失 · PPL红 · YoY降	PPL 分层跟进，主管抽查低分工单	店长	周五
5	二级	华南 C 店	i6	91.2	流失 · PPL红	优化试驾陪同，24H 内必回访	销售主管	周五
…	二级 4 家 + 三级 3 家 · 各层独立排序 · Control 同层抽取 · 完整 CSV 见引擎输出

#1 算分示例
流失(+30)+PPL红(+35)+异常橙(+15)=80
×1.25(三信号)=100
+10(pipeline)=110.0

飞书卡片

✅ 确认本周清单
📤 分派给店长
追踪执行率

验证指标

主：清单执行率
次：次周锁单转化
Treatment vs Control

参数怎么确定？五步法迭代 · 对应 S 场景

Step 1 · 业务锚点 — 与区域销售负责人对齐：S2 试驾→锁单(35%)、PPL 转化(25%) 最影响 revenue；S4 PPL 跟进强度大盘约 0.5，低于 0.3 视为「几乎没跟」。

Step 2 · 数据分布校准 — 680 单元跑批后看 P25/P50/P75；S4 PPL<200 不触发 R1/R2 避免小店误伤；8/15 快照 26 PPL 红 / 98 流失作为校准基准。

Step 3 · 线下验证 — Top10 发给城市部：「5 秒内知道先督导谁吗？」V1 常答「信息太多」→ V2 消费 S2+S4+S7+YoY 四路信号收敛。误报样本（S7 数据链路问题）降权。

Step 4 · 灵敏度测试 — run_must_win.py --sensitivity 扫描 S4 阈值。8/15 结论：follow_intensity 0.25–0.35 不影响 PPL 红数量 → 红警由「无长期跟进+无效跟进」驱动，非跟进量。

Step 5 · AB 验证 — Treatment(Top10 触达) vs Control(接近分数但不触达)。主指标：清单执行率→锁单转化率。无显著差异则迭代 S4 阈值 / must_win 权重 / S7 分派角色。

关键参数表 · 标注所属 S 场景（config.yaml 可调，改 YAML 不改代码）

参数	所属场景	默认值	确定依据
health_factors.td_to_lock_rate	S2	0.35	销售链路最关心「试驾能不能锁单」
health_factors.ppl_conversion	S2	0.25	商机→锁单反映全漏斗效率
health_thresholds.中等	S2	45	线下复盘：<45 门店已感「明显跑单」
ppl_alert.follow_intensity	S4	0.30	广东大盘 ~0.5，0.3 为「明显偏低」
ppl_alert.long_follow	S4	0.005	大盘 ~2.1%，0.5% 以下视为未做
ppl_alert.min_ppl_for_alert	S4	200	避免小店样本不足误报
anomaly_alert.daily_drop	S7	40%	城市部周会「掉四成必须当天介入」
anomaly_alert.zscore_threshold	S7	1.8	偏离大区均值 >1.8σ 触发异常
yoy_decline_threshold	YoY	-20%	平衡敏感度与误报
top_n_by_tier	V2	一级3/二级4/三级3	避免零售中心垄断 Top10；小店有对标、有配额
weight_ppl_red	V2	35	有 pipeline 可挽回，优先于纯流失
weight_churn	V2	30	S2 流失严重，但无 PPL 池时紧急度略低
multi_hit_multiplier	V2	1.25	S2+S4+S7 三信号叠加门店稳定排 Top3

产品迭代时间线 · 标注 S 场景变更

方案

Pivot

S1–S7
ML→规则模型

→

W1–2

V1.0

680 宽表
S1–S7 首跑

→

V1.1

S2 权重 v2
Narrative

→

V1.2

S6 新车引擎
S7 预警分派

→

V1.3–1.5

YoY · S8 线索
归因/风险/ROI

→

V2.0

must_win
S2+S4+S7+YoY

→

W7+

V2.1

执行率回流
AB 迭代阈值

面试口述 · S 场景迭代 + 产品思维（45 秒）

我的产品经历了三次关键 pivot：第一次是建模方案，S1–S7 全部从 ML 黑盒改为可解释的规则模型——S2 用 Z-score 加权、S4 用阈值引擎、S7 用三层预警，因为 DC 是聚合数仓不是明细数仓。

第二次是逐场景精调：V1.1 调 S2 权重让「试驾→锁单」占 35%；V1.2 把 S6 从占位升级为独立新车引擎、S7 加了 P1/P2/P3 分派；V1.3 加 YoY 同店同比；V1.4 发现 DC 缺线索层，新增 S8 从 PB 补「线索→排程→试驾」，邀约 +1.8pp。

第三次是交付形态 pivot：V2.0 没改 S 算法，而是加了 must_win_list 决策层——消费 S2 流失 + S4 PPL 红 + S7 异常 + YoY 四路信号，从 680 行收敛到 Top 10 × 动作 × 负责人。V1 证明我能建系统，V2 证明我能帮管理者做决策。

📄 完整产品方案 Word 文档（含建模细节 + 参数迭代五步法）

下载产品方案 Word 公开复刻版零售经营驾驶舱返回 V1 说明页