企业官网建设流程全解析

把时钟拨回提交离职申请的那个下午——我坐在工位上把写了十年的Java代码最后 review 了一遍，心里没有想象中的激动，只有一种“算了很多遍终于落地”的踏实感。35岁，后端开发近十年，简历里堆满了微服务、分布式、高并发这类词，换来的却是招聘软件上越来越克制的回应。真正让我按下“裸辞”键的，是一条招聘JD里白纸黑字写着的方向：大模型应用开发，月薪2w+，年龄放宽。我决定给自己两个月时间，赌一把。

这篇文章把我从算账、定路线、学东西、做项目、投简历、面试、谈薪到入职后的全过程原样写出来，不吹不黑，有具体的时间节点，有踩过的坑，也有可以直接抄走的学习路径和面试弹药。如果你也在35岁左右，正站在“继续卷老技术栈”和“转一个看起来有上升空间的方向”之间犹豫，这篇文章应该能给你一个相对理性的参考样本。

1. 35岁裸辞的真实决策过程：账本、退路与赛道观察

1.1 离职前我算的三笔账，不是鸡血是计算

网上聊裸辞转行，很多人上来就灌鸡汤，什么“勇敢迈出第一步”。我特别反感这个说法。35岁的人做决定，最忌讳的就是“勇敢”，最需要的是“计算”。我离职前认认真真算了三笔账。

第一笔是现金账。我把房贷、孩子学费、日常开销、保险这些刚性支出全部列出来，算出一个数——每个月必须进账多少才能维持家庭正常运转。然后拿现有存款去除这个数，看能撑多久。我当时算下来是18个月。这意味着即便我转行失败，也有一年半的时间缓冲，不至于断粮。这笔账直接决定了后面两个月的学习心态：我可以接受学习期没有收入，但绝不允许自己陷入恐慌性求职，因为一慌就容易贱卖自己。

第二笔是市场账。我花了一周时间，把招聘平台上所有带“大模型”三个字的岗位JD过了一遍，总数超过50条。我把出现频率最高的词拉出来看，结果很有意思：排在前面的不是“论文”“算法”“数学”，而是“RAG”“Prompt”“微调”“部署”“向量化”。这让我意识到一件事——市场大量需要的不是能发明新模型的人，而是能把已有模型用起来、让它在业务里产生价值的人。这个判断后来被证明是对的。

第三笔是退路账。我想清楚了最坏情况：如果学了两个月，市场根本不接受一个35岁的新人，怎么办？我的答案是，回归老本行。十年后端经验还在，Java技术栈还没完全生锈，即使空窗几个月，拾起来也不难。有了这条退路垫底，裸辞的风险就从“可能毁掉生活”降级成“最多损失几个月时间”，这就可以接受。

1.2 大模型圈真正缺的不是炼丹师，是能搬砖的人

很多人一提起转行大模型，第一反应是“我数学不行”“我没读过论文”“我不会调参”，于是直接放弃。这个认知在2025年这个时间点已经过时了。

现在的大模型圈，大致可以分三类岗位。第一类是算法研发岗，研究新模型、新架构，发论文，这个确实门槛高，需要扎实的数学和机器学习功底，35岁零基础转过去基本不现实。第二类是数据工程岗，负责清洗、标注、构建训练数据，这个偏数据方向，薪资没有想象中高。第三类是应用工程岗，把现成的开源基座模型拿来，结合业务场景做应用，比如企业知识库问答、客服自动分诊、工单信息抽取，这个岗位需求量最大，而且技术栈偏工程——恰恰就是老程序员最擅长的事。

我给自己定的位置就是第三类。我把它叫作“大模型搬砖工”，不是自嘲，是真觉得这个定位适合我。相比科班出身的年轻人，我有十年工程经验，知道一个系统上线后要考虑稳定、安全、可维护、内存占用、并发量；相比同样想转型的同龄人，我又先跑了一步，把大模型应用侧的工具链摸熟了。这两点叠加在一起，就是我的差异化优势。

1.3 我的止损线和时间盒

裸辞之前我还做了一个很多人忽略的动作：设定止损线。我给自己定的规则是，学习期最多投入两个月，如果两个月后投出去的简历连面试机会都拿不到，或者拿到的面试全部折戟，我就启动退路方案，回归老本行，绝不在“再等等”“再学一个月”的自我感动里继续消耗。

这个止损线非常重要。它把一次可能无限扩散的冒险，变成了一个有边界、有终点的项目。后面两个月里，每当我焦虑失眠，我就把止损线拿出来回忆一遍——“最坏无非是损失一段时间”，这句话比任何打气都管用。

2. 两个月突击学习路线：从Prompt到微调再到交付的战场主线

明确了方向之后，剩下的问题只有一个：两个月时间，学什么，怎么学，学到什么程度才算够？我在正式学习前花了整整两天设计路线图。原则很简单：围绕就业市场需求来倒推学习内容，不追热点，不贪多，每个阶段结束都要有一个能看得见的产出物。

2.1 第1周：把地基补到刚好够用就停

我在读 Python 和深度学习基础时浪费了差不多两个月的时间。为什么要提这个？因为我的第一个教训恰恰是：地基不能不打，但千万别想一步挖到岩浆层。大多数专注力本就不够用的成年人，死在“追求完美地基”上。

我给自己规定：Python 基础语法只要看懂主流项目代码即可，不求精通每个库；PyTorch 只需要会加载权重、跑推理，不深入源码；模型原理以“能向别人解释清楚 transformer 大致在做什么”为目标。所有的学习，都以“能跑通代码”为验收标准，而不是“看完了”。

这一周我做的最有价值的事是，在第一天就动手跑通了一个开源基座模型的本地对话Demo。方式很朴素：去社区找文档、按文档配置环境、把模型权重下载下来、写一段十几行的Python脚本用它在终端里完成一次问答。当终端里弹出第一个回答时，那些抽象的“大模型”概念迅速落地了，我瞬间知道自己接下来要补什么。地基学到刚好够用就停，把省下来的时间留给后面真正能写进简历的东西。

2.2 第2-4周：死磕RAG这条主线，这是性价比之王

第二到第四周，我把80%的精力砸在了RAG（检索增强生成）上。市场JD里的高频词不是随便说说的，RAG相关的岗位需求确实最多，而且它天然适合有工程背景的人——因为RAG本质上是把“搜索系统”和“生成模型”拼装起来。

RAG的核心链路是这样的：先准备一批文档或数据，把它们拆分成合适大小的片段（chunk），对每个片段做向量化，存入向量数据库；用户提问时，把问题做同样的向量化，去库里检索最相似的若干个片段；然后把“用户的提问 + 检索到的片段”一起组装成一个提示词，交给底座模型生成回答。上游是文档处理和向量检索，下游是提示词组装和生成，中游还要处理相关性排序、上下文截断、回复兜底这些工程细节。

我照着这个链路，用自己过去十年攒下的笔记、博客草稿和项目文档搭了一个“个人知识库问答系统”。现在很多人搭RAG都直接用现成框架一把梭，我建议入门阶段不要这样。我全程手写了文档解析、切片、向量化、检索、提示词组装这几步代码，一共几百行，虽然粗糙，但通过亲手写一遍，我彻底搞懂了每个环节的输入输出。这个底子，后面对面回答“为什么你的检索效果比那个方案好”之类的问题，发挥了巨大作用。

这个阶段有三个坑我当时踩得比较深。第一是切片大小。切片过大，检索到的内容不精准；切片过小，上下文信息缺失。我反复试了128、256、512这些档位，最终在一个问答效果与检索精准度相对平衡的区间停下来——但不同业务的最优值不一样，面试时能说出来“我为什么选这个值”，就已经超过多数候选人。

第二是召回效果评估。很多初学者搭完RAG只关心回答顺不顺，却忽略了一个关键指标：检索系统到底把对的文档捞出来没有。我做了个最简单的评估：准备一批测试问题，人工准备好“应该召回的文档片段”，然后看检索结果命中率，再据此去调整切分和检索参数。这个习惯让我在面试讲项目时很有底气，因为我能用数字说话。

第三是提示词组装时的原文引用问题。如果不做“引用来源”设计，模型经常会把检索到的内容和我自己的提示词框架混在一起，生成语义飘忽的回答。我在提示词里明确区分了“检索到的资料”和“用户问题”两个区域，并要求模型只基于资料回答，同时标注来源编号。这个小设计，让整个系统的可信度上了一个台阶。

2.3 第5-6周：微调从“能跑通”到“能讲清楚”

第五周进入微调阶段。入门微调，我第一周几乎全程在用LoRA（Low-Rank Adaptation，低秩适配）。对新人来说，LoRA有两个肉眼可见的好处：显存占用小，用一张普通级别的消费级显卡也能跑；训练速度快，可以在可接受的时间内完成多轮实验。

微调训练本身并不复杂，把数据集、基础模型权重、训练参数喂进去就行。真正决定微调成败的不是跑代码，而是数据。我花在整理训练数据上的时间，大约是写训练脚本的三倍。我用的是自己业务里积累的问答对，把它们清洗成指令格式，去掉重复、错误、模糊的样本，然后才送进训练流程。

这个阶段我犯过一个特别典型的错误：第一轮微调跑完，loss降得很漂亮，但实际生成的回答质量反而下降了。后来复盘发现，数据量太少、格式太单一，模型过拟合了。调整方式是扩充数据多样性，并在训练时保留一部分验证集，用验证集loss来判断是否该早停。另一个常见问题是灾难性遗忘——模型学新东西的时候把原来的通用能力弄丢了。我用了一个很笨但有效的办法：在训练数据里混合一部分通用对话数据，保证模型在做垂直领域任务的同时，还保持着基本的对话能力。

学微调的过程中我慢慢悟到一个关键点：大部分公司招微调工程师，要的不是你能训练出多惊人的模型，而是你能不能讲清楚“我为什么这么设置参数”“我的数据是怎么构建的”“我的评估方式是什么”。这才是工程思维和调参直觉的体现。所以从第五周开始，我要求自己对每一个关键选择都说得出理由。

2.4 第7-8周：部署与评估，这是面试的弹药库

最后两周我做了两件事：把做好的项目部署成可访问的Web服务，以及系统梳理评估方法。

部署这件事，很多人觉得“又不是运维岗，没必要学”，这是大错特错。面试官最怕招进来的人只会跑Jupyter Notebook，根本不知道模型怎么上线、怎么给别人用。我花了一周时间，把自己做的知识库问答系统用推理框架加速，再用容器打包，部署到一台云主机上，提供API接口和一个简单的聊天页面。整个流程走下来，我对“显存占用”“并发请求”“流式输出”“重启加载时间”这些词都有了体感认识。面试谈项目的时候，我说“这个系统已部署上线，支持多人同时访问，单次问答延迟控制在秒级”，这句话的杀伤力远超背十页八股文。

评估这块，我也做了结构化梳理。对大模型应用来说，评估至少有三个层面：底座模型本身的效果，比如生成质量、指令遵循度；RAG系统的检索效果，比如召回率、命中率；端到端的业务效果，比如回答准确率、用户满意度。对不同的问题，评估手段完全不同。我把自己的项目按这三个层面各做了一组评估，并记录下评估方法、测试集、结果数据。这些内容后来直接变成了面试里最实的部分。

3. 简历、面试与谈薪：把项目经历变成薪资翻倍的说服链条

学习路线跑完后，真正的战斗才开始——让市场承认你、让面试官信服你、让公司为你的定价买单。这个过程里，简历、面试、谈薪是一个完整的说服链条，环环相扣。

3.1 简历重写：删掉十年Java经验，只留三页纸

我原来的简历是典型的后端程序员简历：工作经历按时间排列，每段下面列五六条“负责了XX系统开发”“参与了XX项目重构”。这种简历投传统后端岗没毛病，但如果投大模型应用岗，第一轮就会被筛掉——因为HR和面试官根本看不到你和大模型有什么关系。

我花了整整两天重写简历。原则很简单：所有内容向“大模型应用”这个目标收拢。十年前的Java经历，压缩成一小段“具备扎实的后端工程基础，熟悉高并发等常用技术”，放在最后面作为背景补充。篇幅大头全部留给最近两个月做的两个项目，以及在学习过程中掌握的核心技能。

这里有一个非常关键的技巧：简历里的项目描述，要用“业务价值”而不是“技术动作”来写。比如不要写“实现了基于向量的文档检索”，要写成“搭建企业知识库问答系统，将资料检索准确率从X%提升至Y%，单次问答延迟控制在秒级”。面试官看简历时的心理是“你能给我带来什么”，不是一个一个技术名词的堆砌。

我简历上放了两个项目：一个是个人知识库问答系统（覆盖RAG全链路），一个是对开源基座模型做LoRA微调并完成部署的Demo（覆盖微调与部署全流程）。每个项目都写清楚了背景、我做了什么、用了什么技术、取得了什么可量化的效果。写完那一刻我自己都有感觉：这份简历在“大模型应用”这个方向上的匹配度，是之前那份的三倍以上。

3.2 面试应答：从背答案到讲案例

面试是转行路上最大的坎。第一次面试大模型岗时，我紧张到把“softmax”说成“softmax函数”，面试官笑着打断说“别紧张，咱们聊聊天”。那次经历让我彻底放下了包袱——我开始把面试当成一次“技术方案交流”，而不是“考试”。

整理了大量面经后，我总结出这套方向的高频问题大致集中在三个层次。第一层是概念层：“什么是RAG？它要解决什么问题” “LoRA的原理是什么，相比全参微调有哪些优势”。第二层是项目层：“你这个项目检索效果怎么样，怎么评估” “训练数据怎么构建的，数据量多大” “如果效果不好，你第一反应排查哪些环节”。第三层是系统设计层：“如果给你一个客服工单分类场景，让你从头设计一套方案，你会怎么做” “模型上线后回答质量下降，你怎么排查”。

我的准备策略绝对不做“背诵全文”。我做得最多的是“用项目讲原理”：把知识点挂在项目案例上。比如讲到RAG，我就从自己知识库系统的一个真实调优案例展开；讲到LoRA，我就讲训练数据不平衡导致过拟合的那次教训。面试官能明显感觉到你是真的做过、真的想过，而不是背了一堆文档来应试的。这种“真实感”，对转行者来说是最稀缺的竞争力。

遇到不会的问题，我的处理方式也可以参考。我一般先坦白“这个方向我不太熟悉”，然后补一句“但根据我做项目的经验，我的第一反应是从哪个角度去排查”。多数面试官都很吃这一套。他们最怕的是遇到不懂装懂绕来绕去的候选人，敢说“不会”并且展示出思考框架的人，反而更容易拿到加分。

3.3 谈薪：月薪2w+是“算”出来的，不是“要”出来的

关于薪资，我想先说一个扎心的真相：裸辞转行的人，在谈薪这件事上天然处于弱势，因为你没有现成的薪资作为锚点。所以我的策略不是“我要多少”，而是“我值多少”。

在投简历之前，我对自己做的两个项目做了一个“市场定价”：这两个项目覆盖的技能组合（RAG全链路 + 微调实操 + 部署落地），在招聘市场上对应的正是月薪2w左右的岗位需求。我把这些项目做成可以在线访问的Demo，简历里附上链接。面试聊到项目时，我可以当场打开页面操作给他看。这比任何口头描述都有说服力。

真正谈薪时，我坚持三个原则。第一，不主动报价，先让HR或业务负责人说他们的预算区间，我根据他们的第一版数字来调整自己的策略。第二，不只看月薪，要看总包——有没有年终奖、五险一金缴纳基数、试用期薪资是否打折、股票期权怎么算，这些加起来可能差出好几个月的收入。第三，用一个“我能带来的价值”来支撑要价，而不是用“我需要多少钱生活”——这两个话术的说服力差着量级。

最终拿到手里的offer，月薪确实到了2w+，跟我调研时的判断基本一致。整个过程一共投了十几家公司，面试了六家，拿到两个offer，一个2w-，一个2w+。从提交离职申请到入职新公司，正好两个月出头。

4. 上岸后的复盘：哪些经验依然有效，哪些坑不该踩

入职新岗位一个月后，我才有余力回头看这段经历。回头看的结果有惊喜也有意外，有些我当时以为很管用的方法现在发现还有更优解，有些当时无意间做的决定反而在关键时刻救了我。

4.1 我实际踩中的三个坑，和差点踩中的两个

第一个实际踩中的坑在微调阶段：过分追求更低的loss，结果模型在垂直领域数据上表现很好，一问日常话题就退化。后来我在数据里混入通用对话样本，才算把这个问题稳住。这个教训让我明白：微调的目标不是“让模型更懂某个领域”，而是“在整体不失衡的前提下增强某个能力”。

第二个坑是学习期间信息过载。我一开始关注了几十个行业社群和几十个公众号，每天刷到的都是“重磅发布”“震惊”“必学技术”。这些东西看起来都很有用，实际上大部分与就业市场毫无关系。我后来做了一个“信息戒断”：只保留两三个能提供系统教程的官方文档入口，其余全部分组折叠，每天只在晚上固定时间看半小时。这个动作让我的有效学习时间至少多出了三分之一。

第三个坑在面试阶段，但教训来自入职之后：我低估了真实业务场景中数据的脏乱差程度。面试时我讲的是“处理干净的数据”，入职后面对的是几百个格式不一致的Excel文档、几十种命名规则的附件、大量缺字段的记录。公司可能根本不指望你做出什么高大上的效果，只希望你先能把数据处理得能看、能用。能在面试前了解这个现实，简历策略和预期管理都会更准确。

差点踩中的坑有两个。一是差点去报一个价格不菲的“AI转行训练营”，后来因为时间冲突没去成。回头看，当时那些课程大纲里80%的内容，我后来都通过官方文档和开源社区免费学完了。二是差点在一家“画大饼”氛围浓厚的创业公司面试中头脑发热。幸运的是朋友提醒我看它的现金流和产品落地情况，我冷静下来后才发现它连核心需求都没理清。

4.2 转行之后，我对“35岁危机”的看法变了

入职一个月后，我对年龄这件事有了新的理解。刚裸辞时，我把35岁当成一个巨大的劣势；上岸后发现，在应用工程这个方向上，年龄和经验的组合其实是有溢价的。

举一个很具体的例子：同一个RAG项目，年轻同事更关注模型效果、提示词花活；我会自然而然地想到权限控制、日志审计、并发上限、接口鉴权这些东西。这两种思维没有高下之分，但业务方和领导往往更愿意把项目交给“能兜底”的人来负责。做了十年工程积累下来的稳定性意识、边界意识、上线前的自检习惯，这些不是简历上的词，而是刻在肌肉记忆里的职业本能。

另一个感受是，转行最大的阻力其实不在技术，而在心理。35岁的人学东西不比22岁慢多少，但“我是不是太晚了”“我失败了怎么办”这类内耗会成倍地消耗精力。我之所以能在两个月里保持高密度学习，很大程度上归功于最开始设定的止损线，它让我从“放手一搏”变成“按计划执行”，心态完全不同。

4.3 一些可以抄走的实操建议

最后分享几条我觉得可以直接抄走的建议，全部来自这两个多月的实际体验。

第一，转行方向的选择，要用岗位JD倒推。先看你想去的岗位需要什么技能，再把这些技能按出现频率排序，照着排顺序去学。别被“三个月精通大模型”这类口号带着走，那只会让你在无用的角落里越走越远。第二，每学一个模块，都要有一个能演示的产出物。跑通一个Demo、写好一篇复盘、录一段讲解视频，都比“我学完了某课程”有说服力。面试官想看的永远不是你看过多少资料，而是你能做出什么东西。第三，把身体照顾好。脱产学习两个月，我每天保持一次运动，同时给学习任务划定明确的时间盒。没有好的精神状态和体力，学习效率和面试状态都会大打折扣。

现在我坐在新工位上写这篇复盘，回想那个提交离职申请的下午，心里最庆幸的不是“我赌赢了”，而是“我终于按计算好的路径走了一次”。35岁转行大模型，两个月的冲刺只是第一步，后面还有很多的未知模型、复杂场景和苛刻需求在等着。对我来说，这两月最大的收获，是重新找到了那种“还能学会新东西、还能被市场需要”的感觉。这感觉比两万块的月薪值钱得多。

最后再给你一个小技巧：如果决定走这条路，建议从第一天开始就写“转行日志”，每天哪怕只写一百字，记录今天学会了什么、踩了什么坑。两个月后回头看，那本日志就是你面试时最真实的素材库，也是你迷茫时最好的定心丸。