1. 为什么“AI定义汽车”的成败，先卡在AI Infra上
前阵子有位做算法的朋友跟我抱怨：模型在云端的评测集上刷到第一，一上实车就被测试同事打回原形，白天晚上表现差异大，偶尔还会碰到几个完全没见过的场景，整个团队都在忙着“修模型”。我当时直接问他一句话：你们的数据回传链路一天能进多少有效场景？你们的车端推理跑的是量化前的模型还是量化后的模型？你们的仿真回归有没有把上个月的所有badcase都跑一遍？他愣了半天。这个朋友遇到的问题，其实是大量做智能汽车团队的通病——算法、算力、模型大家都舍得投入，但真正决定一辆车“AI能力”能多快迭代的，恰恰是那条看不见的AI Infra链路。
AI Infra这个说法这两年越来越高频。它不是什么新算法，也不是某一个具体芯片，而是从数据采集、回传、存储、标注、训练、仿真、评测、部署、OTA到车端运行时监控的一整套基础设施。放到整车语境里，它承担的就是“AI定义汽车”的全域智能底座这个角色：没有底座，模型再强也只是实验室里的demo；底座扎实，新模型才能在几天内完成训练、验证、上车、灰度、放量。
传统汽车定义功能靠的是硬件平台和ECU软件，功能出厂即冻结，最多通过4S店升级一下固件。但现在一辆智能汽车的核心竞争力，取决于AI模型能否持续进化：感知模型要覆盖更多长尾场景，规控策略要更像老司机，座舱模型要能理解更复杂的自然语言指令。这些能力没有一个是一锤子买卖，它们依赖高频的数据闭环和模型迭代。而迭代速度，完全被AI Infra的工程化程度锁死。
我常喜欢用一个比喻：如果把整车当成一个人，AI算法是大脑，芯片是心脏，那AI Infra就是遍布全身的神经和血管。大脑再聪明，神经传导慢、供血不足，这个人照样跑不起来。所谓“全域”，指的就是它不止管云端的大规模训练集群，还管车端的推理算力、传感器数据链路、远程升级通道，甚至包括车辆运行一年之后的数据回流。这个底座覆盖了车辆完整生命周期，少了任何一环，AI迭代就会卡壳。
这里需要先给AI Infra划个范围，避免聊到最后变成“服务器运维”的另一种说法。我理解的智能汽车AI Infra至少包含以下五层：
| 层次 | 职责 | 整车场景举例 |
|---|---|---|
| 数据层 | 采集策略、车端过滤、回传、脱敏、存储、索引、场景挖掘 | 从海量路采数据里捞长尾corner case |
| 训练层 | 大规模算力集群、分布式训练、断点续训、资源调度 | 千卡并行训练感知大模型 |
| 仿真评测层 | 场景库、离线指标、闭环仿真、实车路测回归 | 新版本规控策略在仿真环境跑完上万个场景 |
| 部署层 | 模型转换、量化、推理引擎、车端运行时、OTA | 把云端训练好的模型安全高效地跑到车规芯片上 |
| 运营层 | 影子模式、灰度发布、在线监控、数据回流 | 新车模型在影子模式跑几周，对比决策一致性 |
这五层叠在一起，才是完整的“全域智能底座”。很多团队一开始只把注意力放在训练集群上，觉得买个几十张卡、搭个训练框架就是做了AI Infra，但没过半年就发现，算法在云端跑得飞起，上车和迭代却处处是瓶颈。做AI Infra，本质上是在做一套端到端的“模型迭代流水线”，让数据、模型、算力、车端在一条高效的闭环里运转。这一篇我就把自己在这些层里实战趟过的经验摊开，从数据链路讲到底座落地，希望对正在做智能汽车基础架构的人有点帮助。
2. 从数据回传开始，先把数据闭环这条链路打通
2.1 车端数据采集，不是把传感器数据导出来就行
我见过不少团队做数据采集，策略很粗放：定义一批触发规则，比如急刹车、疲劳驾驶、车道偏离，规则一触发就把前后几路摄像头和雷达数据全存下来，回传云端。这种方式不能说错，但它会带来两个严重问题。
第一个问题是数据偏差。靠简单规则触发，采回来的数据永远集中在规则覆盖的场景里，真正算法需要的长尾场景——比如异形车辆、遮挡物、施工改道、极端天气——反而漏掉了。第二个问题是数据质量差。车端采集如果只是为了“把数据存下来”，往往没有保存好传感器时间戳、标定参数、车辆底盘状态这些元数据。等数据回到云端要训练模型时，才发现不知道这条数据对应的车速、转向角、自车位置信息，也没法把激光雷达点云和相机画面在时间上对齐，这批数据基本就废了。
正确做法是先定义“这条数据将来要用来解决什么问题”，再倒推采集策略。比如目标是提升夜间感知，那采集规则里就必须包含光照强度、时间、天气这些条件；目标是提升路口场景，就要结合地图信息和车辆转向动作来判断车辆是否在路口。采集策略本身就是要用数据驱动的方式来做，让算法团队和数据平台团队共同维护一套场景触发配置，而不是靠几个固定阈值打天下。
在车辆端，采集模块的职责还包含一层“过滤”。不要把所有触发数据都回传，带宽和存储都是成本。车端可以先做初步的场景分类，低价值数据只保留索引不保留原始数据，高价值数据做小体积压缩后回传。这个工作做得越细，云端存储和后续处理压力越小。很多团队前期贪多，总担心漏数据，最后数据堆了一屋子，真正能被用进训练的不到十分之一。
2.2 回传链路与存储：过滤、脱敏、压缩缺一不可
数据要回到云端，中间要过无线网络。无论是走4G/5G还是Wi-Fi热点，回传策略都得考虑流量成本、带宽峰值和网络不稳定问题。我的经验是，回传必须设计成“多优先级、可断点续传”的异步任务：紧急场景数据用高优先级通道尽快传回，常规数据在夜间或者车辆驻车有稳定网络时慢慢传。车端本地还要预留可靠的缓存空间，防止网络不佳时数据丢失。
还有一个不能被忽视的处理是脱敏。道路采集数据里经常包含行人脸部、车牌号，有些还可能涉及小区内部环境等隐私信息。数据一旦落地云端，合规风险是逃不掉的。我见过有团队在数据回传之后再做脱敏，结果等发现人脸没遮干净，大半批数据都要返工重处理，浪费大量算力和人力。正确的做法是在车端完成检测、打码、模糊化之后，再进入回传链路。车端脱敏会增加一些前向计算压力，但这笔成本必须花。
云端存储这块，大多数人以为建一个对象存储桶就行了，实际上制约数据使用效率的是“索引”和“目录”。没有元数据索引的数据湖就是数据沼泽。数据回传之后，至少要自动建立以下维度的标签：采集时间、天气、光照、道路类型、城市、场景事件类型、传感器配置版本、车辆型号、算法版本。这些字段会被后续的场景挖掘、训练集构建、仿真场景生成反复用到。
到这一步，数据链路才勉强算“通”了。我经常说，数据平台建设最忌讳一步到位，一开始不要想着把所有采集数据都完美组织起来，先保证元数据从源头就规范，后续补历史数据会痛苦得多。很多团队后面花几个月去清洗前期的脏数据，根子就是当时没在采集端把元数据格式定好。
2.3 数据挖掘与标注，决定模型迭代的上限
数据回传之后，场景挖掘是接下来最关键的一环。别把所有数据都送去人工标注，成本会立刻爆炸。比较靠谱的流程是：先让云端用已上线的模型对海量回传数据做一轮“预识别”，把模型表现不稳定的、置信度偏低的、预测结果和真值偏差大的样本自动捞出来，再结合人工抽检确认。这个过程能快速产出高质量的难例数据集。
难例数据的标注也需要工具和流程支撑。纯人工框框效率太低，纯自动标注又容易带着模型自身的错误偏好。我的做法是先由自动标注模型给出预标注结果，再由人员做校正，同时标注平台上要有“质检抽检”和“多人一致性校验”机制，避免个人标注风格影响标签质量。标注质量直接影响模型上限，一个标签错位的训练集，比没有这个数据更可怕，因为它会让模型学到错误映射。
这里还要强调一下数据版本管理。训练数据集是会持续演化的，今天加了1000个夜间场景，明天加了500个异形车场景，如果对数据集没有版本概念，模型训练完就说不清自己见过了哪些数据，评测结果也没有办法溯源。建议把数据集像代码一样管理，每次变更都有记录，训练任务里记录数据集commit号，这样模型、数据、代码三者之间才能做到可追溯。这个习惯越早建立越好，团队到后期一定会感谢当初坚持做了这件事。
3. 训练侧基础设施：算力集群、分布式训练与评测体系
3.1 训练集群的软硬配置怎么做才算及格
训练侧是多数人理解中“AI Infra”的全部，因为它最早被感知到。确实，模型训练是最吃算力的环节，车端感知、规控、座舱大模型的训练量都很大。但我的判断是：训练集群建设，硬件先放一边，先把软件和流程想清楚。
集群硬件层面，无非是几件套：GPU服务器、高速互联网络、共享存储。这三样缺哪样都白搭。很多人只盯着GPU卡的数量，却忽略了高速网络和存储带宽，结果就是卡一多，分布式训练通信就变成了瓶颈，几千张卡只能跑出几百张卡的效率。互联网络至少要做到计算节点间无损低延迟，存储要能支撑大文件高吞吐读写和大量小文件的元数据访问。
软件层面反而才是真正拉开差距的地方。一个合格的训练平台，至少要有统一的资源调度、任务排队、镜像管理、日志采集、监控告警、分布式训练框架适配这些能力。不要一上来就搞很重的自助平台，可以先用脚本加调度器把流程跑通，再逐步完善。但有一件事必须一开始就做——统一GPU资源申请和配额管理。没有配额制度的集群，最后一定会被少数几个“算力黑洞”任务占用，其他团队排不上队。
我在一个项目里还遇到过这种情况：同一个训练任务，跑在不同节点上，结果出现微小差异，导致模型指标不稳定。排查了很久才发现是有两台机器硬件驱动版本不一致。所以训练集群的镜像和驱动管理必须统一，最好能做到环境可复现。这些都是看不见但特别磨人的坑。
3.2 分布式训练的工程细节：断点续训与数据管道
当模型大到单卡放不下，或者训练数据量大到单卡跑不完，分布式训练就不可避免。在智能驾驶场景里，感知大模型的训练数据动辄几百万帧，模型参数量从几亿到上百亿不等，多机多卡并行是常态。但分布式训练不是把训练框架参数一改就能稳定跑起来的，真正花时间的往往是稳定性问题。
我最看重的三个细节：
第一，断点续训。一个训练任务跑三五天甚至几周，中途断电、机器故障、显存溢出都可能导致任务中断。不接受断点续训的集群，会让团队不敢跑大规模任务，因为失败一次的成本太高。训练框架要周期性地保存checkpoint，平台要有故障自动重启任务的机制，哪怕最坏情况下多损失半小时的算力，也比从头再来强。
第二，数据管道和计算的重叠。训练框架启动时如果数据加载跟不上GPU计算速度，再强的算力也会在那干等。数据读取、预处理、增强这些最好都放在CPU侧并行流水线里，做到“边读边训”。这个优化效果立竿见影，往往比多申请几十张卡还实在。
第三，实验追踪。训练过程中的每个配置、每个超参数、每个数据版本，都要能被记录和回溯。不然两个模型指标对比出来，负责训练的同事却说“我不记得当时batch size用的多少”，项目迭代立刻乱套。实验追踪系统是训练平台里投入产出比最高的一个组件。
3.3 仿真与评测，把“训练得好”变成“真能跑”
模型在训练集上指标好，不意味着在真实场景里表现好。所以训练侧的最后一步不是“模型收敛”，而是“通过评测”。评测体系分三层递进：
第一层是离线数据集评测。固定一批不参与训练的高质量测试集，包含各种场景类型，每次模型迭代都要在同样条件下跑一遍，保证指标曲线可比。这一层最容易做，但只靠它远远不够。
第二层是闭环仿真。自动驾驶的规控模型尤其需要这种评测。把感知识别结果放进仿真环境里，让虚拟车辆在场景库中行驶，观察它能否安全完成各种交通交互。场景库的构建本身也是AI Infra的一部分：从真实路采数据中提取关键场景，生成参数化变体，再放到仿真环境里做闭环测试。
第三层是实车路测。实车测试成本最高、周期最长，但无法完全替代。一个好的AI Infra，会把路测中发现的失败场景自动沉淀回场景库，成为下一轮训练和评测的回归用例。我特别强调这个“回归闭环”，因为它保证了问题被解决后不会复发。
很多团队在评测环节最常犯的错误是，把“离线评测指标涨了”当成“模型可以上车了”。实际上，离线指标和真实体验之间有巨大的gap，必须要靠仿真和实车评测两层来做缓冲。AI Infra做得好的标志，不是说模型训练得有多快，而是模型从训练完成到完成全部评测、确认可以上车，这个过程越来越自动化、越来越短。
4. 车端AI Infra：模型上车不是把模型文件塞进芯片
4.1 车端推理的软硬协同设计
训练侧的模型通常跑在高精度GPU上，但车端算力芯片资源有限、功耗敏感，不可能直接拿训练时的模型格式去跑。这里就需要AI Infra里非常重要的一环——模型部署优化。
车端推理首先要做模型转换，把训练框架的模型格式转换到车端推理引擎支持的格式，过程中要处理算子映射。然后是量化，最常见的做法是把FP32模型转成FP16或者INT8，精度会有轻微损失，但推理速度大幅提升、内存占用减少。很多人以为量化是一个开关，开了就行，实际上量化后的模型在边界场景容易出现精度崩坏。稳妥的做法是准备一个覆盖关键场景的校准数据集，量化后用这个数据集对比量化前后的输出差异，发现异常就针对性做算子回退或者混合精度。
车端推理引擎还要面对多传感器融合的调度问题。摄像头、激光雷达、毫米波雷达、超声波传感器都在以不同频率产生数据，AI模型需要在一个严格的时间窗口内完成融合推理。如果推理任务的调度设计得不好，传感器数据等待时间不一致，模型输入的就是“错位”的数据，推理结果自然不靠谱。
还有一点是车端的资源隔离。在同一颗车规芯片上，可能同时要跑自动驾驶感知、规控、座舱语音、驾驶员监控等多个AI任务。AI Infra必须提供任务级的算力分配和优先级管理：紧急的安全相关推理要保证低延迟，非紧急的座舱功能可以在资源空闲时再跑。底层操作系统、中间件、AI推理框架之间要配合好，这绝对不是把网络模型文件打包丢进芯片就能完成的。
4.2 安全机制下的冗余与降级
车端AI和云端AI一个本质区别，就是车端AI的错误会直接影响物理世界安全。所以AI Infra在车端必须考虑安全兜底机制。我不建议把系统全部押注在单个大模型上，尤其是在涉及车辆控制的核心链路上。工程上常用“主导模型加降级策略”：主模型失效时，系统迅速切换到一个保守但可靠的规则模型，保证车辆进入安全状态，比如减速靠边停车。
这种设计对基础设施提出的要求是：主模型和降级模型必须在同一运行时环境里被管理，切换逻辑要有严格的状态机，而且切换动作本身要被埋点记录、回传云端分析。很多团队把降级策略写在应用代码里，却没有统一的切换框架，出了问题很难排查。
车端推理还需要非常重视确定性。同一份模型、同一份输入，车端推理引擎最好每次都给出相同输出，否则测试和验证都无从谈起。为了提高确定性，需要排除非必要的并行扰动、固定算子执行顺序、对浮点数累加顺序做约束。这里面的细节很多，但都是车端AI Infra绕不开的硬功。
安全认证和功能安全标准也是车端AI Infra的一部分，虽然有些团队觉得这属于“合规工作”，但它实际会影响整个技术架构。比如功能安全要求越高的模块，越倾向于简单、可证明、可解释的算法，这在AI模型设计早期就要考虑进去。等到模型都训练完了再补功能安全设计，成本会非常高。
4.3 车内通信与中间层，为什么也算Infra
很多人以为AI Infra只涉及“AI相关”的软硬件，但我做过几个项目后发现，车内通信链路和中间件才是车端AI运行质量的隐形命门。
传感器数据从物理接口进入计算平台，要经过一条完整的数据通路。如果中间某个环节的带宽设计不足，或者某个通信模块出现偶发超时，AI模型拿到的数据就会出现卡顿和丢帧。在实车调试中，我遇到过一次“幽灵问题”：推理模型在测试台上一切正常，上车后发现偶发延迟。查到最后，根因是车内一条总线的仲裁优先级配置不合理，导致视频流被其他周期报文挤占。
所以车端AI Infra团队必须懂“车”。除了推理引擎、量化、算子优化，还要知道传感器接入、信号同步、总线通信、电源管理这些底层细节。一个合格的车端AI架构师，通常要能看懂网络拓扑和通信矩阵，知道不同信号的实时性要求。如果只懂云端那套部署方式，到车端会非常被动。
5. 面向整车生命周期的模型管理与OTA运营
5.1 模型仓库与版本追踪
当模型数量多起来之后，最害怕的事情就是“不知道哪个版本在跑”。训练侧有几十个实验版本，测试侧验证了十几个候选版本，上线后又因为有badcase迭代了好几个版本，如果没有系统性的模型仓库管理，很快会陷入混乱。
模型仓库不只是存模型文件，还要存关联的元数据：模型结构、训练数据版本、训练配置、测试集指标、仿真通过率、路测报告、量化参数、已知边界案例。我建议每个模型版本都生成一个全局唯一的版本号，并且让这个版本号贯穿整个发布流程。从计划发布到最终OTA，每一步都引用这个版本号，形成完整的追溯链。
模型仓库还有一个容易被忽略的作用：线上问题回溯。车端反馈回来一个case，说这个场景表现不好，这时候模型管理平台能快速回答“线上跑的是哪个模型版本、训练数据是什么、评测报告怎么说”，排查效率会大幅提升。没有这套能力，问题定位基本靠猜。
5.2 影子模式、灰度发布与回滚
模型上车不是“一次切换”，而是“渐进式放量”。这背后需要AI Infra提供一套完整的发布机制。
第一步是影子模式。新模型先以影子身份在车辆上运行，但它不参与实际控制，只把推理结果和当前线上模型的推理结果做对比。这个阶段可以积累大量真实道路数据，验证新模型在真实环境下的稳定性，又不会因为模型错误带来安全风险。影子模式的比对结果要回传云端，做统计分析和badcase挖掘。
第二步是灰度发布。在影子模式验证通过后，先让小批量车辆切换到新模型，继续监控关键指标，比如接管率、感知置信度、决策一致性。如果指标稳定，再逐步扩大灰度范围。这个过程必须配合远程监控和告警，一旦发现问题能立刻干预。
第三步才是全量发布。但即使全量发布了，也需要保留快速回滚的能力。OTA系统要支持差分升级和版本回退，模型文件最好可以独立于业务程序升级，这样回滚时不影响其他功能。很多团队一开始只做了“升上去”，没做“退回来”，后来被线上问题逼着补课，非常被动。
另外，模型OTA升级方案要充分考虑下载失败、安装失败、断电等异常情况，车端必须有可靠的恢复机制。车规级别的OTA可靠性设计，比互联网App的版本更新要严格得多，因为车上出问题会直接影响用户安全和品牌口碑。
5.3 建立车辆侧的可观测性
模型发布出去只是开始，AI Infra的运营层还要回答一个问题：模型在真实用户车辆上到底跑得怎么样。这个问题的答案依赖车辆侧的可观测性建设。
车端AI运行时要持续上报轻量化指标：推理耗时、CPU/GPU占用、内存占用、温度、模型输出置信度分布、识别异常次数、降级事件等。这些指标不是把所有原始数据都传回来，而是在车端做聚合统计，只传有价值的概要数据，控制流量成本。
一旦线上指标出现异常，比如某个车型版本的推理耗时突然上涨，或者某个天气条件下的感知置信度明显下降，运营平台要能快速从“指标异常”定位到“车辆范围”、“软件版本”、“数据特征”。这些能力都需要提前设计好，等到问题来了再补报表就来不及了。可观测性本质上是在为模型的下一次迭代提供输入，它把线上运营和离线研发真正打通，让“全域底座”形成了闭环。
6. 算力与成本：买卡、租卡还是混合调度？
6.1 算力需求估算的粗粒度公式
做AI Infra绕不开预算，而预算的核心是算力规模。经常有团队来找我，第一句话就问“我们该买多少卡”。这个问题没有标准答案，但我可以给一个非常实用的粗粒度估算思路。
先算训练需求：一次完整训练需要的总算力约等于（模型参数浮点运算次数×训练tokens数×训练轮数）/（芯片总算力×GPU利用率）。比如一个体量适中的自动驾驶感知模型，训练集有500万帧数据，跑20轮，假设单卡每秒能处理一定数量的样本，单卡训练一轮需要若干小时，那20轮就要乘以20，再留出实验和调参的倍率，通常是3到5倍。
还要考虑评测和仿真推理的算力需求。很多人只算训练算力，忽略了评测和仿真也需要GPU。尤其闭环仿真跑起来，瞬间算力需求甚至比训练还猛。仿真集群和训练集群可以在低峰期复用，但资源规划时要统一考虑。
最后要考虑峰值和平均值的差异。模型每天的训练任务不是匀速产生的，发版前集中训练、数据增长导致的重新训练，都会产生峰值需求。我的建议是核心基础算力自建或者长租，峰值弹性用短期资源或者云端资源补齐，不要按峰值采购硬件，否则平时利用率会很难看。
6.2 混合算力调度与利用率优化
自有算力和云端算力各有千秋，但管理混合算力是很多团队头疼的事情。我的经验是，不要为了混合而混合，关键是建立统一的调度入口。不管底层算力在哪里，用户提交训练任务的体验应该是一致的，平台层面再根据任务特点和资源价格把任务路由到最合适的算力池。
调度策略上，可以把训练任务按照优先级和可中断性分类。优先级高、不能中断的正式训练任务，跑在稳定的自有集群上；探索性实验、调参测试、数据预处理这类可中断任务，可以调度到更便宜或者弹性的资源上，随时会被抢占也不心疼。这种“混部+抢占”的模式能明显提升整体算力利用率。
利用率优化还有一个常见抓手是数据缓存。训练任务每次启动都要从存储系统读取大量数据，如果不做缓存，存储带宽会成为瓶颈。把高频使用的训练数据预加载到计算节点的本地缓存里，能大幅减少任务启动开销，让更多时间花在真正的计算上。我见过一个团队，通过数据缓存和更合理的调度策略，在不增加GPU的情况下把集群有效产出提高了百分之三四十。
6.3 成本治理，从分账开始
AI算力成本治理的第一原则不是省钱，而是“知道谁在花、花在哪、值不值”。没有分账机制的算力平台，用不了几个月就会出现大量重复实验和浪费。每个团队、每个项目、每个任务组的算力消费都要被记录，并且定期复盘。
复盘的时候不能只看GPU卡占用小时数，更要看“有效训练产出”。有的任务在集群上挂了一周，实际checkpoint只出了两个版本；有的任务一天跑完，产出了十几次有效实验。算力成本要和模型指标提升挂钩，这样才能判断投入的产出效率。
我个人的原则是：在算力成本上既不要抠门到影响迭代速度，也不要漫无目的地囤卡。算力扩张永远跟着数据规模和模型规模走，按需扩容、弹性伸缩。这里的平衡点需要持续调整，但不管怎么调，成本数据和实验数据都要透明，这是AI Infra团队必须守住的一条底线。
7. 落地AI Infra的几条实用经验
7.1 先捞最痛的一条链路，不要一开始就追求大而全
我见过太多团队拿着“全域智能底座”的宏大规划，第一版就上几十个模块，结果半年过去了，大部分功能处在“看起来有，用不起来”的状态。这里我要给出一个非常反共识的建议：AI Infra起步阶段，千万别做全平台。
正确的做法是先找一条对业务影响最大的链路，把它打穿。比如团队现在最大的痛点是“数据不能高效变成训练集”，那就先做数据采集、回传、脱敏、存储、索引、挖掘这条链路，做到让算法同学每天都能拿到新鲜的高质量数据。只要这条链路通了，模型的迭代速度立刻就有感知，团队信心也会建立起来。
第二条再打通训练评测链，第三条再做车端部署和OTA。每一条链路都要做到“真的能用”而不是“功能存在但没人用”。AI Infra的价值永远体现在使用频率上，一个只有PPT上好看、研发日常不用的平台，再精细也没有意义。
7.2 平台化是结果，不是起点
很多团队在建设过程中容易陷入“工具崇拜”，总觉得买了某套开源系统或者商业工具，AI Infra就自动建成了。但实际的智能汽车场景非常复杂，不是装一个标准软件就能覆盖的。真正好用的基础设施，一定是从解决具体问题出发，逐步打磨出来的内部平台。
我比较推荐“工具先行、平台后置”的路径：初期让各团队用脚本、命令行、可执行工具把流程跑起来；等流程稳定了，再把这些工具封装成平台服务，把最佳实践沉淀到系统里。这样做的好处是，平台里的每一步都是被实践验证过的，而不是架构师拍脑袋想出来的。平台化应该是过程的结果，而不是从一开始就追求的一个壳。
7.3 一点个人体会
如果只让我总结一条最值得投入的AI Infra能力，我会选“元数据治理”。从车端采集的第一秒开始，到数据回传、标注、训练、评测、上车、运营，所有环节都围绕元数据在协作。一个场景数据有没有清晰的场景标签，直接决定它能不能被挖掘；一个模型能不能追踪到训练数据和评测版本，直接决定线上问题能不能高效定位。
做了这么多年AI Infra，我最大的感受是，这个岗位不追求炫技，追求的是把每一件“基础的事”做到极致。数据不丢、链路稳定、版本可控、成本清晰，这些看起来都很朴素，但在整车智能的长期竞争中，恰恰是这些朴素的能力，决定了AI定义汽车这件事到底是停留在口号里，还是真正跑在路上。如果你现在正要开始搭建这套底座，不要怕慢，先把数据闭环走通，后面每一步都会顺起来。
