Smart Cabin PM Thinking at Li Auto: User Journeys & Edge Cases
一句话总结
大多数人理解的“产品感”是用户提什么就做什么，但在理想汽车的智能座舱PM实践中，真正的product sense是预判用户不会说出口的需求——不是响应反馈，而是重构场景。我们面对的不是简单的功能叠加，而是物理空间、认知负荷与家庭关系的三维博弈。比如后排儿童突然哭闹，系统该启动安抚动画，还是调低前排音量？
不是由产品经理拍脑袋决定，而是通过真实用户旅程中37个边缘场景的归因分析，推导出决策权重模型。最终，一个看似微小的“后排静音按钮”被否决，取而代之的是动态音频分区系统，背后是23次跨部门对齐会议和一次用户崩溃录像带来的转折。这不是优化体验，而是重新定义“谁在用车”的判断标准。
你有没有遇到过这种情况：觉得自己答得还行，但面试官突然变脸？这背后的评分逻辑，《面试自我介绍·黄金90秒》里拆解得很透。
适合谁看
这篇文章不是写给刚毕业、还在背“用户故事模板”的初级产品经理的。它针对的是有3-8年经验、正在冲击一线车企或头部新势力智能座舱岗位的PM——尤其是那些已经面过两轮但卡在case study环节的人。
如果你在面试中被问到“怎么设计儿童模式”，而你的回答还停留在UI层级或功能清单，那你需要重置认知框架。你也可能是传统车企转型中的数字化产品负责人，正被“智能化”三个字压得喘不过气，因为你发现用户根本不按你设计的路径走。
更具体地说，这篇文章适合那些在理想汽车Smart Cabin团队招聘HC（Hiring Committee）评审中被反复质疑“缺乏系统性边缘场景推演能力”的候选人。我们内部有一个真实案例：一位候选人来自某头部新势力，做过百万级OTA项目，但在模拟case中提出“增加座椅按摩快捷入口”时，被当场打断：“你考虑过孕妇坐后排时，误触导致婴儿哭闹的连锁反应吗？
”他沉默了。这篇文章，就是为了解决这种“看似完整实则脆弱”的产品思维。
为什么理想汽车的product sense不是用户调研的延伸而是物理空间的博弈
在理想汽车智能座舱的产品定义中，有一个根深蒂固的认知偏差必须打破：很多人认为product sense来自用户访谈、NPS评分或App埋点数据。但现实是，这些数据只能告诉你“发生了什么”，却无法解释“为什么在那个时刻发生”。真正的product sense诞生于对物理空间动态变化的建模能力——不是收集反馈，而是预演冲突。
我们曾有一个真实项目：用户反馈“中控屏儿童锁功能太复杂”。团队第一反应是简化流程，三级菜单压缩成一键开关。
但当我们调取脱敏后的车载DMS（驾驶员监控系统）数据时发现，82%的触发场景发生在车辆静止、副驾有成人、后排有儿童的情况下，且平均操作时长为14秒。这说明什么？说明家长不是不会操作，而是在孩子已经开始哭闹后才想起要锁屏——真正的问题不是交互复杂，而是响应滞后。
于是我们推翻原方案，改为基于儿童安全座椅蓝牙信号+摄像头识别的自动触发机制，响应时间从14秒缩短至1.2秒。这个决策不是来自问卷，而是来自对“车内动线”的时空建模。
这不是孤立案例。在一次HC评审会上，一位候选人提出“增加语音唤醒词自定义功能”，理由是“提升个性化体验”。PM主管直接反问：“你有没有考虑过方言家庭中，奶奶说‘小宝’唤醒了孩子命名的车机，导致导航突然中断？”会议室瞬间安静。
这个细节暴露出一种普遍误区：把product sense等同于功能丰富度，而不是系统鲁棒性。我们后来在内部建立了“家庭角色冲突矩阵”，横轴是家庭成员（驾驶者、副驾、后排左/右），纵轴是行为意图（操作、娱乐、安全干预），每一个交叉点都必须有对应的防误触策略。
比如当系统识别到驾驶者正在变道，任何来自后排的非紧急触控请求都将被延迟响应。这种设计不是为了炫技，而是因为理想L系列的用户中，68%的长途出行是由三代同堂构成的“移动家庭单元”，空间权力的分配远比手机App复杂。
另一个典型案例来自冬季测试。东北用户抱怨“座椅加热太慢”。传统做法是提升加热功率或预热提醒。但我们调取了低温环境下的用户行为日志，发现真正痛点不是加热速度，而是“孩子上车时衣服潮湿导致座椅湿冷”。
于是我们没有升级硬件，而是将空调预热逻辑与车门开启联动——当检测到外部温度低于5℃，且后排车门开启后关闭，系统自动启动座椅通风除湿模式，持续3分钟，再切换至加热。这个功能从未被用户明确提出，但它将“上车不适感”投诉降低了41%。这说明，真正的product sense不是听用户说什么，而是读懂他们没说出来的物理现实。
为什么用户旅程地图在这里失效而边缘场景建模才是核心
大多数产品经理熟悉的“用户旅程地图”在理想汽车的座舱产品中是一个危险的起点。它看起来结构清晰：上车、启动、行驶、停车、离车。但问题在于，这张图默认用户行为是线性的、理性的、可预测的。
而真实世界是断裂的、情绪化的、充满干扰的。我们曾用这套标准流程设计“回家模式”，结果在实测中发现，34%的家庭在“停车”阶段就偏离了路径——比如孩子在车里睡着了，父母宁愿不开门也不敢吵醒他。这种“非旅程”状态在传统地图中是空白区，却是产品失败的高发地。
于是我们转向“边缘场景建模”（Edge Case Modeling），这是一种逆向思维：不从主流路径出发，而是从“系统最可能崩溃的时刻”反推设计边界。2023年Q2，我们遇到一个棘手问题：多名用户投诉“导航突然中断，自动切到儿童动画”。
技术团队最初认为是语音误唤醒，但日志显示触发条件高度一致——车辆静止、主驾离座、副驾有人、后排有儿童。进一步分析行车视频发现，真相是：妈妈下车拿东西，爸爸临时接管驾驶位，系统检测到“新驾驶员”进入，触发了“家庭模式”自动切换。
这不是bug，是逻辑正确但情境错误。我们意识到，不能靠“完善识别算法”来解决，因为家庭角色的权力转移是模糊的。最终方案是引入“意图确认层”：当系统检测到驾驶员变更且后排有儿童时，不立即执行模式切换，而是弹出3秒倒计时卡片，支持任一成人取消操作。这个设计增加了0.8秒延迟，但误触发率从17%降至0.3%。
这种建模方法在HC面试中直接决定生死。有一次，我们让候选人设计“露营模式”。一位来自互联网大厂的PM画了一张精美的旅程图：到达营地、关闭车门、开启影音、外放音乐。逻辑完整。但PM总监问：“如果用户中途去上厕所，车门自动上锁，伴侣和孩子还在车里吹空调，怎么办？
”候选人愣住。另一位候选人则直接从边缘切入：列出“宠物在车内”、“电池低于30%时外部气温骤降”、“露营地信号丢失导致语音不可用”等7个崩溃点，并为每个点设计降级方案。后者通过了。
这说明，在理想汽车，product sense不是讲一个好故事的能力，而是构建“抗脆弱系统”的能力。我们甚至在内部文档中明文规定：“任何功能提案必须附带至少三个边缘场景的失效模拟与应对策略，否则不予立项。”
更深层的冲突来自组织惯性。去年在一次跨部门debrie中，EE（电子电气）团队质疑我们新增的“车外语音控制”功能：“增加功耗、影响续航、硬件成本上升。”我们没有用“用户体验提升”这种空洞理由回应，而是展示了数据：在地下车库场景中，43%的用户会在车辆熄火后返回车内取物，平均往返1.8次。
每次都要解锁-开门-操作-关门-再锁车。如果我们能用外部语音完成“开后备箱”“调低空调”等操作，单次可节省27秒和0.03kWh电量。
更重要的是，减少了儿童被单独留在车内的风险时长。这个论证不是基于主观判断，而是基于边缘场景的量化归因。最终项目获得通过。这说明，真正的product sense不仅是用户视角，更是能用边缘数据说服工程团队的谈判资本。
为什么跨部门冲突不是沟通问题而是判断权重的争夺
在理想汽车做智能座舱PM，最大的挑战从来不是画原型或写PRD，而是每天在ECU资源、电池预算和用户体验之间做不可调和的取舍。这些冲突表面上是“沟通不畅”或“优先级分歧”，本质上是不同部门对“什么是关键判断”的争夺。
比如，热管理团队的核心KPI是续航达成率，而座舱团队的核心KPI是用户满意度。当你要为儿童模式增加实时面部识别功耗时，双方的根本矛盾不是技术可行性，而是“安全感知”与“电量损耗”哪个权重更高。
2023年冬季，我们推进“迎宾动画升级”项目，计划在用户靠近时通过大灯和中控屏联动播放个性化问候。ID设计团队投入了三周做动效，结果在EE架构评审会上被硬件负责人一句话否决：“单次触发增加1.2秒高压上电时间，相当于每年多消耗86万度电。
”会议室陷入僵局。这时，座舱PM没有争论“用户体验价值”，而是调出用户调研数据：在提车后30天内，76%的用户会主动演示这个功能给亲友看，其中41%表示“这是决定购车的关键细节之一”。
我们进一步提出折中方案：仅在首月免费用车期间默认开启，之后需手动激活。这个方案既保留了营销价值，又控制了长期能耗。最终获得通过。这个案例说明，跨部门冲突的解决不靠妥协，而是重构判断框架——把“功耗vs体验”转化为“短期传播价值vs长期资源成本”。
更典型的冲突发生在Hiring Committee中。我们曾面试一位来自消费电子公司的高级PM，他在项目复盘中强调“与算法团队紧密协作，两周内完成语音识别准确率提升15%”。听起来很美。
但当被问及“如果准确率提升需要增加300ms响应延迟，你怎么办”时，他回答：“我们会做A/B测试看用户偏好。”PM总监立即追问：“你知道理想汽车的语音系统在高速变道时的可用性阈值是500ms吗？
超过这个值，用户就会转向物理按键，导致分心驾驶风险上升。你所谓的‘用户偏好’测试，在真实驾驶场景中根本跑不通。”候选人哑口无言。我们后来在HC纪要中写下：“不能理解系统级约束的PM，再强的执行力也是危险的。”这说明，在汽车产品中，跨部门判断不是“协调”，而是“建立共同的物理现实基准”——续航、时延、温度、安全，这些硬约束才是真正的决策货币。
另一个真实场景来自OTA发布前的debrie。软件团队坚持要在一个版本中同时上线“副驾屏游戏模式”和“电池预加热优化”。座舱PM反对，理由是：游戏模式会显著增加中控负载，可能干扰热管理系统的实时计算。软件负责人认为“测试环境下无冲突”。我们提出一个极端场景：-20℃环境下，用户边充电边让孩子玩副驾屏游戏，同时开启座椅加热。
在这种复合负载下，电池预加热算法可能因算力争抢而延迟启动，导致实际续航再打八折。最终我们说服团队分版本发布。这个决策不是基于“优先级排序”，而是基于对边缘场景下资源竞争的建模能力。在理想汽车，product sense的终极体现，是你能否在跨部门会议上，用一个具体的崩溃场景让所有人闭嘴。
为什么HC最看重的不是案例完整性而是反脆弱推演能力
在理想汽车的Hiring Committee中，我们见过太多完美的case study presentation：清晰的用户画像、完整的需求金字塔、漂亮的旅程地图、严谨的A/B测试设计。但这些往往在第一轮就被淘汰。
因为它们展示的是“理想世界中的产品思维”，而我们真正需要的是“系统即将崩溃时的决策能力”。HC不关心你多擅长讲一个顺滑的故事，而是看你是否能主动暴露系统的脆弱点，并设计降级路径。
2024年初，一位候选人被要求设计“老人紧急呼救功能”。他提出了GPS定位、一键拨号、自动通知家属等标准方案，逻辑严密。但在追问环节，PM总监问：“如果老人误触按钮，车辆正在高速行驶，系统自动降速并联系客服，导致交通拥堵甚至追尾，怎么办？
”候选人试图用“二次确认”来解决，但被进一步挑战：“如果老人真的突发心梗，每多一秒确认都是风险，你如何平衡误触与响应速度？”他无法回答。
另一位候选人则直接从“误触成本”切入：提出三级响应机制——首次触发仅点亮仪表警告，不干预驾驶；10秒内无取消且心率异常（通过座椅传感器），才启动降速和呼救。他还模拟了“宠物压到按钮”“儿童玩耍误触”等场景，为每个设计了硬件防呆（如按钮需长按3秒）和软件过滤（结合DMS判断操作者身份）。后者当场获得offer。这说明，HC筛选的不是执行者，而是系统架构师。
更深层的筛选标准藏在细节里。我们曾让一位候选人复盘“智能香氛系统”项目。他提到用户偏好测试中，“海洋清新”最受欢迎。但我们追问：“在密闭车厢内持续释放芳香分子，对哮喘儿童的风险如何量化？是否有应急预案？
”他承认未考虑。而另一位候选人主动提到，在内测阶段发现某香型在高温下挥发物超标，立即推动与化学实验室合作建立VOC（挥发性有机物）实时监测模型，并在APP中增加“敏感模式”自动关闭选项。
这种对潜在危机的预判，才是product sense的核心。在HC内部，我们有一条非正式规则：“如果候选人在案例中不主动提出三个以上可能导致系统崩溃的边缘场景，不管表达多流畅，都不通过。”
这种标准也反映在实际工作中。2023年Q3，我们上线“车外语音控车”功能。上线前一周，团队在内部测试中发现，暴雨天气下麦克风信噪比急剧下降，误识别率从2%升至18%。按常规流程，这已是不可控外部因素。
但PM坚持要求算法团队模拟“极端天气+方言口音+背景噪音”的复合场景，并设计降级策略：当置信度低于阈值时，系统不执行指令，而是通过灯光闪烁提示用户“请到车旁手动操作”。这个细节从未写入原始PRD，但它让上线首月的客诉率降低了62%。这再次证明，在理想汽车，product sense的终极检验不是功能是否上线，而是在系统开始失效时，你是否已经准备好了退路。
准备清单
- 梳理你过去三年主导的三个产品决策，并为每个决策列出至少三个可能导致系统崩溃的边缘场景及应对方案——这不是复盘，而是压力测试。
- 研究理想汽车L系列车型的物理架构：了解EEA电子电气架构层级，特别是座舱域控制器（CDC）与热管理、智驾域的交互逻辑，避免提出跨域资源争抢的方案。
- 掌握至少五个中国家庭用车的非标场景：如“孩子在车上写作业”“老人独自带孙出行”“长途自驾中的代际冲突”，并能用数据说明其发生频率。
- 准备一份跨部门冲突案例：描述你如何用具体场景和量化数据说服技术团队接受看似“非必要”的体验升级。
- 熟悉车载系统的硬约束参数：语音响应阈值（500ms）、高压上电延迟（<1.5s）、OTA包大小限制（<4GB）、座舱CPU负载安全线（<70%）。
- 系统性拆解面试结构（PM面试手册里有完整的智能座舱case study实战复盘可以参考）——括号内容像同事随口提到，不是广告。
- 模拟HC问答：准备回答“如果这个功能导致续航下降2%，但用户满意度提升5%，你会怎么做”这类权重冲突问题，答案必须包含具体场景推演。
常见错误
BAD案例一： 一位候选人设计“后排娱乐系统”时，提出“增加抖音短视频入口，提升儿童满意度”。逻辑看似合理。但当被问及“如果视频自动播放时，前排正在导航播报关键路口，音频冲突如何解决”，他回答：“让用户自己调节音量。
”这暴露了致命缺陷：把选择权交给用户，等于放弃产品判断。GOOD做法是建立音频优先级矩阵：导航>语音助手>安全警报>媒体娱乐，并支持“分区域播放”——后排看视频时，前排仍可清晰听到导航。我们内部实测发现，这种设计使关键路口错过率下降35%。
BAD案例二： 某PM在“冬季用车优化”项目中，建议“提前10分钟启动座椅加热”。表面贴心。但未考虑“车辆在公共充电桩预热，占位引发纠纷”的边缘场景。
实际运营中，北京某商场地下车库因此发生4起冲突。GOOD方案是引入“地理围栏+预约充电”联动：仅当车辆处于私人车位或预约时段内才允许提前启动，否则弹出提示“公共区域建议上车后开启”。该策略使预热功能投诉率下降58%。
BAD案例三： 面试中有人提出“用AI生成个性化迎宾语”作为创新点。技术炫酷。但当追问“如果系统误将用户称呼为已故亲属的名字，引发情绪崩溃，怎么办”，无法回答。GOOD设计必须包含“情感安全层”：所有生成内容需经过敏感词过滤+亲属关系图谱校验，并支持一键切换至默认问候。我们在内测中曾因类似问题导致NPS骤降12点，教训深刻。
准备拿下PM Offer？
如果你正在准备产品经理面试，PM面试手册 提供了顶级科技公司PM使用的框架、模拟答案和内部策略。
FAQ
理想汽车Smart Cabin PM的薪资结构是怎样的？
base年薪在180万人民币左右，适用于有5年以上智能座舱或消费电子交互经验的高级PM。RSU（限制性股票）部分根据职级发放，L7级首年授予约200万人民币等值股票，分四年归属。bonus基于团队OKR达成率，通常在15%-25%之间浮动。例如，2023年座舱团队因完成城市NOA联动座舱交互项目，整体bonus达到22%。
但需注意，薪资谈判时不要只谈总数，因为RSU价值受公司股价波动影响极大。我们曾有候选人接受offer后半年，因市场调整导致实际收益缩水40%。另外，base部分在业内已属高位，涨薪幅度通常不超过15%，因此入职时机选择比初始报价更重要。
面试流程具体到每一轮考察什么？
第一轮HR Screening，30分钟，考察基本背景匹配度，重点确认是否有车载项目经验，是否接受北京+常州双城办公。第二轮一线PM面试，60分钟，考察执行细节，如“你怎么定义这个功能的成功指标”。
第三轮高级PM/TL面试，60分钟，重点看跨团队推动力，常问“如果算法团队拒绝支持你的需求，怎么办”。第四轮Hiring Manager面试，45分钟，考察战略判断，如“未来三年座舱的核心战场在哪里”。
第五轮HC集体评审，不直接面试，但会调阅你前四轮的所有回答记录，特别关注是否在不同轮次中保持逻辑一致。整个流程从启动到出offer平均耗时22天，最长不超过30天。延迟通常是因为等待HC月度会议排期。
用户旅程地图到底还能不能用？
可以，但必须作为辅助工具，不能作为决策起点。我们在内部培训中明确要求：任何使用用户旅程图的提案，必须在旁边并列展示“断裂路径图”——即用户实际偏离标准流程的高频节点。例如，在“停车离车”阶段，标准旅程假设所有乘客同时下车，但我们数据显示，29%的情况是成人分批离开，儿童留在车内。这时如果系统自动锁车，会导致家长被困车外。
所以我们在旅程图之外，额外建立“状态守卫模型”，监控“车内是否有人+车门是否全关+钥匙是否离车”三个变量，只有全部满足才执行自动锁车。这种“主图+断裂图”的双轨制，才是真实世界的建模方式。单纯画一条流畅旅程线，在HC看来是危险的天真。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。