这两年在招聘平台翻职位你会很明显感觉到一件事同样是写代码只要岗位描述里出现“大模型”“RAG”“模型部署”“微调”这些词薪资就能比传统开发岗高出一大截。尤其是一些直接挂着“大模型应用工程师”“AI 应用开发”的岗位月薪 30K 往上走已经不是新闻。我身边就有原本做后端的朋友转过来做大模型应用交付不到一年薪资涨了接近一倍。这个行情确实很热但热归热作为过来人我得先泼一盆冷水很多 30K 的岗位要的不是“会聊天式地调用一下大模型”而是能真正把它接进业务、控制成本、解决幻觉、稳定上线的能力。这篇我会把背后的人才需求、真实工作内容、转岗路线和面试考察逻辑一次性说清楚打算吃这碗饭的同学可以当成一份实操参考来看。1. 这一波AI岗热度需求从哪来的能持续多久1.1 企业从“尝鲜”转向“卖铲”前两年多数公司接触大模型还停留在“哪个模型写文案更强”“用 AI 生成一张图发朋友圈”这种尝鲜阶段。现在已经完全不一样了——不少业务方开口就是“我要把知识库问答做出来”“客服机器人要能看懂退换货规则”“合同审批能不能自动提取关键条款”。这些需求本质上是同一个词落地。落地意味着什么意味着企业不再满足于“模型很厉害”的演示效果而是要求模型在真实业务数据上稳定输出。为了做到这一点就需要有人去处理文档切分、向量检索的召回率、提示词模板的设计、模型输出格式的约束、接口并发和成本控制甚至还要定期跑评测集验证效果有没有回退。这些活儿恰恰是传统软件开发和算法岗之间的一片空白地带。所以这轮招聘热不是凭空来的——是业务需求倒逼出的岗位分化。以前一个团队把数据工程师、后端工程师、算法工程师凑一起就能慢慢磨一个 AI 功能现在老板等不了三个月他要的是尽快能用、尽量省心于是专门负责“把大模型用起来”的岗位自然就值钱了。1.2 供需缺口高薪不是噱头是还没抢到人我帮公司招过几轮 AI 应用方向的岗位最直观的感受是简历多但真正能直接上手的人非常少。很多人写“熟悉大模型”细问之下只是用过网页版对话工具写“了解 RAG”但连检索用的向量索引和普通数据库索引的区别都说不清楚写“做过模型微调”实际上只跑通了一个开源示例没有处理过真实数据。需求端不是只有那些大厂——现在很多做企业服务、电商、教育、法律、医疗信息化的中小公司都在招能用大模型改造现有产品的人。这类公司往往给不出算法研究岗那种动辄几十上百人的团队它们更需要一个能独立扛起技术选型、原型开发、上线调优的人。供需一错位薪资就被抬上去了。当然“能持续多久”这个问题得冷静看。我认为只要大模型在真实业务里的降本增效价值还在被验证相关岗位就会持续有需求但市场的耐心也在缩短前两年会说“你懂概念就行进来再学”现在大多数面试官会直接让你讲项目、讲评测数据、讲上线遇到的坑。风口还在只是筛选变严了。2. 月薪30K的招聘背后三类AI人才的真实工作内容2.1 岗位拆解应用开发、提示工程、模型调优我观察了大量招聘信息也面试过不少人现阶段所谓“AI岗”其实可以拆成三个方向分别对应不同的技能侧重点。为了防止大家被岗位名称绕晕我干脆放到一张表里对比岗位方向核心任务常用技术栈典型踩坑点大模型应用开发把模型接进业务系统做 RAG、Agent 编排、接口设计与部署Python、向量数据库、API 调用、FastAPI 之类的服务框架只会在本地跑 Demo一上线就扛不住并发和上下文成本提示词/评测工程设计高质量提示模板搭评测集分析模型输出的偏差与回归数据分析、Prompt 设计、测试集管理、小样本标注凭感觉调 Prompt没有量化指标效果好坏全靠“看起来像”模型微调/部署工程师用业务数据对开源模型做 SFT 或适配做量化与服务化部署PyTorch、训练脚本、量化工具、推理优化训练完模型效果没提升反而把已有能力弄丢缺乏对比验证这三个方向里需求最大、入门门槛相对友好的是第一个大模型应用开发。大多数公司要的是“把模型用起来”而不是“从零搓一个模型”。所以别一听 AI 岗就觉得自己得是大牛先找准自己的切入点更重要。2.2 一天的工作流与那些没人告诉你的细节如果把“大模型应用工程师”的日常拉出来看你会发现它跟很多人想象中的“搞 AI”差别很大。早上 11 点前通常在做数据侧的事。比如一份新的产品文档要接进知识库你得清洗格式、按标题层级切块、决定块大小和重叠度然后灌进向量库。这些活儿听起来简单但切大了检索不精准切小了上下文碎片化都要反复试验。下午的黄金时间用来调检索和提示词。用户问“第二年的订阅能退款吗”系统明明有对应条款却答不上来你要查是向量检索没召回还是排序权重不对或者是模型没理解问题。每一次改动都要在几十条评测问题上跑一遍用数据决定改不改。临近下班反而在写工程代码把调好的链路封装成接口做鉴权、限流、日志和异常兜底。模型偶尔会给出格式不对的输出你要用正则或二次校验把结果拉回正轨。应该说这岗位 70% 的时间在跟数据处理、服务化、评测较劲真正“请模型思考”的环节只占一小部分。想清楚这一点再决定要不要上车会比单纯冲着钱来靠谱得多。3. 挤进这个赛道我给普通研发者的技术路线与项目清单3.1 反直觉的学习顺序先会用再懂原理很多想转岗的同学第一反应是去买一本深度学习教材从反向传播开始啃。我不反对补理论基础但实话实说以应用岗的面试要求来看这个顺序太低效了。因为大多数业务场景里模型本身就是现成的你真正要解决的是“怎么把数据喂进去、怎么把结果接出来、怎么保证效果稳定”。我的建议是倒着学先把大模型的 API 用熟了解上下文窗口、温度、系统提示词这些概念然后做一次完整的 RAG 项目把文档加载、切分、向量化、检索、生成、退回纠偏这一条链路跑通再回头补 Transformer 基础、注意力机制、嵌入向量这些原理你会发现原来不懂的抽象概念一下子都对应上了。这里有个很重要的“为什么”面试官问原理不是要你背定义而是想确认你在碰到问题时有没有判断力。比如你知道模型是基于 Token 概率做生成的就不会奇怪“为什么同样的提示词两次答案不一样”你理解嵌入向量的空间分布才会想到在召回去重时计算向量距离。所以原理要补但一定是配合实践去补。3.2 一个可复现的“RAG问答机器人”项目模板为了让你有抓手我给一个最小但完整的项目骨架这也是我在多个实际项目中用过的思路# 一个用于演示的本地RAG检索-生成骨架 from embeddings_provider import get_embedding from vector_store import VectorStore def build_knowledge_base(text_chunks): store VectorStore() for chunk in text_chunks: vector get_embedding(chunk) store.add(vector, chunk) return store def answer_question(question, store): q_vector get_embedding(question) top_chunks store.search(q_vector, k4) context \n.join(top_chunks) prompt f请基于以下资料回答问题 如果资料中没有相关信息请直接说“当前资料无法回答”不要编造。 资料 {context} 问题{question} result llm_chat(prompt, temperature0.2) return result你别小看这段骨架实际项目里 80% 的代码量都是围绕这 20% 的核心逻辑展开的。真正要下功夫的是下面这些细节文本切分我一般会用三层策略——先按标题分大块再按段落分中块最后按句子边界补块。纯粹的固定长度硬切会把语义切断召回效果会很差。检索策略不只是“向量相似度最高”就能用先做召回再做重排把关键词匹配和向量匹配的结果合并效果会有明显提升。答案验证生成完答案以后可以要求模型返回引用的资料片段编号找不到编号就不出答案。这一招能有效压低幻觉率。做完这一步你手里就有了一个能讲清楚的项目假设你在做一个内部知识库问答系统你可以说清数据怎么清洗、分块参数怎么调、检索召回率怎么评测、模型幻觉怎么兜底。这套经验比把一个大模型“从 0 训练到 70 亿参数”的 Demo 值钱得多。3.3 作品集不用多但要有评测数据我筛简历时最怕两种一种是什么都写了但没一个能展开深聊另一种只有一个看起来很唬人的大项目但问两句就穿帮。相比“我做过什么”我更想知道“你如何证明你做得好”。所以做项目时一定要顺手把评测集建起来。比如你做了一个客服问答机器人别只贴一个“答对了”的界面截图。你可以在项目里准备 50 条真实场景测试题分成“常见问题”“长尾问题”“无答案问题”三类然后把准确率、无答案拒答率、平均响应耗时列成一张表。面试时直接拿出这张表比任何修饰都有说服力。我见过一个候选人项目技术含量不一定是最高的但就是因为把评测指标、失败案例和迭代记录写得清清楚楚反而在几轮技术面里稳住了。4. 面试环节的真实考察逻辑三个高频问题背后的判断标准4.1 问题一RAG检索质量差怎么排查这个问题在应用岗面试里几乎必问因为 RAG 是大模型落地的绝对主力。面试官其实不是要你背一个标准答案而是想观察你的排查思路是否成体系。我会这么拆解先分内因和外因。内因看文档处理格式是否清洗干净、切分是否破坏了语义、是否有重复或噪音数据外因看检索链路嵌入模型是否适合当前领域、TopK 是否设置得太小或太大、是否缺少重排环节。接着看问题本身的表述用户问题里如果包含“去年”“合同里”这类指代直接拿原始问题去检索大概率不准需要先做改写或扩展。最后看生成侧模型有没有正确使用上下文提示词里是否强调“不知道就回答不知道”。能按“数据-检索-生成-提示词”四个层面依次给排查方向的人基本就是实战过的只记得“调大 K 值”这一招的多半没真正处理过脏数据。4.2 问题二模型输出不稳定怎么量化我说过凭感觉调提示词是大忌。面试官问这个问题实际上在考你有没有“评估闭环”意识。我的推荐做法是准备三种指标格式正确率输出能否被程序稳定解析、内容准确率答案与标准答案的语义一致性、拒绝率无答案时有没有正确拒答而不是硬编。以格式为例。如果业务要求模型输出 JSON你就在评测时统计“可解析 JSON 比例”。假设上线前跑 100 条正确率是 85%你通过加约束提示、输出后纠正等手段提到 97%这就是一个可量化的成果。面试时你不用空谈“模型效果很好”直接报数字再说明你用什么方案让数字变化的说服力完全不同。4.3 问题三成本与效果冲突时怎么取舍这题越来越常见因为企业是真金白银在付 API 费用或算力成本。面试官想看你有没有成本意识。我会分三层回答第一层能不能少调用。很多流程不需要每次都问大模型规则优先、小模型优先、缓存优先。第二层能不能用小模型。上下文短、任务单一的场景完全可以用参数量小得多的模型只有复杂推理、长文本改写才需要上大模型。第三层能不能控 Token。压缩系统提示词、精简检索返回的文档片段、拆复杂问题为多个子任务按需调用都能直接降本。说到底30K 的岗位不是招一个“只会把 demo 跑起来亮给老板看”的人而是招能对业务结果负责的人。面试官看中的不是你会背多少模型名称而是你的每个决策是否都建立在成本和效果的平衡之上。5. 准备期最容易踩的认知坑关于风口、课程和外包5.1 “学几个提示词模板就能高薪”的幻觉这波热度起来以后市面上冒出了大量“AI 应用开发速成班”宣传语都很诱人零基础、学完月薪过万、手把手带你做项目。我不否认培训有信息整理价值但你要分清“被喂知识”和“具备解决问题能力”是两回事。真正面试时面试官会往细节里追问你做过的项目是不是真实数据、有没有考虑并发、模型答错了怎么兜底这些没法靠背模板混过去。我的观点很直接如果不是科班出身就把重点放在项目实战和工程能力上。与其花大钱去买“包就业”承诺不如自己拿一个真实的业务主题从数据采集、清洗到 RAG 搭建、评测、部署完整走一遍这个过程的成长效率远高于任何课程。5.2 被“高端”反噬重演示轻上线还有一种很容易踩的坑是把精力全花在“看起来很高级”的演示效果上。比如给老板展示“模型自动生成周报”“一张图生成网页”屏幕前一亮掌声一片但真正上线时发现数据接口不稳定、生成结果频繁出错、业务方无法对输出负责最后项目烂尾。做 AI 应用和做传统软件一样稳定压倒一切。我自己的经验是宁可功能做得窄一点也要把“能用、稳定、可回退”做好。先在一个非常明确的场景里跑通闭环再慢慢扩展。这种克制反而更容易让业务方买单。5.3 数据合规和隐私我的一条红线最后提一个容易被忽视但极其重要的问题——数据安全。做 AI 应用经常会接触客户资料、内部文档、合同信息如果你图省事直接把这些数据传到外部模型的接口或者拿未脱敏的真实数据做演示风险非常大。这不仅是职业操守问题也是技术方案设计时必须考虑的一环。我在做技术方案时一般会先和业务方确认哪些数据可以出域、哪些必须本地处理、是否需要脱敏或鉴权然后将这些约束写进设计里。哪怕是做个人作品集项目也尽量用公开数据集或自己造的数据不仅安全还能避免“因为用了某个客户的真实信息反而不敢公开聊项目”的尴尬。这条红线越早守住越好。说到底大模型岗的高薪确实让人心动但它对应的不是“会喊风口”的人而是“能扛事”的人。我的建议是别急着冲进去先拿一个项目把手弄脏把调研、搭建、评测、迭代、上线、维护这一整条链路走一遍。等你真的经历过“线上问答答错了客户来投诉”这种时刻你就知道这碗饭能不能端稳了。