1. 先把“AI失业潮”这件事聊透1.1 这一轮AI到底改变了什么年初团队开始大规模接入AI编程工具的时候我明显感觉到周围气氛不一样了。以前聊AI大家还在讨论“能不能帮我写个正则”“帮我补个注释”今年直接变成了“这个需求还要不要招人做”“实习生写CRUD还有没有意义”。后台也经常有人私信我问得最多的一句话是AI都这样了技术人是不是真的离失业不远了先把话说在前面这轮由大模型驱动的AI确实和以前几次技术变革不一样。以前的新技术不管是云计算还是大数据本质上是“让一个人能管更多机器”最终还是人在主导。但这次大模型直接冲击的是“脑力劳动”本身——它能写代码、能补测试用例、能做需求分析、能画原型图甚至能自己调用工具完成一条完整的任务链路。换句话说AI从一个“检索工具”变成了“能交活的执行者”。但这不意味着技术人没有活路。我自己的观察是这轮AI淘汰的不是“人”而是“不会用AI的人”和“只做重复性劳动的人”。打个比方当年电子表格出现的时候会计行业也慌过一阵觉得“算盘都要被淘汰了”。结果呢会计没有消失但只会打算盘的人确实被淘汰了活下来的都是能熟练用电子表格建模、做分析的会计。AI这一轮逻辑一模一样。1.2 哪些岗位风险最高哪些其实更安全根据我这段时间和不同团队交流的信息可以给一个比较直观的风险梯度不一定全面但方向是靠谱的岗位类型风险程度原因纯CRUD业务开发高AI生成这类代码已经非常成熟完成度高只需要人工校验基础测试用例编写中高大模型能轻松覆盖正常路径和常见边界初级测试的价值被压缩数据清洗与报表开发中高这类工作模式固定AI处理效率极高架构设计与技术选型低需要结合业务、成本、团队、长期维护做取舍AI很难独立做好复杂系统调优与排障低依赖大量上下文和实操经验AI只能辅助不能主导垂直行业AI落地低需要同时懂行业业务和AI技术目前严重缺人这张表想说明一件事风险不等于失业而是“岗位价值重心在转移”。同样的岗位以前比的是“谁写得快”现在比的是“谁会定义需求、谁能验证结果、谁能把AI产出落到生产环境”。技术人的对手从来不是AI而是那些比你更早学会用AI的人。2. 技术人的护城河从“会写”到“会定义”2.1 问题定义能力AI最缺的不是算力是边界我面试过不少候选人代码能力都不错但一聊到“这个需求到底要解决什么问题”很多人卡住了。以前这个短板不太致命因为哪怕需求理解偏了改代码的成本也就是一两天。现在不一样了用AI编程需求理解偏了AI会非常高效地写出一堆“正确但没用”的代码返工成本成倍增加。这就是我想说的第一个护城河问题定义能力。说白了就是你能不能把一个模糊的诉求拆成一个AI能执行的任务描述。举个例子“帮我做一个用户登录功能”这种描述AI确实能生成一版代码但能不能用完全是另一回事。你需要告诉它登录方式支持哪些密码加密用什么算法鉴权用JWT还是SessionRedis缓存怎么做token过期时间多久并发登录怎么处理黑名单策略是什么。这些边界条件不给清楚AI生成的代码就是一堆“看起来能用”的废品。怎么练这个能力我建议从写“需求结构化文档”开始别一上来就甩给AI一句“帮我写个功能”。养成习惯写清楚背景、目标、输入输出、约束条件、验收标准、反面案例。这套思路放到任何领域都成立——AI绘画要写清楚风格、构图、主体AI写作要写清楚受众、语气、篇幅本质上都是“把需求讲出边界”。2.2 AI编程的正确打开方式提示词、审查与架构AI编程已经是我日常工作的一部分了但我想说句实话直接把AI生成的代码粘贴进生产仓库是最危险的操作习惯。正确用法是三段式提示词给足约束、生成后结构审查、关键逻辑人工细看。先说提示词。很多人写AI编程提示词只有一句话“帮我写个订单接口”这等于让一个刚入职的实习生独立负责核心模块不出问题才怪。我常用的结构是四块角色背景你是谁、任务目标要做什么、输入输出定义接口参数、返回结构、边界与禁忌不要用什么库、不要动哪些现有代码。有这几个要素AI生成的代码质量能提升一个档次。再说审查。重点关注三个地方并发安全、输入校验、异常处理。模型很擅长生成“理想状态下的代码”但真实系统永远充满并发、超时、脏数据。有一次我让AI生成一段消息队列消费逻辑它写得非常优雅唯独漏了消费失败后的重试策略——如果直接上线消息丢失就是事故。这种坑你不踩上一次很难记住“AI代码必须审查”这条铁律。最后是架构。AI擅长的是“填空”不太擅长“画框”。整个系统的模块划分、技术选型、数据流向这些还是得靠人来定。我的建议是把AI当成一个“执行力超强的中级开发”你来做架构师和技术负责人。它负责把瓷砖铺好你得负责画好整个房子的图纸。2.3 AI Agent从写单点代码到编排完整工作流如果说AI编程是基础操作那么AI Agent就是这轮竞争的分水岭。AI Agent可以理解为“能自己调用工具、规划步骤、完成多阶段任务的智能体”。它不是回答你一个问题就结束而是能围绕一个目标连续干活。举个我实际做过的例子。我以前做技术方案时要花不少时间收集信息查接口文档、翻历史代码、找监控数据、整理成文档。现在我用AI Agent搭了一条工作流第一步Agent根据我给的模块名自动检索代码仓库里相关文件第二步读取这些文件的关键逻辑并生成摘要第三步把摘要和历史维测数据汇总第四步输出一份结构化文档。整个过程从原来的一小时压缩到十分钟左右我做的是在关键节点上校验它有没有理解错。Agent工程实践有几个关键点上下文窗口管理、工具调用的异常处理、任务拆分粒度。拆分太粗Agent容易迷路拆分太细Token消耗和耗时都蹭蹭涨。我的经验是先跑通一个最小闭环再逐步加复杂逻辑别上来就搞一个“全自动”的宏大Agent。工程上没有银弹Agent也一样。3. 一个完整的AI工程实践实录3.1 项目背景给团队做一个AI代码审查助手与其空谈理论不如分享一个我近期完整落地的项目。背景很简单团队代码量增长很快人工审查压力大低级问题比如缺少空指针判断、数据库SQL没有索引、日志字段不统一经常漏到线上。我们决定做一个AI代码审查助手集成到现有的工作流里。这个项目的价值很典型它不是要替代程序员而是把人从“重复检查低级错误”里解放出来让人的精力聚焦在高层次设计上。这也正好是应对AI焦虑的一个正向案例——不是等AI来替代你而是主动去用好AI。3.2 技术选型云端API还是本地部署做AI应用第一个要决策的就是模型从哪来。两种主流路线云端大模型API或者本地部署开源模型。我们当时做了详细的对比。对比维度云端API本地部署落地速度快注册即可调用慢需要准备GPU环境和推理框架使用成本按Token计费量大成本高前期硬件投入大长期边际成本低数据隐私数据出网有合规风险数据不出内网安全性高可控性受限于服务商限流和策略模型、参数、版本全可控维护成本几乎为零需要专门维护一套推理服务专业能力通用模型能力强开箱即用需要微调或引入RAG弥补能力我们最终的方案是“两条腿走路”日常非敏感代码走云端API效率高、效果好核心业务和涉及用户隐私的模块走本地部署用开源模型加上RAG增强把团队历史代码规范文档作为检索知识库。这个组合在成本和合规之间找到了平衡点。本地部署这部分的配置我可以给个参考用一个中等规模的开源模型参数规模在7B到14B之间配合4位量化显存需求大概在8GB到16GB消费级显卡或者云上的推理实例就能跑起来。推理框架用的主流方案部署好之后单次推理延迟在几百毫秒到一两秒之间对于代码审查这种异步场景完全够用。3.3 落地步骤与关键参数整个落地过程大致分了五步每步都有值得记录的坑第一步明确输入输出。我们把问题定义成“输入一段代码diff输出结构化审查意见”。结构化的意思是要有“问题级别严重/建议/信息”“问题类型安全/性能/可读性/规范性”“具体行号”“修改建议”四个字段。这一步极其重要它决定了后面所有的评测标准也决定了整个功能的体验。如果不做结构化输出AI给出一大段“这段代码写得不错但有一些地方可以优化”之类的废话研发同学看十条就烦了。第二步构造评测集。我们从历史代码里挑了几十个有代表性的问题提交人工标注出“标准答案”用来验证AI审查效果。这一步非常耗时间但绝对不能省。没有评测集你根本不知道提示词改了一个字到底是变好了还是变坏了。第三步提示词模板迭代。初期效果不理想要么漏报要么误报。我们反复调整提示词把“这次审查只关注以下五类问题”写进约束把“不要给出赞美性评价”也写了进去。效果提升最明显的一版是在提示词里加入了“请站在一个五年经验的资深架构师角度”这句话。很玄学但实测下来确实有用。第四步接入CI流程。当效果达到可用标准后我们把它接入了CI流程只对Merge Request触发的diff做增量审查限制单次审查时长在30秒以内。这里有个细节我们对Token消耗做了上限控制因为一个大MR可能产生几千行diff全部喂给模型既贵又慢。解决方案是先做“文件级过滤器”用规则引擎筛掉那些没有风险点的文件只对高疑似文件走模型分析。第五步灰度与反馈闭环。先小范围试用收集反馈把“模型漏报”和“模型误报”的case持续回填到评测集里。这个反馈闭环是AI工程和传统研发流程最大的不同——不是上线就结束了而是需要持续迭代提示词和上下文策略。3.4 踩坑实录这些问题你大概率也会遇到第一个坑模型幻觉。AI会言之凿凿地指认一个本来没问题的代码有Bug并且编一个合理的解释。解决思路是增加“被审查代码的完整上下文”而不是只看那几行diff。只看局部代码很容易误判把整个函数甚至整个文件的上下文喂进去之后误报率明显下降。第二个坑上下文爆炸。代码文件太大一个文件可能有上千行全塞进Token里很快就会超限。我们最后的处理方式是做“关键片段截取”通过AST解析拿到代码结构只把函数签名、关键逻辑片段、相关变量声明等喂给模型而不是全量塞进去。第三个坑本地部署的推理延迟比预想的要高。并发稍高就会排队导致CI流程被拖慢。这个也好解决把同步调用改成异步队列审查结果出来后通过机器人通知到具体提交人。第四个坑评测集污染。一开始我们用的历史问题集后来发现AI可能早就“见过”这些代码效果虚高。一定要定期加入新的、真实的代码问题样本否则评测指标会失真。4. 保持竞争力的四个值得投入的方向4.1 AI应用开发与Agent工程这是我觉得当前最值得投入的领域。所谓AI应用开发不是调一个API就完事了而是要把大模型和真实业务场景做深度耦合。底层模型的能力上限在那里但怎么设计提示词流程、怎么接入私有数据、怎么做结果校验、怎么控制成本、怎么评估效果这些全是技术活。Agent工程更是如此。市面上已经有不少Agent框架但真正生产级的Agent实践还很早期。核心难点不在“调用工具”这个动作本身而是任务规划、长期记忆、纠错恢复、多Agent协作这些环环相扣的工程问题。这个方向的招聘需求涨得很快而且门槛并不在于算法功底而在于你能不能把一个真实业务拆成Agent能执行的动作序列。给个具体建议如果要做Agent先从“工具增强”开始。选一个你熟悉的日常流程例如把“接收工单-查日志-定位模块-生成处理建议”这条链路用Agent编排一遍过程中你就能理解什么是工具调用、什么是状态管理、什么是失败回退。这种项目做上两三个你对Agent的理解会远超只看文档的人。4.2 AI测试工程师一个被低估的缺口很多人都盯着AI编程忽略了测试环节。实际上一旦代码生产速度上去了测试和质量保障的压力会骤增。这就给AI测试工程师留出了非常大的空间。我最近和几个团队聊到大家的痛点高度一致代码产出量上去了但测试用例的覆盖效率没跟上上线质量反而下滑了。AI测试工程师的工作不是“用AI取代测试”而是用AI武装测试如何让大模型根据需求自动生成高覆盖率的测试用例如何用AI做缺陷分析和根因定位如何在自动化测试里引入智能断言。这些工作既需要懂测试理论又要会写提示词、懂得模型输出的不确定性。这个方向很适合有测试经验但在焦虑打工人。你已经有业务理解、测试方法论、定位问题的经验只需要补充AI工具使用和一点提示词技巧就能很快上手。而且这个方向的竞争者比应用开发少很多性价比非常高。4.3 模型部署与推理优化AI的“水电工”当大量企业开始落地AI应用时一个绕不开的现实问题是模型从哪跑、用多少显存、延迟怎么控制、并发怎么扛、成本怎么压。这就是模型部署与推理优化的价值。这个方向是最不“性感”但最刚需的。它不是研究怎么训练模型而是研究怎么把模型高效地跑起来。包括量化技术把模型从FP16压到INT8甚至INT4、推理框架的选型与调优、GPU资源调度、多模型复用的推理服务设计。热词里那个“AI大模型本地部署配置”就落在这个方向。实际做本地部署时碰到的全是具体问题显存不够怎么办、推理速度太慢能不能裁剪、长文本输入会不会超限、并发请求怎么排队、显存碎片怎么解决。这些问题没有标准答案全是靠实操积累的经验。如果你愿意踏踏实实去解决这些“脏活累活”在AI基础设施层面会非常吃香。4.4 垂直行业AI产品化懂行业比懂算法更稀缺观察现在的AI落地节奏会发现通用大模型的能力已经很强了但真正能产生业务价值的往往是那些深扎到具体行业里的应用。法律、医疗、制造、金融、教育……每个行业都有大量know-how这些经验沉淀在行业老法师的脑子里AI没法凭空学走。所以有一个很有意思的复合型角色正在变得抢手既懂某个行业业务又懂AI怎么落地的人。比如懂专利行业的人拿AI辅助做专利检索和审核工作流懂数学建模的人用AI辅助建模推导。热词里面“专利相关辅助链接”“数学建模AI提示词”看起来在跑偏但背后其实是同一个趋势AI正在进到各行各业的专业流程里成为辅助工具。我不建议所有人都去卷算法岗反而建议大家“守住行业经验补上AI技能”。你在自己行业积累了三五年的业务sense这是AI短期内学不会的。在这个基础上学会怎么用AI加固你的效率、优化你的工作流你就是一个“行业AI化”浪潮里最需要的人。这种复合型人才远远没有饱和。5. 常见问题速查与独家心态建议5.1 实操中反复被问到的问题问题我的看法现在转行学AI还来得及吗AI应用层面不怎么看年龄和基础更看学习速度和动手能力。几个月就能入门关键在于持续实践先学算法还是先学应用大多数非研究岗先学应用先做出能用的东西。算法以后有需求再补不要一上来啃论文只会调包不会原理会被淘汰吗应用层大量工作确实不用手写原理但要懂概念否则出了问题不知道从哪排查AI生成代码质量不行怎么办先检查你的提示词约束够不够细再看上下文给得足不足最后看用来做什么场景。脱离场景谈模型差评没有意义提示词工程师是不是伪需求单独的提示词岗位可能不是终局但提示词能力会成为基础技能。就像现在没人专门设“Excel工程师”可谁不会Excel呢5.2 我的四点实际操作心得每天用AI完成一个具体的、身边的任务。别只看新闻和评论要亲手用。我今天用它写了一段复杂的SQL窗口函数昨天让它把一段老代码重构出单元测试。每天一个真实任务一个月后你对AI能力边界的感知会非常准这种感知就是竞争力。建立自己的提示词库。我电脑里有一个专门的文件夹把验证过有效的提示词按场景分类存起来有写SQL的、做代码审查的、生成文档的、做数据清洗的。下次遇到类似任务直接复制改几个参数就行不用每次从零开始。这套方法我分享出去后很多同事反馈说工作效率提升非常明显。主动承担团队里的AI试点项目。想保持竞争力光自己用不够要让自己成为团队里“把AI引入流程”的那个人。无论是给测试团队做个自动生成用例的工具还是给运维团队搭个日志分析助手这种试点项目天然能让你积累别人没有的经验。留出时间做“难而慢”的事情。AI能帮你把常规任务做得飞快但技术人的深度竞争力依然来自那些AI做不了也不愿意做的事理解一个复杂业务的来龙去脉设计一个能扛住三年演进的架构解决一个隐蔽的性能瓶颈。别把所有时间都花在和AI较劲上留一部分给自己慢慢积累。最后再分享一个我个人的观察每一轮技术变革都会带来一波焦虑潮但也会带来一波红利期。焦虑的人花时间担心被替代行动的人已经在用AI武装自己。一年之后这两拨人的差距会大到难以想象。这个题目没有标准答案唯一稳妥的做法就是让自己成为那个“动手试过”的人。