汽车AI量产死局：90%项目沦为PPT的三大陷阱与破局思路

1. 汽车AI项目的真实处境：为什么演示很惊艳，量产却遥遥无期

我在车云这个圈子里摸爬滚打了快八年，从最早的T-Box远程控制，到后来的车机OTA，再到这两年铺天盖地的AI Agent上车，几乎每一波技术浪潮我都亲身跟过。2023年大模型爆发之后，我参与过至少五个主机厂的汽车AI项目评审，也帮两家Tier1做过AI Agent的架构咨询。说句不客气的话，我见过的汽车AI Demo里，十个有九个在演示阶段都能让领导点头，但真正走到量产SOP的，一只手数得过来。

这不是某一家的问题，而是整个行业的系统性困境。你随便打开一个车展的发布会，台上讲的全是“我们的AI助手能理解复杂指令”“我们的座舱Agent能主动服务”“我们的大模型已经完成端侧部署”，PPT做得一个比一个漂亮，视频剪得一个比一个流畅。但你要是真去问他们的工程师：这个功能什么时候OTA推给用户？推给多少用户？推了之后日活多少？大部分人的回答都是含糊其辞的。

我写这个系列，就是想把这层窗户纸捅破。第一篇聊了汽车AI的基本盘，这一篇专门讲“死局”——为什么90%的汽车AI项目最后都沦为了PPT。我会从车云从业者的视角，拆解三个最致命的死局，每个死局都配上我亲身经历或近距离观察到的真实案例，以及我认为可行的破局思路。

如果你是在主机厂做智能化规划的，或者是在Tier1做AI产品定义的，又或者你是刚入行的车云工程师想搞清楚这个领域的真实玩法，这篇文章应该能帮你少走不少弯路。我不会讲太多虚的方法论，主要聊的是：钱花在哪了、人卡在哪了、技术到底能不能落地、以及那些PPT上永远不会写的坑。

2. 死局一：需求定义阶段的“伪场景”陷阱

2.1 为什么车企总在造“用户不需要的AI功能”

我先说一个我亲身参与过的项目。某主机厂要做“座舱AI Agent”，产品经理给的需求文档里写了这么一条核心场景：“当用户说‘我有点累了’的时候，AI Agent应该自动调整座椅到按摩模式、播放舒缓音乐、调暗氛围灯、并把空调温度调高两度。”

听起来很美好对吧？Demo视频里也确实很惊艳。但实际开发的时候，我们团队内部就吵起来了。做语音的同事说，用户说“我有点累了”这句话的识别准确率在嘈杂的车内环境下只有70%左右；做座舱控制的同事说，座椅按摩、氛围灯、空调这三个域控的响应延迟加起来超过2秒，用户体验会很割裂；做数据的同事说，我们根本没有足够的真实用户语料来训练这个场景的意图识别模型。

最后这个功能还是上了，但实际推送之后的数据惨不忍睹。我后来拿到了一份内部数据：这个“疲劳关怀”场景的触发率不到0.3%，而且触发之后有超过一半的用户在10秒内手动关闭了座椅按摩。原因很简单——用户说“我有点累了”的时候，往往是在跟副驾聊天，或者是在打电话，根本不是在对车机说话。

这就是典型的“伪场景”。产品经理在办公室里拍脑袋想出来的需求，看起来逻辑自洽，实际上跟真实用户的用车习惯完全脱节。我后来总结了一个规律：凡是需要用户“主动说出某种情绪”才能触发的AI功能，大概率都是伪需求。因为人在开车的时候，最不想做的事情就是跟机器解释自己的情绪。

2.2 真实用户场景和PPT场景之间的鸿沟

那什么才是真实场景？我举一个反例。同样是做座舱AI，另一家主机厂的做法就务实很多。他们没有做“情绪识别”，而是做了一个很土的功能：根据导航目的地和当前时间，主动推荐沿途的服务区或充电站。比如用户导航去一个300公里外的地方，车机在行驶到一半的时候会主动说：“前方30公里有服务区，您已经连续驾驶2小时，建议休息一下，需要我帮您导航过去吗？”

这个功能的技术难度比“情绪识别”低得多，但它的触发率超过了15%，用户接受推荐的比例也有将近40%。为什么？因为它解决的是一个真实存在的痛点：长途驾驶时的疲劳和补能焦虑。而且它的交互方式很自然——不是让用户主动说话，而是AI主动服务，用户只需要说“好”或者点一下屏幕就行。

我后来复盘这两个案例，发现一个很残酷的事实：很多车企做AI，本质上是在做“技术展示”，而不是在做“产品”。技术展示的逻辑是“你看我的AI多厉害”，产品逻辑是“用户到底需要什么”。这两者的区别，在需求定义阶段就已经决定了项目的生死。

2.3 需求评审时应该问的五个问题

基于这些踩坑经验，我现在参与任何汽车AI项目的需求评审，都会问五个问题。这五个问题如果有一个答不上来，这个需求就值得重新考虑：

• 这个功能在用户不主动说话的情况下，能不能触发？如果必须用户主动说某句话才能触发，那就要评估这句话在真实场景下的出现频率。
• 这个功能的响应延迟能不能控制在1.5秒以内？超过1.5秒，用户就会觉得“这AI怎么这么慢”，体验直接降级。
• 这个功能需要跨几个域控？跨域越多，响应越慢，出bug的概率越大。超过三个域控的功能，建议拆解或放弃。
• 我们有没有足够的真实数据来训练这个场景？如果没有，能不能先用规则引擎兜底，而不是硬上大模型？
• 这个功能上线后，我们用什么指标来判断它是不是成功了？如果指标是“演示效果好不好”，那这个项目大概率会沦为PPT。

这五个问题看起来很基础，但我见过太多项目连第一个问题都没想清楚就开始立项了。结果就是开发做了半年，Demo很漂亮，一推送就露馅。

3. 死局二：技术架构上的“大模型万能论”

3.1 端侧大模型上车的真实算力账

2024年的时候，我参加过一个行业闭门会，某新势力车企的智能化负责人上台分享，说他们已经在端侧部署了一个70亿参数的大模型，实现了“全离线语音助手”。台下掌声一片。但我当时就在心里算了一笔账：70亿参数的模型，即使做了4-bit量化，模型文件大小也在4GB左右。车机芯片的NPU算力，主流的高通8295大概是30 TOPS，看起来够用，但你要知道，这个算力是要跟座舱的其他功能共享的——仪表渲染、导航、娱乐系统、DMS驾驶员监控，都在抢这个NPU。

我后来私下问他们团队的工程师，实际运行的时候，这个端侧大模型的推理速度是多少。对方支支吾吾地说，在实验室环境下，首token延迟大概是800毫秒，但到了实车上，因为要跟其他任务抢资源，有时候会飙到2秒以上。而且这还是在没有开空调、没有开导航、没有同时运行其他AI功能的情况下。

这就是“大模型万能论”的第一个坑：算力账算不过来。很多车企在立项的时候，只算了模型本身的推理算力，没有算系统级的资源竞争。结果就是，单个功能演示的时候很流畅，一旦多个AI功能同时运行，整个座舱就卡成PPT。

3.2 云端大模型和车端控制的“最后一公里”

那有人会说，端侧算力不够，那就上云端大模型呗。反正现在5G覆盖率也上来了，云端算力无限，想跑多大的模型都行。

这个思路听起来合理，但实际落地的时候，有一个致命的“最后一公里”问题：云端大模型可以理解用户意图，但它控制不了车。车端的执行器——车窗、座椅、空调、氛围灯——都是通过CAN总线或者以太网连接的，云端模型输出的结果，需要经过车端的网关、域控制器、再到底层ECU，这个链路很长，而且每一层都有延迟和安全校验。

我见过一个项目，用户说“打开车窗”，云端大模型识别意图用了300毫秒，网络传输用了200毫秒，车端网关校验用了100毫秒，域控制器转发用了50毫秒，最后车窗开始动的时候，已经过去了将近1秒。用户的感觉就是“这AI反应好慢”。更麻烦的是，如果网络信号不好，这个延迟会更大，甚至直接失败。

所以现在的行业共识是：涉及车控的指令，必须在端侧做兜底。云端大模型可以负责复杂的语义理解和对话，但最终的指令解析和执行，必须由端侧的规则引擎或者小模型来完成。这就带来了一个新的架构复杂度：端云协同怎么做？什么任务放端侧，什么任务放云端？端侧和云端的模型怎么保持一致？这些问题，很多项目在架构设计阶段根本没有想清楚。

3.3 我见过的三种典型架构翻车案例

我总结了一下，汽车AI项目的技术架构，最常见的翻车方式有三种：

第一种是“全端侧”架构。为了追求低延迟和离线可用，把所有AI能力都塞到端侧。结果就是模型被迫做得很小，能力很弱，用户觉得“这AI怎么这么笨”。而且端侧模型的更新很麻烦，每次升级都要通过OTA推一个几百MB的包，用户不一定愿意升级。

第二种是“全云端”架构。为了追求模型能力，把所有推理都放在云端。结果就是延迟高、依赖网络、流量成本高。我算过一笔账，如果一个AI功能每天被调用100万次，每次请求的云端推理成本是0.01元，那一年就是365万。这还没算网络传输和存储的成本。

第三种是“端云割裂”架构。端侧和云端各做各的，没有统一的调度和兜底机制。结果就是用户体验不一致——有时候很快，有时候很慢，有时候能用，有时候不能用。这种架构最要命，因为用户根本不知道这个AI什么时候靠谱。

那正确的架构应该是什么样？我的经验是：端侧做意图识别和车控兜底，云端做复杂对话和知识问答，中间用一个统一的Agent调度层来协调。这个调度层要根据当前网络状态、端侧负载、任务类型，动态决定把请求发给端侧还是云端。听起来很复杂，但这是目前唯一能兼顾体验和能力的方案。

4. 死局三：OTA推送之后的“数据黑洞”

4.1 为什么AI功能推了OTA就没人管了

这是我最想吐槽的一个死局。很多车企的AI项目，在OTA推送的那一刻，项目组就解散了。产品经理去忙下一个项目了，开发去修别的bug了，测试去测新功能了。没有人去跟踪这个AI功能上线之后的真实表现。

我见过一个极端的案例。某车企做了一个“AI语音助手”，OTA推送之后，官方发了一篇新闻稿说“用户满意度超过90%”。但我后来拿到了一份真实的埋点数据：这个语音助手的日活用户占比只有8%，而且这8%里面，有超过一半的用户只用了“导航到某地”和“播放音乐”这两个基础功能。那些PPT上吹的“多轮对话”“上下文理解”“主动服务”，几乎没有人用。

为什么会出现这种情况？因为OTA推送不是终点，而是起点。AI功能跟传统车控功能不一样，传统功能推出去之后，只要没有bug，就不用管了。但AI功能是需要持续迭代的——用户的语料在变，使用习惯在变，模型也需要不断微调。如果没有一个团队持续跟踪数据、优化模型、迭代功能，这个AI功能就会慢慢变成一个“僵尸功能”。

4.2 数据闭环为什么在车企内部这么难建

那为什么车企不建数据闭环呢？我观察下来，主要有三个原因：

第一是数据归属问题。车端产生的语音数据、图像数据、行为数据，到底归谁？是归车厂？归Tier1？归云服务商？这个问题在很多车企内部都没有明确的答案。结果就是数据散落在各个部门，没有人能拿到完整的用户行为链路。

第二是数据合规问题。车内语音数据涉及用户隐私，不能随便上传云端。很多车企的做法是“端侧脱敏后再上传”，但脱敏之后的数据，很多有价值的上下文信息就丢失了。比如用户说“我有点冷”，脱敏之后可能只剩下“冷”这个关键词，但用户是在什么场景下说的、之前说了什么、车外温度是多少，这些信息都没了。

第三是数据标注成本。大模型的微调需要高质量的标注数据。但车内场景的标注很复杂——同样一句“打开车窗”，在不同的语境下，可能是要开主驾窗、副驾窗、还是全部车窗？这个标注工作需要既懂车又懂AI的人来做，而这样的人在市场上非常稀缺。

我见过一个做得比较好的案例。某车企专门成立了一个“AI数据运营团队”，大概10个人，负责跟踪所有AI功能的线上表现，每周出一份数据报告，每月做一次模型迭代。这个团队的负责人跟我说，他们最大的挑战不是技术，而是“让公司相信这件事值得持续投入”。因为数据闭环的收益是滞后的，而成本是即时的。在车企这种KPI导向的环境里，很难说服管理层持续为一个“看不见直接收益”的团队买单。

4.3 一个可落地的数据闭环最小方案

如果你所在的车企或团队，也想建数据闭环，但资源有限，我建议从一个最小方案开始。这个方案我在两个项目里验证过，成本不高，但效果很明显：

第一步，定义三个核心指标。不要贪多，就三个：AI功能的日活占比、核心场景的触发率、用户主动打断率。这三个指标能帮你快速判断这个AI功能是“活着”还是“死了”。

第二步，在端侧做轻量级埋点。不需要上传原始语音，只需要上传结构化的行为数据：用户说了什么意图、AI响应了什么、用户有没有打断、响应延迟是多少。这些数据量很小，一天的数据可能就几百KB。

第三步，每周做一次数据复盘。不需要复杂的BI系统，用Excel就行。把上周的数据拉出来，看看哪个意图的触发率下降了，哪个场景的打断率上升了。然后针对性地优化。

第四步，每月做一次小版本迭代。不需要重新训练大模型，只需要调整规则引擎的阈值，或者优化意图识别的关键词库。这种小迭代的成本很低，但能让用户感觉到“这个AI在变聪明”。

这个方案的核心逻辑是：先用最小成本跑通数据闭环，再逐步扩大投入。很多车企一上来就想建一个大而全的数据平台，结果平台建了半年，数据还没跑通，项目已经黄了。

5. 破局思路：从PPT到量产的三个关键转变

5.1 从“技术驱动”转向“场景驱动”

我前面说的三个死局，归根结底都是一个原因：项目是技术驱动的，而不是场景驱动的。技术驱动的逻辑是“我们有什么技术，就做什么功能”；场景驱动的逻辑是“用户有什么痛点，我们就用什么技术去解决”。

这个转变听起来很简单，但在车企内部做起来非常难。因为车企的组织架构通常是按技术域划分的——语音团队、视觉团队、座舱团队、智驾团队，每个团队都有自己的KPI和技术路线。要让这些团队坐下来，一起讨论“用户到底需要什么”，而不是“我的技术能做什么”，需要很强的产品经理来牵头。

我的建议是：在项目立项阶段，先不要谈技术方案，先做用户调研。找20个真实车主，跟他们聊一个小时，问他们平时开车的时候最烦什么、最希望车能帮他们做什么。你会发现，很多你以为是痛点的东西，用户根本不在乎；而很多你没想到的东西，用户天天在忍受。

5.2 从“大模型崇拜”转向“混合架构”

第二个转变是从“大模型崇拜”转向“混合架构”。我并不是说大模型不好，而是说大模型不是万能的，它只是工具箱里的一把锤子。汽车AI的场景非常多样，有的场景需要大模型的语义理解能力，有的场景只需要一个简单的规则引擎。

我现在的做法是：把AI功能分成三类，分别用不同的技术方案。第一类是“车控指令”，比如“打开车窗”“调低空调”，这类场景用规则引擎或者小模型就够了，不需要大模型，因为大模型反而会增加延迟和不确定性。第二类是“知识问答”，比如“这附近有什么好吃的”“这个故障灯是什么意思”，这类场景适合用云端大模型，因为需要广泛的知识和推理能力。第三类是“主动服务”，比如“根据你的日程和路况，建议你提前出发”，这类场景需要端云协同，端侧做意图预测，云端做路径规划。

这个分类方法的核心逻辑是：用最合适的技术解决最合适的问题，而不是用最先进的技术解决所有问题。

5.3 从“项目制”转向“产品制”

第三个转变是从“项目制”转向“产品制”。项目制的逻辑是“做完就结束”，产品制的逻辑是“上线才开始”。汽车AI功能，尤其是涉及大模型和Agent的功能，必须用产品制的思路来运营。

这意味着什么呢？意味着你需要一个常设的团队，而不是一个临时的项目组。这个团队里要有产品经理、算法工程师、数据工程师、运营人员，他们要对这个AI功能的长期表现负责。这个团队的KPI不是“按时交付”，而是“用户满意度”和“功能使用率”。

我知道在车企里推动这种组织变革很难，但如果不做这个转变，AI项目就永远逃不出“PPT—Demo—OTA—僵尸功能”的循环。我见过一家车企，他们的AI团队是独立于其他部门的，直接向CTO汇报，有独立的预算和KPI。这个团队做的AI功能，上线一年之后，日活占比从5%涨到了25%。他们的负责人跟我说，最关键的不是技术，而是“公司给了我们持续迭代的空间”。

6. 实操建议：如果你正在负责一个汽车AI项目

6.1 立项阶段的自检清单

如果你正在负责一个汽车AI项目，或者准备立项，我建议你先做一遍这个自检清单。这个清单是我从多个项目的失败和成功经验里总结出来的，能帮你提前发现大部分坑：

这个清单看起来很简单，但我见过太多项目连第一项都没做到就开始开发了。结果就是开发了半年，上线之后发现用户根本不需要这个功能。

6.2 开发阶段的资源分配建议

在开发阶段，我建议把资源按照“40-30-30”的比例分配：40%的资源用于端侧的基础能力建设，包括意图识别、车控兜底、延迟优化；30%的资源用于云端的大模型能力建设，包括对话管理、知识库、多轮上下文；30%的资源用于数据闭环和运营工具，包括埋点、数据看板、模型迭代流程。

很多项目的资源分配是“80-20-0”——80%的资源花在云端大模型上，20%花在端侧集成上，0%花在数据闭环上。这种分配方式的结果就是：Demo很惊艳，上线很拉胯，迭代很缓慢。

6.3 上线之后的运营节奏

上线之后的运营节奏，我建议按照“周-月-季”的节奏来：

• 每周：看核心指标，包括日活、触发率、打断率、延迟分布。发现异常及时排查。
• 每月：做一次小版本迭代，优化意图识别的关键词库、调整规则引擎的阈值、修复用户反馈的bad case。
• 每季度：做一次大版本迭代，可能需要重新训练模型、增加新的场景、优化端云协同策略。

这个节奏的关键是“持续”。我见过很多项目，上线第一个月很积极，第二个月就开始懈怠，第三个月就没人管了。AI功能跟传统功能不一样，它需要持续喂养数据、持续优化，才能保持效果。

7. 一些踩坑之后的个人体会

我在车云这个领域做了这么多年，最大的体会是：汽车AI的难点不在AI，而在汽车。互联网公司做AI，可以快速迭代、快速试错、快速上线。但汽车不行，汽车涉及到安全、涉及到法规、涉及到供应链，任何一个功能上车，都要经过漫长的验证和审批。

所以，如果你是从互联网转过来的AI工程师，我建议你先花三个月时间，搞清楚车端的电子电气架构、CAN总线、域控制器、OTA流程。这些东西看起来跟AI无关，但它们决定了你的AI功能能不能真正落地。

另外，不要迷信大模型。我见过太多项目，一上来就说“我们要用大模型重构座舱体验”，结果做了半年，发现大模型在车端的推理成本太高、延迟太大、效果不稳定。反而是那些用规则引擎和小模型做的“土办法”，上线之后效果更稳。

最后，我想说的是：汽车AI项目要成功，技术只占30%，产品定义占40%，组织保障占30%。很多项目失败，不是因为技术不行，而是因为产品定义错了，或者组织上没有持续投入。如果你正在做汽车AI，我建议你多花点时间在用户调研和产品定义上，少花点时间在技术选型和架构设计上。因为前者决定了“做不做”，后者只决定了“怎么做”。

这个系列我还会继续写，下一篇打算聊聊“汽车AI Agent的架构设计”，包括端云协同、意图路由、车控兜底这些具体的技术方案。如果你对这个话题感兴趣，或者你正在做类似的项目，欢迎一起交流。