1. 先聊聊这90%的PPT是怎么炼成的
先说个真事儿。前两年某家车企找到我们，要做智能泊车辅助的云端能力。启动会上，供应商、算法团队、产品经理、测试工程师坐了一屋子，领导开口就是“我们要做行业领先的泊车体验”，PPT上写着“全场景、视觉+超声波融合、云端代客泊车”。后面的事情你可能猜到了——三个月后项目从“优先项目”降级为“预研项目”，六个月后连预研都算不上，只剩下一个演示视频放在年度技术日上循环播放。这样的事，我在这行干了十几年，亲自参与或复盘过上百个车企AI项目，最后能真正量产的，十个手指头数得过来。剩下的九成，基本都变成了PPT。今天我不绕弯子，就站在一个一线车云人的角度，把这几个致命死局拆开给你看。
1.1 一个典型AI项目的生命周期
这类项目普遍是这样过完一生的：领导在战略会上看到友商发布了一个“AI+汽车”的新功能，心里一紧，立刻拍板要搞。然后技术预研团队开始写立项报告，供应商闻着味就来了，带着一套漂亮的车机演示环境，在展厅里把自动跟车、语音交互、疲劳监测做得像科幻电影。内部评审一看，觉得有戏，预算批下来，大干一场。
接着就开始踩坑了。数据采集要用路测车队，路测车队说排期满了；数据标注要外包，标注团队说你这个场景太复杂，之前没标过；算法团队训出来的模型在内部测试集上跑分很高，一上实车就翻车；好不容易小批量装车了，标定部门又说你这套传感器硬件更换了，需要重新适配。每个环节都像在泥巴地里走路，谁都觉得自己没责任。
等到项目周期过半，各方一看，钱花了不少，演示效果还停在三个月前。于是项目启动“防守模式”，争相写报告说明“难度超出预期”，把目标调成“行业验证”“技术储备”。再往后，PPT里多了一页“阶段性成果”，配几张曲线图，领导看完点点头，项目就这么“被成功”了。这就是我见过的大多数车企AI项目的真实简历。
1.2 三个死局，都藏在技术外
很多人以为这些项目失败是因为算法不够强、算力不够用。但在我这些年一线实践里，真正的死局从来不在算法本身，而是三个更底层的东西：
第一，数据看似很多，但没有形成可用的数据资产；第二，组织流程出现“三不管”地带，项目责任断在部门之间；第三，价值闭环缺失，没人说得清这东西到底能为用户和公司带来什么。
这三个死局彼此纠缠，数据问题引发进度拖延，进度拖延引发组织甩锅，组织甩锅又让团队没心思思考真正的用户价值，最后大家心照不宣地做了个“体面收场”。下面我一个个拆开细讲，每个死局都附上我亲历过的案例和踩坑经验。
2. 死局一：数据“金矿”其实是“矿渣”，很多项目死在了第一步
2.1 车企最不缺的是数据，最缺的是数据流水线
我在不少内部研讨会说过一句话：车企说自己有海量数据，这话没毛病，但海量数据不等于数据资产。就好比你家里囤了几十袋米，但从来没做过一顿饭，那不能叫有粮食储备能力，只能叫有囤积癖。
真正的数据资产，是经过清洗、脱敏、标注、管理、版本化之后，可以直接拿来训练模型并用于量产迭代的数据。大多数车企的数据现状是什么？路测采集车跑了几万公里，原始视频存在机房服务器里，连索引都没做。想做某个场景识别的时候，先让实习生去翻录像，翻半天找不到几条符合条件的数据。找到了也不知道这条数据出自哪个传感器配置、天气如何、光线如何，全是断链的。
我参与过一个摄像头污损检测项目，算法团队需要雨雪、泥浆、逆光等边缘场景的数据。查了一圈，发现公司数据湖里存着三十万条道路视频，但按场景打标签的比例不到1%。最后怎么解决的？车队重新出去跑了两个月采集。项目刚起步就被拖了两个月，这绝对不是个例。所以我说，数据问题第一大坑不是没有数据，而是没有围绕“算法训练需求”来建数据流水线。
2.2 标注环节正在消耗你项目的“信任存款”
数据有了，第二个坑出现在标注。很多车企不重视标注质量，觉得算法才神秘，标数据不就是画框框嘛。实际上，标注质量对模型效果的影响巨大。我见过一个车道线识别项目，算法工程师复现论文里的SOTA模型，效果始终差了七八个点。后来一查标注数据，发现外包标注员把货车挡风玻璃上的反光杆阴影也标成了车道线。这种问题在初期很难自动发现，但模型一训完，性能天花板就卡住了。
更要命的是，标注标准的语境不通。算法团队说是“检测动态车辆”，标注团队理解成“把画面里所有跑的车都框起来”，于是路边停着的车、对向车道等候的车也全标了。模型训练出来，在井喷的车流场景里误检率奇高。之后车队再实路测试，发现一堆脱离预期的错误，项目口碑就此崩坏。数据标注领域的“信任存款”，是耗尽了就很难补回来的。
2.3 场景碎片化：一个模型换一台车就失灵
第三个数据相关的死局是场景碎片化。同样是车载语音唤醒，在轿车上的麦克风阵列参数和SUV上不一样；同样是视觉感知，前置摄像头安装在挡风玻璃中心偏下的位置，和安装在后视镜支座上的视角完全不一样。很多车企做一个AI功能，只针对一款车型验证通过，就轻飘飘说“我们技术成熟了”。等到第二款、第三款车型导入，发现模型表现大幅下降，又得重新采集数据、重新标定、重新训练。
车云协同在这里就显得特别有意思。理论上，云端可以积累多车型、多工况的分布数据，用一套基础模型配合车型适配层。但实际做的时候，很多车企都没有建设这样的云数据平台，每个项目组各自为战，本地硬盘里存了一堆“私有宝藏”，却永远无法打通。于是模型每换一个环境就“失忆”一次。我见过最夸张的项目，一个疲劳驾驶监测算法，因为摄像头安装位置不同，在三个车型上各训练了一个独立模型，每次上线都要重新做整车集成验证。这种重复造轮子的事，注定了项目只能长期停留在PPT阶段。
提示：数据死局的本质不是某个团队不努力，而是缺少自上而下的数据资产规划。没有数据资产地图，没有标注规范，没有数据版本管理，AI项目就算算法再强，也只能在有限数据集上自嗨。
3. 死局二：组织与流程的“三不管”，项目不是被算法拖死的，是被部门墙压死的
3.1 业务方、算法团队、供应商的三方博弈
车企AI项目天然要跨部门协作，但部门墙比大家想象中厚得多。业务部门说：你们做出功能来，我就卖大点。算法部门说：你们连用户场景都定义不清楚，我怎么设计模型？供应商说：我们方案成熟，但你们得先把接口和数据给到我们。
这三方坐在一起，看起来是在开会，实际上在打心理战。业务方怕承担指标责任，算法方怕被业务方瞎指挥，供应商怕项目做不完尾款收不到。最后往往是谁嗓门大谁说了算，但没人对最终量产负责。
我亲眼看过一个座舱手势识别项目，业务方为了发布会噱头，非要支持“比个动作就切歌”的复杂手势。算法团队明确说这种手势在驾驶状态下误触率太高，不安全。业务方不听，硬把需求写进合同。供应商倒是乐呵呵，先报个高价再说。结果项目做了一年，误触率确实压不下来，发布会PPT却已经提前画上了“指尖交互”。这就是三方博弈的典型后果——说到做不到，只能靠PPT圆场。
3.2 POC到量产之间的“工程化鸿沟”
车企内部的AI项目，最常见的推进路径是先做POC（原型验证）。POC阶段大家热情都很高，算法工程师在实验室笔记本上跑通了一个demo，拿来一演示，效果惊艳，领导喜笑颜开。然后呢？然后就卡住了。
因为从POC到量产之间，还隔着一整套看不见的工作：模型压缩、嵌入式平台移植、交叉编译、定点化、内存优化、故障降级、OTA升级策略、误报日志回传、数据回流闭环、测试用例沉淀……这些工作不性感，但每一项都要真金白银地投入。问题是，组织上往往没有一支专职的“工程化小组”来承接这件事。算法团队的KPI是模型精度，他们没义务也没动力去解决端到端延迟问题；嵌入式团队有自己的硬科技业务要忙，分不出人手去优化AI模型；云平台团队又觉得AI模型跟我有什么关系。
于是项目就卡在“demo能跑”和“量产能卖”之间的无人区。我常跟朋友说，这个无人区比烂尾楼还难处理，因为烂尾楼至少还有明确的产权人，而POC到量产的鸿沟连责任人都找不到。最后项目只能停在那里，PPT上写着“已完成POC验证，具备量产条件”。
3.3 KPI错位，让所有人都成了PPT的帮凶
还有一个根本性问题：KPI错位。算法团队考核指标是mAP、ACC、recognition rate这些模型指标，业务部门考核的是车型销量和功能开启率，云平台考核的是服务可用性，几个团队的激励方向完全不同。
算法团队为了让指标好看，可以悄悄把训练数据里简单样本的比例调高，或者选用计算量更大的模型结构，反正他们不关心实际功耗和成本。业务部门为了宣传亮点，宁可选择一个实际场景中用户根本不会用的小众功能。云平台只保证服务不宕机，但AI模型的迭代优化跟他们无关。各部门各自都完成了自己的KPI，项目却没有产生真正的商业价值。
后面我遇到过最离谱的一件事：某车企的自动泊车项目，算法团队汇报的“泊车成功率”用的是封闭停车场、没有动态障碍物、车位线清晰的测试环境数据，实际用户场景中侧方停车、斜列式停车、儿童乱跑进车位等情况一多，成功率直接掉到一半以下。但算法团队自己打分很高，觉得项目已经可以SOP了。业务部门那边则担心装机后用户抱怨率飙升，不敢启动量产。结果两边扯了半年，项目最终从“量产”变成“继续预研”。说白了，只要没人把“真实用户场景下的综合表现”作为统一的北极星指标，所有人都会都在各自的小指标里自嗨，PPT也就不远了。
4. 死局三：价值闭环缺失，Demo很酷，商业上是负资产
4.1 不是问“技术能不能做”，而是问“用户为什么需要”
第三个死局，也是最要命的，就是整个项目从立项开始就没有回答“用户为什么需要”这个问题。很多车企上AI项目，理由很简单：别人家有，我们也要有。技术部门接到指令后，第一反应是“我们能做什么样的炫酷功能”，而不是“什么功能能真正解决用户痛点”。
举个例子，某车企想在智能座舱里做一个“驾驶疲劳状态实时监测”，技术方案很先进，摄像头加红外补光，加上眼部状态识别模型，还能结合驾驶行为数据做融合判断。做出来之后才发现，用户真正需要的不是一句“您已疲劳，请休息”，而是当他真的快睡着的关键时刻，系统能给出足够强刺激的预警，同时联动云平台通知家人。但项目团队把精力都花在“识别眼部状态分类”上，到最后连“怎样触达用户才能引起警觉”都没设计过。
真到了量产前，市场部门一问：“这个功能给用户带来的可感知价值是什么？愿意为之多花多少钱？”没人答得上来。于是项目不死不活，回头又靠PPT里的“行业首创”硬撑。这是我见过最多的一种死法——技术上成立，但价值逻辑站不住。
4.2 成本黑洞：算力、流量、合规、运维的费用被严重低估
AI项目要量产，成本测算往往是致命的。很多项目的立项PPT只会写模型识别率能到多少，功能体验多么顺畅，却完全忽略了下游的算力成本、流量成本、数据合规成本和后期运维成本。
我算一笔简单的账：一个云端语音助手场景，假设每月活跃用户50万，每人每天交互10次，每次调用云端大模型推理，每秒处理数百token，这背后的GPU服务器成本和云流量费用，一个月轻松上百万。再加上模型的持续迭代、数据回流处理、标注人力、模型上线AB测试，每一个环节都是持续烧钱。
更别提合规成本了。车内摄像头采集的驾驶员面部数据，必须经过用户的明确授权，数据上传要加密，存储要脱敏，还涉及个人生物识别信息的严格管理。这些合规要求让很多算法效果大打折扣——比如不能把原始人脸图像传云端，有些项目因此不得不改成端侧识别，端侧算力又不够，效果直线下降，然后整个项目就被砍掉了。见惯了这样的项目，我发现不少汽车AI产品不是被技术淘汰的，是被成本账本算死的。
4.3 为了展示而展示的“伪需求”是怎么制造出来的
还有一种情况更讽刺：很多AI功能的存在，不是为了给用户用，而是为了给投资人看、给媒体看、给竞争对手看。我参与过某个“AI全场景自动泊车”的项目，当时量产日程根本没排，但为了在车展上有一个震撼的演示视频，团队花了两个月时间，精心编排了一段“车主下车后，手机一键召唤，车辆自动停入狭窄车位”的动画。
视频里车辆丝滑得像科幻电影，可实际测试环境中的泊车系统，连地面有积水时的视觉标定都还没有打通。这件事让我印象很深，因为所有人都知道这是假的，但每个环节都在配合生产这个“假象”。市场部门需要故事，供应商需要案例，技术部门需要预算，于是大家合谋制造了一堆伪需求。最后车展结束，视频倒是火了，项目却变成了一个悬案——没人真的去推进量产。这大概就是“PPT项目”的最高境界。
5. 破局思路：逆着死局，从PPT杀回量产的几条路
讲了这么多死局，并不是说车企AI项目就没有活路。我这几年也见过一些真正活下来的项目，它们有一个共同特点：特别“小气”，特别“克制”。下面分享四条亲测有效的破局思路。
5.1 选窄场景，打穿一个全链路闭环
别一上来就做“全场景智能驾驶”这种大而全的东西。真正的活路往往藏在很窄的场景里。比如“高速公路匝道口的导航自动变道”，或者“停车场闸机前的车牌识别+无感支付”，再比如“车内儿童遗留监测报警”。
选窄场景有个好处：用户价值可以讲清楚，技术边界可以定清楚，数据采集可以聚焦，验证成本低。我见过一个“车载空气质量管理AI”，没做什么惊天动地的事，就是根据车外空气污染指数自动切换内外循环，加一个PM2.5趋势预测模型。这个功能看起来不性感，但确实减少了用户操作，而且整个链路很短：传感器采集→边缘识别→云端空气质量模型→车机策略执行。这个项目最后做了六个月就量产了，用户反馈率还不错。
所以我建议各个项目组拿一张纸，把你要做的AI功能最核心的使用场景缩小到一个非常具象的片段，然后只围绕这个片段做全链路闭环。不要贪多。
5.2 用数据飞轮反向牵引数据资产，而不是先囤数据
数据资产这件事不需要一步到位，可以围绕一个具体功能反推需要哪些数据，然后建立触发机制。比如你做疲劳监测，那就在量产车端设计好数据采集触发规则：检测到疑似疲劳时，自动截取脱敏后的视频片段上传云端。这还不够，还要主动设计“困难场景采集包”，让测试车队专门去跑夜间、逆光、下雨、用户戴墨镜等工况。
更重要的是，数据不能采完就丢。要建立数据版本管理，把每个数据对应到传感器配置、车型、天气、光线等关键维度。哪怕一开始只覆盖一款车型，也要把数据的血缘理清楚。这样等到第二个车型导入时，你才能快速判断哪些旧数据还能复用，哪些必须补充。用一个项目的角度去倒逼数据平台建设，比憋一个大而全的数据中台靠谱多了。
5.3 建立“运营指标”验收标准，用开源节流说话
不要再看“算法准确率99%”这种虚头巴脑的东西了。要量产，就要问三个问题：这个AI功能给用户节约了多长时间？给车主降低了多少操作频率？给公司节约了多少运营成本？
我的经验是，把验收标准从“模型指标”换成“全链路业务指标”。比如做语音助手，验收指标不是“语音识别词错率”，而是“用户每次有效请求的解决率”和“操作耗时下降百分比”。做车云能力，验收指标是“平均响应时延P99”和“月度GPU成本/有效请求数”。用这些指标说话，业务方听得懂，管理层能理解，供应商也没法拿测试集上的好看数字来忽悠你。
5.4 让车云工程化团队拥有真正的预算和决策权
最后一个破局点可能听起来很“虚”，但特别关键：任何一个AI项目，必须有一个独立的工程化负责人，他既懂算法，又懂车载嵌入式，还懂云平台，同时拥有独立预算和决策权。他需要对最终的量产进度负责。
这个负责人不是项目经理，项目经理往往只盯交付计划，贴着各方开会。工程化负责人要盯的是全链路：数据采集是否满足模型需求、模型压缩后是否不丢点、车机芯片能否hold住、云端API能否扛住并发、合规检查是否通过。只有当这么一个人站在整合者位置上的时候，项目才可能从PPT走向量产。我所在的团队正是靠这条原则稳住了几个项目，而没有沦为PPT大军中的一员。
6. 常见问题与避坑实录
6.1 项目做了一年还在预研，是不是该砍掉？
我的判断标准很简单：再给这个项目三个月，它能不能在真实的量产车或者云环境中跑通一个端到端的最小链路？如果不能，那就要认真考虑砍掉。不要信奉“技术预研总会有成果”这种说法，商业环境里，超过一年还在预研的AI项目，大概率是方向有问题或者是组织问题，而不是单纯的技术难度问题。
我见过一个项目组花了18个月打磨“驾驶行为分析”模型，数据没少采，模型没少训，但始终没有接入到任何一家的车险服务或车队管理平台。季度会上老板问：我们的合作伙伴在哪里？没人敢吱声。后来项目被砍，大家反而松了一口气。
6.2 供应商说“我们做了几十个量产项目”，怎么验证？
别听他怎么说，直接要三个东西：量产项目名称和大致生命周期、对应车型的版本迭代记录、近一年的故障率和用户投诉率数据。如果供应商支支吾吾，后面很大概率是吹牛。
另外千万不要只看供应商的演示视频。所有演示都是精心挑选的“天时地利人和”场景。我学到的土办法是：要求供应商直接在你的目标车型上，用你们的数据集跑一轮盲测，并且允许你们自己的人坐在副驾驶全程录像。这个环节一加，很多供应商当场露馅。
6.3 关于数据合规和隐私保护，有哪些容易被忽视的细节？
第一个细节是车内摄像头数据默认不保留原图，必须在端侧完成人脸特征提取，把脱敏后的特征上传云端。第二个细节是车外摄像头采集的道路数据同样涉及地理信息合规问题，有些区域甚至不允许采集。第三个细节是OTA升级前的数据变更必须做系统的差分隐私评估，否则可能引发法律风险。
我身边好些项目就因为在合规审核环节没有提前介入，等到硬件和算法都定型了才补合规，结果发现摄像头角度不合理、数据加密不达标，整车被迫改硬件架构，项目自然是天折一半。所以一定要在项目立项的第一天就把合规工程师拉进来，而不是最后一天。
6.4 手里没有AI人才，怎么启动第一个AI项目？
如果你的团队之前没有任何AI经验，最稳妥的方式不是招一个算法大牛，而是找一个具有完整量产经验的供应商，但合作方式要做成“联合开发加知识转移”，而不是全权交钥匙。合同里明确要求供应商派工程师到你们公司驻场，把他们的数据采集流程、训练框架、迭代方法论都留下来。同时，内部抽两三个真正聪明、肯学的人全程跟着做，不需要他们会写模型，但必须看得懂训练曲线、能写数据清洗脚本、能跑基本模型评估。
等第一个项目走通全链路之后，你再考虑自建团队，这时你已经知道每一步的坑在哪里了。不要一开始就迷信“自研算法”，在车企这个体系里，自研不是目的，能规模量产并产生持续价值才是目的。
我一直有个固执的观点：汽车AI项目不是死在科技树上，而是死在从科学到产品的“最后一百米”。如果你正带着一个AI项目在车企里艰难推进，希望这四条破局思路能让你在某些深夜里多一点底气。项目可以不那么酷，但真能量产、能服务用户、能创造价值，才是我们这行的Face。
