企业官网建设流程全解析

自动驾驶这个圈子有个挺有意思的现象：每年都会攒出一份“合集”，把这一年里踩过的坑、换过的方案、推翻重来的架构整理成册。我手上这份已经排到第24期了，从最早的“能不能跑起来”，到现在的“能不能稳定交付”，内容的重心几乎完全换了一轮。所谓自动驾驶合集24，说白了就是把感知、规控、数据闭环、工程落地这几条主线上的最新实践做一次系统盘点，它解决的不是“某个算法怎么写”，而是“一堆看起来很美的模块怎么拼成一台能连续跑几百公里不出岔子的车”。这份内容适合三类人看：刚进这个方向、被各种名词砸晕的新人；做了一两年、卡在调参和联调泥潭里的工程同学；以及负责技术选型、需要判断哪条路线值得投入的团队负责人。下面我按实际做项目的顺序往下拆，不讲空话，只讲能直接抄走的东西。

1. 这份“合集”到底在解决什么问题

1.1 从“功能演示”到“可持续交付”的分水岭

早几年做自动驾驶项目，评判标准很朴素：能不能在园区里绕一圈、能不能识别出锥桶、能不能自动泊车入库。那时候一个演示视频就能说明很多问题，团队也乐于把资源砸在“让某个功能跑通”上。但到了这两年，尤其是把系统往真实道路上放的时候，评价体系完全变了。我见过太多团队，Demo 阶段指标漂亮得不行，一上车连续跑两个小时就开始出各种莫名其妙的降级，要么是感知偶发丢目标，要么是规划在某个路口反复犹豫，要么是定位在树荫下跳变。这些问题单看都不致命，凑在一起就没法交付。

分水岭就在这里：功能演示考察的是“最坏情况下的最好表现”，而可持续交付考察的是“最好情况下的最坏表现”。前者可以靠挑场景、挑天气、挑路段来美化，后者必须在长时间、多工况、无人干预的条件下依然稳定。合集里我反复强调一个观点——评估一套自动驾驶系统，不要看它成功了多少次，要看它失败的时候是怎么失败的。是安全降级、是平稳接管，还是直接罢工，这三者的工程价值天差地别。

所以这份合集的第一个作用，是把评价维度从“单点能力”拉到“系统鲁棒性”。具体落地时会拆成几个可量化的东西：单位里程的人工接管次数、降级触发频率、同一场景重复通过的方差、以及各模块的超时率。这几个指标里，我最看重的是“同一场景重复通过的方差”，因为方差大说明系统行为不可预测，而不可预测在自动驾驶里比“稍微差一点”危险得多。一个每次都稳稳开得慢一点的车，比一个九次完美、一次抽风的车更值得信任。

1.2 一套技术栈的取舍逻辑：为什么我不建议“全都要”

新手最容易犯的错，是看到什么技术火就往架构里塞。激光雷达要有，毫米波要有，视觉 BEV 要有，端到端也要试试，最后搭出来的系统模块之间互相打架，出了问题根本定位不到是哪一层的锅。我在合集里给的建议很直白：先确定你的运行设计域，再倒推技术栈，而不是反过来。运行设计域就是这套系统承诺在什么条件下工作——什么道路类型、什么速度区间、什么天气、什么光照。这个边界一旦定死，很多选型问题会自动消失。

举个例子，如果系统只跑封闭园区、限速 30 公里每小时、光照条件基本可控，那高线数激光雷达的边际收益就很低，一颗中低线数的雷达配合环视相机完全够用，省下来的成本和算力可以投到规控的平滑性上。反过来，如果要做城市开放道路、要处理无保护左转和加塞，那感知的冗余度就必须拉满，因为这类场景的容错空间极小。我在一个模拟项目里做过对比：同一套规控代码，感知输入从“单激光雷达”换成“激光加视觉前融合”，路口通行成功率从七成出头提升到九成以上，但代价是算力占用翻了一倍多，帧率从 20 帧掉到 9 帧。最后我们没有全量上融合，而是做了分层——近距离用融合结果，远距离用纯激光，把算力花在刀刃上。

这个取舍背后有个朴素的逻辑：技术栈的复杂度必须和运行设计域的难度匹配，超配和欠配都是浪费。超配浪费的是成本和功耗，欠配浪费的是返工时间。合集里我列过一张对照表，把常见的几类场景和技术配置对应起来，虽然不能照搬，但至少能给选型一个起点。

注意：这张表只能当参考，不能当标准答案。真正决定配置的是你的失效容忍度和成本红线，先算清楚“一个感知漏检值多少钱”，再决定加不加传感器。

2. 感知链路：从传感器选型到目标输出的关键细节

2.1 传感器配置的三个硬约束与参数计算

选传感器这事，很多人凭感觉，觉得线数越高越好、像素越大越好。实际上有三个硬约束必须先算清楚：探测距离够不够、角分辨率够不够、时间同步能不能兜住。这三个约束任何一个不满足，后面算法再强也白搭。

先说探测距离。激光雷达标称的探测距离通常是在高反射率目标下测的，实际道路上大部分目标反射率很低，尤其是深色车辆和行人衣物。行业里常用的参考值是 10% 反射率下的有效距离，这个数值往往只有标称值的六成到七成。假设你需要在一百五十米外稳定检出目标，那选型时就得找标称两百米以上的型号，留出余量。这个余量不是浪费，是给雨雾天气和脏污镜头留的缓冲。

再说角分辨率，这个直接决定点云在远处的稀疏程度。角分辨率 θ 对应的横向点间距可以这么估：距离 d 处的点间距约等于 d 乘以 tanθ。取 θ 等于 0.1 度，在 100 米处点间距约 17.5 厘米，50 米处约 8.7 厘米。这意味着什么？在 100 米外，一个宽度 40 厘米的行人身上可能只落到两三个点，检测网络很容易漏。所以如果你的运行设计域要求远距离识别行人，要么提高角分辨率，要么靠视觉补，要么把最高车速压下来缩短所需探测距离。三者必选其一，没有第四条路。

相机这边算的是视场角和像素密度的平衡。水平视场角的估算公式是两倍反正切（传感器宽度除以两倍焦距）。假设用一颗 1/1.8 英寸传感器，有效宽度约 7.2 毫米，配 8 毫米焦距镜头，算下来水平视场角约 48 度。想看得更远就加焦距，但视场角会跟着收窄，近处盲区变大。我通常的做法是前视用两档焦距——广角负责近处路口和横穿目标，长焦负责远处车道线和对向车辆，两路图像在特征层做融合，比单用一颗广角靠谱得多。

第三个约束是时间同步，这个最容易被低估，也最容易在联调阶段把人逼疯。传感器之间的时间戳哪怕差 10 毫秒，在高速下就是实打实的距离误差。车速 72 公里每小时约等于 20 米每秒，10 毫秒对应 20 厘米；车速 120 公里每小时约 33.3 米每秒，10 毫秒对应 33 厘米。在近距离跟车场景里，33 厘米的纵向误差足以让规控做出完全错误的加减速判断。所以硬同步必须做，不能靠软件打时间戳凑合。

2.2 标定与时间同步：最容易翻车的地方

标定分内参和外参。内参相对稳定，出厂标一次，后面定期校验就行。外参才是重灾区，因为车辆一跑起来，震动、温度变化、轻微的碰撞都会让外参漂移。我遇到过最典型的情况：车跑了两个月，激光雷达和相机的外参偏了 0.3 度，人眼完全看不出来，但融合后的目标框开始系统性偏移，规控以为前车在旁边车道，实际就在正前方。这种问题排查起来极其痛苦，因为单看每个传感器的输出都是正常的。

我的做法是把外参校验做成常态化流程，而不是出了问题才做。具体是找一段有明确几何特征的路段，比如车道线清晰、有标准杆状物的直道，定期跑一遍，用点云和图像里的对应特征反算外参偏差，超过阈值就触发重标。阈值定多少？横向偏移超过 5 厘米、角度偏差超过 0.2 度就该处理了。这个数值不是拍脑袋，是按你系统最敏感的环节倒推的——如果规控对横向位置敏感度是 10 厘米，那标定误差必须控制在它的一半以内。

时间同步这块，硬件触发是基础，但触发之后的软件链路同样会引入延迟。相机曝光、图像传输、预处理、推理，每一环都有几十毫秒的耗时，这些延迟如果在融合时没有补偿，等于白做硬同步。我习惯在每条数据上带两个时间戳：一个是传感器采样时刻，一个是数据进入融合模块的时刻，融合时统一按采样时刻对齐，同时记录链路延迟用于监控。一旦某个传感器的延迟突然变大，往往是硬件或者驱动出了问题的前兆，这个监控比事后排查有用得多。

提示：标定间的温度要尽量接近实际运行温度。我见过在空调房里标得完美无缺，开到太阳底下晒半小时就偏的例子，原因就是镜头座和支架的热膨胀系数不一致。标定前先把车在目标环境里静置半小时，这个习惯能省掉后面很多扯皮。

2.3 多模态融合的工程化取舍：前融合、后融合还是特征融合

融合方式的选择，论文里讨论得很热闹，工程上其实就一句话：看你的算力预算和失效模式。后融合最简单，每个传感器各自出目标，然后在目标层做关联和滤波。优点是模块解耦、好排查、算力友好；缺点是信息损失大，两个传感器都漏的目标，融合也救不回来。前融合在原始数据层做，信息保留最完整，但对齐要求极高，标定误差会被放大，而且算力消耗大。特征融合是折中，在网络的中间层做注意力或者拼接，效果和成本都比较均衡。

我在几个项目里都倾向特征融合，但不是无脑用。有一个判断标准：如果你的传感器之间视野重叠区域很大、标定精度能稳定控制在 0.2 度以内，特征融合值得上；如果重叠区域小、或者标定稳定性差，老老实实做后融合，别给自己找麻烦。曾经有个项目为了追求“先进”，硬上了前融合，结果因为一颗相机的安装支架刚度不够，高速上轻微抖动就导致融合结果抖成一团，最后退回后融合，反而稳了。

还有一个细节很少有人提：融合的置信度怎么给。后融合里每个传感器都有自己的置信度，融合时简单取最大值或者加权平均都不太对。我的做法是按场景动态调权——晴天视觉权重大，雨雾天激光和毫米波权重大，夜间无路灯时视觉权重进一步下调。这个权重表不是拍脑袋定的，是用采集数据离线拟合出来的，具体做法是拿标注好的真值，统计各传感器在不同场景下的检出率和虚警率，反推出最优权重。这套东西做下来不复杂，但收益很直接，尤其是在恶劣天气下的误检率能降下来一大截。

3. 规控与仿真：让车“开得像人”而不是“开得像机器”

3.1 规划的分层设计与代价函数调参

规划这块，我坚持分层：全局路径负责“从 A 到 B 走哪条路”，行为决策负责“这个路口是等还是抢”，局部规划负责“未来几秒的轨迹长什么样”。三层分开的好处是每层的问题边界清晰，出了事能快速定位。很多人喜欢把决策和规划揉在一起做，用一个大代价函数把所有因素加权求和，短期看代码少，长期看调参调到怀疑人生，因为一个权重改动会同时影响跟车、变道、路口通行，牵一发动全身。

代价函数的调参是重头戏。常见的项包括：偏离参考线的横向代价、速度与期望速度的偏差、加速度和加加速度的平滑代价、与障碍物的安全距离代价、以及舒适性相关的转向角速度代价。每一项都要有明确的物理意义和量纲，不能混着加。我的习惯是先把每一项单独标定，找到它在“合理行为”下的取值范围，再做归一化，最后才加权。比如横向偏差代价，先用厘米做单位，除以一个参考宽度（比如车道宽的一半），把它变成无量纲的比值，这样不同项之间才有可比性。

加加速度这一项要特别说。它对应的是乘客的体感，取值太小车会一顿一顿，取值太大车会变得迟钝、变道拖泥带水。经验值是在城市工况下把加加速度限制在每秒三次方米两到三之间，高速工况可以放宽到五左右。这个数值不是死的，得结合你车辆的悬架特性和座椅感受实测。我做过的项目里，同一个参数在不同车型上的体感差异非常明显，所以调参必须上车，坐在屏幕前看曲线是调不出来的。

3.2 仿真闭环：场景库怎么建才有用

仿真不是跑得越多越好，是要跑得“有针对性”。我见过不少团队，场景库动辄几十万个，跑一遍要几天，但真正有价值的场景可能不到百分之五。问题出在场景生成方式上——很多场景是从真实数据里随机切片来的，大量重复的直道跟车、空旷路口，边际价值极低。

我的做法是按“失效模式”组织场景库，而不是按“道路类型”。具体分四类：第一类是感知边界场景，比如逆光、隧道出入口、雨雾、夜间会车远光，这类场景考验的是感知的极限；第二类是决策博弈场景，比如加塞、无保护左转、窄路会车，考验的是决策逻辑；第三类是控制极限场景，比如低附着路面、急弯、连续减速带，考验的是执行层；第四类是系统异常场景，比如传感器短暂失效、通信延迟、算力过载，考验的是降级策略。这四类里，第四类最容易被忽略，但恰恰是真实道路上最容易出问题的。

场景库建好之后，还要解决“仿真和实车对不上”的老问题。我的经验是建立一个“仿真可信度”指标，拿同一批场景在仿真和实车里各跑一遍，对比关键指标——接管次数、最大减速度、横向偏差峰值。如果偏差超过两成，说明仿真里的车辆动力学模型或者传感器模型需要重新标定。这个过程很枯燥，但不做的话，仿真里跑得再好也只是自嗨。

3.3 控制层的常见抖动与解决

控制层的抖动，十个项目里有八个遇到过。表现是方向盘小幅高频抖动，或者纵向速度轻微波动。原因通常有三类：一是感知输入的目标位置本身在抖，控制只是忠实地复现了这种抖动；二是控制参数整定不当，比例项过大或者微分项引入了噪声；三是执行器的死区和延迟没有被建模。

排查顺序我一般是从源头往下查。先把感知输出的目标轨迹录下来，看横向位置的频谱，如果抖动频率和控制的响应频率对不上，那问题多半在感知。如果感知平滑，那再看控制器的输出，用阶跃响应测试，看有没有超调或者持续振荡。最后查执行器，给一个固定的转角指令，看实际转角是不是有小幅摆动，如果有，那是执行器本身的死区问题，得在控制器里加死区补偿。

有个小技巧挺管用：在控制输出后面加一级低通滤波，截止频率根据车辆的执行带宽来定，一般取执行带宽的三分之一到二分之一。这一级滤波能吃掉大部分高频抖动，代价是引入一点相位滞后，但只要截止频率选得合理，滞后在可接受范围内。我在一个模拟项目里用这招，方向盘抖动幅度降了七成，主观体感从“发麻”变成了“正常”。

4. 数据闭环与工程化落地

4.1 数据采集、标注与回流的流水线

数据闭环这件事，说起来简单——采数据、标数据、训模型、发版、再采数据。做起来每一步都有坑。采集环节最大的问题是“采什么”。全量采集成本高得离谱，一小时的多传感器原始数据动辄几十个 G，存都存不下。所以必须做触发式采集，只在系统“不确定”或者“表现异常”的时候才落盘。

触发条件的设计是关键。常见的触发源有几类：感知置信度低于阈值、规划频繁重规划、控制输出接近限幅、人工接管、以及基于规则的场景识别（比如检测到施工区域、异形车辆）。我还会加一类“随机采样”，按很低的比例随机录一段正常数据，用来做负样本和基线对比，防止模型越训越偏。这个比例一般控制在百分之一到二之间，既能控制数据量，又能保证样本分布不失真。

标注环节的成本往往被低估。一个小时的原始数据，标完可能要几十个工时。所以标注策略必须分层：高频出现的常见目标用自动标注加人工抽检，低频的长尾目标才全人工标。自动标注的准确率不用追求极致，八成五以上就可以用，剩下的人工修正。这里有个细节，自动标注的误差分布要监控，如果某个类别的误差突然变大，往往是上游模型退化或者数据分布漂移的信号。

4.2 训练与部署的一致性坑

这个坑我踩过不止一次，值得单独拎出来说。训练时用的是浮点精度、标准预处理、标准颜色空间，部署到车端变成了定点量化、不同的预处理顺序、甚至不同的插值算法，结果就是离线指标漂亮、车上表现拉胯。最典型的例子是图像归一化，训练时用的是减均值除方差，部署时忘了减均值，模型直接崩掉，但离线测试完全看不出来，因为离线测试脚本用的是训练时的预处理。

解决办法是把预处理也纳入模型的导出流程，用同一套代码生成训练和部署的输入，从源头上消除不一致。量化这块，一定要做逐层的敏感度分析，找出对精度影响最大的那几层，对这些层保留高精度或者做混合量化。我一般会留百分之五左右的层不量化，换来的是整体精度损失控制在百分之一以内，比全量量化划算得多。

还有一个隐蔽的坑是算子支持。训练框架里某个算子用得很顺手，导出到车端推理引擎发现不支持，只能拆成几个基础算子拼出来，性能和精度都变样。所以选模型结构的时候就得把部署侧的算子库摸清楚，别等训完了才发现要重构。

4.3 算力与成本的账怎么算

算力规划这事，很多人是“先买最大的，不够再加”。这在原型阶段没问题，量产阶段就是灾难，因为算力直接对应功耗、散热和成本。我的算法是先算峰值需求，再留百分之三十的余量，最后按这个数选平台。

峰值需求怎么估？把每个模块的单帧耗时列出来，注意是峰值不是均值，因为偶发的长尾延迟才是导致丢帧的元凶。感知通常是大头，多路相机加激光点云的前处理和后处理加起来可能占到六成以上。规控相对轻，但仿真和日志回传会额外占用。算完之后除以目标帧率，得到所需的算力。举个具体的例子，假设单帧总耗时峰值是 80 毫秒，目标帧率 15 帧每秒，那单帧预算就是 66 毫秒，明显不够，要么降帧率要么优化。优化优先级我一般按“耗时占比乘以优化难度”排序，先啃那些占比高又好啃的骨头。

成本这块还有个容易被忽略的维度：数据存储和传输。一辆车一天产生的数据可能上百 G，如果全量回传，流量费用比算力还贵。所以必须做车端筛选，只回传有价值的数据，这个筛选逻辑本身也要占算力，得算进总账里。

5. 常见问题与排查速查

5.1 典型故障速查表

下面这张表是我这几年攒下来的，按“现象、可能原因、排查顺序”组织，遇到问题可以先对号入座，能省不少时间。

5.2 独家避坑经验

第一条，永远保留一份“最小可运行系统”。就是那种只保留最核心感知加最基础规控的版本，功能简陋但绝对稳定。它的作用是在你折腾新架构把主系统搞崩的时候，还有一个能上车的基线做对比。我吃过亏，有次大改感知架构，改到一半发现新方案在某个场景下彻底不行，回头想找回旧版本，发现代码已经混在一起了，重构花了整整两周。从那以后，主干分支永远保留一个可运行的稳定版本。

第二条，日志要按“能复现问题”的标准来设计，而不是按“能看”的标准。很多团队的日志只记录输出结果，不记录中间过程，出了问题只能靠猜。我的做法是关键模块的输入输出都落盘，尤其是那些有随机性或者依赖时序的环节，比如跟踪的关联结果、规划的候选轨迹评分。日志量会大一些，但排查效率提升是数量级的。

第三条，不要迷信单一指标。接管次数低不代表系统好，可能是运行设计域太窄；感知精度高不代表能用，可能是标注集和测试集有重叠。我习惯同时看至少三个正交指标，比如精度、稳定性、以及计算资源占用，任何一个恶化都要警觉。

第四条，降级策略要在设计阶段就定，不能等出了问题再补。什么情况下降级、降级到什么程度、降级后怎么提示、怎么恢复，这套流程要在架构设计时就画清楚。我见过系统在传感器失效后直接退出，没有任何过渡，这种设计在真实场景里是很危险的。合理的做法是分级降级，先限速、再靠边、最后才请求接管，每一级都有明确的触发条件和恢复条件。

最后分享一个我在实际项目里养成的小习惯：每次版本发布前，固定跑一遍“老场景回归集”，这批场景不多，几十个，但都是历史上出过问题的。跑通了不代表没问题，跑不通一定有问题。这个习惯坚持下来，能把大部分低级回归挡在发布之前，比事后救火省心得多。