在自动驾驶这行混久了，你会发现一个很有意思的现象：圈子里提到“黄埔军校”四个字，大家不用解释就知道说的是哪家。前阵子跟几个老朋友闲聊，有人随口说了句“现在从那儿出来的，加起来得有4500人了”，在场的都愣了一下——不是惊讶于数字本身，而是这个数字背后折射出来的行业版图变化。4500个受过体系化训练、经历过真实项目考验的工程师，分散到各家主机厂、Tier 1、Robotaxi公司、芯片公司，这已经不单是一家公司的人才储备问题了，而是整个行业的技术扩散源。这篇文章不聊具体技术方案对比，也不评价某家公司的产品路线，就单纯聊聊这个“黄埔军校”是怎么成型的、它到底教什么、4500人这个数字意味着什么，以及最关键的——这套打法能不能复制，对还在门外的从业者有什么参考价值。1. “黄埔军校”这个称号是怎么来的1.1 为什么偏偏它配得上这个称呼国内做自动驾驶的团队不少，能被称为“黄埔军校”的，得满足几个硬条件：第一，起步早，早到行业还没有成熟人才供应链的时候就开始成建制培养；第二，培养链路完整，不是拉几个人做做算法demo就算数，而是从数据采集、标注、模型训练、仿真验证到实车测试全流程跑通；第三，输出量大且持续多年，形成足够规模的“校友网络”。这个团队赶上了最好的窗口期。那几年高校里做感知、控制、SLAM的博士生毕业没几个去处，自动驾驶公司屈指可数，供需极度失衡。它率先把一批有学术底子但完全不懂工程的年轻人招进来，用自研工具链和项目实战把他们磨成了行业需要的“成品”。关键是，这个过程是成体系的——新人进来有统一的培训流程，有mentor带，有内部文档库可以翻，有真实路测数据可以练手，而不是像很多小团队那样全靠自己摸着石头过河。1.2 4500人这个数字的分量4500人放在互联网行业可能不算什么，放到自动驾驶赛道就是另一个概念了。全国真正在一线做自动驾驶核心算法和系统工程的人，满打满算也就几万，一个团队累计培养和吸纳了就占其中相当可观的比例。这是什么概念？相当于你随便参加一个自动驾驶行业的技术交流会，台下坐的听众里可能就有好几个是“校友”，而且分布在完全不同的公司。这个数字更重要的含义在于“外溢效应”。一个工程师从这套体系里出来，他脑子里装的不仅仅是某个模型的训练技巧，而是一整套做事的标准——数据怎么管、实验怎么设计、代码怎么Review、系统出了故障怎么排查。这些人散到行业各处，实际上是把一套成熟的方法论复制到了几十家公司里。与其说4500人是一个团队的人数，不如说它是行业技术标准扩散的节点数。1.3 自动驾驶人才培养的三个阶段回头看自动驾驶行业的人才供给，大致走过三个阶段。早期是学院派时代，高校实验室是唯一的人才来源，导师的研究方向基本决定了学生入行时懂什么、不懂什么。到了产业发展期，企业开始大规模建团队，“黄埔军校”这种内部造血模式成为主流，它的价值在于把“能不能干活”作为培养的终点，而不是停留在“懂不懂理论”上。现在则进入存量整合期，行业对人才的要求明显提高了，光会一个感知模型训练已经不够，得懂整个系统怎么协同。三个阶段里，“黄埔军校”恰好卡在第二个阶段的中段发力，用标准化批量生产的方式，在那个最缺人的时候补上了最大的缺口。这个时间窗口不可复制，后来者就算完全copy它的培训体系，也找不到那么大的场景和数据去喂人了。2. 这个“军校”到底在教什么2.1 感知方向：从目标检测到BEV感知感知是整个自动驾驶技术栈里最“热闹”的部分，也是这个团队最早建立优势的地方。早期大家做感知就是2D目标检测加上单目或者多目视觉，后来上了激光雷达，开始做3D检测、多传感器融合。这里面的核心矛盾一直是：摄像头有丰富的纹理信息但缺少深度，激光雷达有精确的深度但语义信息弱，怎么把两者接起来，业内走了好几年的弯路。“黄埔军校”在感知方向上的贡献，是让一大批工程师在BEV（鸟瞰图）感知成为主流之前，就把多传感器融合的各种姿势都趟了一遍。前融合还是后融合、特征级融合还是目标级融合、时间对齐怎么做、外参标定误差怎么处理，这些问题不是靠读论文能学会的，必须真刀真枪在数据和实车上磨。后来Transformer架构兴起，BEV感知变成标配，这套经验的价值反而更突出了——因为模型架构可以快速切换，但数据闭环和评测能力不是一天能建起来的。2.2 决策规划：从规则到模型规划控制是自动驾驶里最“劝退”的环节，原因很简单：感知错了还能靠后融合拉一把，规划错了就直接体现在车上，乘客和路人都能感受到。早期做决策规划基本是规则派的天下——有限状态机加一堆if-else，把场景拆成巡航、跟车、变道、转弯、靠边停车，每个场景写一套逻辑。这套方案的优点是安全可控，缺点是场景组合爆炸，长尾case根本写不完。这个团队培养规划工程师的思路是“先规则后模型”：新人先老老实实把规则框架摸透，理解每个阈值背后的工程考量，然后再接触基于学习的方案——模仿学习、强化学习、交互博弈，但始终把安全兜底规则放在最前面。这个顺序很重要。上来就学模型化方案的工程师很容易做出学术上好看、但上车就跑偏的东西。真正成熟的规划工程师，脑子里同时有两套系统：一套是用来解决99%日常场景的学习型策略，一套是用来兜住那1%极端场景的硬规则。2.3 仿真与评测：虚拟世界里的极限测试行业内有个说法：自动驾驶的进度不是由算法决定的，而是由测试决定的。车不能只在路上跑，一来是安全风险，二来是效率太低——很多极端场景百万公里都遇不到一次，纯靠路测不知道要攒到猴年马月。所以仿真平台是每家公司的核心基建，黄埔军校在这方面给工程师的训练是非常严格的。场景库怎么构建、corner case从哪儿来、传感器噪声怎么建模、怎么避免“仿真里跑得好好的、一上路就翻车”的过拟合陷阱，这些都是核心课题。评测体系本身也是一门学问——接管率、平均无故障里程（MPI）、每秒碰撞风险（PDD）这些指标怎么组合使用，才能既反映系统真实水平又不至于被刷分。从这套体系里出来的人，对数字非常敏感，他们不会说“效果还行”，而是会追问：哪个场景集上测的？数据分布是什么样的？指标波动区间是多少？2.4 系统与工程化：真正拉开差距的部分如果只看算法能力，很多学校出来的优秀博士生未必比“黄埔系”差，真正拉开差距的是工程化能力。自动驾驶系统是一个典型的实时嵌入式系统加上大数据处理平台的混合体，传感器数据要在毫秒级完成处理，模型推理要跑到低延迟，同时整个链路要满足功能安全的要求。这就涉及一大堆脏活累活：中间件怎么选型、计算平台怎么适配、时间同步怎么做、标定工具链怎么维护、系统降级策略怎么设计、远程监控怎么搭。这些东西论文里不会写，学校里也不教，只能在真实系统里踩坑踩出来。“黄埔军校”的做法是让每个算法工程师都必须经历至少一次从模型到上车全流程的交付，谁也别想只做PPT算法。这个训练养成的工程直觉，是这批人后来的立身之本。3. 4500人是怎么炼成的：人才培养路径拆解3.1 选人标准：不只看算法基础很多人好奇这个团队当年怎么挑人，市面上流传很多说法，有说只看顶会论文的，有说只收名校博士的。根据我接触过的“校友”来看，选人标准里论文和学历只是入场券，真正决定录不录用的是另外三样东西：一是工程直觉，给一个模糊的问题，候选人会不会主动追问边界条件和使用场景；二是Debug能力，给他一个看似诡异的现象，能不能有条理地定位可能的原因；三是owner意识，聊到之前做过的项目，他是只说自己负责的部分，还是能讲清楚整个项目的来龙去脉。这三样东西没法靠短期刷题刷出来，所以这个团队的面试风格以开放性问题为主，会故意抛一些没有标准答案的系统设计题，看候选人怎么拆解、怎么权衡、怎么承认自己不知道的地方。比起招一个什么都会的人，他们更愿意招一个知道自己不会什么、并且知道怎么去学会的人。3.2 新人成长：从工具人到问题owner新人进去之后，成长路径大体上分三步。前三个月基本在“打杂”：整理数据、跑评测脚本、给资深工程师提bug单，这个阶段考验的是耐心和细心，很多眼高手低的新人会在这个阶段露馅。半年到一年开始接触真实模块开发，但通常是从边缘模块做起——比如某个后处理逻辑、某个评测指标的计算脚本——这些工作不性感但非常练基本功。两年左右开始独立负责一个完整模块，这时候才算真正进入核心圈。这个爬坡节奏设计得很讲究。前期的“打杂”不是真的浪费人力，而是让新人在最底层把数据流、工具链、评测逻辑摸清楚，后面独立做模块时才不会犯“数据没洗干净就训模型”这种低级错误。从工具人到问题owner的转变，关键是思维模式的切换：工具人想的是“把这个任务完成”，owner想的是“这个模块长期怎么演进、边界在哪、依赖什么、风险是什么”。3.3 梯队建设与传帮带机制支撑这套培养体系的，是几个具体机制。mentor制度是标配，每个新人进来会指定一个资深工程师带，mentor不光是答疑，还要定期review新人的代码和设计文档。代码Review是整个团队非常看重的事，一份好的Review不只是挑错，而是会指出“为什么这么写不好”和“在什么场景下可能会出问题”，这个过程对新人的提升比自己做十个模块都大。还有一个容易被忽视的机制是技术分享。团队内部定期有人讲自己踩过的坑或者读过的论文，分享不强制参加，但几乎场场爆满，因为分享的人会把自己做的方案从头到尾讲一遍，包括失败的尝试和被毙掉的设计——这些内容是外面查不到的。梯队建设说白了就是让每个人都有机会当老师，当一个人开始给别人讲东西的时候，他才会真正发现自己哪些地方没想透。3.4 流动与输出：行业“校友会”的形成一个培养了4500人的团队，意味着人员流动率一定不低。很多人聊到这个话题会觉得可惜，但从行业视角看，这种流动恰恰是技术扩散最主要的方式。早期出去的工程师，很多都成了其他公司自动驾驶部门的创始成员或技术负责人，他们带去的不仅是代码和算法，还有一整套做事的标准和流程。这里面有个值得玩味的生态现象：当某个公司有多个“校友”时，新人的招聘会不自觉地倾向于继续招“校友”，因为磨合成本低、技术语言一致、做事风格互相认可。这带来了一个结果——黄埔军校的人才网络是自增强的，它的影响力并没有随着人员流出而减弱，反而因为校友散布得更广而变强。对还在团队里的人来说，这也是一种隐性的收益：你在行业里的人脉和口碑，很多是从这个网络延伸出去的。4. 这个模式能复制吗4.1 可以借鉴的具体机制说实话，黄埔军校模式里有相当一部分东西是可以迁移到其他团队的，关键看愿不愿意投入。文档沉淀制度。所有重大技术决策、事故复盘、设计评审结论都有存档，新人遇到问题先查文档而不是到处问人，这套体系能把组织智慧固化下来，不会因为核心员工离职而断档。新人轮岗机制。前几个月在数据、评测、仿真等支撑部门轮一圈再定岗，保证每个人对全链路都有体感，这个机制成本高但回报极高。复盘文化。上线出问题不追责个人，而是追责流程和机制——为什么这个问题没有被提前发现？测试集里为什么不包含这类场景？下次怎么避免？这种复盘机制让组织是“学习型”的，而不是“追责型”的。4.2 很难复制的部分但有些东西确实复制不了。第一是数据资产，那几年积累的路测数据、仿真场景库、corner case集合，是用真金白银和时间堆出来的，后来者除非花同样的时间跑同样的路，否则补不齐。第二是组织记忆，团队经历过从demo到量产的全过程，“哪些方案看着好看但实际跑不通”这种经验只存在于老员工脑子里，没法量化也没法快速传递。第三是时间窗口，自动驾驶人才最稀缺的年代已经过去了，现在再花同样的力气培养新人，从投入产出比看不划算，这也是很多团队后来直接挖人而不愿意自己培养的原因。4.3 对从业者的参考价值对还在选择团队的从业者来说，判断一个团队是否值得去，可以从“黄埔军校”模式里提炼几个检验标准：团队有没有完整的数据闭环和实车验证能力？有没有成体系的Code Review和设计评审？新人进来有没有mentor带、有没有时间适应和试错？团队内部有没有鼓励分享和复盘的氛围？如果答案都是肯定的，即使这个团队规模不大，也是值得考虑的去处——因为你进去之后获得的不只是一份工资，而是一套能带走的方法论。5. 常见问题与学习路径避坑5.1 自学入门最常见的三个误区这几年经常有读者问我想转行做自动驾驶怎么自学，我观察下来，大部分人卡在三个误区里。第一个误区是只刷论文不看工程。有些人把顶会paper刷了个遍，聊起某个新模型头头是道，但给他一份真实数据，他不知道怎么清洗、怎么组织训练集、怎么评估效果。自动驾驶是门工程学科，模型只是整个系统里的一环，数据、评测、部署占的权重远大于模型结构设计。第二个误区是只跑开源代码不理解数据。开源项目拿来就能跑通，给了很多人“我会了”的错觉，一旦换了数据分布，模型效果崩塌就不知道怎么办了。正确的做法是花大量时间看数据、标数据、分析bad case，对数据形成直觉，这部分功夫别人替代不了。第三个误区是数学基础不扎实。做感知和规划，概率论、优化理论、矩阵论是逃不掉的地基，很多人上来就啃深度学习框架，结果遇到问题只能调参，不知道背后的原理，天花板很低。5.2 面试时最容易暴露的问题面试过不少候选人，发现有一个共性问题：简历上写“熟悉”的东西，经不起三个追问。写“熟悉Transformer”，问为什么需要位置编码就卡壳；写“熟悉多传感器融合”，问时间同步误差怎么处理就开始含糊；写“主导过xx模块开发”，问当时有哪些可选方案、为什么选这个方案、有哪些权衡，就答不上来。这个问题的根源在于很多人的学习方式是被动的——跑通了就认为会了，接受了某个现成方案就认为理解了。想解决这个问题，一个有效的方法是把每个知识点都追问三层：是什么、为什么、如果换一种做法会怎样。面试官真正想看的不是你知道什么，而是你的思考深度和解决问题的框架。5.3 几条掏心窝的实操建议结合我自己在行业里这些年接触各类工程师的经验，给想走这条路的朋友几条建议：不要只盯着算法岗，嵌入式、系统工程、仿真工具链这些方向同样稀缺，而且竞争小很多。有机会一定要接触实车，哪怕只是跟着出去跑跑测试、看看问题是怎么被发现的，对系统理解会有质的提升。学会写文档。能把一个复杂问题用文字清楚地讲明白，是一种比写代码更稀缺的能力。定期复盘自己做过的项目，不只是记录结果，更重要的是记录当时为什么这么决策、有没有更好的方案、如果重来会怎么做。经常有人问我个人感受，我印象最深的反而不是某个技术方案或者项目里程碑，而是从黄埔军校出来的人身上那股劲——遇到问题第一反应是“我来想办法”，而不是“这个不归我管”。这种习惯一旦养成，比任何技术能力都值钱。最后再分享一个观察：这些年技术风口来来去去，但踏实积累的工程能力和解决问题的方法论，永远不会过时，不管在哪个团队、做哪个方向，都是这行的硬通货。
在自动驾驶这行混久了，你会发现一个很有意思的现象：圈子里提到“黄埔军校”四个字，大家不用解释就知道说的是哪家。前阵子跟几个老朋友闲聊，有人随口说了句“现在从那儿出来的，加起来得有4500人了”，在场的都愣了一下——不是惊讶于数字本身，而是这个数字背后折射出来的行业版图变化。4500个受过体系化训练、经历过真实项目考验的工程师，分散到各家主机厂、Tier 1、Robotaxi公司、芯片公司，这已经不单是一家公司的人才储备问题了，而是整个行业的技术扩散源。这篇文章不聊具体技术方案对比，也不评价某家公司的产品路线，就单纯聊聊这个“黄埔军校”是怎么成型的、它到底教什么、4500人这个数字意味着什么，以及最关键的——这套打法能不能复制，对还在门外的从业者有什么参考价值。1. “黄埔军校”这个称号是怎么来的1.1 为什么偏偏它配得上这个称呼国内做自动驾驶的团队不少，能被称为“黄埔军校”的，得满足几个硬条件：第一，起步早，早到行业还没有成熟人才供应链的时候就开始成建制培养；第二，培养链路完整，不是拉几个人做做算法demo就算数，而是从数据采集、标注、模型训练、仿真验证到实车测试全流程跑通；第三，输出量大且持续多年，形成足够规模的“校友网络”。这个团队赶上了最好的窗口期。那几年高校里做感知、控制、SLAM的博士生毕业没几个去处，自动驾驶公司屈指可数，供需极度失衡。它率先把一批有学术底子但完全不懂工程的年轻人招进来，用自研工具链和项目实战把他们磨成了行业需要的“成品”。关键是，这个过程是成体系的——新人进来有统一的培训流程，有mentor带，有内部文档库可以翻，有真实路测数据可以练手，而不是像很多小团队那样全靠自己摸着石头过河。1.2 4500人这个数字的分量4500人放在互联网行业可能不算什么，放到自动驾驶赛道就是另一个概念了。全国真正在一线做自动驾驶核心算法和系统工程的人，满打满算也就几万，一个团队累计培养和吸纳了就占其中相当可观的比例。这是什么概念？相当于你随便参加一个自动驾驶行业的技术交流会，台下坐的听众里可能就有好几个是“校友”，而且分布在完全不同的公司。这个数字更重要的含义在于“外溢效应”。一个工程师从这套体系里出来，他脑子里装的不仅仅是某个模型的训练技巧，而是一整套做事的标准——数据怎么管、实验怎么设计、代码怎么Review、系统出了故障怎么排查。这些人散到行业各处，实际上是把一套成熟的方法论复制到了几十家公司里。与其说4500人是一个团队的人数，不如说它是行业技术标准扩散的节点数。1.3 自动驾驶人才培养的三个阶段回头看自动驾驶行业的人才供给，大致走过三个阶段。早期是学院派时代，高校实验室是唯一的人才来源，导师的研究方向基本决定了学生入行时懂什么、不懂什么。到了产业发展期，企业开始大规模建团队，“黄埔军校”这种内部造血模式成为主流，它的价值在于把“能不能干活”作为培养的终点，而不是停留在“懂不懂理论”上。现在则进入存量整合期，行业对人才的要求明显提高了，光会一个感知模型训练已经不够，得懂整个系统怎么协同。三个阶段里，“黄埔军校”恰好卡在第二个阶段的中段发力，用标准化批量生产的方式，在那个最缺人的时候补上了最大的缺口。这个时间窗口不可复制，后来者就算完全copy它的培训体系，也找不到那么大的场景和数据去喂人了。2. 这个“军校”到底在教什么2.1 感知方向：从目标检测到BEV感知感知是整个自动驾驶技术栈里最“热闹”的部分，也是这个团队最早建立优势的地方。早期大家做感知就是2D目标检测加上单目或者多目视觉，后来上了激光雷达，开始做3D检测、多传感器融合。这里面的核心矛盾一直是：摄像头有丰富的纹理信息但缺少深度，激光雷达有精确的深度但语义信息弱，怎么把两者接起来，业内走了好几年的弯路。“黄埔军校”在感知方向上的贡献，是让一大批工程师在BEV（鸟瞰图）感知成为主流之前，就把多传感器融合的各种姿势都趟了一遍。前融合还是后融合、特征级融合还是目标级融合、时间对齐怎么做、外参标定误差怎么处理，这些问题不是靠读论文能学会的，必须真刀真枪在数据和实车上磨。后来Transformer架构兴起，BEV感知变成标配，这套经验的价值反而更突出了——因为模型架构可以快速切换，但数据闭环和评测能力不是一天能建起来的。2.2 决策规划：从规则到模型规划控制是自动驾驶里最“劝退”的环节，原因很简单：感知错了还能靠后融合拉一把，规划错了就直接体现在车上，乘客和路人都能感受到。早期做决策规划基本是规则派的天下——有限状态机加一堆if-else，把场景拆成巡航、跟车、变道、转弯、靠边停车，每个场景写一套逻辑。这套方案的优点是安全可控，缺点是场景组合爆炸，长尾case根本写不完。这个团队培养规划工程师的思路是“先规则后模型”：新人先老老实实把规则框架摸透，理解每个阈值背后的工程考量，然后再接触基于学习的方案——模仿学习、强化学习、交互博弈，但始终把安全兜底规则放在最前面。这个顺序很重要。上来就学模型化方案的工程师很容易做出学术上好看、但上车就跑偏的东西。真正成熟的规划工程师，脑子里同时有两套系统：一套是用来解决99%日常场景的学习型策略，一套是用来兜住那1%极端场景的硬规则。2.3 仿真与评测：虚拟世界里的极限测试行业内有个说法：自动驾驶的进度不是由算法决定的，而是由测试决定的。车不能只在路上跑，一来是安全风险，二来是效率太低——很多极端场景百万公里都遇不到一次，纯靠路测不知道要攒到猴年马月。所以仿真平台是每家公司的核心基建，黄埔军校在这方面给工程师的训练是非常严格的。场景库怎么构建、corner case从哪儿来、传感器噪声怎么建模、怎么避免“仿真里跑得好好的、一上路就翻车”的过拟合陷阱，这些都是核心课题。评测体系本身也是一门学问——接管率、平均无故障里程（MPI）、每秒碰撞风险（PDD）这些指标怎么组合使用，才能既反映系统真实水平又不至于被刷分。从这套体系里出来的人，对数字非常敏感，他们不会说“效果还行”，而是会追问：哪个场景集上测的？数据分布是什么样的？指标波动区间是多少？2.4 系统与工程化：真正拉开差距的部分如果只看算法能力，很多学校出来的优秀博士生未必比“黄埔系”差，真正拉开差距的是工程化能力。自动驾驶系统是一个典型的实时嵌入式系统加上大数据处理平台的混合体，传感器数据要在毫秒级完成处理，模型推理要跑到低延迟，同时整个链路要满足功能安全的要求。这就涉及一大堆脏活累活：中间件怎么选型、计算平台怎么适配、时间同步怎么做、标定工具链怎么维护、系统降级策略怎么设计、远程监控怎么搭。这些东西论文里不会写，学校里也不教，只能在真实系统里踩坑踩出来。“黄埔军校”的做法是让每个算法工程师都必须经历至少一次从模型到上车全流程的交付，谁也别想只做PPT算法。这个训练养成的工程直觉，是这批人后来的立身之本。3. 4500人是怎么炼成的：人才培养路径拆解3.1 选人标准：不只看算法基础很多人好奇这个团队当年怎么挑人，市面上流传很多说法，有说只看顶会论文的，有说只收名校博士的。根据我接触过的“校友”来看，选人标准里论文和学历只是入场券，真正决定录不录用的是另外三样东西：一是工程直觉，给一个模糊的问题，候选人会不会主动追问边界条件和使用场景；二是Debug能力，给他一个看似诡异的现象，能不能有条理地定位可能的原因；三是owner意识，聊到之前做过的项目，他是只说自己负责的部分，还是能讲清楚整个项目的来龙去脉。这三样东西没法靠短期刷题刷出来，所以这个团队的面试风格以开放性问题为主，会故意抛一些没有标准答案的系统设计题，看候选人怎么拆解、怎么权衡、怎么承认自己不知道的地方。比起招一个什么都会的人，他们更愿意招一个知道自己不会什么、并且知道怎么去学会的人。3.2 新人成长：从工具人到问题owner新人进去之后，成长路径大体上分三步。前三个月基本在“打杂”：整理数据、跑评测脚本、给资深工程师提bug单，这个阶段考验的是耐心和细心，很多眼高手低的新人会在这个阶段露馅。半年到一年开始接触真实模块开发，但通常是从边缘模块做起——比如某个后处理逻辑、某个评测指标的计算脚本——这些工作不性感但非常练基本功。两年左右开始独立负责一个完整模块，这时候才算真正进入核心圈。这个爬坡节奏设计得很讲究。前期的“打杂”不是真的浪费人力，而是让新人在最底层把数据流、工具链、评测逻辑摸清楚，后面独立做模块时才不会犯“数据没洗干净就训模型”这种低级错误。从工具人到问题owner的转变，关键是思维模式的切换：工具人想的是“把这个任务完成”，owner想的是“这个模块长期怎么演进、边界在哪、依赖什么、风险是什么”。3.3 梯队建设与传帮带机制支撑这套培养体系的，是几个具体机制。mentor制度是标配，每个新人进来会指定一个资深工程师带，mentor不光是答疑，还要定期review新人的代码和设计文档。代码Review是整个团队非常看重的事，一份好的Review不只是挑错，而是会指出“为什么这么写不好”和“在什么场景下可能会出问题”，这个过程对新人的提升比自己做十个模块都大。还有一个容易被忽视的机制是技术分享。团队内部定期有人讲自己踩过的坑或者读过的论文，分享不强制参加，但几乎场场爆满，因为分享的人会把自己做的方案从头到尾讲一遍，包括失败的尝试和被毙掉的设计——这些内容是外面查不到的。梯队建设说白了就是让每个人都有机会当老师，当一个人开始给别人讲东西的时候，他才会真正发现自己哪些地方没想透。3.4 流动与输出：行业“校友会”的形成一个培养了4500人的团队，意味着人员流动率一定不低。很多人聊到这个话题会觉得可惜，但从行业视角看，这种流动恰恰是技术扩散最主要的方式。早期出去的工程师，很多都成了其他公司自动驾驶部门的创始成员或技术负责人，他们带去的不仅是代码和算法，还有一整套做事的标准和流程。这里面有个值得玩味的生态现象：当某个公司有多个“校友”时，新人的招聘会不自觉地倾向于继续招“校友”，因为磨合成本低、技术语言一致、做事风格互相认可。这带来了一个结果——黄埔军校的人才网络是自增强的，它的影响力并没有随着人员流出而减弱，反而因为校友散布得更广而变强。对还在团队里的人来说，这也是一种隐性的收益：你在行业里的人脉和口碑，很多是从这个网络延伸出去的。4. 这个模式能复制吗4.1 可以借鉴的具体机制说实话，黄埔军校模式里有相当一部分东西是可以迁移到其他团队的，关键看愿不愿意投入。文档沉淀制度。所有重大技术决策、事故复盘、设计评审结论都有存档，新人遇到问题先查文档而不是到处问人，这套体系能把组织智慧固化下来，不会因为核心员工离职而断档。新人轮岗机制。前几个月在数据、评测、仿真等支撑部门轮一圈再定岗，保证每个人对全链路都有体感，这个机制成本高但回报极高。复盘文化。上线出问题不追责个人，而是追责流程和机制——为什么这个问题没有被提前发现？测试集里为什么不包含这类场景？下次怎么避免？这种复盘机制让组织是“学习型”的，而不是“追责型”的。4.2 很难复制的部分但有些东西确实复制不了。第一是数据资产，那几年积累的路测数据、仿真场景库、corner case集合，是用真金白银和时间堆出来的，后来者除非花同样的时间跑同样的路，否则补不齐。第二是组织记忆，团队经历过从demo到量产的全过程，“哪些方案看着好看但实际跑不通”这种经验只存在于老员工脑子里，没法量化也没法快速传递。第三是时间窗口，自动驾驶人才最稀缺的年代已经过去了，现在再花同样的力气培养新人，从投入产出比看不划算，这也是很多团队后来直接挖人而不愿意自己培养的原因。4.3 对从业者的参考价值对还在选择团队的从业者来说，判断一个团队是否值得去，可以从“黄埔军校”模式里提炼几个检验标准：团队有没有完整的数据闭环和实车验证能力？有没有成体系的Code Review和设计评审？新人进来有没有mentor带、有没有时间适应和试错？团队内部有没有鼓励分享和复盘的氛围？如果答案都是肯定的，即使这个团队规模不大，也是值得考虑的去处——因为你进去之后获得的不只是一份工资，而是一套能带走的方法论。5. 常见问题与学习路径避坑5.1 自学入门最常见的三个误区这几年经常有读者问我想转行做自动驾驶怎么自学，我观察下来，大部分人卡在三个误区里。第一个误区是只刷论文不看工程。有些人把顶会paper刷了个遍，聊起某个新模型头头是道，但给他一份真实数据，他不知道怎么清洗、怎么组织训练集、怎么评估效果。自动驾驶是门工程学科，模型只是整个系统里的一环，数据、评测、部署占的权重远大于模型结构设计。第二个误区是只跑开源代码不理解数据。开源项目拿来就能跑通，给了很多人“我会了”的错觉，一旦换了数据分布，模型效果崩塌就不知道怎么办了。正确的做法是花大量时间看数据、标数据、分析bad case，对数据形成直觉，这部分功夫别人替代不了。第三个误区是数学基础不扎实。做感知和规划，概率论、优化理论、矩阵论是逃不掉的地基，很多人上来就啃深度学习框架，结果遇到问题只能调参，不知道背后的原理，天花板很低。5.2 面试时最容易暴露的问题面试过不少候选人，发现有一个共性问题：简历上写“熟悉”的东西，经不起三个追问。写“熟悉Transformer”，问为什么需要位置编码就卡壳；写“熟悉多传感器融合”，问时间同步误差怎么处理就开始含糊；写“主导过xx模块开发”，问当时有哪些可选方案、为什么选这个方案、有哪些权衡，就答不上来。这个问题的根源在于很多人的学习方式是被动的——跑通了就认为会了，接受了某个现成方案就认为理解了。想解决这个问题，一个有效的方法是把每个知识点都追问三层：是什么、为什么、如果换一种做法会怎样。面试官真正想看的不是你知道什么，而是你的思考深度和解决问题的框架。5.3 几条掏心窝的实操建议结合我自己在行业里这些年接触各类工程师的经验，给想走这条路的朋友几条建议：不要只盯着算法岗，嵌入式、系统工程、仿真工具链这些方向同样稀缺，而且竞争小很多。有机会一定要接触实车，哪怕只是跟着出去跑跑测试、看看问题是怎么被发现的，对系统理解会有质的提升。学会写文档。能把一个复杂问题用文字清楚地讲明白，是一种比写代码更稀缺的能力。定期复盘自己做过的项目，不只是记录结果，更重要的是记录当时为什么这么决策、有没有更好的方案、如果重来会怎么做。经常有人问我个人感受，我印象最深的反而不是某个技术方案或者项目里程碑，而是从黄埔军校出来的人身上那股劲——遇到问题第一反应是“我来想办法”，而不是“这个不归我管”。这种习惯一旦养成，比任何技术能力都值钱。最后再分享一个观察：这些年技术风口来来去去，但踏实积累的工程能力和解决问题的方法论，永远不会过时，不管在哪个团队、做哪个方向，都是这行的硬通货。