校招季一开私信里十条有八条在问同一件事听说某头部电商大厂这一届校招放出来的岗位里AI 相关的占了绝大多数是不是真的普通程序员还有没有活路。这个数字的具体统计口径我没法逐条核实不同事业部的口径差得很远但要问“岗位结构正在往 AI 侧大幅倾斜”这件事本身只要你打开几家大厂的校招页面翻一遍 JD半小时就能自己得出结论——AI 相关的岗位描述确实铺满了整屏。对还在读书或者工作一两年、底子不算厚的人来说真正值得焦虑的不是那个百分比而是你有没有搞清楚这些挂着 AI 名头的岗位究竟在招什么样的人要干什么活需要什么能力。这篇就把这件事掰开揉碎讲清楚从岗位分类、考察链路到一份能走完的九十天切入路线尽量让不同基础的人都能找到自己的位置。1. 一条岗位结构的消息为什么让普通程序员集体焦虑1.1 先把这条消息拆开看数字背后是四种完全不同的活大部分人看到“AI 岗位占大头”脑子里浮现的画面是一群人坐在工位上推导损失函数、调 Transformer 的超参、跑几百张卡训模型。这个画面不能说错但它描述的是整个 AI 岗位池里最顶端、占比最小的一小块。真实情况是一个岗位被归到“AI 相关”可能意味着完全不同的四类工作而它们的门槛相差三到五倍。我把这些年见过的、以及帮人改简历时反复对照过的岗位类型整理成一张表你可以直接拿去和校招页面上的 JD 对号入座岗位类型典型title日常在干什么核心门槛大致占比感觉模型研究算法研究员、大模型算法工程师预训练、对齐、多模态融合、新结构探索博士或硕士顶会/大厂实习数学功底硬很小应用算法推荐算法、搜索算法、风控算法、NLP/CV 算法把成熟模型套到具体业务上调特征、调样本、调线上指标机器学习基础扎实懂业务能写工程代码中等AI 工程/平台AI 应用工程师、推理优化、训练框架、数据链路把模型接进业务系统做推理服务、向量检索、评测流水线、成本优化工程能力为主模型理解够用就行很大AI 产品/数据/运营AI 产品经理、数据策略、效果评测定义场景、写评测集、做数据闭环、管标注质量业务理解数据敏感度沟通不小看清楚这张表焦虑会降一半。因为绝大多数校招放出来的“AI 岗”落在后两类。而后两类要的核心能力恰恰是普通程序员手上已经有一部分的东西——工程能力、系统思维、排查问题的耐心。它们不是要求你从零变成一个数学家而是要求你在原有工程底子上补一层对模型的理解并且能把这层理解用在“让模型在真实业务里跑得又稳又便宜”这件事上。我见过太多人栽在这里一听说 AI 岗多立刻去买了一摞《深度学习》和概率论教材从第一章开始啃啃到第三章梯度下降推不下去信心崩了然后得出结论“我不适合”。这个路径本身就是错的。正确的顺序是先搞清楚目标岗位到底考什么再倒推要补什么而不是从头把整个学科铺一遍。1.2 岗位结构为什么会这样迁移三条推力不理解原因就容易把这件事当成一时的风口赌一把理解了原因才知道该怎么长期下注。我观察到的推力主要有三条。第一条是模型能力的“可用性”跨过了某个临界点。早些年很多业务场景不是没想到用模型是用了效果不如规则或者成本高到不划算。现在通用模型的能力上来了调用成本也在往下走于是每个业务线都在重新评估“我们这块能不能换成模型来做”。评估一多就需要人去做验证、做接入、做效果对比——这些活全是工程活。第二条是组织结构的收敛。基础模型研发是典型的规模效应生意一家公司不需要五个团队各训一个基座通常是一两个核心团队负责底座其余所有团队负责在底座上做应用。底座团队人数有限但门槛极高应用团队数量多、铺得广于是招聘需求自然倾斜到应用侧。这就是为什么你看到的岗位多但真正做模型研究的坑位少。第三条是产品形态在变。以前一个功能是“人点按钮系统执行逻辑”现在是“人说一句话系统理解意图再编排动作”。这个变化会波及前端交互、后端接口、数据存储、权限体系、监控告警——每一层都要改。改的过程需要大量懂工程又能和模型打交道的人。这类岗位在校招里通常不会写得很“玄”JD 上也常出现“熟悉 Python、熟悉常用后端框架”这种朴素要求但实际含金量不低。把这三条放在一起看结论就很清楚这轮岗位结构变化本质上不是“所有程序员都要转去做研究”而是“所有程序员都要学会在自己的工程能力上叠加一层模型理解”。前者是少数人的路后者是大多数人的路。1.3 被挤出去的是哪部分人别自己吓自己坦白讲确实有一部分岗位在收缩。纯粹的、只做增删改查的业务开发岗需求在减少只做页面还原、不碰数据链路的前端岗要求在上移连测试岗都在变手工点点点的岗位在缩会写自动化、会用模型辅助生成用例的岗位在扩。但这里有个容易被忽略的事实业务的复杂度并没有降低。模型接进来之后系统变得更不稳定、更不可解释、更难排查需要的人反而更专业。一个能定位“为什么这个请求延迟从 80ms 涨到 900ms”的工程师在任何时代都稀缺。模型不会替你做这件事模型只会让这件事变得更常发生。所以真正危险的不是“AI 抢了岗位”而是“你的能力停留在可被模板化描述的那一层”。简历上写“熟悉 Spring Boot、熟悉 MySQL、参与过 XX 系统开发”这种描述在五年前够用现在很难让人记住。反过来如果你能说清楚“我做过一个检索服务 QPS 从 200 提到 1500卡点在哪怎么解决的”哪怕这个服务跟 AI 一点关系都没有面试官也会认真听——因为这种能力迁移到 AI 应用侧几乎是即插即用的。2. 大厂嘴里的“AI 相关岗位”其实分四种完全不同的活2.1 四类岗位的职责边界别一头扎错方向上一节给了一张总表这一节把每类的边界讲细一点因为校招投递最忌讳的就是“看着名字像就投”投进去发现干的活完全不是自己想的那样白白浪费一次机会。模型研究岗的核心产出是“新方法”或者“新能力”。日常工作里读论文的比重很高实验周期长一次训练跑几天很正常失败率也高。这类岗位在校招里通常要求硕士起步很多直接卡博士并且会看你的论文发表情况、有没有在开源项目里提交过实质代码、有没有在公开评测榜单上有名次。如果你本科毕业、没有科研经历硬投这类岗位的性价比很低不如把精力放到后面几类。应用算法岗的核心产出是“业务指标的提升”。它不需要你发明新结构但要求你能判断这个场景该用召回排序的两段式还是直接端到端样本怎么构造负样本怎么采离线指标涨了线上为什么不涨模型上线后效果衰减了是数据漂移还是特征穿越。这类岗位特别看重“踩过坑”——你有没有经历过一次完整的从离线到线上的闭环比你会背多少公式重要得多。AI 工程岗的核心产出是“让模型稳定、便宜、可观测地跑起来”。具体包括推理服务的吞吐优化、显存占用控制、批量请求的调度、模型版本管理、灰度发布、效果监控、失败兜底。这类岗位对工程功底要求扎实对模型的要求是“懂原理、能读懂论文、能改推理代码”不要求你会训基座。对绝大多数有后端或服务端经验的程序员来说这是最短的一条切入路径。AI 产品与数据岗的核心产出是“把模糊需求翻译成可执行的任务并定义什么叫做好了”。写评测集、设计标注规范、做数据清洗、分析 badcase这些活看着不起眼但直接决定模型效果的上限。这类岗位对代码要求不高对逻辑严谨性和沟通能力要求高适合非技术背景或者技术背景但更偏业务的人。2.2 挂 AI 名头却不碰模型的岗位怎么识别这是我最想提醒的一点。校招季里一定会有一些 JD 写着“AI”“大模型”“智能”但你进去之后发现日常工作是管理标注团队、对接外包供应商、把需求文档转成工单。这类岗位不是没有价值但如果你抱着“学技术”的期待进去落差会非常大。识别方法其实很简单看 JD 里动词的密度。真正的技术岗JD 里会密集出现“设计”“实现”“优化”“调优”“排查”这类词并且会点名具体技术栈伪技术岗的 JD 里更多是“跟进”“协调”“整理”“对接”“管理”。另一个更准的办法是看任职要求里有没有硬性技术门槛比如“熟悉 PyTorch”“有分布式训练经验”“熟悉 CUDA 编程”——这些是编不出来的。面试环节还有一招就是反问。我在帮人做模拟面试时通常会让他们在最后问三个问题这个团队最近一次把模型上线到生产环境是什么时候解决了什么业务问题如果我入职前三个月主要负责哪一段工作是数据、训练、推理服务还是评测团队现在最头疼的技术问题是什么如果对方对第一个问题含糊其辞或者回答里全是“我们在探索阶段”那大概率这个团队的 AI 业务还没真正落地你进去可能是做预研甚至做文档。这不是坏事但对校招新人来说第一份工作最好能进一个有真实线上流量的场景你才能看到完整的闭环。提示反问环节不是走过场。问得好面试官会认为你想清楚了问得空反而扣分。上面三个问题里第二个最能筛出岗位真实内容。2.3 按自己的底子选赛道三种典型背景的匹配建议第一种有扎实后端或服务端经验的。这条路最稳直接对准 AI 工程岗。你需要补的是模型推理的基本流程输入怎么预处理、输出怎么后处理、常见推理框架的用法、向量检索的基本原理、以及一点模型评测的知识。工程能力你已经有了这些补起来三到六个月足够而且不需要你把数学重修一遍。第二种算法、数学、统计背景的。走应用算法岗。你缺的通常不是理论是工程落地经验——没写过生产级代码、没做过数据管道、不知道怎么把一个 notebook 变成能跑的服务。补的方向是工程规范代码结构、日志、异常处理、性能分析。第三种非科班或者基础比较薄的小白。我的建议是别一上来就冲算法岗先从前面的 AI 产品/数据岗或者 AI 工程岗里的数据与评测方向切入在工作中把模型的基本概念摸熟再决定要不要往深走。这条路慢一点但不容易半途而废。硬着头皮从零直接冲算法岗成功率我见过的不高因为竞争者里有一堆科班硕士带着实习经历你在简历关就很难过。3. AI 岗校招的真实考察链路从笔试到终面都在问什么3.1 笔试环节算法题仍是硬门槛但出题口味变了先说个反直觉的观察这两年 AI 相关岗位的笔试算法题的难度并没有比普通开发岗低甚至因为投递人数多筛得更狠。中等难度的数组、字符串、动态规划、图遍历依然是主力题型一道题限时三十分钟是常态。所以别信“做 AI 就不用刷题”这种话那是给自己找借口。但出题口味确实有变化。以前偏爱考一些偏技巧的脑筋急转弯式题目现在更偏向“数据处理”类的题给你一批日志统计某个指标给一个二维矩阵做区域聚合实现一个带容量限制的缓存。这类题的特点是即使你一时想不出最优解写出一个正确但慢的版本也能拿部分分而且更能反映你平时写代码的习惯。除了编程题很多笔试还有选择题部分考的概率统计、线性代数、机器学习基础。这部分不难但很杂容易失分。我的建议是考前两周集中过一遍高频考点贝叶斯公式、期望与方差的性质、常见分布、矩阵求导的基本结论、过拟合与正则化、偏差方差权衡、常见损失函数的适用场景。不用深挖证明但要能算、能解释。3.2 技术面八股之外面试官在确认哪三件事面过几轮之后你会发现面试官问的问题看似发散其实在确认三件很具体的事。第一件你的基础是不是真的扎实而不是背的。典型问法“你说 BN 能加速收敛那推理阶段 BN 怎么处理为什么”这种问题一追问到底背的人就露馅了。类似的还有“为什么交叉熵比 MSE 更适合分类”“Attention 的计算复杂度是多少序列长度翻倍会怎样”“梯度消失你是怎么判断出来的”。准备这类问题的方法不是背答案是找一个小数据集自己动手验证一遍你会记得非常牢。第二件你有没有独立解决过非标准问题。面试官会挑你简历上的项目往死里问这个指标为什么选它基线是什么你改的那一部分贡献了多少有没有做过消融失败的尝试有哪些。这一轮最忌讳的是“我只是负责调包”。哪怕你做的项目很小只要你能说清楚“我试了 A 方案不行因为 X换成 B 之后涨了 Y”你就赢了大部分候选人。第三件你的工程习惯怎么样。会问“你的代码怎么组织的”“实验怎么记录”“怎么保证结果可复现”“线上服务怎么监控”。这类问题在 AI 工程岗里权重很高在算法岗里也越来越被看重因为很多模型效果问题最后都是工程问题。3.3 项目经历怎么写才不像课程作业我改过的简历里最常见的写法是“基于 XX 框架实现了 XX 系统准确率达到 XX%”。这种句子信息量接近于零因为面试官无法判断这个数字是好还是坏也无法判断你做了什么。有效的写法是三段结构问题与基线 → 你的改动与动机 → 量化结果与失败分析。举个例子对比一下。差的写法使用 PyTorch 实现了一个文本分类模型准确率 92%。好的写法针对某公开文本分类数据集N 类、M 条样本搭建基线基线采用词袋线性模型准确率 86.3%分析错误样本发现长尾类别召回低改用预训练语言模型微调并加入类别加权损失长尾类别 F1 从 0.61 提升到 0.74整体准确率 89.1%尝试过数据增强但对该数据集无增益判断是增强方式与文本长度分布不匹配。后者大概多花你两天时间整理但它在面试里的价值是前者的五倍以上。因为它同时展示了你会做基线、你会分析错误、你会归因、你能诚实报告失败。这四件事恰好就是应用算法岗每天在做的事。3.4 场景题与手撕代码的临场节奏场景题的典型形式是给你一个业务描述问你“怎么建模、怎么评估、上线后指标掉了怎么查”。这类题没有标准答案面试官看的是你的拆解顺序。我习惯的答题框架是先确认目标和约束数据有多少、延迟要求多少、有没有标注再定方案召回用什么、排序用什么、冷启动怎么办再定评估离线用什么指标、线上看什么指标、怎么避免 offline-online 不一致最后讲风险数据漂移、特征穿越、badcase 兜底。手撕代码环节很多人栽在“闷头写”。我的建议是把节奏拆成四步先用一句话复述题意确认理解再说思路和复杂度再写伪代码或骨架最后补实现并主动跑一两个边界用例。哪怕你最后没写完这个流程也能让面试官看到你的思维是清楚的。我见过写对了但一句话不说、最后被判定“沟通有问题”的很可惜。4. 给底子薄的人一条能走完的路线90 天从看懂到交得出东西4.1 前 3 周先把地基补到“够用”别急着上模型这半个月的目标不是学完机器学习是让你后面看代码、看论文不至于卡死。具体三件事。一是 Python 的工程用法。不是语法是能写脚本处理数据读写文件、处理 JSON、用 pandas 做分组聚合、用 numpy 做矩阵运算、会用 argparse 传参、会用 logging 打日志。这些技能看起来琐碎但它们决定了你后面跑实验的效率。我见过太多人卡在“数据读不进来”这种问题上耗掉一周。二是数学的最小必要集。矩阵乘法与转置、向量的点积与范数、偏导数与链式法则、期望与方差的定义、交叉熵的表达式。这些不需要你会推导但要能看懂公式在说什么。推荐的检验方式是随便找一篇模型论文的方法部分看你能不能把主要公式用自己的话解释一遍。三是工具链。会用 git 管理代码、会在命令行里跑脚本、知道怎么看报错栈。这三样是硬门槛缺了后面寸步难行。4.2 第 4 到 7 周跑通一条端到端链路哪怕模型很土这四周只干一件事把“数据进来结果出去”这条链路走完一遍。模型可以选最简单的那种线性回归、逻辑回归、甚至一个 KNN 都行重点不是模型多先进是链路完整。具体链路是数据读取 → 清洗与划分训练/验证/测试注意别泄漏→ 特征或文本预处理 → 模型训练 → 评估 → 保存权重 → 加载权重做推理 → 写一个能接收输入返回结果的函数。我把评估这一段单独拎出来给你看因为这是新手最容易糊弄、面试官又最容易考的地方import numpy as np def confusion_matrix(y_true, y_pred, num_classes): cm np.zeros((num_classes, num_classes), dtypeint) for t, p in zip(y_true, y_pred): cm[t][p] 1 return cm def prf_per_class(cm): result {} for c in range(cm.shape[0]): tp cm[c][c] fp cm[:, c].sum() - tp fn cm[c, :].sum() - tp precision tp / (tp fp) if (tp fp) else 0.0 recall tp / (tp fn) if (tp fn) else 0.0 f1 2 * precision * recall / (precision recall) if (precision recall) else 0.0 result[c] {precision: precision, recall: recall, f1: f1} return result这段代码不长但它能撑起面试里的一大串追问为什么类别不均衡时看 macro-F1 而不是准确率混淆矩阵里哪一格对应哪类错误多分类的 micro 和 macro 差在哪。你自己手写一遍比背十遍定义都管用。4.3 第 8 到 11 周做一个带对比实验的小项目这四周是整个路线的核心也是简历上唯一真正值钱的部分。选题原则任务要小、数据要好找、必须有基线可对比、必须能做错误分析。三类比较适合的方向文本分类情感、意图、主题都行、检索问答给定一批文档输入问题返回相关段落、图像分类细粒度分类比手势识别更有说服力因为后者太烂大街。选一个别贪多。实验设计上必须包含四样东西一个简单基线规则、词袋、或最朴素的模型一次明确的改进换模型、改损失、加特征、做增强任选其一一组对比数据改进前后在同一测试集上的指标一份错误分析挑 20 个错例归类给出你的判断错误分析这一块最容易被跳过但它恰恰是面试时最能加分的地方。你做完了会发现很多你以为的“模型不行”其实是标注噪声、是数据分布问题、是你的预处理把关键信息吃掉了。这些发现写进简历含金量远高于一个漂亮但来路不明的数字。4.4 最后两周包装、投递与复盘简历改法前面讲过这里补两点实操。一是关键词密度要对齐 JDJD 里写了“向量检索”“RAG”“推理优化”你的项目里如果涉及就用同样的词描述如果没有涉及宁可空着也别硬塞面试一追就穿帮。二是每个项目下面留一行“技术栈”把用到的框架、库、工具列清楚方便筛选。投递节奏上别一次性全投完。先投几家你不太在意的练手面完复盘把被问住的问题记下来补掉再投心仪的。校招的时间窗口不短但很多人的问题是一上来就把最想去的投了然后在最关键的面试里暴露准备不足。4.5 学习资源的选型逻辑与常见的浪费这块我踩过坑说点直接的。第一别囤课。买十门课看一门不如选一门跟到底。判断标准很简单这门课有没有配套代码和作业有没有让你自己跑起来的部分。纯讲理论的课对找工作帮助有限。第二优先看官方文档和论文的方法部分。很多二手教程会省略关键的实现细节你照着抄跑不通然后卡三天。官方文档里的 quickstart 通常是最靠谱的。第三看开源复现仓库时重点看 issue 区。别人踩过的坑十有八九你也会踩issue 里往往有现成的解法比你自己debug快得多。第四警惕“只会调 API”的学习路径。调用一个现成接口跑出结果很快但面试官一问“这个参数改了会怎样”“换个场景还行不行”就答不上来。至少要有一两个地方你是自己写过训练循环、自己算过损失、自己调过超参的。5. 这几年带人看简历、陪练面试踩得最多的五个坑5.1 坑一把“学完了”当成“会做了”最常见的自我误判。教程看完了代码跑通了就以为掌握了。实际上你只是复现了别人的路径中间任何一个环节出问题你都解决不了。检验标准很粗暴关掉教程从空文件开始能不能把这条链路重新写出来能不能换一个数据集还跑得通。做不到就是没会。5.2 坑二项目全是调包说不清一行代码为什么这么写面试官问“你这个学习率为什么设 2e-5”回答“教程上是这么写的”这一句基本就判了。你不需要每个参数都有充分理由但至少要有两三个是你自己试出来的并且能说出试的过程我先用 1e-4loss 震荡降到 2e-5 之后稳定了。这种回答的价值在于它证明你真的动过手。5.3 坑三简历堆名词关键词和经历对不上简历上写“熟悉大模型微调、RAG、Agent”项目里只有一个文本分类。面试官一眼就能看出这是凑关键词。更糟的是他会顺着这些词问而你一个都答不深。我的建议是简历上的每个技术名词都要能在项目描述里找到对应的落点找不到就删掉。5.4 坑四只盯算法岗忽略了工程侧的巨大缺口前面反复说过岗位池里最大的一块是 AI 工程。但很多人因为“算法”两个字听起来更硬核拼命往那条路上挤挤不进去就放弃。其实换个角度看能在推理服务上把延迟砍掉一半、能把训练成本降下来、能把评测流水线搭起来的人稀缺程度一点不比算法岗低而且竞争者少得多。5.5 坑五把转型当成一次性赌博最后说个心态上的。很多人给自己的设定是“三个月转不成就彻底放弃”这个设定本身就容易失败因为三个月只够你跑通链路远不够形成竞争力。更现实的做法是把它当成一个持续叠加的过程先在现有岗位上找能用到模型的地方把手弄脏攒真实场景的经验再考虑换岗。这条路慢但每一步都是实的。我个人在实际操作中的体会是这一轮变化里真正的分水岭不在于你会不会训模型而在于你能不能在“模型”和“业务系统”之间那段又脏又乱的灰色地带里把事情做成。那段地带没有教程全是日志、超时、脏数据、指标抖动和说不清的 badcase但它恰恰是最缺人的地方。如果你能沉下心在那里面待上一年你手上的东西会比任何一份课程证书都硬。
