1. 汽车AI项目的真实生存现状
我在车云这条线上摸爬滚打了快八年，从最早的T-Box数据回传，到后来做车联网平台，再到现在带团队搞座舱AI和故障诊断Agent，见过的“汽车AI项目”没有一百也有八十。说句得罪人的话，90%这个数字不是夸张，是我自己经手和旁观的真实比例。大部分项目在立项的时候PPT做得天花乱坠，什么“全场景智能座舱”“主动式故障预判”“多模态人车交互”，Demo视频剪得跟科幻片一样，但真正推到量产车上、推到售后体系里，能活过两个季度的屈指可数。
这个标题里的“汽车AI真相”，我想聊的不是技术有多难，而是为什么明明技术路线看起来都通，最后却做不成。核心关键词就几个：汽车AI、车云、AI Agent、大模型、故障诊断。这几个词放在一起，外行觉得是风口，内行知道是泥潭。我见过太多团队把大模型往车机里一塞，把Agent框架往云端一搭，就觉得自己在做“汽车AI”了，结果连最基本的故障诊断准确率都跑不过传统规则引擎。
这篇文章适合谁看？如果你是车企的AI项目负责人、车云平台的产品经理、或者正在做故障诊断方向的技术同学，那这里面的坑你大概率正在踩或者即将踩。如果你只是对汽车AI好奇，那也可以看看这个行业真实的一面——不是发布会上的那一面。
我先把结论撂在这儿：汽车AI项目沦为PPT，不是因为模型不够大，而是因为三个致命死局——数据闭环断裂、场景定义错位、工程化能力缺失。下面我一个一个拆。
2. 死局一：数据闭环断裂，模型越训越废
2.1 车云数据链路的真实断裂点
做汽车AI，尤其是故障诊断方向的，第一件事就是数据。但车企的数据链路，跟互联网公司完全不是一个物种。互联网公司是“用户产生数据→后台直接消费”，链路短、闭环快。车企呢？我画一下真实链路你就明白了：
车端传感器→CAN总线→T-Box→车云网关→消息队列→数据湖→标注平台→训练平台→模型仓库→OTA回传车端
这条链路上，我数了一下，至少有七个地方会断。
第一个断点：T-Box的数据回传策略。很多车企的T-Box默认只回传故障码（DTC），不回传原始信号。为什么？流量成本。一辆车一个月回传几百兆原始CAN数据，乘以几十万辆，这个流量费谁出？所以大部分车企的策略是“只传故障，不传原始”。但问题来了——你要做AI故障诊断，尤其是早期预警，恰恰需要故障发生前的原始信号序列。没有这个，你拿什么训？
第二个断点：数据湖的schema混乱。我见过一家车企的数据湖，同一个“电池温度”字段，在A车型叫batt_temp，在B车型叫battery_temperature，在C车型叫BMS_TEMP_01。你要做跨车型的故障诊断模型，光字段对齐就能耗掉两个月。更别提采样率不一致、时间戳对不齐、单位不统一这些破事。
第三个断点：标注平台和训练平台脱节。故障诊断的标注不是“标猫标狗”，是需要懂车的人来标。一个“电机异响”的样本，你得让NVH工程师听了之后标出“轴承磨损早期”还是“齿轮啮合异常”。这种标注资源，车企内部往往没有专职团队，外包出去质量又控不住。标完的数据进了训练平台，格式又对不上，还得再洗一遍。
注意：如果你正在立项汽车AI项目，先别急着选模型，先花两周时间把数据链路从头到尾走一遍，把每个断点标出来。这一步不做，后面全是空中楼阁。
2.2 为什么“先攒数据再训模型”在车企行不通
互联网的玩法是“先跑起来，数据自然就有了”。但车企不行。一辆车从立项到SOP（量产启动）要三年，从SOP到保有量上规模又要两年。你等数据攒够再训模型，项目早黄了。
我见过一个团队，做电池故障预警，等了八个月攒了三千条故障样本，结果发现其中两千条是同一个批次电芯的问题，数据分布严重偏斜。训出来的模型在测试集上AUC 0.95，一上真实车端，误报率30%。为什么？因为真实场景里大部分电池是正常的，故障样本的多样性远远不够。
那怎么办？我的经验是合成数据+迁移学习+小样本学习三管齐下。合成数据这块，可以用基于物理模型的仿真（比如电池的电化学模型）生成故障样本；迁移学习可以从实验室台架数据迁移到实车数据；小样本学习用原型网络（Prototypical Network）或者MAML，在几十条样本上做fine-tune。这些方法不是万能的，但比干等数据强。
2.3 数据闭环的工程化重建方案
如果你现在要从零搭一个能跑通的数据闭环，我建议按这个优先级来：
| 优先级 | 动作 | 预期耗时 | 关键产出 |
|---|---|---|---|
| P0 | 统一数据schema，建立字段映射表 | 2-3周 | 跨车型字段字典 |
| P0 | T-Box回传策略调整，故障前后30秒原始信号回传 | 4-6周 | 带上下文的高质量样本 |
| P1 | 搭建标注平台，接入领域专家 | 6-8周 | 标注规范+首批标注数据 |
| P1 | 训练平台与数据湖打通，自动化特征工程 | 4-6周 | 可复现的训练流水线 |
| P2 | 模型仓库与OTA链路打通 | 8-12周 | 模型可回传车端 |
这个表看着简单，但每一步都有坑。比如T-Box回传策略调整，你得跟车端团队、云端团队、流量成本团队三方扯皮。车端说“内存不够”，云端说“消息队列扛不住”，成本团队说“预算超了”。我的经验是，先做一个触发式回传——只有DTC触发时才回传前后30秒的原始信号，这样流量成本可控，数据质量也够。
实操心得：跟车端团队沟通时，不要提“AI需要数据”，要提“故障复现需要上下文”。前者他们听不懂，后者他们秒懂，因为售后部门天天找他们要这个。
3. 死局二：场景定义错位，Agent成了玩具
3.1 汽车AI Agent的典型伪需求
现在但凡是个汽车AI项目，不提Agent都不好意思立项。但我在车云一线看到的Agent，大部分是“为了Agent而Agent”。举几个我见过的真实案例：
案例一：座舱语音助手接大模型。团队花了三个月把语音助手从规则引擎换成大模型，结果用户最常用的指令还是“打开空调”“导航回家”“放首歌”。大模型带来的“闲聊能力”在车里根本没人用——谁会在开车的时候跟车机聊哲学？更致命的是，大模型推理延迟从规则引擎的200ms涨到了1.5s，用户说“打开空调”，等1.5秒才响应，体验反而降级了。
案例二：故障诊断Agent自动派单。团队做了一个Agent，能根据故障码自动生成维修建议并派单给4S店。听起来很美好对吧？但实际跑起来，Agent生成的维修建议4S店技师根本不看——因为技师有自己的诊断流程，而且Agent的建议经常是“建议检查相关线路”这种正确的废话。更麻烦的是，Agent误派单导致4S店白跑一趟，投诉率反而上升。
案例三：用车知识问答Agent。用户问“我的车胎压报警了怎么办”，Agent回答了一大段胎压原理和检查步骤。但用户真正需要的是“附近哪里有充气的地方”或者“能不能继续开”。Agent答非所问，因为它的知识库是维修手册，不是用户场景。
这三个案例的共同问题是什么？场景定义错了。团队在定义场景的时候，想的是“AI能做什么”，而不是“用户需要什么”。这是典型的工程师思维，不是产品思维。
3.2 从“AI能做什么”到“用户需要什么”的转换方法
我后来总结了一个笨办法，但很管用：去售后车间蹲三天，去4S店前台蹲三天，去车主群里潜水三天。不要带任何技术预设，就记录用户真实的问题和抱怨。
我蹲出来的结果是这样的：
- 用户最关心的故障问题Top 3：“还能不能开”“要花多少钱”“多久能修好”
- 用户最讨厌的AI行为：答非所问、响应慢、反复确认
- 用户最需要的AI能力：快速定位问题、给出明确行动建议、预估成本和时间
你看，用户根本不关心你用的是大模型还是小模型，是Agent还是工作流。用户要的是确定性。而大模型和Agent恰恰最缺的就是确定性。
所以我的建议是：汽车AI的场景定义，要从“确定性需求”出发，而不是从“AI能力”出发。故障诊断就是一个确定性需求——用户要的是“哪里坏了、能不能开、多少钱”。这个需求用规则引擎+小模型就能解决80%，大模型和Agent用来解决剩下的20%长尾问题。
3.3 故障诊断场景的Agent架构设计
如果你非要用Agent做故障诊断，我建议的架构是这样的：
第一层：规则引擎兜底。覆盖Top 100高频故障码，直接映射到维修方案。这一层响应时间<100ms，准确率>95%。不要用大模型，用决策树或者查找表就行。
第二层：小模型做分类。对于规则引擎覆盖不到的故障，用一个小模型（比如BERT-base或者轻量级CNN）做故障分类。这一层响应时间<500ms，准确率>85%。
第三层：大模型+Agent做长尾推理。对于小模型也搞不定的复杂故障，才走大模型+Agent。Agent负责调用维修手册、历史工单、技术通报等工具，大模型负责推理和生成建议。这一层响应时间<3s，准确率>70%就算合格。
这个架构的核心思想是分层过滤，把大模型和Agent放在最后一层，而不是第一层。为什么？因为大模型和Agent的成本高、延迟高、不确定性高，它们只适合处理长尾问题。高频问题用规则和小模型解决，又快又准又便宜。
注意：Agent的工具调用（Tool Use）在车云场景下要特别小心。我见过一个Agent调用“查询车辆位置”工具，结果因为权限配置错误，把A用户的位置返回给了B用户。这种事故在车云场景下是致命的。所有工具调用必须做严格的权限校验和审计日志。
3.4 Agent并发扛不住的真实原因
热词里有个“ai agent 怎么扛并发”，这个问题在车云场景下特别突出。我实测过一个基于LangChain的Agent，单实例QPS大概在5-10左右，延迟P99在5s以上。为什么这么低？
原因有三个：第一，大模型推理本身慢。一个7B模型在A10上推理，单次生成500 token大概要2-3秒。第二，Agent的ReAct循环会多次调用大模型。一个简单的故障诊断，Agent可能要调用3-5次大模型（思考→调工具→再思考→再调工具→生成答案），延迟直接乘以5。第三，工具调用是同步阻塞的。如果工具是查数据库，那还好；如果工具是调另一个API，那延迟就不可控了。
怎么扛并发？我的经验是：
- 异步化：Agent的整个执行链路改成异步，用消息队列削峰。
- 缓存：高频问题的Agent输出直接缓存，下次同样问题直接返回。
- 降级：并发超过阈值时，自动降级到规则引擎或小模型。
- 限流：按用户等级和场景做限流，比如故障诊断优先于闲聊。
这些手段组合起来，单实例QPS能提到50左右。但说实话，车云场景的并发峰值其实不高——一辆车一天可能就触发几次AI请求，几十万辆车的并发峰值也就几百QPS。真正难的不是并发量，而是并发下的确定性。你不能因为并发高了就返回错误答案，这在故障诊断场景下是不可接受的。
4. 死局三：工程化能力缺失，Demo即巅峰
4.1 从Demo到量产之间的鸿沟
我见过太多团队，Demo做得惊艳，一上量产就崩。这个鸿沟有多大？我举个例子。
Demo阶段：用一台服务器，跑一个7B模型，接一个测试车辆的数据，故障诊断准确率90%。团队很开心，觉得可以量产了。
量产阶段：要部署到车云平台，要支持几十万辆车的并发，要保证99.9%的可用性，要在3秒内返回结果，要支持OTA更新模型，要符合功能安全要求，要有完整的监控和告警。这时候团队发现，原来的架构根本撑不住。
这个鸿沟的本质是什么？Demo是“功能验证”，量产是“工程验证”。功能验证只需要证明“能做”，工程验证需要证明“稳定地做、便宜地做、可维护地做”。
我列一下从Demo到量产需要补的工程化能力：
| 能力维度 | Demo阶段 | 量产阶段 |
|---|---|---|
| 部署 | 单机Docker | K8s集群+多可用区 |
| 模型 | 单模型 | 多模型版本管理+灰度发布 |
| 数据 | 静态数据集 | 实时数据流+特征存储 |
| 监控 | 打印日志 | 全链路追踪+指标告警 |
| 安全 | 无 | 权限校验+审计日志+数据脱敏 |
| 成本 | 不计 | 单次推理成本<0.01元 |
| 合规 | 无 | 功能安全+数据合规 |
这张表里的每一项，都是需要专门团队花几个月去补的。但很多车企的AI团队只有算法工程师，没有工程化团队。算法工程师把模型训出来，往服务器上一扔，就觉得完事了。结果一上量产，各种问题爆发。
4.2 车云AI的工程化落地清单
如果你现在正在做车云AI项目，我建议你对照这个清单自查：
基础设施层：
- [ ] 是否有K8s集群，支持自动扩缩容？
- [ ] 是否有模型仓库，支持版本管理和回滚？
- [ ] 是否有特征存储，支持在线和离线特征一致性？
- [ ] 是否有消息队列，支持削峰填谷？
模型服务层：
- [ ] 是否支持多模型路由（规则/小模型/大模型）？
- [ ] 是否有模型推理的GPU池化，提高利用率？
- [ ] 是否有模型量化/蒸馏，降低推理成本？
- [ ] 是否有A/B测试框架，支持灰度发布？
数据层：
- [ ] 是否有实时数据流处理（Flink/Spark Streaming）？
- [ ] 是否有数据质量监控，自动发现数据异常？
- [ ] 是否有数据脱敏，符合隐私合规？
- [ ] 是否有数据血缘，支持问题追溯？
应用层：
- [ ] 是否有全链路追踪（Trace ID贯穿车端到云端）？
- [ ] 是否有指标监控（延迟、准确率、成本）？
- [ ] 是否有告警机制（模型漂移、服务降级）？
- [ ] 是否有降级预案（大模型挂了走小模型）？
这个清单里的每一项，都是我踩过坑之后总结出来的。比如模型量化，我们一开始用FP16推理，单次成本0.05元，后来改成INT8量化，成本降到0.02元，准确率只掉了1%。再比如GPU池化，我们用Triton Inference Server做动态批处理，GPU利用率从30%提到70%，成本直接减半。
实操心得：车云AI的成本大头在GPU推理。如果你的单次推理成本超过0.1元，那这个项目在商业上很难成立。因为一辆车一年可能触发几百次AI请求，乘以几十万辆，成本就是千万级。所以工程化的核心目标之一就是降本。
4.3 大模型微调在车云场景的实战
热词里有“大模型微调实战”“大模型微调技术”，我聊聊在车云场景下微调的真实经验。
首先，不是所有场景都需要微调。故障诊断场景，如果只是做故障码到维修方案的映射，那用RAG（检索增强生成）就够了，不需要微调。RAG的好处是知识更新快——维修手册更新了，直接更新向量库就行，不用重新训模型。
那什么时候需要微调？当你的场景有大量领域术语和特定表达时。比如用户描述故障的方式千奇百怪：“车抖得像筛糠”“加速的时候一窜一窜的”“刹车踩下去软绵绵的”。这些表达，通用大模型能理解个大概，但不够精准。这时候用几千条标注数据做LoRA微调，效果会明显提升。
微调的实操步骤：
- 数据准备：收集用户真实描述+对应的标准故障描述，至少2000条。
- 数据清洗：去掉重复、错误、敏感的样本，确保数据质量。
- 格式转换：转成Alpaca格式或ShareGPT格式。
- LoRA配置：rank=8，alpha=16，target_modules选q_proj和v_proj。
- 训练：用A100 40G，batch_size=4，gradient_accumulation=8，学习率2e-4。
- 评估：在留出集上评估，重点看故障分类准确率和生成建议的可用性。
- 部署：LoRA权重和基座模型合并，或者用vLLM做动态加载。
我实测下来，LoRA微调在故障描述归一化任务上，准确率能从基座的65%提到88%。但要注意，微调数据一定要覆盖长尾场景，否则模型会在常见故障上过拟合，遇到罕见故障就胡说八道。
4.4 故障诊断代码的工程化实践
热词里有“故障诊断代码”，我分享一段我们在用的故障诊断特征提取代码。这段代码的核心是从原始CAN信号中提取时域和频域特征，用于后续的故障分类。
import numpy as np from scipy import signal from scipy.stats import kurtosis, skew def extract_time_domain_features(signal_data): """提取时域特征""" features = { 'mean': np.mean(signal_data), 'std': np.std(signal_data), 'rms': np.sqrt(np.mean(signal_data**2)), 'peak': np.max(np.abs(signal_data)), 'kurtosis': kurtosis(signal_data), 'skewness': skew(signal_data), 'crest_factor': np.max(np.abs(signal_data)) / np.sqrt(np.mean(signal_data**2)), 'shape_factor': np.sqrt(np.mean(signal_data**2)) / np.mean(np.abs(signal_data)), } return features def extract_frequency_features(signal_data, fs=100): """提取频域特征""" freqs, psd = signal.welch(signal_data, fs=fs, nperseg=256) features = { 'total_power': np.trapz(psd, freqs), 'peak_freq': freqs[np.argmax(psd)], 'spectral_centroid': np.sum(freqs * psd) / np.sum(psd), 'spectral_bandwidth': np.sqrt(np.sum(((freqs - np.sum(freqs * psd) / np.sum(psd))**2) * psd) / np.sum(psd)), } return features def extract_all_features(can_signal, fs=100): """提取全部特征""" time_features = extract_time_domain_features(can_signal) freq_features = extract_frequency_features(can_signal, fs) return {**time_features, **freq_features}这段代码看着简单，但有几个坑：第一，采样率要对齐。不同车型的CAN信号采样率不一样，有的是10Hz，有的是100Hz，提取频域特征前必须重采样到统一采样率。第二，信号长度要统一。有的故障信号只有几秒，有的有几十秒，需要做窗口切分或者padding。第三，特征要做归一化。不同特征的量纲差异很大，不做归一化会影响模型收敛。
注意：故障诊断代码的工程化，重点不是算法多先进，而是可复现。同样的输入，必须得到同样的输出。所以所有随机种子要固定，所有依赖版本要锁定，所有中间结果要可追溯。
5. 三个死局的破局思路
5.1 数据闭环：从“等数据”到“造数据”
数据闭环断裂的破局点，不是等数据攒够，而是主动造数据。怎么造？
第一，仿真数据。用物理模型或者GAN生成故障样本。比如电池故障，可以用电化学模型仿真不同老化阶段的信号；电机故障，可以用有限元仿真不同磨损程度的振动信号。仿真数据的优势是标签准确、成本低、可大规模生成。劣势是跟真实数据有分布差异，需要做域适应。
第二，迁移学习。从实验室台架数据迁移到实车数据。台架数据的特点是工况可控、标签准确，但跟实车工况有差异。可以用MMD（最大均值差异）或者对抗训练做域适应。
第三，主动学习。让模型主动挑选最有价值的样本让人标注。比如模型对某个样本不确定，就挑出来让专家标。这样标注效率最高，用最少的标注量达到最好的效果。
这三个手段组合起来，可以在数据量不足的情况下，把模型效果做到可用水平。我实测过，用仿真数据预训练+台架数据微调+主动学习精选样本，在只有500条真实故障样本的情况下，故障诊断准确率能做到82%。虽然不如数据充足时的95%，但已经比干等数据强太多了。
5.2 场景定义：从“技术驱动”到“价值驱动”
场景定义错位的破局点，是从价值出发，而不是从技术出发。怎么判断一个场景有没有价值？
我有个简单的判断标准：这个场景，如果不用AI，用规则或者人工，成本是多少？用了AI之后，成本降了多少？
比如故障诊断，不用AI的话，用户打电话给4S店，4S店技师凭经验判断，平均耗时15分钟，成本50元。用了AI之后，用户拍照或者描述，AI 3秒给出建议，成本0.1元。这个价值是明确的。
再比如座舱闲聊，不用AI的话，用户根本不会跟车机闲聊。用了AI之后，用户还是不会闲聊。这个场景就没有价值。
所以我的建议是：每个汽车AI场景立项前，先算一笔账。算清楚不用AI的成本、用AI的成本、用AI之后的收益。如果算不过来，就别做。
5.3 工程化：从“算法思维”到“产品思维”
工程化缺失的破局点，是算法工程师要有产品思维。什么意思？
算法工程师通常想的是“我的模型准确率多少”，产品思维想的是“我的模型在什么条件下会失效，失效了怎么办”。
举个例子：故障诊断模型在测试集上准确率90%，算法工程师觉得可以上线了。但产品思维会问：那10%的错误是什么？是误报还是漏报？误报的代价是什么？漏报的代价是什么？如果误报导致4S店白跑一趟，成本500元；漏报导致用户路上抛锚，成本5000元。那模型应该偏向误报还是漏报？
这些问题，算法工程师通常不关心，但产品经理必须关心。所以我的建议是：汽车AI项目组里，必须有懂业务的产品经理，而且产品经理要有话语权。不能让算法工程师自己定义场景，他们定义出来的场景往往是“技术上很酷但用户不需要”的场景。
5.4 组织架构：从“算法团队”到“全栈团队”
最后说一个组织架构的问题。我见过太多车企的AI团队，只有算法工程师，没有数据工程师、没有后端工程师、没有运维工程师。这种团队做Demo可以，做量产必崩。
一个能打硬仗的汽车AI团队，至少需要这些角色：
| 角色 | 职责 | 人数建议 |
|---|---|---|
| 算法工程师 | 模型训练、调优、评估 | 2-3人 |
| 数据工程师 | 数据链路、特征工程、数据质量 | 1-2人 |
| 后端工程师 | 模型服务、API、工具调用 | 2-3人 |
| 运维工程师 | K8s、监控、告警、成本优化 | 1-2人 |
| 产品经理 | 场景定义、需求分析、价值评估 | 1人 |
| 领域专家 | 故障诊断、维修方案审核 | 1-2人（可兼职） |
这个配置大概8-12人，是一个能打硬仗的最小团队。如果只有2-3个算法工程师，那建议先别做量产，先把Demo做好，证明价值，再争取资源。
6. 常见问题与排查技巧实录
6.1 故障诊断模型上线后误报率高怎么办
这是最常见的问题。模型在测试集上好好的，一上线误报率飙升。排查思路：
第一步，检查数据分布。测试集和线上数据的分布是否一致？我见过一个案例，测试集是夏天采集的，线上是冬天，电池温度分布完全不同，模型直接崩了。解决办法是做在线数据监控，发现分布漂移就触发模型更新。
第二步，检查特征计算。线上特征计算和离线特征计算是否一致？我见过一个案例，离线用Python算特征，线上用C++算，浮点数精度不同，导致特征值有微小差异，模型输出就变了。解决办法是特征计算逻辑统一，最好用同一套代码。
第三步，检查阈值。模型的分类阈值是否适合线上场景？测试集上阈值0.5，线上可能0.7更合适。解决办法是用线上数据做阈值调优，找到误报和漏报的平衡点。
第四步，检查标签。线上的“误报”真的是误报吗？有时候是用户没理解，或者4S店没检查出来。解决办法是建立反馈闭环，让4S店反馈诊断结果，持续优化模型。
6.2 Agent响应太慢怎么优化
Agent响应慢是通病。优化思路：
第一，减少大模型调用次数。ReAct循环里，每次思考都调大模型，太浪费。可以用小模型做意图识别和工具选择，只把最终生成交给大模型。
第二，并行调用工具。如果Agent需要调多个工具，而且工具之间没有依赖，那就并行调。比如查维修手册和查历史工单可以同时进行。
第三，缓存高频结果。高频问题的答案直接缓存，下次同样问题直接返回。缓存命中率能做到30%的话，平均延迟能降30%。
第四，流式输出。大模型生成是逐token的，用流式输出可以让用户先看到部分结果，感知延迟降低。
第五，降级预案。如果大模型响应超过3秒，自动降级到小模型或者规则引擎。用户体验比准确率更重要。
6.3 大模型微调后效果反而变差怎么办
微调后效果变差，通常是这几个原因：
第一，数据质量差。微调数据里有错误标签、重复样本、格式不一致。解决办法是人工审核微调数据，至少抽检20%。
第二，过拟合。微调数据太少，模型记住了训练样本，泛化能力下降。解决办法是增加数据量，或者降低LoRA rank，或者增加dropout。
第三，灾难性遗忘。微调后模型忘了通用能力。解决办法是混合通用数据和领域数据一起微调，比例大概1:1。
第四，评估集泄露。评估集和训练集有重叠，评估结果虚高。解决办法是严格划分训练集、验证集、测试集，确保没有重叠。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查动作 | 解决方案 |
|---|---|---|---|
| 模型上线后准确率下降 | 数据分布漂移 | 对比线上线下数据分布 | 在线监控+模型更新 |
| Agent响应超过5秒 | 大模型调用次数多 | 统计Agent执行链路 | 减少调用+并行+缓存 |
| 微调后效果变差 | 数据质量差/过拟合 | 检查微调数据+评估集 | 数据清洗+降低rank |
| 并发高了就报错 | 同步阻塞+无降级 | 压测+看日志 | 异步化+限流+降级 |
| 成本超预算 | GPU利用率低 | 看GPU监控 | 量化+池化+动态批处理 |
| 用户投诉答非所问 | 场景定义错位 | 看用户反馈 | 重新定义场景+规则兜底 |
7. 我个人在实际操作中的体会
做了这么多年汽车AI，我最大的体会是：这个行业不缺技术，缺的是对技术的克制。大模型很强大，Agent很酷，但不是所有场景都需要它们。故障诊断场景，规则引擎+小模型能解决80%的问题，大模型和Agent只应该用来处理剩下的20%长尾。如果你反过来，用大模型和Agent去处理80%的高频问题，那项目必死。
另一个体会是：汽车AI项目的成败，不在算法，在工程。我见过太多算法很牛但工程一塌糊涂的项目，最后都黄了。反而是一些算法一般但工程扎实的项目，活了下来，而且越活越好。因为工程扎实意味着数据闭环能跑通、模型能持续迭代、成本能控制住。这些才是项目能活下来的根本。
最后分享一个小技巧：如果你要立项一个汽车AI项目，先别写PPT，先写一个“失败预案”。写清楚这个项目可能怎么失败，失败了怎么办。如果写不出来，说明你还没想清楚。如果写出来了，那这个项目大概率能成，因为你已经提前把坑都想到了。
这个内容后续还可以这样扩展：比如具体聊聊车云场景下的模型量化实战，或者Agent在故障诊断中的工具调用设计，或者大模型微调的数据准备技巧。每一个点都能单独写一篇。
