ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

31岁晋升大厂最高职级22级:AI大模型浪潮下的工程师成长路径

31岁晋升大厂最高职级22级:AI大模型浪潮下的工程师成长路径

这几天在几个技术社区和朋友圈里,一条消息反复出现:一位31岁的女工程师,晋升到了大厂最高技术职级。圈内人看到“31岁”和“最高职级”这两个词,第一反应大多是羡慕,第二反应是“这么年轻,凭什么”。但作为一个参与过多次技术晋升评审、也亲眼见过身边不少同龄人走到职业十字路口的人,我更关心的是另一层问题:大厂职级体系里所谓的“最高职级”到底意味着什么?一个31岁的人,又是通过哪些积累和选择,才拿到了这个大部分工程师干到退休都未必能触碰到的级别?

先说清楚一件事:这不是一篇“教你复制某某路线”的鸡汤文。每个走到金字塔尖的人,都有时代机遇、平台红利和个人运气在里面。但这条新闻背后有两样东西是可以拆开分析的:一是大厂职级体系的运转逻辑,二是AI技术爆发周期给一代工程师带来的“电梯效应”。把这两件事看透了,你才知道自己该在哪个阶段、往哪个方向做积累,也才知道网上的那些解读里,哪些是干货,哪些只是带情绪的流量。

1. 22级不是工资条上的数字:大厂双轨职级体系的真实运转逻辑

很多非互联网行业的人看到“22级”会一脸茫然,甚至一些刚入行的工程师也搞不清,为什么同样是做技术的,有人是16级,有人是20级,这中间差的不只是几万块钱工资。

1.1 技术职级背后的“双轨制”:P序列和M序列的底层设计

国内头部科技公司普遍采用“双轨制”职级体系。一条线是管理序列(M序列),一条线是专业序列(P序列,也有的公司叫T序列)。管理序列管的是人、预算和业务结果,专业序列管的是技术方向、系统架构和专业深度。

22级属于专业序列的顶端,这个级别在各家大厂内部的叫法不太一样,有的叫“首席科学家”,有的叫“首席架构师”,但共同点是:它已经不再是一个“干活”的岗位,而是一个定义“干什么活最有价值”的岗位。在这个级别上,你的产出不是写了多少行代码、交付了几个项目,而是你能否为公司在某个技术方向上做出关键判断,能否让一个技术领域的投入产生十倍百倍的杠杆效应。

我用一张表帮大家快速建立对标概念:

职级区间角色标签日常工作状态对应管理级别
13-14级校招初级工程师分工明确的执行者,完成模块开发不对标管理岗
15-16级高级工程师独立负责中型模块,参与方案设计不对标管理岗
17-18级资深工程师/技术专家带小团队,主导跨团队项目落地对标总监或高级总监
19-20级资深专家/高级专家负责某条技术线的整体方向对标总监/资深总监
21-22级首席科学家/首席架构师定义公司级技术战略,影响行业方向对标VP及以上

看到这里你应该明白了:16级和17级之间是一个巨大的分水岭,因为从17级开始,你不再仅仅为自己的代码负责,而是开始为“一个团队的技术产出”负责。而21级到22级之间又是一个分水岭,因为这个级别的人,开始为“一个行业的技术走向”负责。

1.2 为什么22级这么罕见:晋升评审在评什么

很多人以为晋升是靠“熬年限”,年限到了自然往上走。这是对职级体系最大的误解。在大厂里,晋升评审的核心是回答三个问题:第一,你的技术能力在这个级别上是否站得住;第二,你的工作成果是否产生了这个级别要求的影响力;第三,如果把你的级别降回去,这个组织还能不能正常运转。

特别是到了20级以上的评审,考核维度不再是“你做了几个项目”,而是三个硬指标。

第一个指标是技术判断力。你能不能在一堆看似都有价值的技术方向里,挑出那个对公司最有利的方向。这个能力没法靠加班获得,只能靠足够的深度积累和行业视野。比如同样是做大模型,你是选择继续堆训练数据,还是去做模型架构创新,还是转去搞推理成本优化,这几个选择对应的投入产出比完全不一样。

第二个指标是技术杠杆。你的影响力是不是只局限在你自己所在的组,还是能跨团队、跨BG(事业群)甚至跨行业产生辐射。一个22级的候选人,往往要拿出证据证明:我做的技术工作影响了多少人、多少团队,有多少外部开发者在使用我的开源项目,或者我为公司建立了什么样的技术壁垒。

第三个指标是组织认知度。圈内人认不认可你是这个领域的代表人物。说白了就是当公司外部提到某个技术方向时,会不会第一个想到你,或者当你发表技术观点时,行业会不会认真听。这也是为什么“开源影响力”和“技术布道能力”在高阶评审中越来越重要。

这也就是说,22级并不是“代码写得最好的人”就能拿到的。它要求的是一个人在技术判断、行业影响和组织推动三个维度上同时站到顶端。这三样,每一样都需要少则五年、多则十年的持续积累,所以“31岁拿到22级”这件事才会在圈内引起这么大的讨论。

2. 31岁凭什么能冲到这个位置:技术窗口期给了一代人“电梯”

面对“31岁晋升最高职级”,大部分人脑子里冒出的第一个词可能是“天才”。但作为从业者,我更愿意把这件事拆成两个要素:个人硬实力确实够强,但更关键的是,她踩中了AI大模型爆发的整个周期,而这个周期恰好在她职业发展的高速期给了她一部别人没搭上的“电梯”。

2.1 从开源大模型团队到手机大厂AI部门:她的路径不是偶然

说到这位工程师的公开履历,有几个关键节点值得留意:长期在AI大模型领域做底层技术研发,深度参与过开源大模型的发布,在混合专家架构(MoE)这类核心模型结构上有过专项突破,之后进入手机大厂负责AI平台与开源相关工作,最终在31岁拿到专业序列的最高职级。

这条路径单独看每一步都合理,但放到一起看,你就会发现它和AI技术代际演变是高度重叠的。过去十年,AI领域走过几个明显的技术周期:早期的深度学习图像识别、随后的NLP预训练模型、再到最近这波大模型和生成式AI的爆发。如果在每一个代际切换时,你都在上一代技术栈里重复做已经成熟的事情,那你的职业价值就会随着技术成熟而贬值。但她选择的是一条“一直在上新方向”的路径:当市场还在用传统NLP做问答时,她已经转向了大规模预训练和模型架构本身的优化。

更关键的是,她进入开源大模型领域的时间点正好在2020年前后,那正是GPT系列开始出圈、国内大模型创业潮即将启动的前夜。在这个时间点积累了模型训练、架构设计和开源社区影响力的工程师,等到2023年大模型全面爆发时,已经天然成为市场上最稀缺的一批人。这不是单纯的个人能力强,而是“能力+时机”的双重叠加。

2.2 开源影响力是硬通货:为什么大厂评审委员会认这个

这套履历里还有一个细节容易被忽略:开源社区的影响力。在很多普通工程师眼里,写写技术博客、给开源项目提个PR是锦上添花的事,但在高阶技术评审里,开源影响力是一项非常硬的指标,原因很简单——因为无法造假。

你在公司内部做项目,评审委员会很难判断这个项目到底是你的功劳还是整个团队的功劳,而且内部项目的价值往往来自业务增长,外部环境一变,价值就不好衡量。但开源项目不一样,代码是公开的,讨论是公开的,有多少人使用了你的项目,有多少开发者愿意在社区里跟你互动,有多少外部公司拿你的工作做技术选型,这些数据摆在那里,一查便知。

这就相当于把一个人放到了全球同行的审视之下,能在这个环境里建立口碑的人,至少说明三点:你的工程能力经得起公开检验,你的技术判断被同行认可,你具备跨团队协作和沟通的基本素养。这三样东西恰好是大厂高阶技术评审最想看到的。

所以,不要觉得写博客、做开源是在“浪费时间做和KPI无关的事”。从我见到的高阶工程师样本来看,几乎每一个走到顶层的人,都有持续向外输出技术影响力的习惯。区别只是有人在职业生涯初期就开始积累,有人做到中高层才意识到这件事的重要性,后者往往要付出更大的代价来补课。

2.3 从“调参工程师”到“定义模型的人”:大模型时代的能力跃迁

这里还要多说一层,为什么这一代AI工程师更容易出现“跳级式”成长。上一代算法工程师,日常工作是做特征工程、调参数、跑实验,这些工作很大程度上依附于业务场景和平台环境。公司换了一个业务方向,你积累的经验可能瞬间清零,因为那些经验是“场景技能”而不是“底层能力”。

而大模型时代的核心工作是模型架构设计、训练策略制定、推理优化、数据配比和评测体系搭建,这些能力高度依赖一个人对深度学习底层的理解,是可迁移并且能够持续积累的。当一个工程师的工作从“被业务推着走”变成“能主动定义模型怎么做”,她的产出就和行业基础技术进步直接挂钩了。行业涨,她也在涨。这就是为什么在AI浪潮里,一批深度参与底层模型的工程师能实现职级上的跨越式上升,因为他们的技能正好嵌在了行业增速最快的齿轮上。

3. 专家路线vs管理路线:能到顶层的人,走的其实是同一条路

聊完行业窗口期,我们把视角拉回到一个更普遍的问题上:普通工程师应该走管理路线还是专家路线?很多人觉得这是两条截然不同的路,但如果你去观察那些真正走到高层的技术人,会发现他们做的事情高度相似。

3.1 转管理不等于升官:技术人最常见的路径误区

技术人工作五年左右,通常要面临一个岔路口:是接一个小组长的角色开始带人,还是继续在技术深水区做专家。在不少公司,这个岔路口看起来像是“只有带人的那条路才能继续往上走”,于是大量技术不错但管理意愿不强的工程师,半推半就地转了管理岗,结果发现自己每天都在开会对齐、处理项目杂事,原来的技术优势逐渐荒废,管理能力也没建立起来。

我这些年参与团队建设最大的感受是,一个人适不适合做管理,看的是两个底层特质:一是你愿不愿意花80%的时间在别人的成长上,二是你能不能接受自己的技术产出大幅降低。这两个问题的答案如果是否定的,那你硬走管理路线,最后大概率会卡在一个不高不低的位置,既上不去,技术也回不来了。

相比之下,专家路线的本质是另一件事:通过技术深度建立不可替代性,不靠人数只靠自己的判断力和工程产出说话。很多大厂里的首席科学家、首席架构师手下并没有庞大的团队,但他们对公司技术战略的影响力可能比某些总监级的人都大,因为他们在关键决策点上一锤定音。

3.2 高阶专家和普通专家的分水岭:技术判断力

这里有必要澄清一个常见的误读:专家路线不等于“一个人默默研究高深技术”。如果你去看高阶专家的工作方式,会发现他们日常做的大部分事情,其实是在做技术方向和资源投入的判断。

普通专家和高阶专家的分水岭,恰好在于“技术判断力”。普通专家能回答“这个东西怎么做”,高阶专家能回答“这个东西该不该做”。举个例子,同样是在评估是否要投入大模型推理优化,普通专家会去调研主流框架、对比性能数据、估算收益;高阶专家则要回答:这个问题现在是卡在算力上还是卡在算法上?优化推理能带来多少业务增量?如果行业模型结构一变,我们的投入会不会白费?这三个问题每一个都需要对技术周期和业务需求同时有深刻理解,这就是判断力。

所以,走专家路线做到顶层的人,表面看是不带团队的技术人,实际上做的却是“技术战略决策”的工作。从这个意义上说,管理者和高阶专家的能力模型是殊途同归的:上层的角色必须处理不确定性,必须做优先级判断,必须把自己的知识和判断力转化成组织能力,区别只在于你是通过管人来放大影响力,还是通过技术布道、技术决策和开源输出来放大影响力。

4. 想抓住大模型这波机会:AI工程师真正要补的是这几层能力

谈完了“为什么”,落点还是要回到“怎么做”上。我自己看过不少AI工程师的成长路径,也参与过技术评审,发现一个残酷的现实:大多数人的技能积累是线性的,而职业跃迁是非线性的。如果你想在35岁之前走到更高的职级,光靠按部就班地完成需求是远远不够的,你必须主动补上下面这几层能力。

4.1 底层技术栈的深度:在大模型方向上至少要有一项“壁垒级”技能

第一层是深度。大模型方向的技术栈非常宽,从模型架构、训练框架、数据工程、强化学习到推理优化,每个方向都够一个人钻研五年以上。但很多人犯的错误是,每个方向都只做到了解而没有到精通的level,什么都碰过,但问起任何一个方向的核心难点,都答不出可落地的方案。

如果你想走这条路,我建议集中突破一个窄方向,至少要在一项能做到“行业前5%”的程度。例如在模型结构上,你是不是真的吃透了MoE(混合专家架构)的负载均衡问题,能不能说明白专家路由策略和显存占用的关系;在训练框架上,你能不能独立设计和排查千卡以上集群的训练稳定性问题;在推理优化上,你是不是能把量化、剪枝、投机采样这些手段的收益算清楚。

评判标准很简单:你在这个方向上的经验,是否足以让你在技术评审中回答“如果我们这么做,会遇到什么问题、应该怎么解决”这一类深水区问题。如果你的经验全都来自“网上别人这么说”,那你还没到Depth的水位。

4.2 跨层视野的广度:从模型训练到业务产品的全链路认知

第二层是广度。我见过太多算法工程师,对自己那层技术栈非常熟悉,但一问到“我们调的模型到底怎么服务用户、成本曲线怎么样、竞品是怎么做的”就答不上来了。

高阶工程师和非高阶工程师的一个显著差别是:前者能把一个技术决策放在完整链路里去评估价值。比如你优化了一个大模型的推理速度,速度提升了30%,但如果你不了解整体服务的调用规模、成本结构和用户体验指标,你就无法判断这个优化的真实业务价值到底有多大。而“业务价值”恰恰是晋升评审中权重最高的因素。

要补上这个视野,一定要有意识地跳出自己的岗位职责来看问题。算法工程师不妨去读一读系统设计和成本分析文档,工程研发不妨去了解一下模型评测的指标含义和产品经理的需求逻辑。不需要你成为每个领域的专家,但你需要能在讨论时准确听懂对方在说什么,并且能把自己的技术方案的价值翻译成人人都懂的“降本增效”或“体验提升”。

4.3 对外发声力的积累:把工作成果“产品化”是晋升加速器

第三层很多人完全会忽略:你的价值不仅仅是你做了什么,还要看有多少人知道你做了什么。这里说的不是让你去混圈子搞人脉,而是强调一种“技术成果产品化”的能力。

具体来说,就是把你的每一次重大技术产出,沉淀成可迁移的形式。比如写完一套大规模分布式训练方案,能不能抽出一篇高质量技术分享;解决了线上一个棘手的稳定性问题,能不能复盘成一份问题排查方法论;参与开源项目后,能不能持续维护并和外部开发者形成良性互动。

我见过一个很有意思的案例。两个工程师水平和产出很接近,其中一个只是闷头做项目,另一个在做好项目的同时,还坚持把项目中的方案整理成内部技术白皮书,并在行业中做了一次公开分享。结果两年后,后者在晋升评审里的“影响力”维度上得到了压倒性的优势。原因不难理解:评审委员会判断一个人的影响力,本来就需要可见的证据,如果你不主动把你的专业度展示出来,别人就更难替你背书。

5. “31岁拿最高职级”给普通人留下的冷思考:别只盯着天花板

说完了体系和路径,最后想聊一点更个人化的观察。在大家热烈讨论“31岁拿22级”的时候,我反而想提醒身边的朋友们:这类新闻最大的价值不是让你产生焦虑,而是帮你校正自己的坐标系。

5.1 警惕幸存者偏差:金字塔尖永远只有少数人

首先要正视一个事实:能走到22级的人,在任何一家大厂都是极少数。这里面的构成要素包括行业红利、平台机会、个人天赋,甚至还有运气。绝大多数能力很强的工程师,可能一辈子也未必能拿到这个级别,但这里面有相当一部分人依然在各自领域做出了重要贡献,过着体面的职业生活。

所以我们看这类新闻,不应该得出“只有做到22级才算成功”的结论,而更应该看到“确实存在一条技术人可以持续成长到高层的路径”。对普通工程师来说,真正有价值的参考不是那个最终头衔,而是她身上体现出来的几个关键决策:持续选择高成长方向、重视开源影响力、不把自己锁死在单一技能树里。这些决策习惯是可复制的,虽然复制后未必能抵达同样高的位置,但一定能让你的职业道路走得更宽。

5.2 职业护城河的构建:从“升职加薪”到“独一无二的交付能力”

我判断一个工程师的长期价值,从来不看他的职级有多高,而是看他是否拥有“在某个范围内独一无二的交付能力”。这个范围可以是某个行业的业务知识,可以是某个复杂系统的全盘掌控,可以是某个开源社区里的声望,也可以是跨部门协作中别人信得过的靠谱程度。这些能力叠加在一起,就是这个人的职业护城河。

建护城河是个慢功夫,但有一个很实用的自检方法:每隔两三年,你回头看看自己最近一次能被别人记住的技术产出是什么?如果答不上来,或者上一条还是三年前的事,那就要警惕了,这说明你可能已经在消耗存量而非积累增量。大厂职级有评审周期,职业护城河也要有复盘周期,不要等到晋升失败或者市场环境变化时才发现自己手里没有可以抵御波动的资产。

5.3 一条可执行的阶段建议:按五年周期规划技术成长

如果你看完前面这些分析还是有点不知道从何入手,我给你一套我自己在实际辅导和复盘时用的框架,它不一定适合每个人,但方向是对的。

职业阶段核心目标关键动作需要避开的大坑
0-3年打好工程和算法基础跟完至少一个大模型的完整训练和部署流程,掌握一个框架的底层原理频繁换方向,每个方向都浅尝辄止
3-5年建立窄方向的专业深度选定一个子方向做持续攻坚,对外发布至少一个拿得出手的技术成果只顾深度不看业务价值,自嗨式研究
5-8年从执行者转向方向判断者参与至少一次跨团队技术规划,建立行业内的影响力和跨部门信任埋头苦干不表达,做了大量工作但无人知晓
8年以上构筑可迁移的行业影响力在技术社区或行业会议中形成公开影响力,能决定一个技术领域的投入优先级固守过往经验,拒绝拥抱新的技术周期

我自己在实际带人的过程中感受最深的一件事是:大多数人对职业发展的焦虑,其实不是来自能力不够,而是来自“目标模糊、路径不清”。一旦你看明白了职级体系背后的逻辑,也找到了一个值得深扎的方向,剩下的基本就只是时间积累了。回过头再去看“31岁拿最高职级”这条热搜,它真正给的信号其实很朴素:技术人的路可以很长很长,那个年龄并不会成为你的天花板,方向判断和稀缺性才是。

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进