小鹏汽车自动驾驶中心2019年春招笔试题复盘又到了春招旺季后台有好多同学私信我问自动驾驶岗笔试到底考什么。我翻出了自己当年刷小鹏汽车自动驾驶中心研发岗笔试题时的完整笔记结合后来在一线做自动驾驶开发的实际经验认真做了这版复盘。这套题放在今天看仍然非常有代表性考的不只是八股文式的知识点更多是看你对整个自动驾驶技术栈有没有结构化认知以及遇到实际问题时能不能把代码落地。无论你准备投递小鹏、蔚来、理想还是百度Apollo、文远知行这类公司这份复盘都有参考价值。文章会从题目本身出发逐层拆解出题人想考察的能力模型并给出我自己的解题框架和踩坑记录。1. 笔试整体设计与考察方向拆解1.1 2019年春招自动驾驶中心笔试的定位分析先说说这份笔试题的总体感觉。小鹏那年在自动驾驶中心的招聘方向非常明确主要集中在这几条线感知算法、融合定位、路径规划与控制、传感器与嵌入式平台、仿真测试。笔试分两大部分一部分是通用编程能力和C基础另一部分是专业方向题允许你在感知、规划、定位等几个模块里选做。这种设计背后藏着很实际的招聘逻辑——自动驾驶是一个长链条系统既有深度学习模型训练这类数据驱动的任务也有像卡尔曼滤波、坐标变换这类强数学推导的任务还有ROS系统中节点通信这类工程问题。公司需要的是能直接干活的人所以题目设计上非常强调“能不能把算法变成可靠运行的代码”。从题型占比来看通用编程题大概占30%到40%方向题占60%到70%。通用题主要刷掉编程基本功不扎实的候选人方向题则是在过滤对自动驾驶领域缺乏深度的简历党。当年的笔试时间一般是120分钟题量不小至少有6到8道大题每道大题下还有若干小问。我印象最深的是有一道关于路径规划的题目不仅要求写出算法流程还要求分析在真实道路场景下这个规划结果合不合理怎么评估。这就很典型地体现了我开头说的——它考察的是工程思维而不是单纯让你背一个算法。1.2 核心考点分布与侧重点评估我把这份笔试题涉及的核心考点整理成了几个大块方便后续逐个拆解。编程基础与C能力包括指针与引用、内存管理、STL使用、面向对象设计、多线程基本概念。这些是自动驾驶研发岗的基本门槛。算法与数据结构网格地图上的搜索算法A*、Dijkstra是高频考点还会涉及动态规划、图论基础、时间空间复杂度分析。专业方向题感知方向目标检测基本流程、IOU计算、NMS实现、卷积神经网络基础结构、数据集标注格式。定位方向坐标变换、IMU/GNSS融合原理、卡尔曼滤波推导或手写简化版、点云配准的基本思路。规划控制方向路径规划常见算法RRT、A*、Lattice Planner、轨迹平滑、PID与MPC控制器概念、安全行驶约束。系统与仿真方向ROS的通信机制、话题与服务的区别、TF坐标树、仿真测试的闭环流程、HIL硬件在环基本原理。数据集与测试相关内容如何评估一个数据集能不能用来训练感知模型、自动驾驶测试场景如何设计、如何评估路径规划是否合理。这个考点分布其实已经透露了行业对初级研发工程师的核心预期你不需要变成所有方向的全才但你必须在一个方向上有完整闭环的认知同时具备跨方向沟通的基础概念。2. 编程基础与C能力题目的解题要点2.1 C高频考点与典型题目先说通用编程题。小鹏笔试的C题目不追求偏怪难但非常重视底层基本功。比如有一道典型的题目是“解释下面代码的输出结果”内容涉及指针和引用的混用#include iostream using namespace std; void swap1(int a, int b) { int tmp a; a b; b tmp; } void swap2(int* a, int* b) { int tmp *a; *a *b; *b tmp; } void swap3(int a, int b) { int tmp a; a b; b tmp; } int main() { int x 3, y 5; swap1(x, y); cout x y endl; swap2(x, y); cout x y endl; swap3(x, y); cout x y endl; return 0; }这道题看起来很简单但考察的知识点其实很密实参形参的值传递、指针的解引用操作、引用的本质是别名。输出结果是“3 5 3 5 5 3”。很多同学对引用和指针的区别说不上来或者只知道“引用是别名指针是地址”但一旦到实际代码里画不清内存关系就开始糊。我的建议是这一类基础题不要靠死记结论关键要建立起“函数调用时栈帧是独立内存”的认知。无论形参是值、指针还是引用关键看函数内部能不能通过某种方式找到并修改外部变量的内存单元。值传参拿不到外部变量的地址所以改不了指针传参拿到地址可以改引用传参本质是地址传递的语法糖。你在笔试时最好不光写答案还把每一步的栈帧变化画出来这样即使答错了批卷人也能看到你的思考路径。2.2 动态内存管理与内存泄漏的考察另一类高频题是C内存管理相关。比如给出下面这段代码问哪里出了问题class LidarFrame { public: LidarFrame(int size) { data new float[size]; size_ size; } ~LidarFrame() { delete[] data; } private: float* data; int size_; }; void processFrame() { LidarFrame frame1(10000); LidarFrame frame2 frame1; } // 程序崩溃为什么这题考察的是浅拷贝与深拷贝、析构函数的调用时机、堆内存重复释放问题。默认拷贝构造函数执行的是浅拷贝也就是frame2的data指针只是复制了frame1的地址值两个对象指向同一块堆内存。在函数结束时frame1和frame2各自调用析构函数同一块内存被delete两次直接触发未定义行为甚至崩溃。自动驾驶里这种问题特别容易出现因为一帧激光雷达点云动不动就是几万甚至几十万数据点如果到处拷贝性能和稳定性都会崩。所以笔试里凡是涉及自定义类管理资源的都要立刻想到规则三需要自定义析构时也应该自定义拷贝构造和拷贝赋值运算符。这里可以补充回答一句更现代的方式是使用shared_ptr或unique_ptr来管理原始指针或者直接将数据存进容器如std::vector。如果你能在笔试答案里写上一句“建议用vector容器代替手动内存管理”就意味着你有生产级代码的思维印象分会高不少。2.3 算法题网格地图搜索与A*实现算法题里面小鹏很爱考网格地图上的路径搜索。这很贴合自动驾驶的真实需求——机器人/车辆在地图上要从A点走到B点地图被栅格化成若干网格有障碍物要找到最短路径。最典型的题目就是手写A算法或Dijkstra算法。A作为启发式搜索算法在自动驾驶的全局路径规划中特别常用尤其是低速园区场景和局部绕障场景。手写A*的题阅卷人主要看三个点第一是否理解open list和closed list的意义及使用逻辑第二是否写清楚了代价函数 f(n) g(n) h(n)尤其是启发式函数h(n)选择的是什么常见的是曼哈顿距离或欧氏距离第三代码是否能在网格地图上真正输出一条合理的路径。我当年用C实现过一个简化版本核心代码框架大致如下struct Node { int x, y; int g, h; int f() const { return g h; } Node* parent; }; int heuristic(int x1, int y1, int x2, int y2) { return abs(x1 - x2) abs(y1 - y2); // 曼哈顿距离 } std::vectorNode* aStarSearch(int startX, int startY, int goalX, int goalY, const std::vectorstd::vectorint grid) { // openList用优先队列按f值升序 std::priority_queueNode*, std::vectorNode*, CompareNode openList; std::vectorstd::vectorbool closedList(grid.size(), std::vectorbool(grid[0].size(), false)); // 方向数组上下左右 int dirs[4][2] {{-1,0},{1,0},{0,-1},{0,1}}; Node* start new Node{startX, startY, 0, heuristic(startX, startY, goalX, goalY), nullptr}; openList.push(start); while (!openList.empty()) { Node* current openList.top(); openList.pop(); if (closedList[current-x][current-y]) continue; closedList[current-x][current-y] true; if (current-x goalX current-y goalY) { // 回溯路径 std::vectorNode* path; Node* p current; while (p ! nullptr) { path.push_back(p); p p-parent; } return path; } for (auto d : dirs) { int nx current-x d[0]; int ny current-y d[1]; if (nx 0 || nx grid.size() || ny 0 || ny grid[0].size()) continue; if (grid[nx][ny] 1 || closedList[nx][ny]) continue; // 1代表障碍物 Node* neighbor new Node{nx, ny, current-g 1, heuristic(nx, ny, goalX, goalY), current}; openList.push(neighbor); } } return {}; }笔试时不用追求代码一次编译完美但至少要体现清楚open list和closed list两个核心集合以及启发式搜索的思路。如果时间充裕最好再补一句“h(n)需要满足一致性或可采纳性才能保证最优解”。这句话往往是你和普通候选人拉开差距的关键。3. 路径规划方向如何评估路径规划是否合理3.1 从一道题看规划合理性评估框架前面提到了笔试里有一道题让我印象非常深刻就是“自动驾驶中路径规划的结果是否合理如何评估”。这道题放在2019年那个时间点非常前沿因为那时候很多公司还在纠结“能不能规划出路径”而小鹏已经开始考察“规划的路径好不好、安不安全”。放到今天来看这其实就是自动驾驶量产落地阶段最核心的问题——规划模块不仅要让车能走还要让乘客敢坐、让系统足够安全。我当时给出的回答分成了四个层次。第一层是安全性评估检查规划结果是否会碰撞到静态障碍物或动态障碍物。这层是最基础的直接由成本函数和约束条件来保证。第二层是舒适性评估路径的曲率是否突变、加速度是否过猛、车辆横摆角速度是否超出了人的舒适区间。第三层是效率评估规划路径长度是否在合理范围内是否绕了不必要的远路。第四层是可行性评估也就是这个路径是否满足车辆运动学约束——比如最小转弯半径是否满足车辆有没有可能真正跟得上这条轨迹。实际笔试题如果以简答题形式出现很有可能会要求你结合具体场景来描述比如前方突然出现违停车辆你怎么判断重新规划出来的绕行路径是否合理。这就要靠分层的指标来拆解了。3.2 路径规划合理性的量化评价指标针对上面那个问题我建议你学会建立一套可量化的指标体系这在笔试和面试中都非常加分。可以把路径规划的评价映射成数值分析。比如安全距离裕量规划路径与最近障碍物之间的最小距离通常要求不小于0.3米到0.5米这个数值与车辆宽度、定位精度、控制精度强相关。路径曲率最大值与曲率变化率曲率过大意味着弯太急曲率变化率过大意味着转向在短时间内突变直接影响乘坐舒适性。一般情况下曲率最大值不宜超过0.1 1/m极限情况下不超过0.2 1/m。横向加速度和纵向加速度人体舒适性研究表明横向加速度保持在0.2g以下会感觉比较平稳超过0.4g就会明显不适。与全局参考路径的偏离程度局部路径规划是为了绕障绕完之后要尽快回到全局路径上如果偏离太远说明规划器目标性不足。规划耗时规划周期一般在100ms以内超过这个时间说明算法实时性不够无法满足量产要求。在回答“评估是否合理”时还要提到测试方法。一种是在仿真环境里批量注入场景比如切车、行人横穿、静态障碍物占道观察规划器输出有没有异常。另一种是在实车上设计封闭场地测试用真车执行规划轨迹并记录乘客主观评价和传感器客观数据。这里的高阶答案是规划合理性评估不能只看单条规划结果而要看规划器在整个场景序列里有没有产生多次规划之间的抖振问题。因为路径规划频率是10Hz到20Hz新规划的路径之间如果不连续车辆就会出现来回打方向的现象这是评估合理性的一个隐性维度。3.3 常见规划算法的类型对比与出题倾向笔试中涉及规划算法概念考察时常见的是要求对比几种算法说明各自适用场景。我在这里列一个选择方法算法搜索方式核心优势主要限制在自动驾驶中的典型应用Dijkstra广度优先扩展保证最短路径搜索范围大实时性差小规模离线地图上的最短路计算A*启发式搜索比Dijkstra高效保证最优解需要设计合适的启发函数全局路径规划的经典选择RRT/RRT*随机采样适合高维空间能快速找到可行路径RRT不保证最优路径不平滑复杂环境下的快速探索Lattice Planner状态采样天生满足运动学约束轨迹平滑计算量随采样密度增大而上升低速园区自动驾驶、泊车场景答题时记得加上一句“实际工程中很少只用单一算法通常是全局规划与局部规划相结合比如全局用A*找到粗路径局部用Lattice Planner生成细轨迹并实时避障”。这种观点能体现你对系统架构的认知而不是只会背单个算法的特性。4. 感知方向题目从目标检测到数据集评估4.1 感知方向的笔试典型题目感知方向是小鹏笔试的重头因为视觉感知在自动驾驶里的地位不言而喻。典型题目包括解释什么是IOU交并比手写计算两个矩形框的IOU说明NMS非极大值抑制的原理和实现步骤什么是anchor它有什么作用训练目标检测模型时正负样本不均衡怎么处理。这些题目的风格就是考你“是否真正用深度学习做过目标检测”而不是只刷过几篇论文就能糊弄过去。以手写IOU计算为例笔试题会给出两个矩形框坐标分别是(x1, y1, x2, y2)和(x3, y3, x4, y4)。你应该快速写出通用计算逻辑def compute_iou(box1, box2): # box1, box2 [x_min, y_min, x_max, y_max] x1 max(box1[0], box2[0]) y1 max(box1[1], box2[1]) x2 min(box1[2], box2[2]) y2 min(box1[3], box2[3]) inter_w max(0, x2 - x1) inter_h max(0, y2 - y1) inter_area inter_w * inter_h area1 (box1[2] - box1[0]) * (box1[3] - box1[1]) area2 (box2[2] - box2[0]) * (box2[3] - box2[1]) union_area area1 area2 - inter_area return inter_area / union_area if union_area 0 else 0这题本身不难但很多人会忽略一个细节矩形框有交集时的边界条件处理。如果两个框没有重叠x1会大于x2或者y1会大于y2计算出来的宽高是负数。如果直接用负数面积去算IOU就会得到错误结果所以必须用max(0, ...)来钳制。这个细节在自动驾驶的感知评测里非常关键因为模型输出大量候选框很多框与真值完全没有重叠如果IOU计算代码不够健壮评测脚本可能直接报错或者统计失真。4.2 自动驾驶数据集设计的考察方向结合“自动驾驶数据集”这个关键词笔试也喜欢出一些关于数据集构建与评估的问题。比如会问如果要用传感器采集数据训练一个红绿灯识别模型采集时要考虑哪些因素让你列出数据集的评估维度。答案可以从这几个层面展开场景多样性覆盖晴天、雨天、夜间、逆光、背光等不同光照条件。地理多样性不同城市、不同道路结构、不同交通标志风格。时间分布白天和夜晚的数据比例是否合理。目标分布正样本和负样本的比例特别是罕见场景如黄灯闪烁、临时信号灯。标注质量标注框的准确率和漏标率通常需要设置标注质量抽检流程比如人工复核5%到10%的标注数据。数据集与真值一致性用于评估的数据集必须是带真值标注的并且真值的坐标系定义要清晰。我笔试时还遇到过一个进阶题如果自采数据集里晴天数据占比90%雨天只占5%夜间占5%你训练的模型在雨夜场景中的性能下降明显怎么解决。这题没有标准答案但出题人想听到的核心点是数据增强和重采样策略。你可以在回答中提出使用CycleGAN做风格迁移来扩充雨天夜间数据或者利用仿真平台生成极端天气下的合成数据再配合lidar的几何真值来减少对图像的依赖。这种多模态融合思路在今天的自动驾驶量产项目中已经很常见2019年能答出来这一点会相当加分。4.3 感知算法的工程落地陷阱感知方向的笔试题并不总是只问算法本身还会刻意考察一些工程落地经验。举一个非常有代表性的问题一个目标检测模型在离线测试集上mAP达到90%上车实测却发现频繁漏检可能是什么原因这道题考察的就是你对整个感知链路是否了解。常见的答案包括几种。第一是训练数据和测试数据分布不一致实车场景在光照、天气、相机安装位置和角度上和训练集差异较大。第二是数据预处理链路不一致比如训练时图像分辨率是1920x1080实车相机输出经过裁切后分辨率不同或者色域转换不一致都会导致精度下降。第三是推理优化带来的精度损失为了实车实时性可能把模型量化成INT8量化误差在某些光照条件下会被放大。第四是时间同步问题图像和激光雷达数据没有精确时间对齐导致融合时特征噪声增大。这几条里最容易被忽视的是时间同步。很多刚入行的同学根本意识不到数据链路时间戳的重要性但在自动驾驶量产项目中不同传感器的延迟差异常常是感知性能不达标的根源。如果你在笔试里能主动提到“需要检查时间戳对齐和坐标系外参标定”阅卷人就会认为你有过系统级调试经验而不是只在录好的数据集上跑过离线脚本。5. 定位与ROS系统相关的技术考察5.1 坐标变换与多传感器融合题目定位方向在2019年的笔试里占据重要位置。那几年行业主流方案是GNSS/IMU融合加高精地图匹配而视觉和激光雷达的定位也在兴起。典型题目包括解释车体坐标系、传感器坐标系和全局地图坐标系之间的关系一个点从激光雷达坐标系转到车体坐标系的数学表达式解释卡尔曼滤波和粒子滤波的核心思想及区别。坐标变换这部分我建议你把最基本的公式记熟。一个在激光雷达坐标系下的点p_lidar转到车体坐标系p_vehicle需要用到外参旋转矩阵R与平移向量tp_vehicle R * p_lidar t如果再从车体坐标系转到全局地图坐标系还需要另一个变换矩阵。笔试时可能会要求你写出变换矩阵的形式或者给你具体的旋转矩阵和平移向量让你做数值计算。这里面最容易出错的是旋转矩阵的乘法顺序。ROS坐标系约定是右乘和左乘有严格区分如果你拿不准就明确写出“假设p是3x1的列向量变换按照T * p计算”这样即使做错步骤阅卷人也能看出你的思路是对的。卡尔曼滤波适用线性高斯系统核心是预测与更新的迭代过程状态协方差矩阵能定量表达不确定性。扩展卡尔曼滤波EKF针对非线性系统做一阶泰勒展开近似。粒子滤波适合非线性非高斯系统用加权粒子来近似后验分布计算量大但灵活。在实际GNSS/IMU融合中松耦合还是紧耦合方案的选择直接影响定位精度和计算开销。5.2 ROS通信机制与笔试常考概念结合热门标签“自动驾驶ros系统”笔试中必然涉及ROS相关问题。2019年那会儿ROS1还是绝对主流所以题目往往围绕ROS1的核心概念展开但如果你在回答中能带上ROS2的改进点会显得知识比较新。常考问题包括ROS节点之间的通信方式有哪几种话题Topic和服务Service的区别是什么什么是ROS Master节点如何发现对方什么是TF坐标变换树如何写一个Publisher和Subscriberlaunch文件的作用是什么。如果笔试以简答题形式出现你可以这样组织答案Topic通信是异步的、单向的适用于高频数据传输场景比如图像、点云、车辆状态。发布者和订阅者之间通过Master完成节点发现之后数据是点对点直接传输的。Service通信是同步的、双向的适用于请求-应答模式比如停止泊车规划、触发一次定位初始化。Action通信是ROS中的第三种常用方式适合长时间执行任务例如路径跟踪或泊车操作客户端可以实时收到反馈并在必要时取消任务。在自动驾驶系统里图像和点云用话题传输诊断信息也是而地图加载这类一次性的请求用服务轨迹跟踪任务则用Action。工程上有一个高频坑点云数据量大如果直接用rosbag记录原始点云话题一个包几秒钟就能上GB量级。所以笔试里如果问“在大规模路测数据采集中如何降低存储开销”你要能想到降采样、只存ROI区域点云或者直接存压缩编码后的传感器原始数据在离线阶段再做解码处理。5.3 TF坐标树与标定的实际意义ROS方向还有一个重要概念就是TF坐标树。自动驾驶车辆上传感器很多Camera、LiDAR、IMU、GNSS天线都有各自的安装位置和姿态TF坐标树用来维护这些坐标系之间的变换关系。笔试可能会问在TF树中如果某个坐标变换没有被广播会导致什么后果。典型情况是感知模块和规划模块使用了不同时间戳的TF导致坐标转换结果出现明显偏移。我自己的实操经验是做感知融合之前第一步必须验证TF变换是否准确。一个很常用的验证方式是拿激光雷达点云投影到图像上看投影后的轮廓和图像中物体边缘是否对齐。如果外参不准、TF树发布频率过低或者时间戳同步有问题投影结果就会出现重影或错位。这个方法在笔试中如果被问到“如何验证传感器外参标定结果”时直接可以用上而且听起来非常有实战感。5.4 数据链路中的时间同步问题在自动驾驶系统中多传感器时间同步是笔试里容易被忽略、实际工程中却极其致命的问题。小鹏笔试有一道题是车辆的GNSS、IMU、Camera、LiDAR分别工作在10Hz、200Hz、30Hz、10Hz请问如何在软件层面实现时间对齐如果你能说出“统一时间基准时间戳插值”这两步基本就能得分。统一时间基准是指所有传感器数据都转换到同一个时钟源通常是GPS的PPS秒脉冲加NMEA时间消息同步到计算平台系统时钟。时间戳插值是指当算法需要某个特定时刻的IMU数据但实际数据是离散采样时用前后两个IMU采样做线性插值来逼近。还有一个更高级的思路是引入“时间延迟估计”比如用标定方法精确测量相机曝光中点与IMU采样时刻之间的固定延迟然后在软件里补偿这个延迟。这已经属于多传感器融合领域比较深的问题了如果你能提到这套思路就说明你真正做过相关项目。6. 测试与工程化题目从用例设计到仿真闭环6.1 自动驾驶测试用例设计的考察结合“自动驾驶测试”标签笔试中会有一类题目用于考察你对整个自动驾驶系统的验证能力。最常见的是如果要在封闭测试场验证一辆L4级自动驾驶车辆在十字路口左转的功能请设计测试用例。这题考察的是你从功能逻辑到场景拆解的能力并不是要求你背法规。我给出的回答框架可以拆成几个维度基础功能维度正常红绿灯状态下左转、绿灯左转、红灯停止、黄灯通过或停车。特殊交通参与物维度有对向直行车辆、有横向穿行行人、有同向非机动车并行、有大型车遮挡视野。环境维度晴天、雨天、夜间、逆光、光线不足。通信与地图维度红绿灯信号是否能被感知到、高精地图定位偏差较大时的应对。异常情况维度前方车辆突然急刹、信号灯故障全灭或全红、有车辆强行加塞。如果你能按照“正常功能、交互博弈、环境条件、异常故障”这样四层维度来组织用例阅卷人会认为你有测试架构思维。在自动驾驶测试场景实际落地上OpenSCENARIO这类场景描述语言已经逐渐成为行业标准如果你答题时能提一句“用OpenSCENARIO描述场景要素配合仿真平台批量执行用例”会成为很大的加分项因为2019年能意识到这点的候选人确实不多。6.2 仿真平台与HIL测试的基础框架仿真测试也是笔试单选题和简答题的常客。常见的仿真工具有百度Apollo的SimControl、CARLA、LGSVL、自主研发的SceneRunner等。笔试可能问到“仿真环境中最难复现的是哪类场景”真实的答案往往是传感器噪声和极端交互。渲染再好传感器模型不准确仿真结果就不可信。车辆动力学模型是简化的自行车模型还是高精度车辆动力学模型也会极大影响规划控制算法的验证效果。HIL测试硬件在环是笔试的进阶考点。它把真实的控制器硬件接入仿真环境传感器信号由仿真软件模拟但执行算法运行在真硬件上。这么做的好处是能提前验证计算平台的实时性和接口稳定性。笔试中遇到“为什么要做HIL测试”这个问题可以这样回答因为成本和安全约束真实路测无法覆盖所有危险边界场景而纯软件仿真又无法暴露硬件层面的时序和接口问题HIL测试作为中间层能提前发现算法在目标计算平台上运行时的资源瓶颈、通信延迟和内存泄漏问题。7. 常见问题与避坑技巧实录7.1 笔试答题中容易踩的坑我复盘这份笔试题时总结了几个很典型的踩坑点写出来给正在准备的同学避避雷。只看不做很多人复习时把大量时间花在刷论文和看博客上真正落笔写代码的时间少得可怜。笔试里手写A或者IOU这类代码题没有足够的肌肉记忆很容易卡壳。建议至少把A、NMS、卡尔曼滤波简化版、坐标变换代码各手写三遍以上。忽略复杂度分析做题时写了算法但没分析时间空间复杂度这在要求“给出算法复杂度”的题目里很吃亏。自动驾驶是实时系统一个规划算法如果时间复杂度是O(n^3)而你没指出这个瓶颈阅卷人会怀疑你缺乏性能敏感意识。不写注释和关键公式推导很多同学写代码时字母命名混乱也没有注释阅卷人根本不知道你的变量含义。建议在关键步骤旁边写上注释哪怕是中文的也行。比如“更新当前节点邻居的g值”这一类注释能有效降低沟通成本。只看正确性忽略边界条件写IOU时忘记处理两个框不相交的情况写A*时忘记检查栅格地图越界这些错误在笔试里非常常见。写代码时每次循环都要问自己三个问题初始条件对不对、边界条件处理没有、极端情况会发生什么。不展示思维过程笔试不像面试可以口述思路所以笔试卷面上最好在答案前用一两句话概括你的思路。比如先写“本方案采用A*算法主要目标是保证路径最短同时避免障碍物碰撞”然后再上代码。7.2 实操备考建议和面经经验结合我自己和小伙伴的经验准备这类自动驾驶岗位笔试有几个高效的策略。第一建立整体系统架构。不要一上来就埋头做具体题目先把自动驾驶的感知-定位-预测-规划-控制-仿真测试整条链路在脑子里跑一遍明确每个环节的输入输出是什么。这道题为什么这么出、它属于哪个环节你一旦建立起全景图方向题的答案自然就有逻辑层次。第二动手练习标准工具链。笔试中有不少关于工具链的题目比如rosbag、RViz、TF、launch文件的用法。建议直接在本地装一套Ubuntu ROS环境把ROS官方Tutorials的Publisher/Subscriber、Service、Action例子全部跑一遍再用rosbag录一段传感器数据尝试用RViz可视化PointCloud2和Image话题。这些实操经验在笔试和面试中都能转化为真实案例。第三关注行业经典论文和开源项目。2019年笔试中涉及的很多技术比如Lattice Planner、Frenet坐标系、Apollo的规划算法、百度Apollo开源项目等今天依然是行业主流。如果你能自己跑过一遍Apollo或者Autoware的某个模块对源码结构有基本认知那么所有关于工程实现的问题都答得非常轻松。第四有意识培养“指标量化”思维。规划是否合理、测试是否充分、数据集是否合格这些开放性问题的评判标准最好都用量化指标来说话。比如以“路径规划平均耗时低于100ms、最大曲率小于0.1每米、规划成功率大于99%”这样的句式来回答问题比干巴巴说“性能很好”要强无数倍。8. 对当前自动驾驶技术趋势的延伸思考复试这份2019年的笔试题可以明显看出自动驾驶行业这几年的技术演进脉络。比如当年的规划算法笔试主要集中在A*和Dijkstra这类经典搜索框架上而现在的行业技术讨论已经大量转向基于深度强化学习的端到端决策、博弈交互决策、多模态轨迹预测等技术。但不要觉得“经典算法过时了”——事实上很多量产自动驾驶公司仍然在核心安全功能上使用经典搜索算法只是在外部套了更智能的行为决策层。所以笔试中这些基础算法的考察在今天依然具有极其重要的筛选价值。感知方向的题目也从单纯的CNN识别逐渐扩展到多传感器前融合、Transformer结构、Occupyancy Network等新方向。但不变的是对基本概念的考察底线——你仍然要能说清楚IOU、NMS、anchor、数据增强这些基础概念否则无论多新的模型框架在你手里都只是黑盒调用。另外一个越来越重要的趋势是仿真测试的权重提升了稍微大一点的公司都会关注你是否能搭建场景库是否能批量跑仿真回归测试这已经成为一个独立岗位方向。我个人在实际操作中的体会是笔试不只是公司筛选候选人的过程它同时也是你检验自己是否热爱这个行业的机会。如果你在刷这些题目时感到兴奋拿到一道规划题会主动去画地图、推公式、想边界条件那说明你真的适合这条路。如果只是觉得压力大、靠死记硬背硬撑那即使进了自动驾驶行业日常开发的挑战也只会更重未必走得远。最后再分享一个小技巧。准备笔试时千万别只刷题试着把你写的每一个算法都拿回仿真实环境里做一次验证。比如写了A*算法就跑一下仿真地图看看输出的路径是否平滑跟车辆运动学约束匹配不匹配。这种“从代码到运行结果再到拷问原因”的闭环习惯才是自动驾驶工程师最核心的职业素养。祝各位春招顺利。