校招季一开，私信里十条有八条在问同一件事：听说某头部电商大厂这一届校招放出来的岗位里，AI 相关的占了绝大多数，是不是真的，普通程序员还有没有活路。这个数字的具体统计口径我没法逐条核实，不同事业部的口径差得很远，但要问“岗位结构正在往 AI 侧大幅倾斜”这件事本身，只要你打开几家大厂的校招页面翻一遍 JD，半小时就能自己得出结论——AI 相关的岗位描述确实铺满了整屏。对还在读书或者工作一两年、底子不算厚的人来说，真正值得焦虑的不是那个百分比，而是你有没有搞清楚：这些挂着 AI 名头的岗位，究竟在招什么样的人，要干什么活，需要什么能力。这篇就把这件事掰开揉碎讲清楚，从岗位分类、考察链路，到一份能走完的九十天切入路线，尽量让不同基础的人都能找到自己的位置。

1. 一条岗位结构的消息，为什么让普通程序员集体焦虑

1.1 先把这条消息拆开看：数字背后是四种完全不同的活

大部分人看到“AI 岗位占大头”，脑子里浮现的画面是：一群人坐在工位上推导损失函数、调 Transformer 的超参、跑几百张卡训模型。这个画面不能说错，但它描述的是整个 AI 岗位池里最顶端、占比最小的一小块。真实情况是，一个岗位被归到“AI 相关”，可能意味着完全不同的四类工作，而它们的门槛相差三到五倍。

我把这些年见过的、以及帮人改简历时反复对照过的岗位类型整理成一张表，你可以直接拿去和校招页面上的 JD 对号入座：

看清楚这张表，焦虑会降一半。因为绝大多数校招放出来的“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), dtype=int) 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 最后两周：包装、投递与复盘

简历改法前面讲过，这里补两点实操。一是关键词密度要对齐 JD，JD 里写了“向量检索”“RAG”“推理优化”，你的项目里如果涉及，就用同样的词描述；如果没有涉及，宁可空着也别硬塞，面试一追就穿帮。二是每个项目下面留一行“技术栈”，把用到的框架、库、工具列清楚，方便筛选。

投递节奏上，别一次性全投完。先投几家你不太在意的练手，面完复盘，把被问住的问题记下来补掉，再投心仪的。校招的时间窗口不短，但很多人的问题是一上来就把最想去的投了，然后在最关键的面试里暴露准备不足。

4.5 学习资源的选型逻辑与常见的浪费

这块我踩过坑，说点直接的。第一，别囤课。买十门课看一门，不如选一门跟到底。判断标准很简单：这门课有没有配套代码和作业，有没有让你自己跑起来的部分。纯讲理论的课，对找工作帮助有限。

第二，优先看官方文档和论文的方法部分。很多二手教程会省略关键的实现细节，你照着抄跑不通，然后卡三天。官方文档里的 quickstart 通常是最靠谱的。

第三，看开源复现仓库时，重点看 issue 区。别人踩过的坑十有八九你也会踩，issue 里往往有现成的解法，比你自己debug快得多。

第四，警惕“只会调 API”的学习路径。调用一个现成接口跑出结果很快，但面试官一问“这个参数改了会怎样”“换个场景还行不行”就答不上来。至少要有一两个地方，你是自己写过训练循环、自己算过损失、自己调过超参的。

5. 这几年带人看简历、陪练面试，踩得最多的五个坑

5.1 坑一：把“学完了”当成“会做了”

最常见的自我误判。教程看完了，代码跑通了，就以为掌握了。实际上你只是复现了别人的路径，中间任何一个环节出问题你都解决不了。检验标准很粗暴：关掉教程，从空文件开始，能不能把这条链路重新写出来，能不能换一个数据集还跑得通。做不到，就是没会。

5.2 坑二：项目全是调包，说不清一行代码为什么这么写

面试官问“你这个学习率为什么设 2e-5”，回答“教程上是这么写的”，这一句基本就判了。你不需要每个参数都有充分理由，但至少要有两三个是你自己试出来的，并且能说出试的过程：我先用 1e-4，loss 震荡，降到 2e-5 之后稳定了。这种回答的价值在于它证明你真的动过手。

5.3 坑三：简历堆名词，关键词和经历对不上

简历上写“熟悉大模型微调、RAG、Agent”，项目里只有一个文本分类。面试官一眼就能看出这是凑关键词。更糟的是，他会顺着这些词问，而你一个都答不深。我的建议是简历上的每个技术名词，都要能在项目描述里找到对应的落点，找不到就删掉。

5.4 坑四：只盯算法岗，忽略了工程侧的巨大缺口

前面反复说过，岗位池里最大的一块是 AI 工程。但很多人因为“算法”两个字听起来更硬核，拼命往那条路上挤，挤不进去就放弃。其实换个角度看，能在推理服务上把延迟砍掉一半、能把训练成本降下来、能把评测流水线搭起来的人，稀缺程度一点不比算法岗低，而且竞争者少得多。

5.5 坑五：把转型当成一次性赌博

最后说个心态上的。很多人给自己的设定是“三个月转不成就彻底放弃”，这个设定本身就容易失败，因为三个月只够你跑通链路，远不够形成竞争力。更现实的做法是把它当成一个持续叠加的过程：先在现有岗位上找能用到模型的地方，把手弄脏，攒真实场景的经验，再考虑换岗。这条路慢，但每一步都是实的。

我个人在实际操作中的体会是，这一轮变化里真正的分水岭，不在于你会不会训模型，而在于你能不能在“模型”和“业务系统”之间那段又脏又乱的灰色地带里把事情做成。那段地带没有教程，全是日志、超时、脏数据、指标抖动和说不清的 badcase，但它恰恰是最缺人的地方。如果你能沉下心在那里面待上一年，你手上的东西会比任何一份课程证书都硬。