考察点
这道题出自蔚来 AI 产品经理岗面经,是一道典型的「真实工作困境」题。AI 产品交付和传统软件交付的最大区别就在于:功能写完了不等于能力 ready——模型准确率差一点、长尾 badcase 多一堆,这种情况在 AI 项目里是常态而非意外。面试官想看的是三件事:你能不能把「没 ready」从一句焦虑的话拆成可评估的程度问题;你的应对方案是分级的还是只会「延期」一招;你在压力下对客户关系和公司信誉有没有概念。蔚来的语境还自带一层特殊性:车端功能的交付节奏和整车节点绑定,座舱 AI 功能往往跟着车型发布走,延期的代价远大于互联网产品。追问常落在:客户不接受延期怎么办、验收标准怎么定才能避免扯皮、怎么防止下次再估错。
参考答案
先把「没 ready」翻译成程度问题
「能力还没 ready」是一句正确的废话,我的第一反应是拆程度,因为不同程度的应对天差地别。我按三档分。第一档:核心链路不可用——比如语音助手的唤醒识别在真实车内噪声环境下大幅翻车,主要功能路径走不通,这没得谈,必须重新谈交付范围或时间。第二档:核心链路可用但质量不达标——比如准确率 88%,离约定的 95% 差一截,日常能用但 badcase 密度用户能感知,这是最常见也最考验判断力的中间态。第三档:长尾问题多但不伤主干——方言、生僻指令、极端场景表现差,主流用户的主流用法没问题。这三档的本质区别是:交付后用户第一次用的体验是「坏了」「一般」还是「挺好但偶尔犯傻」——用户对产品的信任定价,大部分在第一次使用时完成。
分级应对:核心链路降级,边缘能力分期
对应三档,我的工具箱是四个手段。分期交付:把交付物拆成「核心能力包」和「增强包」,核心包按原定节点交,增强包给出明确的时间表——这不是拖延,是把「一个延期的坏消息」拆成「一个如期的好消息加一个延期的坏消息」,客户感受完全不同,前提是拆出来的核心包本身构成完整可用的体验,不能是半个功能。降级交付:第二档场景的常用手法——能力不降,范围收窄,比如全场景语音降级为「先支持导航和车控两个高频域,其他域转客服或后续 OTA」,用场景白名单把表现差的区域隔离掉,宁小而好,不大而烂。人工兜底:To B 交付里很常用——AI 先上岗,后面配人工复核或客服接管,把准确率的缺口用运营资源先补上,同时积累真实数据反哺模型,代价是短期成本高,适合客户不能接受功能缺失的情况。坦诚沟通换时间:最后一招,也是最后才用的招。
预期管理:坏消息要早说,还要带着方案说
这道题真正的分水岭在预期管理。我见过最差的处理是:团队内部早就知道赶不上,抱着侥幸心理闷头赶工,交付前一周才告诉客户——这时候客户失去的不是时间,是对你的信任,而且没有任何腾挪空间。正确的做法是反过来:里程碑设置「体检点」,我习惯在交付前 4-6 周做一次正式的能力评估,用验收标准同款口径实测,发现缺口当周就沟通;沟通时的姿态是「现状+选项+建议」三件套——摆数据说清差在哪、给两三种应对方案(分期/降级/延期各自的代价)、给出我作为产品负责人的建议,让客户做知情决策,而不是把焦虑原样丢过去。还有一条纪律:所有验收口径的变更都要书面确认,口头答应的「差不多就行」在验收那天会全部翻脸,这条在 To B 交付里是血泪常识。
车端语境:安全相关的没有中间态
蔚来的语境要多说一层:车上的功能分两类,逻辑完全不同。安全相关或行车强相关的(比如驾驶辅助的交互、行车中可用的语音指令),没有「先凑合交付」这个选项——误识别在客厅里是笑话,在高速上是事故,这类功能宁缺毋滥,该砍就砍,该延就延,没有谈判空间。座舱娱乐和舒适类的(语音闲聊、内容推荐、氛围控制),可以走「先交付后 OTA 迭代」的互联网逻辑,车端 OTA 的成熟度已经支持这个玩法,但要把「会持续进化」作为卖点明确讲给用户,把初版的能力边界写清楚,让用户预期落在正确的位置。智能电动车的用户其实已经被教育得接受「常用常新」的叙事,这是车端 AI 产品可以借力的地方——前提是每次 OTA 真的在变好,几次原地踏步后,这个信用就透支完了。
事后复盘:估错的代价比延期更大
最后,一次「交付时没 ready」发生后,真正重要的工作在事后。我的复盘只问三个问题:缺口是什么时候第一次可见的——如果是交付前一周才发现,说明过程里的度量是瞎的,要补中间里程碑的实测机制;当初估算错在哪——是低估了数据工作量(十有八九是这个)、高估了模型基线能力、还是需求中途膨胀没砍;承诺是怎么做出的——销售先行拍脑袋、PM 没参与售前评估,那就要把「能力评估前置到售前」变成流程。AI 项目估算最大的坑是传统软件经验直接平移:功能开发量能按人日估,模型能力不能,它有自己的验收节奏,PM 的责任是把「能力达标」本身列成有验证手段的里程碑,而不是默认它会随开发完成自动发生。
可能的追问
- 客户不接受分期,咬死要全量按期交付怎么办? 答:回到利益和风险的谈判桌:摆数据说清全量硬上的真实后果(上线即翻车的口碑和返工成本远高于分期),把「分期」包装成「核心场景先行保障上线质量」而不是「我们没做完」;同时给补偿性承诺——增强包的时间表写进补充协议、超期有违约条款,用确定性换客户的让步。如果客户仍不接受,升级给双方决策层,PM 不背超出权限的承诺。
- 验收标准怎么定才能避免交付时扯皮? 答:三条:指标化——不用「好用」用「XX 测试集上准确率≥95%」;口径前置——测试集长什么样、谁提供、谁标注、争议谁仲裁,签约时就定;过程共视——里程碑按同口径实测并双方签字,交付那天的数字不该让任何人意外。
- 怎么防止下次再估错? 答:把估算拆成「工程工作量」和「能力达标」两条线,工程线按人日估,能力线按「当前实测基线+数据迭代周期」估,没跑过基线测试不许给承诺;历史项目沉淀「能力爬坡曲线」数据,新项目参照同类场景的爬坡速度估,估错一次就要让组织学到一次。