最近耳边经常听到一句话：大厂集体“养龙虾”。头几次我还以为是哪个新消费赛道，直到同事甩过来一个链接，才发现所谓的“龙虾”，就是 LLM—— Large Language Model。大家图省事，把 LLM 读成“龙虾”，于是“养龙虾”就成了做大模型的戏称。原本以为是玩笑，可仔细一看，从基础模型到应用工具链，各大厂的动作确实像商量好了一样，扎堆下场。很多 IT 朋友问我：这事跟我有什么关系？关系比你想象中大。过去一年我参与过几个带大模型的项目，虽然不是从零训练大模型，但已经把文本生成、知识库问答、自动化分析这些东西接到实际业务里。一个明显的变化是：过去写代码是“表达逻辑”，现在更多是“定义模型要做什么，再由模型生成逻辑”。这种转变不是未来时，而是正在发生。如果说前两年大模型还停留在“聊天玩具”阶段，现在它已经渗透进代码生成、客户服务、数据分析、运维监控这些刚需场景。参数规模不再是唯一焦点，大家更关心的是怎么把它变成可交付的产品。这场“养龙虾”竞赛，最后比的不是谁的池子大，而是谁能让龙虾真正上桌。1. “养龙虾”不是农业，是 LLM 大乱斗1.1 “龙虾”这个梗，到底在说什么先把这个梗给新朋友拆明白。LLM 是 Large Language Model 的缩写，中文叫大语言模型。可能在某个技术群里，有人把这三个字母连起来念快了一点，听起来像“龙虾”，于是“养龙虾”就成了 LLM 生态的代称。你如果看到某条新闻说“某大厂开始养龙虾”，大概率不是真的搞水产，而是在做大模型相关的布局。这看似是个玩笑，其实贴合得很。你去观察一个大模型从无到有的过程：要清理语料，要调配算力，要一遍遍试训练参数，还要在效果不好时做复盘——和养殖户看水质、调饲料、防病害，逻辑上确实接近。模型训练不是一锤子买卖，而是反复“喂养、观察、调整”的循环，所以叫“养”也不算夸张。所以当大家说“某大厂在养龙虾”，意思是它在投入重金做基础大模型或配套工具；说“集体养龙虾”，则是产业链上几乎所有重要玩家都冲了进来，谁也不愿意缺席。这里的关键不在“龙虾”这个梗本身，而在于它背后那场已经白热化的资源争夺战。1.2 大厂为什么会集体下场判断一个技术是不是真的来了，不要看新闻，要看资源流向。过去一两年，各家在预算上越来越谨慎，但和模型相关的能力建设基本没停，甚至还在加码。这背后的商业逻辑很直白：大模型不仅是一个新功能，更是一个新的计算平台，未来软件的核心交互方式会从“人写逻辑”变成“人和模型协同定义逻辑”。你现在点开很多主流应用，可能已经能看到 AI 助手入口，只是没有特意留意。用户习惯一旦养成，谁离用户最近、谁能提供最顺畅的智能体验，谁就握有流量的新入口。大厂如果不养自己的龙虾，就要在别人的龙虾池边交租金，这在商业上很难接受。另外，模型能力带来的内部效率提升也很可观。写代码、做设计、写营销文案、处理客服记录，每一环的边际成本都有可能降低。对大型组织来说，哪怕只是提升几个百分点，乘以业务规模都是不小的数字。所以大厂集体下场，不只是追热点，更是在给未来几年的“智能化水电”提前铺管道。2. 养龙虾的真实成本：算力、数据、算法三座大山2.1 算力：养虾先建池，训练先搭集群训练大模型最直观的门槛是算力。过去买几台高性能服务器就能跑深度学习，现在动辄需要成百上千张加速卡，结构上更像搭建一座小型数据中心。这里面最难的不是买卡，而是让集群在训练期间稳定运行。我记得某中型公司第一次引入大模型训练任务，光解决网络抖动导致的训练中断就花了两周。加速卡之间要做高速互联，存储要跟得上数据读取，调度系统要能弹性分配资源，任何一环出问题，整批算力可能都在空转。很多传统程序员觉得这些事偏“硬件”，不愿意碰。但事实上，懂集群、懂并行训练、懂断点续训的人非常少，这反而是 IT 人可以抓住的缺口。这个岗位不像算法那么引人注目，却是“养龙虾”的基础设施。就像养殖场里的水循环系统，平时没人夸它，一旦停了，整池龙虾都要出问题。2.2 数据：好龙虾都是喂出来的模型的能力上限，基本由训练数据决定。到现在依然有人以为模型越大越聪明，其实一个模型用脏数据喂过和用精炼数据喂过，效果差距可能比参数量差距还明显。数据工程是“养龙虾”的饲料配方，决定了龙虾能不能长肉、肉质怎么样。具体怎么喂？首先要做海量文本清理，去掉重复内容、广告、隐私信息、低质量机器文本；然后要做领域配比，让技术、法律、医疗等内容不至于一边倒；最后还要构造指令数据，把用户的真实问题整理成“提问 + 期望回答”的形式。很多团队嫌麻烦，拿现成的数据直接微调，结果模型学会了“废话文学”——句子流利但没有信息量。这种问题后面再想补，成本高得多。我自己做过的项目里，数据清洗通常占一半以上时间。这不是因为模型训练复杂，而是因为现实数据实在太乱。你永远不知道下一批文档里混着多少表格截图、扫描件和格式错乱的表格，这些东西不处理干净，模型学到的就是噪音。2.3 算法：大家都在卷后训练预训练阶段，模型结构已经高度同质化，真正的竞赛从后训练开始。所谓后训练，就是在基础模型之上做指令微调、人类偏好对齐、推理能力强化。目标只有一个：让模型不只“会说话”，而且“会办事”。这个方向很前沿，但算法岗的门槛确实高。如果你没有扎实的数学功底和论文阅读能力，不建议硬挤。反而是那些能熟练做数据处理、能快速跑通实验、能把训练脚本工程化的人更抢手。很多人把算法工程师想象成只在实验室调参数，其实一线工作大量时间是盯着训练曲线、排查数据样本、做效果回归。我经常说，这个环节和传统软件开发中的持续集成理念很像，只是对象从代码变成了模型。模型每次更新，都要重新跑一遍评测集，看它有没有把旧能力改坏。这套工程体系，恰恰是许多团队最缺的部分。3. IT人进化的第一步：学会和大模型打交道3.1 提示词工程：把需求说清楚是核心竞争力很多人以为提示词就是给模型写几句要求，这太小看它了。真正有效的提示词，是在模仿一名优秀的需求分析师与开发者的沟通。你需要交代背景、角色、目标、约束条件，还要给出输入输出格式和示例，甚至要预判模型可能在哪里跑偏。举个例子，如果你只是说“帮我写个周报”，模型大概率给你一篇泛泛的内容。如果你说“你是某项目的后端负责人，根据下面三条工作记录，输出一份面向直属上级的周报，包含进展、风险、下一步计划，每条控制在 50 字以内”，结果会实用很多。提示词里多给一点上下文，模型返回的内容质量就会明显上升。这种能力在你的工作中马上能用。不管你是前端、后端、测试还是运维，提问质量决定了工具能帮你多少。它不要求你先成为算法专家，只要你愿意把自己的业务语言翻译成模型能理解的指令，就已经走在进化路上了。3.2 RAG：把知识库接到龙虾身上RAG 是现在把大模型接入企业系统最常用的方案。原理不复杂：把私有文档切成碎片，向量化后存进数据库；用户提问时，先从库里找回最相关的片段，再把问题加上片段一起交给大模型生成回答。相当于给模型配了一个“随时翻书”的助手，而不是让它把所有知识背在脑子里。但工程落地有很多细节。切片太大，检索结果携带太多噪音；切片太小，上下文又可能缺背景信息。向量模型选型、召回策略、多轮对话中怎么改写上一轮问题，这些都直接影响效果。我之前做一个内部知识问答系统，前后折腾了三周。最初直接问模型，答案经常一本正经胡说；后来改成 RAG，并反复调整切片和重排序，输出质量才稳定下来。后来我总结：RAG 本质上是一个搜索系统加一个生成器。你得先把搜索做好，模型才能生成得像样。很多团队一上来就追求浮夸的参数调整，结果忽略了最基础的检索准确率，最后效果自然不理想。3.3 Agent：让模型从“答话”变成“干活”如果说 RAG 是让模型“看得更多”，Agent 就是让模型“做得更多”。一个 Agent 能自己规划步骤、调用工具、检查结果并调整策略。比如运维场景中，它收到磁盘告警后，可以先查磁盘使用率，再清理临时文件，如果权限不够，自动提交工单，最后输出一份处置报告。对于 IT 人来说，Agent 的想象空间比单纯对话大得多。因为你熟悉系统接口、数据结构、业务流程，能把工具调用链设计得很稳。模型本身只是一个“调度核心”，真正让 Agent 跑起来的是你设计的工具和规则。需要提醒的是，Agent 目前还不是完全可靠的同事。工具选错、参数不符合、循环不退出这些问题都常见。因此做 Agent 应用，一定要加约束条件和人工确认机制，不能一上来就全自动。先做半自动，让模型把方案和建议提给我，我来点确认，跑顺之后再逐步放权。4. 再往下走：微调、部署和评测4.1 微调：不是救命稻草，而是精确调音很多产品经理一开口就说：把模型微调一下，让它更懂我们业务。但实际情况是，多数业务场景不需要微调。提示词和 RAG 已经能覆盖大部分需求，微调反而可能引入新问题。微调不是救命稻草，更像是对乐器做精确调音，只有在特定情况下才值得动。什么时候该微调？我总结三个条件：一是模型需要长期保持特定语气或专业风格；二是需要稳定输出某种复杂结构化内容；三是因为效果或成本原因，必须用小模型替换大模型。只有在这类情况下，微调的投入才划算。微调本身要准备高质量的数据集，数量达不到几千条以上，效果很难有保证。而且微调后一定要和基础模型做 A/B 对比，不能只看几个“爽样例”。我见过反例：团队费劲微调之后，业务场景确实变好了，但通用能力反而下降，最后只能回滚。所以，动手之前先定义好评估集，把“什么算变好”写清楚，再决定要不要调。4.2 部署优化：让效果与成本达到平衡一旦确认要用模型跑业务，成本就躲不开。商业接口按量付费，私有化部署又要算加速卡和电费。要在产品效果和成本之间找平衡，通常需要多管齐下。常见手段包括降低推理精度、缓存相同请求、用更小的模型处理简单任务、把复杂请求路由到大模型。以客服场景为例，百分之六七十的简单问题完全可以用预设答案或小模型解决，只有复杂问题才需要大模型出手。这种“分级处理”的思路，和传统系统里做多级缓存很像。你不会为了偶尔一次复杂查询，就买一套顶配数据库，对吧？同样，也不该让所有流量都涌向最贵的模型。部署优化还有一个容易被忽视的指标：响应时间。用户对聊天式交互的耐心很低，如果模型转上五秒还没出结果，体验就大打折扣。所以推理引擎的批处理、上下文缓存、量化这些手段，都需要工程团队认真打磨。4.3 安全护栏与模型评测：没这两个别上生产大模型一个特点是输出不确定，所以不能像传统函数一样直接信任。生产环境必须要加三道防线：入口过滤、出口审核、全程审计。敏感数据不能直接塞进公开模型接口，要么私有化部署，要么用带合规能力的中间层。评测体系同样重要。不要拿几个案例人肉判断，要建立自动化回归集：常见问题、边界情况、安全攻击样例，每次模型升级后都跑一遍，记录准确率、偏航率、响应时间。没有评测过程的模型迭代，等于闭眼开车。我见过太多项目在上线后才发现模型在一些角落里胡说八道，原因就是上线前只测了“主路径”。这一块听着不性感，却最能决定项目能不能走远。安全护栏让模型不出圈，评测体系让模型持续变好。很多项目就是因为这两件事没做扎实，上线后没人接得住，最后慢慢被放弃。5. 不进化就晚了？其实考的是场景迁移5.1 职位在变，但不是末日先给焦虑的朋友降低一点心理压力：大模型不会一夜之间让所有程序员失业。一个能流畅回答问题的工具，不等于一个能独立负责业务系统的工程角色。但另一面也要承认，很多重复性编码工作确实会被压缩，尤其是照着模板写增删改查、配表格、调样式的部分。真正拉开差距的，不是你会不会写 for 循环，而是你能不能定义清楚一个问题，并借助工具把它解决。过去这个问题的答案是一段代码，现在可能是一段提示词加少量代码，甚至是一个 Agent 配置。从这个角度看，程序员的工作不是在消失，而是在上移：从实现者，变成定义者和校验者。所以，“再不进化就晚了”不是说今天不学明天就被裁，而是提醒你：新技术带来的分工调整不会等你准备好。与其被动观望，不如主动把自己手上的某件小事交给大模型做一遍，找到那种“原来还能这样”的感觉。5.2 三条适合 IT 人的转型路线我身边陆续有人完成了转型，大致可以分为三类：应用型、平台型、业务型。应用型继续写代码，但主要工作是调用大模型、设计 RAG、开发 Agent；平台型做推理部署、模型服务、评测体系和安全审计；业务型则是靠行业知识做垂直工具。转型方向核心技能适合人群典型产出应用型Prompt 设计、RAG、Agent 开发、业务理解前后端开发智能客服、文档问答、代码辅助工具平台型推理部署、性能调优、评测体系、安全审计运维、后端、测试模型服务、评测平台、安全护栏业务型垂直领域知识、数据构建、流程设计有行业经验者垂直行业 AI 工具、内部知识助手这三条路没有高下之分。平台型岗位在大公司和模型公司更集中，应用型和业务型岗位则在中小公司更吃香。你可以根据自己的积累选择：原本就懂系统稳定性，就往平台型走；原本业务功底深，就往业务型走；如果只想快速看到产品效果，应用型最合适。5.3 90 天实操路线图：马上可以开始如果不知道从哪下手，我给你一条验证过的路线。第一个月：熟悉大模型的基本能力。找一个模型接口，做一些生成、总结、翻译、分类任务，把提示词玩熟，理解参数变化对输出的影响。期间不要急着写复杂代码，重点是建立直觉。第二个月：围绕自己的工作场景做一个真实小项目。比如把接口文档做成一个问答机器人，或者用模型分析日志里的错误规律。引入 RAG，自己切文档、建索引、调召回。第三个月：做评测和部署。把第二个月的项目发给三五个同事用，记录反馈，定义评价指标；如果有可能，把模型推理服务封装成接口，从成本、延迟、效果三个维度评估。完整跑完这一轮，你就能感受到大模型应用的完整链路，比看一百篇文章都有用。别担心项目不够“高级”，只要它解决了你身边一个真实问题，就是最好的练手。6. 谈谈我的个人体会最后不讲大道理，讲一个最近很有触动的经历。某内部系统改造时，我们遇到一个很常规的问题：业务人员想查数据，但不会写查询语句，提需求要排队。传统方案是做一个复杂的查询界面，把字段、条件、筛选都设计好。后来我们换了个思路：让用户直接用自然语言提问，后台把问题转成语义检索和查询生成，再由程序校验后执行。模型负责理解，程序负责兜底，人工负责审核高风险操作。这个方案不算多先进，但带给我的启发是：真正有价值的不是模型本身，而是你愿意把一个老问题放到新技术框架里重新想一遍。过去写代码是教计算机怎么做，现在更多是教模型理解目标，剩下的生成过程交给概率。这种思维方式上的切换，才是“进化”的关键。另外有个小建议：尽量少收藏课程，多让自己上手跑。第一次调用接口时可能会觉得模型答非所问，但只要你真实感受到它能解决和你工作相关的问题，后面就会自发地越走越深。不要等到公司发通知才去学，趁现在还有试错空间，给自己留一条更宽的技能栈。养龙虾这件事，你可以不参与，但一定要学会吃虾。
最近耳边经常听到一句话：大厂集体“养龙虾”。头几次我还以为是哪个新消费赛道，直到同事甩过来一个链接，才发现所谓的“龙虾”，就是 LLM—— Large Language Model。大家图省事，把 LLM 读成“龙虾”，于是“养龙虾”就成了做大模型的戏称。原本以为是玩笑，可仔细一看，从基础模型到应用工具链，各大厂的动作确实像商量好了一样，扎堆下场。很多 IT 朋友问我：这事跟我有什么关系？关系比你想象中大。过去一年我参与过几个带大模型的项目，虽然不是从零训练大模型，但已经把文本生成、知识库问答、自动化分析这些东西接到实际业务里。一个明显的变化是：过去写代码是“表达逻辑”，现在更多是“定义模型要做什么，再由模型生成逻辑”。这种转变不是未来时，而是正在发生。如果说前两年大模型还停留在“聊天玩具”阶段，现在它已经渗透进代码生成、客户服务、数据分析、运维监控这些刚需场景。参数规模不再是唯一焦点，大家更关心的是怎么把它变成可交付的产品。这场“养龙虾”竞赛，最后比的不是谁的池子大，而是谁能让龙虾真正上桌。1. “养龙虾”不是农业，是 LLM 大乱斗1.1 “龙虾”这个梗，到底在说什么先把这个梗给新朋友拆明白。LLM 是 Large Language Model 的缩写，中文叫大语言模型。可能在某个技术群里，有人把这三个字母连起来念快了一点，听起来像“龙虾”，于是“养龙虾”就成了 LLM 生态的代称。你如果看到某条新闻说“某大厂开始养龙虾”，大概率不是真的搞水产，而是在做大模型相关的布局。这看似是个玩笑，其实贴合得很。你去观察一个大模型从无到有的过程：要清理语料，要调配算力，要一遍遍试训练参数，还要在效果不好时做复盘——和养殖户看水质、调饲料、防病害，逻辑上确实接近。模型训练不是一锤子买卖，而是反复“喂养、观察、调整”的循环，所以叫“养”也不算夸张。所以当大家说“某大厂在养龙虾”，意思是它在投入重金做基础大模型或配套工具；说“集体养龙虾”，则是产业链上几乎所有重要玩家都冲了进来，谁也不愿意缺席。这里的关键不在“龙虾”这个梗本身，而在于它背后那场已经白热化的资源争夺战。1.2 大厂为什么会集体下场判断一个技术是不是真的来了，不要看新闻，要看资源流向。过去一两年，各家在预算上越来越谨慎，但和模型相关的能力建设基本没停，甚至还在加码。这背后的商业逻辑很直白：大模型不仅是一个新功能，更是一个新的计算平台，未来软件的核心交互方式会从“人写逻辑”变成“人和模型协同定义逻辑”。你现在点开很多主流应用，可能已经能看到 AI 助手入口，只是没有特意留意。用户习惯一旦养成，谁离用户最近、谁能提供最顺畅的智能体验，谁就握有流量的新入口。大厂如果不养自己的龙虾，就要在别人的龙虾池边交租金，这在商业上很难接受。另外，模型能力带来的内部效率提升也很可观。写代码、做设计、写营销文案、处理客服记录，每一环的边际成本都有可能降低。对大型组织来说，哪怕只是提升几个百分点，乘以业务规模都是不小的数字。所以大厂集体下场，不只是追热点，更是在给未来几年的“智能化水电”提前铺管道。2. 养龙虾的真实成本：算力、数据、算法三座大山2.1 算力：养虾先建池，训练先搭集群训练大模型最直观的门槛是算力。过去买几台高性能服务器就能跑深度学习，现在动辄需要成百上千张加速卡，结构上更像搭建一座小型数据中心。这里面最难的不是买卡，而是让集群在训练期间稳定运行。我记得某中型公司第一次引入大模型训练任务，光解决网络抖动导致的训练中断就花了两周。加速卡之间要做高速互联，存储要跟得上数据读取，调度系统要能弹性分配资源，任何一环出问题，整批算力可能都在空转。很多传统程序员觉得这些事偏“硬件”，不愿意碰。但事实上，懂集群、懂并行训练、懂断点续训的人非常少，这反而是 IT 人可以抓住的缺口。这个岗位不像算法那么引人注目，却是“养龙虾”的基础设施。就像养殖场里的水循环系统，平时没人夸它，一旦停了，整池龙虾都要出问题。2.2 数据：好龙虾都是喂出来的模型的能力上限，基本由训练数据决定。到现在依然有人以为模型越大越聪明，其实一个模型用脏数据喂过和用精炼数据喂过，效果差距可能比参数量差距还明显。数据工程是“养龙虾”的饲料配方，决定了龙虾能不能长肉、肉质怎么样。具体怎么喂？首先要做海量文本清理，去掉重复内容、广告、隐私信息、低质量机器文本；然后要做领域配比，让技术、法律、医疗等内容不至于一边倒；最后还要构造指令数据，把用户的真实问题整理成“提问 + 期望回答”的形式。很多团队嫌麻烦，拿现成的数据直接微调，结果模型学会了“废话文学”——句子流利但没有信息量。这种问题后面再想补，成本高得多。我自己做过的项目里，数据清洗通常占一半以上时间。这不是因为模型训练复杂，而是因为现实数据实在太乱。你永远不知道下一批文档里混着多少表格截图、扫描件和格式错乱的表格，这些东西不处理干净，模型学到的就是噪音。2.3 算法：大家都在卷后训练预训练阶段，模型结构已经高度同质化，真正的竞赛从后训练开始。所谓后训练，就是在基础模型之上做指令微调、人类偏好对齐、推理能力强化。目标只有一个：让模型不只“会说话”，而且“会办事”。这个方向很前沿，但算法岗的门槛确实高。如果你没有扎实的数学功底和论文阅读能力，不建议硬挤。反而是那些能熟练做数据处理、能快速跑通实验、能把训练脚本工程化的人更抢手。很多人把算法工程师想象成只在实验室调参数，其实一线工作大量时间是盯着训练曲线、排查数据样本、做效果回归。我经常说，这个环节和传统软件开发中的持续集成理念很像，只是对象从代码变成了模型。模型每次更新，都要重新跑一遍评测集，看它有没有把旧能力改坏。这套工程体系，恰恰是许多团队最缺的部分。3. IT人进化的第一步：学会和大模型打交道3.1 提示词工程：把需求说清楚是核心竞争力很多人以为提示词就是给模型写几句要求，这太小看它了。真正有效的提示词，是在模仿一名优秀的需求分析师与开发者的沟通。你需要交代背景、角色、目标、约束条件，还要给出输入输出格式和示例，甚至要预判模型可能在哪里跑偏。举个例子，如果你只是说“帮我写个周报”，模型大概率给你一篇泛泛的内容。如果你说“你是某项目的后端负责人，根据下面三条工作记录，输出一份面向直属上级的周报，包含进展、风险、下一步计划，每条控制在 50 字以内”，结果会实用很多。提示词里多给一点上下文，模型返回的内容质量就会明显上升。这种能力在你的工作中马上能用。不管你是前端、后端、测试还是运维，提问质量决定了工具能帮你多少。它不要求你先成为算法专家，只要你愿意把自己的业务语言翻译成模型能理解的指令，就已经走在进化路上了。3.2 RAG：把知识库接到龙虾身上RAG 是现在把大模型接入企业系统最常用的方案。原理不复杂：把私有文档切成碎片，向量化后存进数据库；用户提问时，先从库里找回最相关的片段，再把问题加上片段一起交给大模型生成回答。相当于给模型配了一个“随时翻书”的助手，而不是让它把所有知识背在脑子里。但工程落地有很多细节。切片太大，检索结果携带太多噪音；切片太小，上下文又可能缺背景信息。向量模型选型、召回策略、多轮对话中怎么改写上一轮问题，这些都直接影响效果。我之前做一个内部知识问答系统，前后折腾了三周。最初直接问模型，答案经常一本正经胡说；后来改成 RAG，并反复调整切片和重排序，输出质量才稳定下来。后来我总结：RAG 本质上是一个搜索系统加一个生成器。你得先把搜索做好，模型才能生成得像样。很多团队一上来就追求浮夸的参数调整，结果忽略了最基础的检索准确率，最后效果自然不理想。3.3 Agent：让模型从“答话”变成“干活”如果说 RAG 是让模型“看得更多”，Agent 就是让模型“做得更多”。一个 Agent 能自己规划步骤、调用工具、检查结果并调整策略。比如运维场景中，它收到磁盘告警后，可以先查磁盘使用率，再清理临时文件，如果权限不够，自动提交工单，最后输出一份处置报告。对于 IT 人来说，Agent 的想象空间比单纯对话大得多。因为你熟悉系统接口、数据结构、业务流程，能把工具调用链设计得很稳。模型本身只是一个“调度核心”，真正让 Agent 跑起来的是你设计的工具和规则。需要提醒的是，Agent 目前还不是完全可靠的同事。工具选错、参数不符合、循环不退出这些问题都常见。因此做 Agent 应用，一定要加约束条件和人工确认机制，不能一上来就全自动。先做半自动，让模型把方案和建议提给我，我来点确认，跑顺之后再逐步放权。4. 再往下走：微调、部署和评测4.1 微调：不是救命稻草，而是精确调音很多产品经理一开口就说：把模型微调一下，让它更懂我们业务。但实际情况是，多数业务场景不需要微调。提示词和 RAG 已经能覆盖大部分需求，微调反而可能引入新问题。微调不是救命稻草，更像是对乐器做精确调音，只有在特定情况下才值得动。什么时候该微调？我总结三个条件：一是模型需要长期保持特定语气或专业风格；二是需要稳定输出某种复杂结构化内容；三是因为效果或成本原因，必须用小模型替换大模型。只有在这类情况下，微调的投入才划算。微调本身要准备高质量的数据集，数量达不到几千条以上，效果很难有保证。而且微调后一定要和基础模型做 A/B 对比，不能只看几个“爽样例”。我见过反例：团队费劲微调之后，业务场景确实变好了，但通用能力反而下降，最后只能回滚。所以，动手之前先定义好评估集，把“什么算变好”写清楚，再决定要不要调。4.2 部署优化：让效果与成本达到平衡一旦确认要用模型跑业务，成本就躲不开。商业接口按量付费，私有化部署又要算加速卡和电费。要在产品效果和成本之间找平衡，通常需要多管齐下。常见手段包括降低推理精度、缓存相同请求、用更小的模型处理简单任务、把复杂请求路由到大模型。以客服场景为例，百分之六七十的简单问题完全可以用预设答案或小模型解决，只有复杂问题才需要大模型出手。这种“分级处理”的思路，和传统系统里做多级缓存很像。你不会为了偶尔一次复杂查询，就买一套顶配数据库，对吧？同样，也不该让所有流量都涌向最贵的模型。部署优化还有一个容易被忽视的指标：响应时间。用户对聊天式交互的耐心很低，如果模型转上五秒还没出结果，体验就大打折扣。所以推理引擎的批处理、上下文缓存、量化这些手段，都需要工程团队认真打磨。4.3 安全护栏与模型评测：没这两个别上生产大模型一个特点是输出不确定，所以不能像传统函数一样直接信任。生产环境必须要加三道防线：入口过滤、出口审核、全程审计。敏感数据不能直接塞进公开模型接口，要么私有化部署，要么用带合规能力的中间层。评测体系同样重要。不要拿几个案例人肉判断，要建立自动化回归集：常见问题、边界情况、安全攻击样例，每次模型升级后都跑一遍，记录准确率、偏航率、响应时间。没有评测过程的模型迭代，等于闭眼开车。我见过太多项目在上线后才发现模型在一些角落里胡说八道，原因就是上线前只测了“主路径”。这一块听着不性感，却最能决定项目能不能走远。安全护栏让模型不出圈，评测体系让模型持续变好。很多项目就是因为这两件事没做扎实，上线后没人接得住，最后慢慢被放弃。5. 不进化就晚了？其实考的是场景迁移5.1 职位在变，但不是末日先给焦虑的朋友降低一点心理压力：大模型不会一夜之间让所有程序员失业。一个能流畅回答问题的工具，不等于一个能独立负责业务系统的工程角色。但另一面也要承认，很多重复性编码工作确实会被压缩，尤其是照着模板写增删改查、配表格、调样式的部分。真正拉开差距的，不是你会不会写 for 循环，而是你能不能定义清楚一个问题，并借助工具把它解决。过去这个问题的答案是一段代码，现在可能是一段提示词加少量代码，甚至是一个 Agent 配置。从这个角度看，程序员的工作不是在消失，而是在上移：从实现者，变成定义者和校验者。所以，“再不进化就晚了”不是说今天不学明天就被裁，而是提醒你：新技术带来的分工调整不会等你准备好。与其被动观望，不如主动把自己手上的某件小事交给大模型做一遍，找到那种“原来还能这样”的感觉。5.2 三条适合 IT 人的转型路线我身边陆续有人完成了转型，大致可以分为三类：应用型、平台型、业务型。应用型继续写代码，但主要工作是调用大模型、设计 RAG、开发 Agent；平台型做推理部署、模型服务、评测体系和安全审计；业务型则是靠行业知识做垂直工具。转型方向核心技能适合人群典型产出应用型Prompt 设计、RAG、Agent 开发、业务理解前后端开发智能客服、文档问答、代码辅助工具平台型推理部署、性能调优、评测体系、安全审计运维、后端、测试模型服务、评测平台、安全护栏业务型垂直领域知识、数据构建、流程设计有行业经验者垂直行业 AI 工具、内部知识助手这三条路没有高下之分。平台型岗位在大公司和模型公司更集中，应用型和业务型岗位则在中小公司更吃香。你可以根据自己的积累选择：原本就懂系统稳定性，就往平台型走；原本业务功底深，就往业务型走；如果只想快速看到产品效果，应用型最合适。5.3 90 天实操路线图：马上可以开始如果不知道从哪下手，我给你一条验证过的路线。第一个月：熟悉大模型的基本能力。找一个模型接口，做一些生成、总结、翻译、分类任务，把提示词玩熟，理解参数变化对输出的影响。期间不要急着写复杂代码，重点是建立直觉。第二个月：围绕自己的工作场景做一个真实小项目。比如把接口文档做成一个问答机器人，或者用模型分析日志里的错误规律。引入 RAG，自己切文档、建索引、调召回。第三个月：做评测和部署。把第二个月的项目发给三五个同事用，记录反馈，定义评价指标；如果有可能，把模型推理服务封装成接口，从成本、延迟、效果三个维度评估。完整跑完这一轮，你就能感受到大模型应用的完整链路，比看一百篇文章都有用。别担心项目不够“高级”，只要它解决了你身边一个真实问题，就是最好的练手。6. 谈谈我的个人体会最后不讲大道理，讲一个最近很有触动的经历。某内部系统改造时，我们遇到一个很常规的问题：业务人员想查数据，但不会写查询语句，提需求要排队。传统方案是做一个复杂的查询界面，把字段、条件、筛选都设计好。后来我们换了个思路：让用户直接用自然语言提问，后台把问题转成语义检索和查询生成，再由程序校验后执行。模型负责理解，程序负责兜底，人工负责审核高风险操作。这个方案不算多先进，但带给我的启发是：真正有价值的不是模型本身，而是你愿意把一个老问题放到新技术框架里重新想一遍。过去写代码是教计算机怎么做，现在更多是教模型理解目标，剩下的生成过程交给概率。这种思维方式上的切换，才是“进化”的关键。另外有个小建议：尽量少收藏课程，多让自己上手跑。第一次调用接口时可能会觉得模型答非所问，但只要你真实感受到它能解决和你工作相关的问题，后面就会自发地越走越深。不要等到公司发通知才去学，趁现在还有试错空间，给自己留一条更宽的技能栈。养龙虾这件事，你可以不参与，但一定要学会吃虾。