90%汽车AI项目沦为PPT？三个死局与破局之道

干了八年车云，见过太多汽车AI项目从立项时的轰轰烈烈，到收官时的悄无声息。标题里那句“90%沦为PPT”，说实话我第一反应是：这个数是不是说少了？在我参与和旁观过的项目里，真正能把AI功能交付到量产车上的，连十个手指头都数不满。其他项目倒也不是完全没干活，算法团队跑过模型，数据团队采过数据，云端平台也搭了，但最后都卡在同一个坎上——东西始终停在演示环境里，一到真实场景就露馅。这篇文章我不聊行业趋势，也不报所谓洞察，就把我在一线看到的三个致命死局拆开讲。能救一个算一个。

1. 先别急着骂PPT，先看清楚“PPT项目”长什么样

1.1 “PPT项目”不等于“做了PPT”

我见过不少朋友一听到“PPT项目”就嗤之以鼻，觉得就是画饼、吹牛、不干活。这里我得说句公道话：做PPT本身没有错，技术方案评审、项目汇报、供应商对接，哪个环节不需要PPT？真正的PPT项目，是那种内容永远停留在纸面、演示和汇报，从来没有形成真实工程闭环的项目。

怎么判断一个汽车AI项目是不是PPT项目？看三个特征就够：第一，项目里程碑上全是“完成技术验证”“完成内部演示”“完成平台搭建”，但从来没有任何一个指标落到量产车型的功能列表里；第二，每次汇报都用“性能提升xx%”“准确率突破xx%”这些数字，但问一句“这个数字是哪个车端版本、哪条测试路、哪种天气条件下跑出来的”，没人能答全；第三，项目组成员的绩效考核和项目实际效果之间没有正相关，大家更关心的是如何在季度会上把故事讲圆。

这三点听起来平平无奇，但放在一起，基本就是一个项目的死亡循环：因为不做真实工程验证，所以只能靠抽象指标汇报；因为指标脱离了具体场景，所以纵使数字再漂亮也无法指导下一步优化；因为没有下一步优化，团队只能转向包装旧成果，最后所有人默契地假装项目正在推进。

1.2 三种典型画像：发布型、竞速型、献礼型

这些年我反复见过下面三种“PPT AI”画像，几乎每家车企里都能对上号：

这三种画像里，最阴间的是内部竞速型。表面上看各部门都在拥抱AI，实际上每套方案之间根本不兼容。智驾团队基于英伟达Orin做感知模型，座舱团队基于高通8155做多模态交互，两边用的数据格式、标注规范、推理框架全不一样。等高层想整合成一个统一的汽车AI平台时，发现唯一的“共同语言”就是汇报PPT里的那几张架构图。连底层数据都没打通，谈什么汽车AI落地？

1.3 车云到底是什么？AI上车为什么绕不开它

聊汽车AI，绕不开“车云”这个词。它不是什么新概念，简单说就是车端和云端组成的一套协同系统。车端算力有限，跑不动大模型，也不适合承担全量训练；云端算力强、存储大，适合做数据汇聚、模型训练和大规模推理，但云端和车端之间的网络延迟和带宽又不稳定。所以车云协同的目的，就是让两边发挥各自优势：云端负责“重活”，车端负责“快活”。

我经常用一个类比：这就像手机里的语音助手。云端算力负责听懂复杂指令，本地芯片负责快速响应“打开手电筒”这种高频操作。汽车AI比手机更复杂的一点在于，车辆是在高速移动的物理世界里的，决策关系到安全，所以车端不能完全依赖云端，必须有一套端侧兜底能力。很多PPT项目恰恰相反，满脑子都是“云端大模型赋能一切”，结果网络一波动，车端直接变成砖头。车云不是终点，是手段；手段没想清楚，项目自然翻车。

2. 死局一：数据闭环看着在转，实际都是断头路

2.1 完整的数据闭环长什么样

做汽车AI，第一性原理是数据。但数据不是堆在那儿就完事，它必须形成一个闭环。我脑子里有个标准链路，一共七个环节：

车端采集原始数据 → 车端预处理和脱敏 → 回传云端 → 云端清洗和标注 → 模型训练和评测 → OTA推送模型到车端 → 车端在真实场景继续采集新数据

这一圈跑下来，AI才是“活”的：模型会越用越准，系统会越跑越稳。如果这条链路中间断了，哪怕你采集了一千TB数据、训练了一百个模型，也只是一个静态的资料库，给不了车主任何价值。我见过太多项目，PPT上画着非常漂亮的闭环大图，箭头、节点、数据湖一应俱全，但实际去问一线的数据工程师，得到的回答往往是：“闭环？你说哪个闭环？我们只负责把行车记录仪的视频打包传到对象存储里，后面没人理。”

2.2 最常断的三个地方：采集、回传、标注

先说采集断点。很多车端采集系统是硬件工程师定死的，只在特定触发条件下录数据，比如急刹车、碰撞预警、车道偏离。这些数据对事故分析有用，但对AI训练来说远远不够。你想让模型学会应对“雨天逆光下前车突然急刹”，可采集策略根本没把这种场景列进去。我见过一个项目为了完成月度采集KPI，让测试车在绕城高速上以120公里时速跑了一周，采回来一万多个片段，最后标注团队看一眼就扔了七成——全是枯燥的理想工况，没有任何训练价值。这就是典型的“采了不该采的，漏了该采的”。

再说回传断点。车端到云端的回传链路牵涉流量费、合规脱敏、压缩算法、网络环境。很多项目为了省钱省事，只回传降采样后的视频或者干脆只传统计指标。结果云端工程师拿到的是马赛克级别的画面，别说做3D标注，连理解场景都费劲。等到某天实车出了事故，想复盘原始数据，车端本地存储早就被循环覆盖了。回传这条链路如果不舍得投入，云端再强大也是睁眼瞎。

最容易被低估的是标注断点。标注这件事看起来门槛低，实际上直接影响模型上限。第三方标注团队的水平参差不齐，同一个弯道，有人画成虚线，有人画成实线；同一帧图像里的行人被遮挡一半，有人标“行人”，有人标“未知物体”。如果没有人做抽样复核和一致性校验，模型就等于在一堆互相矛盾的答案里硬找规律。有一次我们debug一个夜间行人检测问题，折腾了两周，最后发现是标注规范里对“反光背心”的类别定义和算法团队理解的不一致，导致模型反复横跳。标注的坑，往往比算法本身的坑更深。

2.3 自查清单：你的数据闭环是真是假？

在项目评审会上，我一般建议团队抛出下面几个问题，谁答不上来，谁的数据闭环就是虚的：

• 车端采集回来的原始数据，有多少比例完整保留了视频帧和传感器报文？还是只留了精简统计？
• 回传到云端的链路，用的是车企自建的传输通道，还是依赖第三方流量卡？有没有断点续传？
• 标注团队的标注结果，有没有人工抽检？抽检比例是多少？标注一致率有没有达标？
• 云端训练好的模型，有没有针对车端部署做过量化、剪枝和精度对齐？
• 最新版本模型，是在仿真环境里评测的，还是在真实路测数据上评测的？

只要有一项回答得含糊，那所谓的数据闭环基本就是给PPT撑场面的。别觉得我苛刻，汽车AI是系统工程，任何一个环节断掉，整个项目的可靠性就归零。

2.4 一个把闭环跑通的项目长什么样

说了这么多，也不是没有正面案例。我参与过一个相对务实的项目，做的是高速路匝道汇入辅助。团队没想一口吃成胖子，只选了华东某城市的一条高速匝道，前后十公里，限定时段，一台测试车。开始两周时间全花在打通信链路上：车端怎么触发采集、脱敏规则怎么定、云端入库和标注怎么流转、模型怎么训练、怎么通过OTA推到车上，每个节点都有明确负责人。到第四周，第一版模型上了车，虽然有明显误判，但已经能跑通全链路。这时候项目负责人做了一件事：把整个链路跑一遍的时间从初始的十天压缩到两天。之后每两周更新一版模型，测试车每天跑这条匝道，数据滚雪球一样回来，三个月后匝道汇入成功率从50%提到85%，而且每次优化都知道是哪些数据起了作用。

这才叫闭环。而不是在数据中心里训练一个SOTA模型，然后写一份报告感叹“效果真好，可惜上不了车”。

3. 死局二：业绩汇报和KPI，逼着所有人“演”

3.1 汇报节奏和AI开发节奏之间有一道裂缝

汽车AI项目的失败，很多时候不是技术不行，是组织方式从一开始就在对着干。车企普遍按季度推进项目，每季度要给高层做进展汇报，而AI模型从数据准备到训练到评测，周期往往按月计算，两三个月能出一个稳定版本已经不错了。这就导致一个非常荒诞的现象：Q1必须有成果，Q2必须有突破，Q3必须有落地，Q4必须有总结。可模型不是生产线上的零件，说产出就产出。于是团队只能把demo当成果，把内部测试当突破，把PoC（概念验证）当落地。

我见过一个典型节奏：三月立项做座舱多模态交互，六月高层来参观，项目组连夜把一段用户语音指令录好放在本地，演示现场机器人管家正常响应，全场鼓掌。八月正式集成到量产座舱时，发现语音识别模型在嘈杂环境下的表现一塌糊涂，因为演示用的麦克风是录音棚级别的。项目只能延期，年底汇报时，Victory Page上写着“智能座舱多模态交互原型验证完成”，可车主至今没有在量产车上见到那个功能。这就是汇报节奏逼出来的PPT。

3.2 算法团队、车端团队、云端团队各怀心思

汽车AI项目天然被切成算法、车端、云端三段，每个团队各有各的KPI。算法团队的KPI是模型精度，车端团队的KPI是稳定性和资源占用，云端团队的KPI是训练效率和资源利用率。听起来可以互补，实际上完全互相拉扯。

算法团队在云端用PyTorch刷出一个高精度模型，到车端部署时发现乙方的推理引擎不支持某个算子，车端团队要么换引擎要么砍算子，最后精度掉了五个点。车端团队为了满足功耗和延迟指标，偷偷把模型输入分辨率从1080p砍到720p，算法团队再跑评测时发现数据对不上了。云端团队抱怨车端回传的数据格式不统一，每次清洗都要写一堆临时脚本。三方每月开一次对齐会，会上各自展示PPT，最后写一个“联合进展”的共识，实际上谁都没动。这种组织断点非常难修，因为它不是某个人能力不行，而是目标函数互相冲突，又没有一个人真正对整个项目的最终效果负责。高层以为在做AI，实际上在做跨部门协调，协调不出结果，只能PPT粉饰。

3.3 一个真实项目的“PPT化”全过程

前两年我围观过一个自动泊车辅助项目，印象特别深。立项时目标很清晰：让车辆在普通停车场完成自动泊入泊出，要求泊车成功率不低于90%，误停率低于1%。算法团队拿到需求后，先找了一个结构简单的露天停车场做采集，把白天、晴天、空车位多的场景全部覆盖。第一版模型在测试集上很漂亮，泊车成功率95%。

到了集成测试阶段，问题开始冒出来。车辆开到地下车库，GPS信号弱，定位漂移，视觉感知在暗光环境下识别车位线不稳定；系统判断的车位跟人眼看到的不一致，测试员不敢放开方向盘让车自己停。项目组内部开始分锅：算法说定位模块做得差，定位说视觉模块的输入分辨率太低，车身控制说收到的目标车位坐标时常跳变。为了在季度会上有东西可讲，项目经理做了一套新PPT，把项目改名为“基于多传感融合的自主泊车技术探索”，展示了几张模型在仿真场景里的截图，还有一张“多传感器融合方案对比表”。高层看完觉得在进步，实际上项目在原地打转。半年后，这个项目悄悄降级，只保留一个传感器融合预研小组，而那套PPT被改了十几版，成了后续新项目立项时的“参考模板”。

3.4 怎么判断你的组织是在做AI还是在演AI

有几个组织信号非常明显：

• 团队人数最多的不是做工程的和做数据的，而是做汇报材料的；
• 每次项目例会，花在“讲故事”上的时间比花在“聊技术细节”上的时间多；
• 同一个问题连续三个季度出现在风险清单里，但一直没人真正推进解决；
• 重要技术决策不是由技术负责人拍板，而是由高层审“PPT是否好看”来决定；
• 项目做完后，没有一个可量化的“车主可感知”结果被放到年度总结里，取而代之的全是“平台能力”“中台底座”这类无法证伪的话。

如果这些信号你身边占了三条以上，那这个项目大概率已经走在PPT化的路上了。趁早换个能拍板扛责任的负责人，比换什么技术方案都管用。

4. 死局三：技术方向年年换，车云底座被反复折腾

4.1 技术选型摇摆不是“探索”，是内耗

汽车AI行业更新快，这是共识，但反应到具体项目上，很多车企的“拥抱变化”变成了“反复横跳”。举个例子，某车企的智驾团队，第一年选型定了TensorFlow，第二年管理层看到几篇文章说PyTorch是趋势，于是要求全部切换。切换不是改写几个API那么简单，数据管线、算子库、量化工具、部署流程全都要跟着动。切换过程中又赶上另一个热点，说是端到端大模型上车，团队又抽调一半人力去搞端到端的概念验证。结果一年下来，模型没训练出几个稳定的，光迁移数据格式和适配推理引擎就耗掉大量工时。

我理解车企想踩技术红利，但AI项目最稀缺的资源不是算力，而是稳定的迭代节奏。你频繁换框架、换架构，等于让团队的每一次积累都作废。这就好比盖房子，地基还没干透就换设计图纸，最后房子永远盖不起来，只能一直给人看效果图——效果图就是PPT。

4.2 车端和云端的物理限制，不能靠PPT抹平

车端和云端的差异，是物理上的，不是PPT能拉平的。车端芯片算力有限，功耗受控，内存带宽有限；云端则可以堆GPU、扩展存储、部署千亿参数模型。很多项目组在云端跑大模型跑出了惊艳的性能，然后天真地问：“直接压一压放到车里不就行了吗？”每次听到这句话，我都想说：压一压，这三个字背后是剪枝、量化、蒸馏、算子替换、精度对齐，每一步都可能带来性能损失，而且需要重新做一遍实车验证。

更麻烦的是网络环境。云端推理再快，也架不住车辆过隧道、进地库、走在信号盲区。你指望车端在弱网时靠云端兜底，结果网络一断，系统就变成“我是谁，我在哪”。那些在发布会演示里看起来“神乎其神”的远程代驾、云端接管，大多数是在满格信号、专人保障的封闭场地里录的。真到了用户的日常通勤，网络条件千差万别，所有没考虑弱网兜底的方案都会原形毕露。我做项目时有一条硬规矩：默认车辆随时可能断网，所有核心功能必须在车端本地能独立闭环。云端只能当增强，不能当命根子。

4.3 能演示和能量产，中间隔着“工程化”这条河

演示环境是一个“无菌培养皿”，量产环境是“野生丛林”。很多团队喜欢把演示做得花里胡哨：视频里车辆自动绕障、自动泊入、语音对话流畅，但量产时遇到的第一批真实用户就把它打回原形。我曾见过一个很可笑的项目，Demo里座舱大模型回答用户“空调温度调到22度”，系统秒回“好的，已调到22度”，现场一片掌声。但量产车真正运行时，因为车机麦克风阵列和多音区语音分离的调教没跟上，后排乘客说一句“它好冷”，前排模型的注意力就被抢走，空调莫名其妙调低好几度。这种体验差距，不是模型不行，是整个工程化链路里的声学、硬件、交互设计都没跟上。

所以我说，能演示不代表能量产。中间隔着的东西叫“工程化”，包括但不限于：传感器标定的一致性、热管理对芯片性能的影响、系统级安全冗余、故障降级策略、OTA升级失败后的回滚机制。这套工程体系，没有任何一个演示版本能覆盖。

4.4 判断一个技术方案“能不能上车”的三个问题

下次评审会，拿这三个问题去问技术方案：

• 这个模型在车端实际部署时，帧率是多少？内存占用多少？芯片温度上来了性能掉多少？
• 弱网、断网、隧道、地库场景下，系统怎么表现？有没有自动降级策略？
• 从云端训练到车端OTA，整个链路有多长？如果发现模型有问题，最快多久能回滚？

如果这三个问题上方案只会说“我们正在评估”，那这个方案离量产差得还远。别被“技术上可行”四个字骗了，技术上可行和量产可交付之间，隔着十个PPT项目都不止。

5. 想从PPT回到车里，我建议你干这几件事

5.1 先跑通一个最小闭环，再包装故事

我见过太多项目第一步就把目标定成全场景、全能力，结果团队被庞大的工程面拖垮。更务实的做法是：选一个足够窄、足够痛、足够能验证的场景，先跑通全链路。比如上一章提到的匝道汇入，或者“地库车位记忆泊车”，或者“高速路施工区预警”。场景窄没关系，关键是它能把数据采集、回传、标注、训练、OTA、实车评测这六件事完整走一遍。哪怕第一个闭环做出来只有70分，也意味着团队建立了可复用的工程管线，后面第二个、第三个场景就是管道里加水的事。如果连最小闭环都没有，那项目唯一的产出就是PPT。

具体执行上，我建议用“两周冲刺”的方法：两周内，一台车、一条固定路线、一个场景，完成从数据采集到模型OTA回车的首次闭环。别纠结模型效果，先把链路走通。这一关过了，项目才真正离开纸面。

5.2 统一云端和车端的评测标准

很多项目失败在“各说各话”：算法团队汇报云端评测指标，车端团队汇报实车路测感受，两边数据对不上，谁都不服谁。解决办法是让云端和车端评测统一。我们后来搭了一套“车端数据回灌系统”，把实车采集到的传感器原始数据回灌到云端评测集，然后云端模型和车端模型跑同一套脚本，对比同一批场景。这样算法团队没法说“车端跑的离线数据不标准”，车端团队也没法说“云端模型理想化”。同一套评测结果说话，扯皮空间瞬间消失。

实际操作上，至少要做到三点：一是评测数据集必须包含真实车端采集的数据，而不是云端自己拼凑的干净样本；二是评测指标要同时覆盖准确率、延迟、功耗、内存占用，不能只看一个维度；三是每次模型更新，都要出一份云端vs车端的对比报告，差异超过容忍阈值必须写原因。

5.3 盯住三个数字：回传率、上线时长、实测里程

预算有限、团队有限的时候，别迷信一堆高深的AI指标，先盯三个工程指标：

这三个数字是项目健康度的“体温计”。它们一旦长期不达标，基本可以断定项目在向PPT滑落。反过来，如果这三个数字不断提升，哪怕某些算法指标暂时不好看，项目也是在往前走的。因为底层工程能力在建设，那是AI项目真正的护城河。

5.4 给正在立项或已经在坑里的人几条忠告

最后分享几条被现实毒打出来的经验。

第一，不要把“Model在公开数据集上达到SOTA”当成功。公开数据集跟真实场景隔着十万八千里，你的车能不能用，只能让真车在这座城市的真实路况里跑出来。第二，警惕那些“旁路式”推进：算法团队在云端做了一堆实验，车端团队毫不知情，最后集成时全得推翻重来。每两周必须让两端代码同步一次，哪怕只是很小的功能。第三，给数据工程师足够的权限和话语权。汽车AI项目里，数据工程师才是真正决定模型上限的人，别让算法工程师整天催他们打杂。

还有一条，任何时候都要保留一份“最小可复现记录”：哪个版本的数据、哪个版本的模型、哪个版本的部署配置，必须在版本管理里一一对应。很多项目死的不是没想法，是出问题之后找不到原因，因为所有环节都不可复现，最后只能靠PPT解释“可能是偶发”。

6. 结尾：让PPT回到它该有的位置

说这么多，不是让大家彻底不写PPT。项目申报、立项评审、资源争取，PPT确实有用，我自己也写。但PPT只能是作战地图，不能当庆功宴。我最怕的，是团队把做PPT本身当成项目目标，天天研究怎么把技术包装得高端，却忘了真正的目标是让车在真实道路上跑得更安全、更聪明、更省心。

如果这篇文章能给人留下哪怕一句话，我希望是这句：先让车跑起来，让数据转起来，让模型在真实世界里自己说话，然后再去开会、再去汇报、再去做PPT。我在实际项目里最大的感触是，技术永远不是汽车AI最难的坎，最难的是能不能顶住组织压力、顶住汇报节奏、顶住技术风口的诱惑，坚持把一件小事从端到端做到闭环。PPT可以做，但请先给PPT配一台真正在路上跑的车。