企业官网建设流程全解析

最近这半年，我被问得最多的问题不是“大模型怎么学”，而是“现在转哪个方向能拿到高薪”。大模型风口从 ChatGPT 出现开始吹到现在，已经不只是算法圈内部的话题，连做后端的、做运维的、甚至做产品的朋友都在问同一个事：这个风口到底会带火哪些岗位，哪些方向值得押注。

我自己的判断是，这一轮机会确实存在，但它和上一轮 AI 热有本质区别。2017 到 2021 年那会儿，AI 岗位的核心是“造模型”，做 CV、做 NLP、发论文、刷榜单，岗位集中在大厂研究院和头部实验室，门槛是名校学历加顶会论文。现在的大模型时代，基座模型已经被几家头部公司卷得差不多了，真正的增量在“怎么把模型用起来”“怎么把模型训得更便宜”“怎么做模型之上的产品和应用”。岗位结构从“极少数人搞研究”变成了“一大批人搞工程”。

这篇文章不聊虚的，直接拆解四个我认为最有代表性的方向，讲清楚每个方向到底做什么、需要什么能力、薪资大概在什么区间，以及最容易踩的坑。

1. 风口背后的结构性变化：为什么这次和上一轮AI热不一样

1.1 从“技术找场景”到“场景找技术”

上一轮 AI 热的时候，很多团队的做法是先训练一个模型，再去找业务场景。比如做一个中文情感分类模型，然后问运营部门“你们需不需要”；做一个图像识别模型，再问安防部门“这个能不能用”。这种模式天然存在问题：模型和业务之间隔着一层，很多时候模型训完了，场景还没找到，项目就烂尾了。

大模型时代完全反过来了。现在的情况是业务方拿着明确的需求来找技术团队，比如“我们的客服知识库要接入大模型”“合同审核要自动提取关键信息”“PDF 报表要能直接问答”。模型本身是现成的，要么用开源基座模型，要么调用 API，真正考验人的是你能不能把模型塞进业务流程里，让它稳定、准确、可控地工作。这意味着行业需要的不再是“能训模型的研究员”，而是“能把模型落地的工程师”。

这个结构性变化直接影响了岗位需求。我在这两年内看到的招聘需求里，纯算法研究岗的增量非常有限，甚至在部分公司还在缩减，因为训练基座模型的成本太高，大多数公司根本玩不起。但应用开发、推理优化、数据工程、评测调优这几类岗位的缺口非常大，而且这个缺口还在扩大。

1.2 人才供给的错配才是高薪的真正原因

为什么大模型岗位依然能开出高薪？说白了就是供给跟不上。市面上大量候选人的简历写的是“熟悉 Python”“了解 Transformer”“用过 LangChain”，但真正能独立完成一个端到端项目的人很少。

我见过太多简历写着“精通大模型微调”的候选人，聊下来连 LoRA 和全量微调的本质区别都说不清楚，更别提怎么设计 SFT 数据。也见过号称“熟悉 RAG”的候选人，问他召回率低的时候先调什么，支支吾吾答不上来。这就是典型的供需错配——岗位要的是能解决实际问题的人，市场上大量的人却还停留在“听说过概念”的阶段。这种错配，就是高薪存在的原因，也是真正愿意深入底层的人的机会。

2. 方向一：大模型算法工程师——训练与对齐，门槛最高但不是唯一解

2.1 这个方向到底在做什么

大模型算法工程师是听起来最“正统”的方向，也是很多人一听到大模型就会想到的岗位。它内部其实可以拆成几个子方向。

预训练方向，就是从头训练基座模型。这个方向目前基本被头部大厂和少量创业公司垄断，因为一次千亿参数的训练成本动辄几百万甚至上千万，数据、算力、工程能力缺一不可。预训练工程师日常做的事情包括：清洗和处理海量训练数据、设计 tokenizer、调整学习率与 batch size 的组合、处理训练过程中的 loss 突刺、做模型并行策略的配置等。这个岗位博士居多，而且要真正烧过钱、踩过训练崩溃的坑才有竞争力。

后训练与对齐方向是目前更现实的选择。大部分公司不会从头训练模型，但会基于开源模型做 SFT（监督微调）、DPO（直接偏好优化）甚至 RLHF（基于人类反馈的强化学习）。这个方向的日常工作重心是数据——SFT 数据怎么构造、偏好数据怎么收集、回答怎么打分，这些环节直接决定微调后的模型好不好用。这里有个很多新人容易忽略的点：微调的代码本身并不难，难的是数据质量的控制。

评测方向是一个被低估但需求量很大的细分。模型做出来了，到底行不行，需要一套科学的评测体系。不是简单跑几个 benchmark 就算完事，而是要针对业务场景设计评测集、定义指标、做 bad case 分析、推动模型的迭代优化。这个方向不那么“性感”，但对业务的价值非常大。

2.2 需要的能力栈与常见误区

如果你想往这个方向走，有几项能力是绕不开的：

• Python 和 PyTorch 是基本功，这是所有工作的前提。
• 分布式训练知识，至少要理解数据并行、张量并行、流水线并行和 ZeRO 优化之间的关系和适用场景。
• 微调实操经验，跑过 LoRA、QLoRA、全量微调，能说清楚不同方法的显存占用和效果差异。
• 数据处理能力，会写清洗脚本、会做数据增强、能梳理出一条数据生产流水线。
• 英文文献阅读能力，因为最新的对齐技术和训练技巧几乎都是英文资料。

这里我要专门说一个常见误区：很多人以为大模型算法工程师就是“调包侠”，只要有显卡就能跑微调。实际上，微调跑通只是第一步，难的是跑通之后的效果提升。我见过不少团队，模型微调完一测，效果比基座模型还差，然后开始怀疑是不是参数不对，其实大概率是训练数据出了问题——指令和回答的配对关系混乱、数据里混入了重复样本、回答风格不一致，这些都是新手最容易踩的坑。

这个方向的薪资区间，应届硕士如果能独立做微调和评测，年薪大约在 40 到 70 万之间，有实际训练经验的博士或资深工程师会更高。但它的门槛也在这里——学历和实操经历卡得比较严，不适合半路出家的人作为第一选择。

3. 方向二：大模型应用开发工程师——RAG与Agent，需求最旺的入口

3.1 RAG 应用开发的完整链路与难点

如果说哪个方向最值得普通人切入，我的答案是大模型应用开发。这个方向的核心工作是把大模型接到真实的业务场景里，解决“模型怎么用起来”的问题。其中最关键的两个技术栈，一个是 RAG（检索增强生成），一个是 Agent（智能体）。

RAG 的基本思路很朴素：模型不知道的知识，你就把资料检索出来喂给它。企业知识库问答就是最典型的场景，把公司文档、产品手册、客服话术做成可检索的索引，用户提问时先召回相关内容，再让模型基于这些内容生成回答。

但 RAG 落地远没有听起来那么简单，完整的链路至少包括五个环节：

• 数据解析：PDF、Word、PPT、扫描件，不同格式有完全不同的问题。扫描件要 OCR，PDF 有复杂的表格结构，PPT 的页面信息需要重新组织。我见过不少项目，前面模型选得多好，最后效果却差，问题就出在解析环节——内容提取得七零八落，后面的检索再强也没用。
• 文本切分：怎么把长文档切成合适的 chunk，chunk 太大召回不精准，太小又丢失上下文。需要根据文档结构动态调整策略。
• 向量化与召回：选 embedding 模型、搭向量库，这里有个很容易忽略的点——混合检索往往比纯向量检索效果好。纯向量召回在语义上强，但对精确关键词（比如设备型号、订单编号）效果差，加上 BM25 关键词检索做融合，才能兼顾两者。
• 重排：第一轮召回可能返回 50 条结果，真正有用的可能只有 3 条。用一个重排模型把最相关的结果排到最前面，能显著提升最终回答质量。
• 生成与引用：把召回内容拼进 prompt，还要让模型回答时标注引用来源，方便用户溯源。工业级 RAG 系统对引用的要求很高，答错了要能定位到是哪份文档造成的。

整个 RAG 链路，每个环节都有优化空间，也都是日常工作中真正需要花时间打磨的地方。很多简历上写“熟悉 RAG”的人，实际上只是调过 LangChain 的三行代码，连重排都没做过——这就是普通应用工程师和资深应用工程师的差距。

3.2 Agent 应用与工具调用的工程实现

Agent 是大模型应用开发的另一个核心方向。它的本质是从“模型回答问题”升级到“模型完成任务”。

一个典型的 Agent 系统包含规划、工具调用、记忆和反思四个模块。规划是让模型把复杂任务拆解成多个步骤；工具调用是让模型根据需求选择并调用外部 API；记忆分为短期记忆和长期记忆，用来保存对话上下文和历史知识；反思机制让模型在执行完一个步骤后检查结果是否正确，错了就调整策略。

实际开发中，Agent 比 RAG 更难落地，因为它的不可控因素更多。模型可能编造不存在的工具参数，可能在多步任务中突然偏离方向，可能在一个死循环里反复尝试同一个错误操作。解决这些问题需要在架构层面做约束——用固定的工作流卡住关键节点，在工具调用处做严格的参数校验，在 Agent 的每个决策点加日志和追踪，方便调试和回溯。

3.3 为什么说这是最适合转行者的方向

这个方向对背景的要求相对宽松，因为它更看重工程实现能力，而不是研究功底。会写 Python、能理解 HTTP 接口、懂基本的数据库操作，再花时间把一个 RAG 项目从数据解析做到重排生成完整跑通，基本就具备了敲门砖。

薪资方面，大模型应用开发工程师在一线城市的普遍区间是 25k 到 50k 每月，资深专家或带团队的人会更高。需求量大、入门路径相对清晰、技术迭代快但底层原理稳定，这三个特点使它成为这波风口里“性价比”最高的选择。

我给想转行的朋友一个建议：不要用 LangChain 这类框架作为学习的起点。先自己动手写一个裸的 RAG 流程，自己调 API、自己做切分、自己实现召回逻辑，搞清楚每一步在做什么，然后再去用框架。框架帮你省掉的是时间，不是理解。直接上手框架的人，很容易在出了问题的时候一头雾水——不知道是框架的 bug，还是自己配置的问题。

4. 方向三：AI Infra工程师——训练推理优化，薪资天花板所在

4.1 为什么最缺的是懂系统的人

如果说应用开发解决的是“怎么用”，AI Infra 解决的是“怎么用得高效”。这个方向是目前大模型行业人才缺口最严重、薪资天花板最高的领域之一，因为它同时要求懂算法、懂系统、懂硬件。

举一个很直观的例子：同一张 H 系列显卡，有的人部署一个 70B 模型只能跑到每秒生成几十个 token，速度慢到没法用；有的人能通过各种手段把速度提升好几倍，同时把显存占用压到更低。这里的差距不是模型本身，而是对推理引擎、算子实现和显存管理的理解深度。

大模型时代最缺的恰恰是这样的人。GPU 是稀缺资源，公司买卡花的是真金白银，工程效率直接转化为成本优势。能把训练效率提升 20%，或者在同样显存下塞进更大的模型，这个价值是立竿见影的。

4.2 核心工作内容与关键技术点

AI Infra 的工作大致可以分为训练设施、推理引擎和模型服务三个板块。

训练设施层面的工作是搭建和优化集群训练环境，包括 GPU 资源调度、分布式训练框架的配置和调优、断点续训机制、checkpoint 的管理和存储。训练千亿模型的时候，一次训练跑几周，中途哪怕机器故障一次，如果没有完善的断点续训机制，损失都是以天计算的。

推理优化是当前最热门也最缺人的赛道。关键技术包括 KV Cache 管理、PagedAttention 显存优化、连续批处理（Continuous Batching）、量化（INT8、FP8、INT4）、投机采样等。每一项技术都能大幅提升推理吞吐或降低延迟。vLLM、TensorRT-LLM、SGLang 这些开源推理框架是绕不开的工具，但会用框架只是基础，能深入源码层面理解性能瓶颈才是核心竞争力。

模型服务层面的工作是支撑模型的线上部署，包括多模型的路由分发、流式输出处理、高并发请求的吞吐优化、GPU 资源池的弹性伸缩等。这里考验的是传统后端高并发架构能力，恰好是很多资深后端工程师的优势所在。

4.3 这个方向的薪资参考与转型路径

AI Infra 的薪资通常比同级别的算法岗和应用岗都要高。在我了解的范围内，一线城市有经验的推理优化工程师年薪普遍在 60 万以上，资深一点的超过百万也不少见，而且因为供给极度稀缺，议价空间往往很大。

这个方向适合两类人转型：一是原本做后端开发、对高并发和系统底层有深刻理解的工程师，补上模型推理和 GPU 知识后非常有竞争力；二是原本做算法但接触过训练框架、对分布式系统感兴趣的人，往工程方向深入。

这里要特别提醒一个坑：很多人以为自己会部署模型就等于会 AI Infra。部署只是最低门槛，一个模型的 API 服务跑起来是很容易的，理解为什么性能差、用什么手段优化、优化到什么程度，这才是核心价值所在。面试时被问到“你的服务 QPS 是多少，显存占用多少，瓶颈在哪里”，答不上来就露馅了。

5. 方向四：多模态与AI产品化——含数据工程与AI产品经理的增量空间

5.1 多模态算法：从文本到图像、视频、语音

大模型的发展方向不只有文本。多模态大模型能同时理解文字、图像、音频和视频，这是当前非常确定的趋势。GPT-4V 级别的能力已经在向图像理解延伸，视频理解和生成也在快速演进。

多模态算法工程师的工作内容包括：视觉编码器与语言模型的融合、图文数据的对齐训练、视频帧序列的高效处理、音频与文本的跨模态转换等。这个方向对算法功底的要求比较高，需要同时理解视觉模型和语言模型，但正因为门槛高，竞争反而比纯文本方向缓和一些。有 CV 背景的朋友往这里转，比直接转纯 NLP 更顺畅。

除了算法本身，多模态数据的构建也是一门学问——图文对数据的清洗、视频片段的有效标注、跨模态训练数据的配比，这些直接决定多模态模型的效果上限。数据在这里不是边角料，而是核心竞争力之一。

5.2 数据工程：被严重低估的高性价比方向

单独说一下数据工程，因为它是这波大模型浪潮里性价比最高的方向之一。

大模型的效果很大程度上由数据决定，这话一点都不夸张。基座模型要的海量语料需要清洗和去重，SFT 需要高质量指令数据，对齐需要人类偏好数据，评测需要标注数据集。所有这些工作都需要大量的数据工程师和数据标注管理人才。

和数据标注流水线的操作工不同，这里说的数据工程师是设计数据流程的人——数据从哪来、怎么解析、怎么清洗、怎么过滤低质量内容、怎么配比不同来源的数据、怎么构建指令数据的模板。这项工作需要细心、耐心和对模型训练的敏感性，技术门槛不像算法那么高，但对业务的价值非常大。

我认识的几位优秀的数据工程师，薪资区间在 30k 到 60k 每月，而且从来不愁找下家。很多团队对数据人才的重视程度不够，这反而是机会——当别人都在卷模型结构的时候，你能把数据做到极致，项目效果自然就体现出来了。

5.3 AI产品经理：懂模型边界的产品决策者

最后提一个非技术岗的新机会——AI 产品经理。

传统产品经理的逻辑是定义功能、画原型、推动开发实现，但 AI 产品经理面对的是完全不同的挑战。你得理解大模型的能力边界，知道什么需求能实现、什么需求现阶段做不到；你得懂 Prompt 设计和评测方法，因为 AI 产品不是写死交互流程，而是要把“模型输出”变成“可控的产品体验”；你还得设计兜底策略，模型回答不可靠的时候，产品怎么降级、怎么提示用户。

这个岗位适合有技术背景但对纯编码兴趣不大的朋友，也适合原本做产品经理、愿意系统学习大模型原理的人转行。它的薪资空间和优秀的技术岗相当，因为能同时懂技术和产品的复合人才太少了。

6. 薪酬地图与转行路径：不同背景的人应该怎么切

6.1 各方向薪酬水平与需求热度对照

把上面四个方向放在一张表里看，会更清楚它们各自的位置。

需要强调的是，薪资区间仅供参考，具体到个人会因为城市、公司、面试表现和个人能力有较大浮动。但大方向是明确的：需求旺的方向薪资抗跌，供给稀缺的方向薪资溢价高。

6.2 四类典型背景的推荐路径

不同背景的人，切入大模型行业的路径应该不一样，没必要都去挤算法那条路。

应届毕业生，特别是硕士，可以分两种情况：如果学校和论文背景都很强，可以冲算法方向；如果背景一般，优先考虑应用开发和数据工程，这两个方向对实操能力的认可度大于学历，而且成长速度更快。

后端工程师，尤其是做过高并发、熟悉分布式系统的人，两条路线都可以走：一条是转 AI Infra，直接吃老本行的红利；另一条是转应用开发，重点补 RAG 和 Agent 相关的知识。从市场需求来看，后端背景转 AI Infra 的竞争更小、溢价更高。

传统算法工程师，做 CV 或 NLP 的，尽量往多模态和模型后训练方向靠。你的算法功底不会浪费，但要补大模型特有的知识，比如 SFT 数据构建、DPO 训练、视觉指令数据构造等。

测试、运维和产品背景的人，也有进入的路径：测试转模型评测非常自然，你现在就能开始学评测集设计和 bad case 分析；运维转 MLOps 和模型部署是有利的位置；产品经理就系统补大模型能力边界和评测方法，走 AI 产品经理路线。

6.3 一个必须纠正的认知

最后想泼一点冷水。大模型确实带来了高薪机会，但不是所有挂着“AI”名头的岗位都值得去，也不是所有人都应该为了高薪硬转。

我看到太多人犯同一个错误：花几百块钱买一个“大模型培训课”，学了半个月 Prompt 工程，就觉得自己可以拿高薪了。不是这样的。这个行业真正愿意付高薪的岗位，没有一个是可以速成的。RAG 你要从数据解析一点点啃到重排优化，Agent 你要在无数个失败的工具调用里摸清边界，Infra 你要对显存、算子、调度有系统的理解。任何想靠“捷径”进来的人，最后都会被面试官两个问题打回原形。

我的建议很简单：选定一个方向，花三到六个月时间，完整做一个端到端的项目，把每一步的原理和坑都搞清楚。这个项目可以是基于开源模型做的一个企业内部知识库问答系统，也可以是一个能自动完成多步任务的 Agent Demo，甚至可以是一次把某个开源模型在单卡上的推理速度优化 30% 的记录。当你真的把一个东西从零做到能跑、能用、能说清楚为什么这么设计的时候，你不需要去追风口，风口会来找你。

我在带人做项目的过程中体会到，大模型时代最值钱的不是“知道很多概念”，而是“踩过足够多的坑并知道怎么解决”。同样是一次显存溢出，有人只能上网搜教程，有人能根据日志判断是序列长度问题还是注意力计算的中间变量过大，进而调整对应的参数和策略——后者才是工程师的真实价值。