最近有个老同事约我吃饭，聊到一个特别现实的问题：35岁，传统后端开发干了十来年，薪资到顶，业务需求也在收缩，要不要all in大模型？他说自己把网上关于“35岁程序员转行大模型”的文章翻了个遍，收藏了一堆，越看越焦虑，因为大部分内容要么是卖课的，要么只说“大模型很火”，真正告诉他“下周一该干什么、三个月后该达到什么水平、简历上写什么项目能过筛”的，几乎没有。
这篇不打算给你打鸡血，也不扯什么“35岁是黄金年龄”这种正确但没用的废话。我结合身边几个转型成功的案例，以及自己辅导过的几十个开发者，整理了一条从零基础入门到能落地求职的全路径规划。它不轻松，平均每天要投入两到三个小时，但它足够具体：什么阶段学什么、学到什么程度算合格、用什么项目证明自己、面试官真正会问什么，都讲清楚。这可能是你看过的同类内容里，最接近“可以直接照着做”的一份。
1. 35岁转大模型：动手前先想清楚五个问题
开始买课、刷视频之前，先把五个问题捋明白。很多人转行失败，不是学不会，而是从一开始方向就错了，学了一堆用不上的东西，简历依然没人看。
1.1 大模型岗位到底有哪些，哪个适合你
大模型领域不是只有“训练大模型”这一种岗位。我把它粗分成四类，你可以对照自己的情况看。
- 大模型算法工程师：做预训练、对齐、评测，要求数学和深度学习底子非常扎实，基本是名校相关专业硕博的赛道，普通35岁后端硬转这里，性价比很低。
- 大模型应用开发工程师：用现成的模型API或开源模型，做RAG、Agent、微调、部署，解决具体业务问题。这是目前需求量最大、和传统软件工程师技能重叠度最高的方向，也是35岁程序员最该切入的位置。
- 提示词工程与LLMOps：偏重Prompt设计、模型选型、成本优化、效果评估、上线监控。这个方向不需要太深数学，但需要很强的工程思维和对业务的敏感度。
- 行业落地顾问/解决方案专家：懂行业痛点，又能把大模型能力翻译成产品功能。适合原本就有深厚行业经验的人，难点在于既要懂技术又要懂业务。
结论很直接：如果目标是半年到一年内转岗成功，优先瞄准“大模型应用开发工程师”和“LLMOps”这两个方向。算法岗不是不能碰，但那应该是你落地站稳之后，再回头去补数学和深度学习的长期目标。
1.2 你的存量经验是包袱还是复利
很多35岁左右的开发者担心：我做的是传统业务系统，跟AI不沾边，是不是等于从零开始？我把这个问题换个说法：一个做了十年后端的人，和一个刚毕业的应届生同时学大模型，谁更容易做出可用的落地系统？大概率是前者。
原因很简单。大模型落地，难点从来不只是“调用一个接口”，而是把模型能力嵌进真实的业务流程里。你过去积累的工程能力，比如数据清洗、接口设计、性能优化、异常处理、部署监控，恰恰是大模型应用从Demo走向生产环境时最需要的。我在实际项目中见过太多翻车案例：算法工程师在Jupyter Notebook里跑得飞起，一上生产就崩溃，因为没做过并发控制、没有日志追踪、不知道怎么做优雅降级。这些事，一个有十年后端经验的人闭着眼都能处理好。
但存量经验也有反面：你过去的技术栈和思维习惯可能形成路径依赖，比如凡事追求“确定性”，习惯了“输入A必然输出B”，而大模型是概率系统，同一个Prompt今天和明天的输出可能不同。转行首先要接受的，就是这种不确定性。
1.3 竞争力对比：你不该和应届生拼什么
有一个事实得先承认：在“算法理论基础”这件事上，35岁的程序员普遍拼不过刚毕业的相关专业硕士。人家学了七年数学和机器学习，你花三个月想追平，不现实。但大模型工程领域的招聘，本质上是“按岗位匹配度筛人”，不是“按分数排名录取”。
面试官招一个应用开发工程师，更看重这几件事：能不能把业务问题拆解成模型能力；能不能设计出稳定、可维护的RAG链路；能不能处理模型幻觉带来的稳定性问题；有没有性能优化的思路；出了问题能不能快速定位。这些正是工程老手的强项。
所以你的策略很明确：不拼推导公式，拼系统落地能力；不拼模型原理背诵，拼业务理解和架构设计。简历和面试都围绕“我过去十年的工程经验，恰好是大模型落地最缺的东西”来展开。
2. 第一阶段底子：四门功课补到什么程度算合格
选定应用开发方向后，第一阶段的任务是补底子。很多人一上来就啃Transformer论文，结果一周就放弃。正确的顺序是先跑通再理解，先会用再深挖。这一阶段建议控制在两个月左右，每天两小时，周末加半天。
2.1 Python编程：不追求精通，但要写得顺手
大模型生态里Python是绝对主力。如果你原本是Java、Go、C++背景，Python语法本身不难，难的是习惯它的生态。这一阶段的目标是：能独立写200行以上的脚本，熟练使用requests、json、pandas、numpy这几个库。
不用专门花时间去学“Python高级技巧”，什么装饰器、元类、协程，遇到再查就行。我比较推荐的做法是直接拿一个小目标练手，比如写一个脚本，调用一个公开的大模型API，把返回结果解析成结构化数据存到本地。这个过程中你会自然接触到HTTP调用、JSON解析、异常处理、日志打印，这些才是实际开发中最常用的东西。
2.2 深度学习基础：重点理解“模型是怎么工作的”
不需要你从零实现一个Transformer，但至少要搞清楚几个核心概念：神经网络是怎么通过梯度下降学习的；什么是Token，为什么文本要被切分成Token；Embedding是什么，为什么语义相近的词向量距离更近；Transformer的Attention机制大致在做什么。
我建议找一门口碑好的深度学习入门课程，只看前三分之一就行，重点是“神经网络基础”和“自然语言处理入门”两个章节。看到公式推导实在看不懂就跳过，但要记住结论。这阶段的目标不是让你能推导反向传播，而是当别人说“这个模型需要多少显存”的时候，你能听懂，不会懵。
2.3 数学基础：够用就好，别陷进去
这是35岁转型最容易“死”的地方：一听说大模型需要数学，就跑去刷线性代数和概率论，一刷又是半年。我的态度很明确：应用开发方向，数学学到“够用”就好。
所谓够用，就是能看懂这几个概念：向量的点积和余弦相似度（用于计算文本相似度）；条件概率和贝叶斯公式（用于理解生成式模型的原理）；矩阵乘法（用于理解参数量和计算量）。这些知识用两天时间就能过一遍，关键是知道它们在大模型里扮演什么角色，而不是会做课后习题。真遇到需要公式推导的场合，现查资料完全来得及。
2.4 必须顺手的基础设施
除了上面三门偏理论的课，还有几样工程工具必须熟练掌握，它们决定你后面做项目的效率：
- Linux基础操作：文件操作、进程管理、查看显存和CPU使用情况，至少要熟练。
- Docker：大模型部署几乎离不开容器，要会用Dockerfile构建镜像、启动容器、挂载数据卷。
- Git：代码管理的基本操作要形成肌肉记忆。
- Hugging Face生态：要会下载模型、查看模型卡、用Transformers库加载模型做推理。这块不用刻意学，做一两个小实验自然就会了。
底子阶段最容易踩的坑是“贪多”。今天看Python教程，明天学Docker，后天又去研究PyTorch，半个月下来什么都没学扎实。正确做法是围绕一个主线任务走：我的主线任务是“把一个大模型跑起来”，所有知识都围绕这个目标补，学完就能用，用完才能记得住。
3. 大模型技能进阶：三个阶段的升级打怪路线
底子补完之后，进入真正的技能进阶阶段。这个阶段我建议安排四到五个月，依然是每天两小时加周末半天的节奏。整个过程分三个阶段，每个阶段都要有产出，不允许只“学完”没有“做出东西”。
3.1 第一阶段：提示词工程与API调用
第一个月，目标是把大模型用熟练。你要掌握的是：怎么设计有效的Prompt，包括角色设定、上下文注入、输出格式约束、少样本示例；怎么处理模型的参数，比如Temperature、Top_p对输出的影响；怎么控制成本和延迟，比如Token用量估算、模型选型。
实际上手操作很重要。给自己布置一个任务：用商业大模型API做一个“文档摘要助手”，输入一篇长文，输出结构化摘要，包含核心观点、关键数据、待办事项三个部分。这期间你会遇到输出格式不稳定、字数超限、摘要遗漏重点等一堆问题，解决这些问题的过程，才是真正的学习。
3.2 第二阶段：RAG与知识库问答
第二个月到第三个月，进入大模型应用开发的核心领域：RAG，也就是检索增强生成。为什么要学RAG？因为光靠模型本身的记忆做问答，一定会遇到知识过时、胡编乱造、无法引用来源的问题。RAG的解决思路是：先把文档切块、向量化存入向量数据库，用户提问时先在知识库里检索出相关片段，再把片段和问题一起交给模型生成答案。
这一阶段你需要动手实现一条完整的RAG链路：文档加载与解析、文本分块策略、Embedding模型选择、向量数据库搭建（比如用开源向量数据库）、检索与重排、Prompt组装、答案生成与引用标注。
有一个我踩过的坑得提前告诉你：很多人以为RAG难点在“调用”，实际上难点在“分块”和“检索质量”。文档怎么切，块太大检索不精准，块太小丢失上下文；Embedding模型怎么选，直接影响检索效果；检索到了相关内容但排序不对，答案也会跑偏。这些都需要你反复实验积累手感。
3.3 第三阶段：Agent与工具调用
第四到第五个月，开始接触Agent。通俗讲，Agent就是让大模型具备“使用工具”的能力：它自己决定调用哪个函数、查询哪张表、访问哪个接口，然后根据返回结果继续推理。
这里要学的东西包括：Function Calling的机制，也就是怎么让模型输出结构化的工具调用指令；常用的Agent框架，比如用开源框架写工作流；多步推理和任务拆解，让模型把一个复杂任务拆成多个步骤执行。
曾经我用一个Agent做过一个小工具：给定一个自然语言需求，Agent自动补全一个Python函数。刚开始它经常写错，但通过给它提供“报错信息反馈”这个工具，它就能读取报错、改写代码、重试执行，最终成功完成任务。这个案例让我真正理解了Agent和大模型之间的关系：大模型是“大脑”，Agent框架是“手脚”。
4. 实战项目：从Demo到能写进简历的落地项目
技能学完，接下来是最关键的一步：用项目证明自己。很多人卡在这里，是因为他们做的项目一看就是照着教程敲的：用现成的框架搭了个聊天机器人，把公司官网介绍丢进去，问两句“你是谁”，就没了。这种项目在面试官眼里等于没做。
4.1 项目选型的三个原则
原则一：解决一个具体问题。不要做“AI聊天助手”，要做“针对某个垂直场景的问答系统”。比如“结合企业内部维修手册的故障排查助手”，一看就知道有明确业务价值。
原则二：体现完整的工程链路。项目必须包含数据处理、模型调用、检索设计、接口封装、前端交互和部署上线，最好还有缓存和日志。这才能把你有工程经验的优势放大。
原则三：做出可量化的效果。项目里要能说清楚“之前人工处理一单要15分钟，现在用这个系统压到3分钟，准确率大概在90%”。哪怕数值是自己实测的，也得有。
4.2 两个可以直接复制的项目思路
第一个是做“垂直领域的知识库问答”。选一个你熟悉且有一定专业性的领域，比如法律条款、医疗科普、设备说明书，收集一批公开资料做数据源，搭建RAG问答系统。重点展示你在文档切分、检索调优上的钻研过程，可以说说试了多少种分块策略、对比了多少个Embedding模型、最后怎么确定参数组合的。
第二个是做“结构化数据自然语言查询”。选一个有结构的数据库，比如电商订单表、库存表，做一个系统让用户用自然语言提问，系统自动生成查询语句，取出数据后再用大模型生成中文回答。这类项目价值在于它涉及“大模型+传统数据库”，面试时很能体现工程能力。
4.3 项目做到什么程度才算“完成”
完成的标准不是“代码能跑”，而是这四件事都做了：
- 项目部署到了云服务器，可以通过公网访问，而不是跑在本地电脑上。
- 写了一份项目文档，包含架构图、核心流程说明、效果截图、性能数据。
- 录一段5分钟左右的演示视频，完整展示从输入问题到输出答案的整个过程。
- 把所有代码推到代码托管平台，有清晰的README，有提交历史。
我见过不少候选人，项目技术含量其实不差，但代码全在本地，面试官看不到，讲的时候又没有演示，只能靠嘴说，可信度大打折扣。把项目“产品化”，哪怕做得粗糙，也比一个只存在本地仓库里的完美Demo有价值得多。
5. 求职与面试：35岁转行怎么谈、怎么展示
项目做好了，下一步是找工作。我身边转型成功的人，没有一个是“海投简历”投进去的，要么是内部转岗，要么是经朋友内推，要么是靠项目作品吸引了招聘方。所以求职策略上，要沿着这几个方向用力。
5.1 简历这样写，通过率更高
不要再用“负责某某系统的开发和维护”这种传统写法，要把每一段经历都往大模型上靠。不是让你造假，而是重新表述你做过的真实工作。
比如你做过内容管理系统，可以改成“主导内容审核模块升级，设计基于关键词+语义模型的两级过滤方案，使审核效率提升40%”。你做过数据报表平台，可以改成“搭建数据查询助手，将自然语言问题转化为结构化查询，完成从需求分析到部署上线的全流程”。哪怕你只做过传统CRUD，也可以写“熟悉业务数据流转，具备将非结构化文档转化为结构化知识库的实践经验”。
项目经历部分，把第4节做的实战项目放在最前面，占最大篇幅。写清楚项目背景、你的角色、技术选型、核心难点、量化结果。技术栈一栏要明确写出：Python、Transformers、RAG、向量数据库、Docker、Prompt Engineering。
5.2 面试官真正会问的四类问题
第一类：项目深挖。你做了什么、为什么这么设计、遇到什么困难、怎么排查的。应对办法是把项目每一处细节都过一遍，尤其是“失败”的经验，比如某个方案效果不好，你怎么发现并换方案的，这种过程比结果更让面试官信任。
第二类：原理理解。RAG为什么能减少幻觉，Embedding是什么，微调和RAG的区别和适用场景是什么。这些不需要你背诵论文，但要用自己的话讲清楚逻辑。
第三类：场景设计。假设现在有一个场景，比如“客服要回答大量关于退换货的问题”，你会怎么设计系统。这是考察你把业务需求转化为技术方案的能力。
第四类：工程素养。怎么控制成本，怎么评估效果，怎么应对模型升级带来的变化。这一块35岁经验反而吃香，要大胆展示。
5.3 合理的薪资预期和Offer选择
客观讲，35岁从传统开发转大模型应用开发，第一份工作薪资能跟原来持平就值得去，能上涨20%已经算不错。不要指望第一年就翻倍，那属于幸存者偏差。大模型的溢价在于未来几年，随着经验积累，薪资天花板比传统开发高不少，这才是你转行的长期价值。
Offer选择上，优先选有真实业务场景、有数据的公司，哪怕规模小一点。一个每天有真实请求量和用户反馈的环境，比一个挂着大模型招牌但只有Demo的团队，成长速度快得多。另外要关注团队里有没有懂大模型的核心角色，如果没有，你进去了所有问题都要自己扛，这对刚转行的人来说压力太大。
6. 365天实操时间表与避坑指南
最后给一份可以直接抄作业的时间表。总时长按12个月规划，前6个月脱产或半脱产学习，后6个月边求职边做项目。
6.1 四阶段时间表
- 第1-2个月：打基础。Python熟练度、深度学习基本概念、Linux/Docker/Git工具链。产出：跑通一个开源模型的本地推理。
- 第3-4个月：RAG专项。吃透提示词工程，完成第一个RAG问答系统并部署上线。产出：可演示的知识库问答项目。
- 第5-6个月：Agent与工程化。学习Function Calling和Agent框架，做一个带工具调用的Agent应用。产出：第二个项目，最好能和第一个项目差异化。
- 第7-9个月：项目打磨与求职准备。完善项目文档和演示视频，优化简历，开始投递、内推、复盘面试问题。
- 第10-12个月：持续面试和补漏。针对面试中暴露的薄弱点专项补课，保持每周至少两个有效面试。
6.2 五个最容易让人前功尽弃的坑
第一个坑是资料囤积症。收藏了几百个教程但从不打开，每天都在“找资料”而不是“学东西”。破解办法：只保留一个主线课程，遇到不会的查官方文档，把收藏夹当字典而不是课本。
第二个坑是死磕数学和模型原理。我发现很多人花了三个月在学怎么推导Transformer的公式，结果连一个完整的RAG系统都没搭出来。对应用开发方向来说，工程能力远比推导能力重要，数学够用就行，不要追求“彻底懂”。
第三个坑是只学不做。看视频的时候觉得“我懂了”，一关电脑全忘。破解办法是边学边做，哪怕做得很粗糙，也要保证每一个知识点都通过一个练习沉淀下来。
第四个坑是忽视业务理解。大模型本身不产生价值，它和具体业务结合才产生价值。面试时如果只能说技术名词，却说不出业务痛点，很容易被拒。平时多琢磨你原来行业里有哪个环节可以被生成式AI改变，哪怕是当一个有趣的思考题。
第五个坑是闭门造车。一个人学很容易走偏，做出来的东西自我感觉良好，实际上漏洞百出。建议加一两个技术社群，或者找个学习搭子每周同步进度，相互review代码和项目。再不行，把项目发到技术社区，接受陌生人的评价，能有效打碎你的盲目自信。
6.3 最后分享一个我反复提到的动作
在所有规划里，有一个动作的价值被严重低估：每天花15分钟，用大模型API写一个自动化小脚本，解决你工作或生活中的一个真实小问题。比如自动整理邮件、自动生成周报摘要、自动批量重命名文件。别小看这15分钟，它让你始终保持“用模型解决实际问题”的敏感性，而不是陷入“为学而学”的陷阱。
我见过太多人把收藏夹当成学习进度条，收藏了就等于学会了。真正让一个人完成转行的，不是某一份完美的规划，而是某个周末的下午，他打开电脑，写下了第一行调用大模型接口的代码。现在，你只需要决定这行代码今天写，还是下周写。
