最近耳边经常听到一句话大厂集体“养龙虾”。头几次我还以为是哪个新消费赛道直到同事甩过来一个链接才发现所谓的“龙虾”就是 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. 谈谈我的个人体会最后不讲大道理讲一个最近很有触动的经历。某内部系统改造时我们遇到一个很常规的问题业务人员想查数据但不会写查询语句提需求要排队。传统方案是做一个复杂的查询界面把字段、条件、筛选都设计好。后来我们换了个思路让用户直接用自然语言提问后台把问题转成语义检索和查询生成再由程序校验后执行。模型负责理解程序负责兜底人工负责审核高风险操作。这个方案不算多先进但带给我的启发是真正有价值的不是模型本身而是你愿意把一个老问题放到新技术框架里重新想一遍。过去写代码是教计算机怎么做现在更多是教模型理解目标剩下的生成过程交给概率。这种思维方式上的切换才是“进化”的关键。另外有个小建议尽量少收藏课程多让自己上手跑。第一次调用接口时可能会觉得模型答非所问但只要你真实感受到它能解决和你工作相关的问题后面就会自发地越走越深。不要等到公司发通知才去学趁现在还有试错空间给自己留一条更宽的技能栈。养龙虾这件事你可以不参与但一定要学会吃虾。