企业官网建设流程全解析

把CV算法工程师实习生面试完整走了一圈之后，我最大的感受并不是题目有多偏多难，而是很多人把精力花在了错误的地方。市面上的面经大多在列“被问了什么”，却很少解释面试官真正想从这些问题里得到什么。尤其是出行平台这种和业务强绑定的场景，技术考察从来不是单纯背八股，而是一层层剥开你的项目、你的思考方式、你的工程底线。

这篇内容围绕我在某头部出行平台面试CV算法工程师实习生岗位前后的复盘展开，也会把面试里出现的典型问题、答题逻辑和现场推演尽量还原出来。如果你正准备投递类似岗位，或者已经收到了面试通知但不知道从哪里开始，这篇内容应该能帮你少走不少弯路。前面讲能力模型和考点，中间是完整的项目问答沙盘，后面给出一个月内的备战路线，整体顺序就是“先看清游戏规则，再逐项拆解”。

1. 出行CV算法实习生的能力要求：简历决定门槛，项目深挖决定结果

1.1 第一层：基本功力的三个考察点

不少同学对“实习生面试”有误解，觉得这是正式工程师的简化版，背一背基础就能过。实际上出行平台的CV实习生面试，基础题覆盖的范围和正式校招几乎没有差别，只是追问深度会根据候选人的背景动态调整。我复盘下来，面试官在基础环节最关注三件事：你对视觉任务的建模能力、你对模型结构的理解深度、以及你对评价指标的敏感度。

建模能力考察的是“拿到一个业务问题，你能不能把它拆成计算机视觉的标准任务”。比如说“识别司机疲劳状态”，这不是一个简单的二分类，背后可能涉及人脸关键点检测、眼部开合度计算、姿态估计、时序状态判定，还可能要做多帧融合。面试官不需要你真的在十分钟里给出完整系统设计，他要看到你有没有这种拆解意识。

模型结构理解比“会调用预训练模型”高一个层次。很多人能说出某个检测模型的设计，但被问到“为什么不直接换一个更大主干”的时候容易卡住。出行场景的模型最终要落到车载设备或者低成本摄像头，算力、内存、延迟都被锁死，模型选型不是追求刷新某个榜，而是在约束条件下求平衡。

评价指标敏感度，是我认为这一轮里最容易被忽视但最容易被问爆的点。比如目标检测项目，多数人会自然说mAP，但面试官往往马上追加“你的业务真实在乎的是mAP还是精准率/召回率？报警类任务里漏报和误报各有什么代价？”这个问题一旦答不好，前面项目讲得再溜也会打折扣。

1.2 第二轮：算法、工程、潜力到底各占多少权重

就我个人的面试复盘来看，实习生岗位的评估维度可以分成三块：算法基础、工程能力、成长潜力。用表格表达更直观：

工程能力在实习生的面评里能占三成，这可能是很多刚从实验室走出来的同学没预料到的。原因其实很简单：实习生入职后做的第一件事往往不是发明新模型，而是把数据管线跑通、把评测脚本写好、把模型从实验结果迁移到新的数据分布上去。如果候选人对“数据怎么采集、怎么标注、怎么清洗、怎么划分”都没什么感知，面试官会有理由担心你上手之后很难独立推进事情。

成长潜力则体现在“被问倒之后的表现”。印象很深的一次追问，是我在讲训练数据来源时，有些细节没接住。当时的应对方式是直接承认“这块我没有深入验证过”，然后马上把已知的部分拆开讲，再列出来我可以从哪几个方向去验证。这比支支吾吾想要硬编一个答案好得多，至少不会让现场空气突然安静。

1.3 认清岗位所在团队的业务方向

出行平台的CV岗位其实有非常不同的细分方向：面向司机端的疲劳分心监测、面向行驶记录仪的车道线感知与车辆检测、面向路侧或地图场景的OCR识别与场景结构化、面向用户产品的图像美化等等。面试前的准备不能只停留在“我会检测、会分类、会分割”的层面，最好针对目标团队的具体业务去做一些模拟思考。

这意味着你要在面试里展现出一点“行业理解”。比如问到自己感兴趣的方向时，可以顺势说出“我了解到这个岗位可能会涉及到道路目标检测，我之前做过类似任务，但我更关心的是恶劣天气和遮挡场景下的鲁棒性处理”。这种表达能瞬间让面试官觉得你做过功课，而不是海投后随机掉进这场面试。

看清楚团队方向还有个直接作用：可以帮你在反问环节问出更有价值的问题，而不是干巴巴地问“实习生主要做什么”。你可以问“现在这个感知模块更关注指标涨点还是更关注数据闭环效率”“数据生产链路里标注团队和算法团队怎么协作”，这类问题既安全又能获得关键信息，还能侧面证明你有工程思维。

2. 目标检测与出行场景的考点清单：几乎每次面试都会遇到的哪几类问题

2.1 从“会调参”到“理解检测头”：YOLO、DETR 的实际对比

在CV算法工程师实习生面试里，目标检测是出现频率最高的任务，没有之一。出行场景下车辆检测、行人检测、车道线检测，几乎全是目标检测或与其相关的变体。所以有关YOLO系列、Faster R-CNN、DETR这些经典模型的追问，基本是必考科目。面试官通常不会点名让你比较某两个模型谁好，而是会在你讲项目时自然地问出来。

常见问法之一是“你自己的项目用的是哪种检测结构，为什么选它”。如果你的回答是“因为大家都用”，那基本直接暴露了理解深度不够。合格的回答至少要包含：任务类别数、目标尺度分布、算力约束、实时性需求、数据量级以及部署环境。比如在低成本设备上跑实时车辆检测，anchor-free的轻量模型往往优于复杂的二阶段模型；但如果是离线场景下的高精度检测，二阶段Cascade结构可能更好。

关于DETR这类基于Transformer的结构，面试官关注的往往不是你是否真的训练过大规模模型，而是你能不能说出它和传统检测的本质差异：集合预测、全局建模、去掉了anchor和NMS。你还要能说明它在出行场景下的一个痛点——小目标和密集目标上的性能通常不够理想，而且训练收敛需要更长时间。这个回答一旦到位，基本可以证明你对模型设计有独立思考，而不是单纯追热点。

另外，我在这部分遇到过一个很有意思的追问：“你刚才说增加特征金字塔能改善小目标，但反过来会不会带来什么坏处？”正确答案要能说出：高分辨率特征图计算量变大、内存占用上升、可能引入更多背景噪声，小目标召回率上升时中大型目标的精度有可能波动。能答出“权衡”二字，往往比写出整段结论更值钱。

2.2 出行场景里的边缘案例：逆光、遮挡、雨雾与误检

实验室数据集和真实道路数据之间的差距,是面试过程中必然会被试探的一个点。出行平台的摄像头装在车上或者路侧，面对的是逆光、夜间、反光、雨雪、泥点、遮挡、多目标叠压等等极端情况。面试官想确认的是：你有没有处理过真实世界复杂数据的经验，以及你有没有应对未知边界的敏感度。

以车辆检测为例，常见的考察角度至少包含下面几个：夜间车牌难以辨认时你会怎么处理；前车与后车严重遮挡时检测框应该保持还是分裂；玻璃反光导致误检你怎么判断；摄像头镜片上的污渍造成固定区域持续误报时，你的策略是什么。这些问题并没有唯一答案，甚至面试官自己也知道在某种条件下没有最优解，他们想听的是你的分析路径和取舍标准。

我当时被问到过一个关于“雨刷扫过前挡风玻璃导致目标短暂消失”的问题，这个细节让我印象很深。比较理想的回答是：先判断这是单帧缺失还是时序问题，如果后接跟踪模块，可以通过卡尔曼滤波或IOU匹配做短时保持；如果只是单帧检测结果做预警，可能不需要重逻辑处理，但要统计这种中断对准确率的影响到底有多大。回答这类问题要抓住“系统性地分析，而不是只抠一个点”。

误检工程也很值得提前准备。比如路侧电线杆、桥墩、水马、隔离栏这些会被误检成目标的情况。面试官会问“你能不能设计一个后处理规则把它过滤掉”。你可以从三类手段展开：几何先验、时序一致性、上下文语义。几何先验例如检测框宽高比异常、位置关系不合理；时序一致性例如目标不会瞬间出现又瞬间消失；上下文语义例如道路区域分割结果可以用来排除路外目标。关键是展现出你脑子里有“检测+后处理”这个整体框架。

2.3 评估指标不能只看mAP：业务视角下的指标权衡

算法工程师写论文时可以只看mAP，做业务的时候不行。出行场景涉及安全预警类任务时，精准率和召回率的代价完全不同。漏报一次危险事件可能造成严重事故，误报太多则会让司机和乘客对系统逐渐失去信任，最终导致功能被关掉。

面试中常见的追问路径是这样展开的：先让你介绍项目的评测指标，然后问你“线上真实场景中，你的模型每天会产生多少误报”，再问“如果你的任务目标是减少误报，你会从哪些环节入手”。这类追问有个很明确的意图：看你懂不懂“阈值”并不是模型结构决定的，而是业务目标决定的。你完全可以回答：通过调整置信度阈值让整体更保守，然后引入时间序列平滑、目标跟踪、区域限定等后处理进一步过滤误报，甚至可以利用分类模型对检测结果做二次确认。

我整理了一个关于“报警类视觉任务指标”的小框架，面试可以直接用：

准备这部分内容的时候，我建议每个项目都提前算好一组自己的指标数据，并且清楚知道这些数字是在什么测试集上得到的。面试官很喜欢在指标前再加一句“你这个数据是在什么场景下测的”，如果连测试集构成都说不清楚，给张满分指标也很难让人信任。

3. 真实沙盘复盘：一次车辆检测项目从数据到面试问答的全过程

3.1 项目切入点与面试官的第一问

复盘一次面试的时候，最好把自己挂在某个具体项目上逐步过筛子。我当时被打的是一个模拟项目X，背景大致可以描述为：面向行车记录仪视角的车辆检测，目的是给前向碰撞预警提供感知支持。这个项目是结构化清晰的典型工程练习：数据来自公共道路场景，类别只有轿车、卡车、公交车、摩托车四类；检测模型早期选择的是轻量化的单阶段结构，主链路由3层下采样特征图组成。

面试官第一个问题是：“你先用两分钟介绍一下这个项目，着重讲你在里面的个人贡献。”这里有个非常重要的技巧：介绍项目时不要从“我们用了什么模型”讲起，而要从“我们要解决什么业务问题”讲起。我当时的表述顺序是：业务希望在前向碰撞场景下更早更稳地识别前方车辆，于是我调研了设备算力和存储限制，确定了轻量级实时检测框架；随后我负责整理训练数据、实现数据增强、完成训练和评估；最后还针对小目标漏检问题额外加了一个特征增强分支，在测试集上把夜间中小目标召回率提升了大约六个百分点。

这样的介绍方式有两个好处：首先，“我负责”和“我们做了”的区别被清晰划出来；其次，所有技术细节都挂在一个业务目标上，面试官不需要费力去猜你到底干了多少活。

接下来一追问很快到达模型层面：“如果你的模型在雨雾天气下的漏检明显增加，你会怎么解决，第一步做什么？”很多人的第一反应是“加大雨雾数据训练”“用更强的数据增强”“换成更大模型”。这些都对，但缺少优先级判断。我当时的回答是把问题拆成三步：先分错，再找根因，后做针对性优化。具体来说，第一步统计雨雾场景的漏检目标距离分布、尺寸分布和遮挡状态；第二步判断漏检到底是特征被雨雾破坏，还是模型对小目标整体不敏感；第三步再决定是该引入去雨雾预处理网络、做数据增强，还是单独学习一个多尺度特征分支。这种拆解顺序能够展示你的战术纪律。

3.2 面试官追问“数据标注错了怎么办”

这个问题看起来简单，但现场很容易答得太虚。面试官会问：“如果你发现在训练集中有百分之五的框标歪了，你怎么判断这个噪声要不要重新标注？如果一定要重标，你有哪些办法降低成本？”

答案可以分成两个层面：判断层面和修正层面。判断层面先做一个快速实验：抽样统计标注偏移量，观察偏移主要发生在目标边缘还是目标内部，再计算这些低质量标签在训练时造成的loss异常有多大。如果样本量足够大、偏移方向随机，模型可能有足够的鲁棒性吸收噪声，此时不必大规模重标；如果偏移集中在某个类别或者某个特定尺度的目标，就需要优先处理这批数据。

修正层面要提一些可落地的方案：用离线检测模型的预测结果叠加标注结果做一致性比对、建立主动学习的难例池、通过“模型预测+人工二次确认”的方式批量修正。出行平台每天会产生大量道路数据，“模型辅助标注”是一个非常常见的工程方案，因此在面试时提出这一点会显得很贴近真实业务。

后续提问还有可能进阶到“标注噪声对评测指标的影响”。这里应该指出：如果测试集同样存在标注噪声，你的模型检测结果可能并没有变差，但测试时的mAP却被拉低。可以这样答：我们通常会对测试集的标注质量再做一轮人工复核，确保关键类别和困难场景的标签是可信的，否则优化方向会失真。

3.3 从“加网络层”到“改数据分布”：优化过程怎么讲才显深度

项目复盘中最容易让面试官失去兴趣的部分，就是候选人把优化过程讲成“我把骨干网络从A换到B，精度提升了”。这种陈述完全没有信息量，因为面试官看不到你为什么做这个选择，也看不到你排除过哪些方案。

更好的方式是讲“以问题为导向的迭代链路”。我在模拟项目X里遇到的核心问题是夜间小目标车辆召回偏低，早期初步尝试加大输入分辨率后，召回率提升有限但是整体推理时间增加了不少，于是判断单纯提分辨率不是一个好取舍；后来我对漏检目标做了统计，发现它们大多是距离较远、在图像中占据面积低于一定阈值的车辆，于是把思路转向特征层的优化，引入了浅层高分辨率特征与上下文特征融合的分支，最后才让召回率有了明显提升。

这段讲述里最关键的是“判断”和“取舍”，而不是最终模型有多先进。面试官会顺着继续追问“为什么浅层特征对小目标有效”，这是送分题，你要能说出一个逻辑链条：深层特征图经过了多次下采样，小目标的语义信息被压缩甚至丢失；浅层特征图空间分辨率高，更多保留了边缘、纹理等细节，把它们与含有强语义的高层特征融合后，模型就能在小目标区域得到更充分的表征。

除了模型结构，数据分布也是出行场景里值得深入讲的话题。夜间场景过少怎么办？晴天数据太多导致雨天过拟合怎么办？你的答案如果只有“做颜色增强”就会显得单薄。面试官想听到的是：你意识到真实场景中天气、光照、地理位置分布的倾斜，并且在训练策略上做了对应调整，例如重采样或合成数据。面试中能把“模型调参”提升到“数据分布管理”层面的人其实不多。

3.4 反问环节如何体现行业理解

面试快结束时，面试官通常会问“你有什么想问我的”。很多实习生在这个环节直接放弃，或者只问“转正率多少”。但反问才是展示行业认知的隐藏加分项。问题不用多，两个就够，但每个问题都要有质量。

一类比较稳的反问是问业务与技术结合的：“我了解到现在出行感知场景大量依赖数据闭环，我想请问团队目前在数据筛选、挖掘难例和主动学习这三块的自动化程度大概到了什么程度？”这个问题既不会打探到保密信息，又能让面试官感觉到你不是只关心算法公榜。

另一类反问可以带一点“思考前置”的感觉：“如果实习生入职后最需要补的一项能力，您觉得会是模型理解还是工程能力？”这种问题不是套路，而是你真的可以拿回去调整学习计划。面试官回答之后，你还能顺着聊一两句，展示你听得懂对方在说什么。哪怕这一轮最终没有通过，你也会在反问中收获真实的岗位信息，这对下一场面试非常有价值。

4. 手撕代码：NMS、mAP 与边界测试的作答策略

4.1 手写非极大值抑制：边界条件比代码本身更关键

CV算法实习生面试里最常出现的手撕代码题目，第一名是手写NMS，第二名是手写计算mAP。一个是后处理的核心，一个是模型评价的核心，两道题都很有区分度。先说NMS。面试官不一定要求你写出多么优雅的向量化实现，但至少不能出现严重错误。

NMS的伪代码流程可以这样描述：先按检测框的置信度从高到低排序，把最高置信度对应的框加入最终结果，然后移除和当前框的IoU大于阈值的所有候选框，重复这个过程，直到列表为空。核心计算包括两个框的交集面积、并集面积和IoU。

一个常见现场作答版本是：

import numpy as np def nms(dets, thresh): x1 = dets[:, 0] y1 = dets[:, 1] x2 = dets[:, 2] y2 = dets[:, 3] scores = dets[:, 4] areas = (x2 - x1) * (y2 - y1) order = scores.argsort()[::-1] keep = [] while order.size > 0: i = order[0] keep.append(i) xx1 = np.maximum(x1[i], x1[order[1:]]) yy1 = np.maximum(y1[i], y1[order[1:]]) xx2 = np.minimum(x2[i], x2[order[1:]]) yy2 = np.minimum(y2[i], y2[order[1:]]) w = np.maximum(0.0, xx2 - xx1) h = np.maximum(0.0, yy2 - yy1) inter = w * h ovr = inter / (areas[i] + areas[order[1:]] - inter) inds = np.where(ovr <= thresh)[0] order = order[inds + 1] return keep

这段代码本身不难，但有几个细节面试官一定想听你亲口说出来：面积计算时x2-x1需不需要加一、IoU阈值通常取多少、如果两个框完全重叠是否只保留置信度更高的那个。像“是否需要加一”这个问题，本质上是坐标定义问题。如果坐标表示的是像素序号边界，面积计算要考虑宽高加一；如果坐标已经是连续坐标边界，就不用加一。能主动提这个细节，比闷头写完代码有效得多。

除了标准NMS，面试官有时还会延伸问Soft-NMS，或者问“NMS在批量推理的时候能不能用更高效的实现”。你不一定需要现场实现Soft-NMS，但至少要能说出Soft-NMS的核心思想：不要直接删除与高置信度框重叠的候选框，而是根据IoU大小降低它们的置信度，这样可以改善密集目标场景下的漏检。谈到这里，你其实已经触碰到“后处理也可以做成可学习模块”这个进阶话题了。

4.2 计算mAP：关键是理解“排序”和“平均”

手写mAP比手写NMS更容易被漏洞卡住。很多应试者知道mAP大概是什么概念，但一写代码就漏掉“对所有预测框按置信度排序”这一步，或者把interpolated AP的采样方式搞错。面试官要的不是唯一官方实现，而是看你能否准确定义这个问题。

核心流程可以拆成四步：获取所有预测框的置信度、真实标签和IoU匹配关系；按置信度降序排列；在每个置信度截断点计算precision和recall；用P-R曲线下的面积近似得到AP值，再对所有类别取平均得到mAP。

一个更偏实现的版本，现场能解释清楚就够了：

def compute_ap(recalls, precisions): # 在P-R曲线末尾补上(0,1)或用某种插值方式 mrec = np.concatenate(([0.0], recalls, [1.0])) mpre = np.concatenate(([0.0], precisions, [0.0])) for i in range(mpre.size - 1, 0, -1): mpre[i - 1] = np.maximum(mpre[i - 1], mpre[i]) indices = np.where(mrec[1:] != mrec[:-1])[0] ap = np.sum((mrec[indices + 1] - mrec[indices]) * mpre[indices + 1]) return ap

写这段的时候你最好能回答两个问题：第一，为什么要让precision曲线单调不降；第二，mAP在多个类别时是对每个类别算AP再取平均，而不是把所有类别混合在一起算。第一个问题关系到AP计算的稳定性；第二个问题关系到评估的公平性。当数据类别极其不均衡时，混合计算会让样本量大的类别主导整体指标，掩盖小类别的问题。

除了手撕代码，面试官还可能现场让你想测试用例。比如给你几个完全相同位置的框，或者两个IoU刚好等于阈值的框，你要能判断预期输出是什么。这种“测试用例”意识在工程实践里非常重要，实际写代码时最容易出错的就是浮点阈值边界和空数组边界。你可以在写完后主动说“我先跑一个三框重叠的用例，再跑一个空输入用例”，这种习惯可以直接把你和只会背代码的候选人区分开。

4.3 手撕环节的沟通技巧：边写边说思路

手撕代码并不是默写考试，面试官通常希望你边写边解释为什么这么做。如果闷头就是写，写得再对也缺乏交互感。我建议采用的节奏是：先用一句话说清自己的整体思路，比如“我会先按置信度排序，然后循环抑制高IoU框”；写完排序后顺手解释一句“这里降序是为了优先保留高置信度的检测结果”；写循环时解释“每次取当前最高置信度框，和剩余框做比较”。

写完后还会有自检阶段。比较稳的做法是立刻检查边界条件：一个空数组会不会报错；所有框都重叠时，是不是只返回一个；两个框IoU等于阈值时，表达式中用的是大于还是大于等于。主动做完这轮自检，即使最终结果有小瑕疵，面试官也会认为你有工程意识。真正扣分的不是写错一行代码，而是写错了还不知道自己错在哪里。

5. 一个月的备战方案：简历、模拟面试与心态管理

5.1 简历：把你做过的事情翻译成“可被验证的问题”

很多简历在项目经验里只写了“使用某种模型完成某检测任务，mAP达到多少”，这种写法信息量偏低。面试官会自然地追问“性能受什么限制”“为什么选这条技术路线”。如果简历里没有给这些线索，追问就会碰撞到很多临时拼凑的内容。比较好的做法是在每一段项目经历下写清楚三行：业务目标是什么、你负责什么、最终效果如何被衡量。

举例来说，不要只写“实现了疲劳检测模型”。可以写：“面向单目摄像头场景的疲劳检测，使用人脸关键点+眼部开合度时序特征完成状态判定；独立负责数据标注清洗和模型迭代，最终在自建测试集上眼睛闭合状态识别准确率达到约95%，在夜间低光照下单独补充增强数据后误报率下降约20%。”这种描述能让面试官快速抓到重点，也给追问预留了明确接口。

简历里还需要克制“什么都写”的冲动。有些同学会把Python、C++、PyTorch、TensorFlow、OpenCV、Docker、K8s全部写上，但每一项都没有实际佐证。与其铺很宽，不如选几个你真正能扛住追问的项目精准展示。面试官看到“熟悉Docker”可能会问“你在项目里怎么用Docker统一训练环境的”，答不上来就会变成负面信号。

5.2 用“20分钟限时模拟”代替盲目刷面经

备战面试的时候，最没有效率的事情就是反复刷面经但从不开口练习。面经只能告诉你问题类型，不能培养你现场组织语言的能力。我建议至少安排三次完整的模拟面试，每次控制在一小时，其中项目深挖部分要占半小时，手撕代码和基础问题各占十五分钟。模拟面试的提问者最好是比你更有经验的人，或者至少是能持续追问的人，否则效果会大打折扣。

模拟面试的核心目的不是“把题做对”，而是训练“条件反射”。具体来说，你要能做到被追问时先停两秒整理逻辑，再给出层次分明的回答。你在模拟中被问到某些不懂的细节，也是一件好事，记录下这些盲区，然后逐个去补，这比毫无目标地翻书效率高得多。

我还发现一个很实用的训练方法：把自己的口头表述录音再回放。你可能会发现自己说话非常啰嗦，总是在“其实”“然后”之间绕圈子。面试高压场景下，语言组织混乱会直接拉低内容质量。通过录音对比，可以快速把项目介绍压缩到两分钟以内，并且逼着自己只讲关键信息。

5.3 面对知识盲区：怎样把“不会”说得有价值

没有人能在面试中做到面面俱到，碰到不会的问题太正常了。不正常的是一碰就问倒，然后彻底冷场。把“我不会”说成“我现在确实没有深入验证，但我可以从哪几个方向去补”，这就是完全不同的效果。

一种可复用的回答结构是：先明确承认缺失的部分；然后说出自己掌握的相关部分；最后提出一个可行的验证思路。举个例子，面试官问“你了解量化感知训练吗”，如果你只在论文里看过这个词，没有真正部署经验，可以这样回答：“量化感知训练我没有在真实设备上完整实施过，但我了解它是在训练阶段模拟低位宽的计算噪声，让模型权重提前适应量化误差；如果让我来落地，我会先观察PTQ在目标模型上的精度损失分布，再针对损失较大的层选择QAT，并且用验证集监控每一层的敏感度。”这个回答既没有装懂，又体现出了工程推演能力。

特别提醒一句，不要不懂装懂。大多数面试官在这个领域深耕多年，一旦被识破，基本整场作废。承认盲区并用工程方法补齐，反而能让面试官看到你的学习潜力和诚实度，这对应届实习生来说远比“看起来很全才”重要。

5.4 一个具体到能直接执行的四周时间表

如果距离面试还有四周，我会把时间切成四个阶段，每个阶段解决一个核心问题。第一周用来梳理自身项目：把所有做过的任务按照数据、模型、评估、部署四个维度拆开，保证任何一个维度都能被连续追问十分钟。第二周用来补基础问题：目标检测、图像分类、语义分割、图像匹配、OCR、图像质量增强这些常见方向的基本原理要过关，同时每天做一道手撕代码题。

第三周用来玩一次“真实场景命题”。尝试给自己出几个出行场景题，例如“夜间高速上车灯反光导致检测框抖动怎么办”“进入隧道瞬间相机曝光剧烈变化，图像质量下降怎么办”。不要只停留在想，可以试着写简短的验证程序，哪怕只在几个公开图片上做模拟，也能大幅提升面试时的具体感。第四周用来做三到四次模拟面试，录音复盘，然后再针对暴露出的薄弱点做定向补齐。

这个计划不复杂，关键在“执行节奏”。很多同学备战的通病是前两周慢慢翻书，最后一周狂背面经，结果项目介绍依然没有主线，手撕代码依然写不顺。把时间表前置，提前进入模拟状态，真正到了面试现场，你会更容易进入“展示自己”而非“应付考试”的心境。

经历这一整轮面试和复盘之后，我最深的感觉是：实习生面试没有想象中那么多“不可准备”的玄学，它更像一次高密度的工程项目验收。面试官想知道的是你有没有解决真实问题的框架感，能不能在数据不干净、现场被追问、指标不完美的情况下保持清醒，而不是你到底背下了多少篇论文结论。出行场景尤其如此，摄像头背后是复杂的天气、光照和路况，算法工程师的每一轮判断都在和不确定性打交道。

最后再分享一个可以在面试前一周反复用的小技巧：不要只是在脑子里过项目，而是把你的项目介绍、项目里的三个重要决策、手撕代码的核心逻辑都写在一张纸上，然后合上纸，用两分钟口头讲一遍。每一次讲完，你都会发现某个原来没理顺的连接断点。把这些断点补掉，再讲一遍。等到你能四平八稳地把整条逻辑链路讲清楚，你的备战状态基本就不会被现场压力打出明显折损了。