这几年我听到最多的一个词就是“焦虑”但说实话程序员这个行业的焦虑从来都不是新鲜事。从移动互联网到大数据再到区块链和元宇宙每隔几年就有一波“狼来了”的论调。但是当我仔细审视2024年之后的行业现状我越来越确信一件事这次不是狼来了是狼已经在圈里了。淘汰不是即将发生而是正在发生只是很多人还停留在“与我无关”的幻觉里。我这么说不是贩卖焦虑恰恰相反我认为看清这个现实是走出焦虑的第一步。作为一个写了十几年代码、带过团队、也面试过几百个候选人的从业者我想从我的视角拆解一下淘汰到底在淘汰谁、AI到底接管了什么、以及在这个已经开始的淘汰潮里哪些能力反而变得更值钱了。这篇文章想聊透这些问题给还在写代码的你一个相对清醒、也相对可操作的坐标系。1. 为什么说淘汰已经开始了一个正在发生的结构变化1.1 三个被忽视的信号岗位断层、技能半衰期与工具平权先说一个很多人不愿意面对的观察。我最近两年面试到的候选人明显呈现出一个趋势大量工作五年以上、简历上写满了“熟练使用某框架”的中层开发正在和刚毕业两三年、但已经把AI工具用得很溜的年轻人抢同一个岗位。这不是个案而是结构性的变化。第一个信号是岗位断层。我认识的一个在某公司带技术团队的朋友去年裁掉了将近三分之一的开发其中绝大多数是“业务CRUD写得熟、但说不出为什么这么写”的工程师。而他们裁完之后业务并没有因此停滞因为剩下的团队加上AI辅助反而把迭代速度提上来了。这不是某一家公司的特例我身边多个做技术管理的朋友反馈的方向几乎一致团队在变薄但产出没有变少。第二个信号是技能半衰期在急剧缩短。五年前你会一个框架能吃三年饭三年前一个框架的流行周期还能覆盖一个项目的完整生命周期但今天一个新技术从火爆到被替代的周期可能只需要一年半载。这意味着什么意味着如果你把职业安全感建立在“我会某个具体工具”上面那你几乎注定要面对周期性焦虑因为工具本身就是消耗品。第三个信号是工具平权。三年前写一个完整的前端后台系统需要你掌握一整套工程化体系今天你用AI辅助一个初级开发者在一个周末就能拼出一个能演示、能连数据库、能走通主流程的东西。能力门槛在被工具拉平这直接压缩了“中间层工程师”的生存空间。这三个信号叠加我得出的判断是我们熟悉的那个“会写代码就能有份稳定工作”的时代已经过去了。淘汰的不是程序员这个职业淘汰的是一大批靠信息差和技术门槛吃饭的岗位形态。1.2 为什么“会写代码”正在变得不够从执行者到决策者很多人问我AI到底能不能替代程序员我的回答一直是AI替代的不是程序员AI替代的是“只会写代码的程序员”。这里的关键在于过去你的价值体现在“把需求翻译成代码”的能力上。需求方给你一个模糊的想法你通过自己的技术积累把它变成可运行的系统这个过程本身就是价值的全部。但当AI能够以越来越高的质量完成这种翻译工作时你的核心价值就必须向上移动。向上移动到哪里移动到“判断做什么”的层面。举个例子。以前一个产品经理带着一个需求来找你你说“这个需求需要三个接口数据库要加两张表排期两周”然后你就开始闷头写。今天你把同样的需求描述丢给AI它可能十分钟就生成了你两周才能写出来的原型代码。但问题来了这个需求本身是否合理这个方案是否是最优解这个功能到底该不该做数据模型这么设计未来会不会成为瓶颈这些问题的回答者只能是人。而这些能力恰恰是过去很多程序员在写代码时从不主动培养的。所以我把这个结构变化总结成一句话行业对程序员的需求正在从“执行者的规模”转向“决策者的密度”。你需要的不是写更多代码而是让你的每一次编码决策——哪怕是生成一段工具函数——都建立在更深的理解之上这才是未来无法被替代的部分。2. AI到底先动谁的饭碗三个正在消失的岗位场景2.1 第一个消失场景重复度高的“业务胶水层”哪种代码最容易生成答案是“胶水代码”。什么是胶水代码就是那种把两个系统接起来、把一种数据结构转成另一种、把一个接口的参数校验一下、把一组布尔条件串成一个判断逻辑的代码。在一个典型的业务系统里这类代码占比可能60%以上。它们不复杂、不涉及核心算法、不考验架构能力它们只是量大、繁琐、需要耐心。坦白说这部分工作AI生成的质量已经非常高了。我给团队配过AI编码工具在写接口对接、DTO转换、简单的增删改查这类任务上AI的速度是人的十倍以上而且错误率并不高只要接口定义准确它生成的代码基本能直接用。这意味着什么意味着过去一个团队里最能“堆量”的工程师现在失去了他们的比较优势。如果你过去的价值主要体现在“我一天能写一千行业务代码”那很不幸你的替代成本几乎为零。最扎心的是这类岗位恰好是很多工作三到五年的人的舒适区。他们熟悉业务、熟悉系统、写起代码来驾轻就熟但这种熟悉恰恰成了遮蔽问题的安全网——当他们发现自己写的每一行代码都能被AI以更快的速度生成时安全感就瞬间坍塌了。2.2 第二个消失场景只会调用工具不会理解原理的“框架使用者”我面试过太多候选人简历上写着熟悉某框架但你往深处问一下“这个框架的Bean生命周期是怎样的当请求量上来的时候它会怎么表现你有没有遇到底层报错排查过”就答不上来了。在过去框架本身提供的记忆门槛足够形成职业壁垒。你用过的框架多、踩过的坑多这就是经验经验能换薪资。但今天这个壁垒正在快速失效——因为AI的知识库里存着所有框架的文档和所有踩坑记录。你问它任何一个框架的问题它都能给你一个比大多数人脑子里更完整的答案。于是问题变成了当“用过什么工具”不再是壁垒的时候你的价值在哪里我觉得答案是理解工具解决问题的底层思想的能力。举一个最直观的对比。同样写一个并发控制逻辑AI能给你写出七八种方案从加锁到CAS到队列削峰。但你为什么选择了其中一种而不是另一种你基于什么标准做取舍你的系统负载特征是什么这些判断AI给不了你它只能给你选项不能替你承担决策责任。而这些决策责任恰恰是高级工程师和初级工程师最本质的差别。2.3 第三个消失场景维护型岗位的收缩还有一类岗位正在悄悄消失纯维护型工程师。过去很多大系统有专门的团队负责维护老代码、修bug、做兼容性升级。这类岗位的特点是不产生新业务价值、但必须存在。AI对这类岗位的冲击是缓慢但确定的。因为维护工作本质上是一种“多模式匹配”工作——根据已知症状匹配历史问题库再参考类似场景的修复方案。这恰好是AI擅长的。我最近就用AI辅助查过几个非常老旧的后端系统的诡异bug。把栈日志丢给它它很快指出可能是哪个版本的某个依赖导致的内存泄漏还给了我Maven依赖排查的命令行序列。我顺着它的思路去查果然十分钟就定位到了问题。放在以前这种问题我可能得翻一天Git提交记录才能锁定。当维护类工作的效率提升十倍以上团队的维护人员配置自然就会收缩。这不是某个人能力不行而是整个岗位的需求在萎缩。如果你恰好在这个类别里早点规划转型尽量别把职业下半场寄托在“老系统越攒越多、永远需要有人修”这种一厢情愿的假设上。3. AI工具的边界与真相它解决什么不能解决什么3.1 为什么说“AI会让平庸更平庸”能力分化的加速我现在观察到一个非常有意思的现象AI工具用得好的人和用得不好的人差距正在以指数级拉大但方向可能和你想的不一样。用得好的人不是那些把需求描述得天花乱坠、让AI生成最漂亮代码的人而是那些能准确判断AI输出质量的人。举个我自己的例子。我用AI写一个数据清洗的Python脚本它给我生成了一段看起来很工整的代码但其中有一个逻辑分支处理了错误的边界情况——它假设某个字段一定是数值型但实际业务里那个字段有30%的概率是空字符串。如果我是那种“复制粘贴跑通了就算完事”的人这段代码上线就会在某天凌晨做数据拉取的时候静默报错。但如果我能一眼看出这里的逻辑疏漏让AI补上类型判断和异常路径处理那这个Script的质量就完全不一样了。所以我反复跟团队说一句话AI不是让你变聪明它是让你原来的判断力在单位时间里创造更多价值。判断力强的AI是放大器判断力弱的AI是哈哈镜——它会把你错误的理解快速变成一堆看起来很对但实际不能用的东西。而在过去你至少需要写一天代码才能暴露这个错误今天你只需要三十秒。3.2 AI的真正弱点需求领域的“歧义消解”依然靠人AI最大的短板不是写不出代码而是在一个模糊的、充满歧义、需要结合业务上下文才能判断的初始需求面前它做不出“看似没有选择但实际影响深远”的判断。举例。产品跟你说“这个页面要加一个筛选功能”这句话至少包含十个需要确认的决策点筛选条件有哪些维度是前端筛选还是接口筛选筛选逻辑是AND还是OR默认值是什么筛选后是否需要同步更新URL作为分享路由性能上需不需要做缓存等等。如果你把这些歧义直接丢给AI它会给一个“看起来能跑”的默认实现但这个默认实现很可能和你真正想要的完全不是一回事。而一个优秀的工程师最重要的能力就是在需求刚刚提出来那五分钟里把这些歧义一个一个问清楚并且根据业务目标做出权衡。这个能力有一个更学术的名字叫“问题重构”。问题重构不是写代码的能力而是定义问题的能力。而定义问题几乎永远是人类的领域因为只有人理解业务目标、用户情感、商业约束和系统演化的长期方向。AI能帮你写好答案但帮不了你定义正确的问题。3.3 实操中我如何使用AI辅助开发一个真实的工作流说了这么多抽象层面的东西我分享一下我在实际项目中用AI辅助开发的一个相对稳定高效的工作流程。这个方法不是标准答案但它让我把AI从“玩具”变成了“生产力工具”。第一步先写技术设计方案再碰AI。不管需求多简单我都会在动手前先把方案写在文档里涉及哪些模块、需要新建什么接口、数据模型怎么设计、异常场景怎么处理。这个过程不需要很详细但它确立了整个开发上下文的边界和方向。这步做完AI的定位就从“替代思考”变成了“辅助执行”这是质的不同。第二步用AI生成代码草稿但带着审查的心态去读。我先给AI一个清晰的上下文描述包括技术栈、项目目录结构、现有代码风格、接口文档摘要然后让它生成某个模块的实现。关键点是我从来不会直接复制粘贴进项目而是把生成代码当作“一个中级工程师提交的PR”来看逐行review确认逻辑正确、风格统一、没有安全隐患。第三步让AI给自己找茬。这是很多人忽略但极好用的一招。代码写完之后我会把它再丢给AI明确告诉它“请以资深架构师的身份审查这段代码指出潜在的性能问题、边界条件漏洞、安全和可维护性缺陷”。这个反向审查在很多次里帮我把前排掉了一些我第一遍没注意到的坑。第四步交互式重构。对于关键模块我会问AI“如果这个模块的调用量增长一百倍你觉得哪一部分会成为瓶颈”然后根据它的回答去做性能评估和压测验证。注意它的答案只是一个假设需要我用测试去验证但这个假设本身极大地提高了我的思考效率。这套流程下来我的日常工作效率提升非常客观但它是建立在“我理解每段代码为什么这样写”之上的。如果我自己都不知道自己在写什么这套流程就会变成灾难。4. 程序员的出路面向“不可替代性”的五项具体行动4.1 跳出“编码心态”建立“系统主人翁”视角我给很多年轻开发的核心建议都是一句话从“这个功能怎么写”跳转到“这个系统为什么长这样”。怎么跳一个具体的练习方式是下次你接到一个开发任务不要急着打开编辑器。先画一张系统的逻辑图——这个功能处于整个系统的哪个位置、它依赖哪些上下游模块、这些模块间的数据流怎么走、哪个环节最容易出错、这个功能上线后会对哪些既有行为产生影响。这个视角的转变是从“编码工人”到“系统设计者”的关键一步。因为它迫使你站在整个系统的高度去理解自己的工作而不是被ask在“一个函数到另一个函数”的微观隧道里。当你习惯了这种视角你会发现自己开始能回答一些过去从来不需要回答的问题这个系统为什么会有这个接口为什么数据模型要这么设计为什么业务逻辑放在这一层而不是那一层这些问题本身就是你不可替代性的来源。因为AI的默认答案往往是“最安全、最常规”的答案而系统的主人人知道“针对这个具体系统什么才是最合理的答案”。4.2 磨三个硬技能以代码为中心的领域建模、调试与代码审查面对AI时代的职业边界我认为有三个硬技能是未来几年内相对抗跌的而且它们之间是相互强化的关系。第一个是领域建模能力。这不是什么高深理论而是说你能不能把一个混乱的业务现实抽象成清晰的数据结构和逻辑模型。比如“订单”这个概念在电商系统和财务系统里的含义和属性是完全不同的。你能不能准确建立不同语境下的领域边界决定了你写出来的系统是长期稳定还是越改越烂。AI写单接口逻辑很强但它给不出一个让“订单”既能支撑交易又能支撑对账还能支撑售后的统一模型——这需要人来判断。第二个是调试与根因分析能力。写代码只是开发的一小部分时间真正考验功力的是出问题时你怎么应对。AI可以帮你生成一段新代码但没法告诉你在一个你没见过的系统里运行时的崩溃日志和业务预期之间的误差出在哪个环节。我见过太多“代码写得快”的工程师在线上bug面前手足无措——他们习惯了美妙的新代码世界却缺乏在混沌的老系统里快速定位故障的经验。第三个是代码审查能力。这可能是被AI时代低估最多的一项技能。当AI能生成大量看似正确的代码时谁能准确识别这些代码里的潜在缺陷、安全隐患和过度设计谁就掌握了质量的守门权。我建议团队里的每个成员都定期轮岗做代码审查这不是走形式而是让自己不断站在“挑错者”的位置上反向训练判断力。这三个能力的核心指向是一致的它们都是对“判断”的操练而判断永远无法被外包给工具。4.3 把AI当同事而不是当神或当玩具一个务实的使用准则关于AI使用我见过两个极端。一是完全抵触觉得AI写的东西都不靠谱坚持手写每一行代码二是无限依赖所有代码都让AI写自己只负责复制粘贴和转发给测试。这两个极端都是危险的。完全抵触会让你在效率上严重落后于整个行业而且错过了通过AI输出反向校准自己知识的绝佳机会无限依赖则会让你快速丧失对代码的理解力最终成为“看不懂自己系统里跑着什么代码”的操作员。我的建议是把AI当成一个“聪明但缺乏常识的初级同事”。你可以让它帮你干活但你必须给它清晰的上下文说明并且审查它的输出你不能指望它理解业务背景和系统约束更不能让它替你背锅。实际操作上的几个小原则涉及生产环境的数据操作脚本AI生成的每一行都必须人工审查至少两遍涉及鉴权、支付、隐私数据处理的逻辑永远不要让AI直接给出最终代码而是要让AI列出你自己思考时需要覆盖的检查点遇到AI给出的长长一串代码永远先问一句“你这段代码的前提假设是什么”再决定能否采纳。我见过太多线上事故的起因就是把AI代码当作“权威代码”直接部署。AI生成的不是权威它是你用自己判断力驯化的一个参考对象。4.4 建立“能力标签”而不是“工具标签”简历与职业定位的新思路最后一个非常现实的问题是你的简历和职业定位应该怎么调整过去很多人习惯在简历上写“熟悉Spring Boot、熟悉MySQL、熟悉Redis、熟悉Kafka……”这些是工具标签。在今天这个环境下工具标签的成色已经大幅缩水了——因为AI的知识库里什么工具都有用人方对你的期待不再是“你会某个框架”而是“你用这个框架解决了什么别人解决不了的问题”。我建议你把自己的能力描述从“工具清单”改成“能力标签”。比如不要写“熟悉MySQL”而是写“设计过分库分表方案支撑过千万级数据量下的订单存储”不要写“熟悉Redis”而是写“定位过缓存穿透和雪崩问题通过多级缓存和熔断策略恢复了不稳定服务”。这种描述的转变背后是一个很重要的自我提问如果有一天这个框架不流行了、这个数据库没人用了我积累下来的核心能力是什么如果你答不上来说明你吃的是工具红利而工具红利的保质期现在越来越短了。定位上也是同理。不要把自己定位成“一个写前端页面的”或者“一个Java开发”而是尽量找到自己在整个业务链路中不可替代的位置。你是最能洞察用户需求边界的那个是最能构建稳定数据模型的那个是Debug能力最强、系统出任何问题都能快速定位的那个这些定位以AI目前的水平都很难被取代。5. 淘汰与进化并存换个角度看这个“最坏的时代”5.1 为什么淘汰反而可能是一个良性的信号聊了这么多“淘汰”我想反过来再聊一个观点行业的这轮洗牌对于真正喜欢技术的人来说可能是一个机会。原因其实不复杂。过去很长一段时间程序员的收入溢价里有相当一部分来自行业早中期的人才供不应求乃至信息不对称。很多平庸的代码、平庸的设计、平庸的需求拆解也能因为行业红利而找到一份不错的薪资。这种状态长期来看其实是不健康的——它让大量人浑水摸鱼也让真正用心的人被平均化拉不开差距。而当AI把执行层效率大幅提升、把基础编码需求快速压缩之后市场从“需要很多人写代码”变成了“需要极少人做高质量决策”。这意味着什么意味着留存下来的岗位薪资天花板更高了。就像任何行业的成熟阶段一样早期靠人海战术跑马圈地后来靠精英团队纵深突破。现在程序员这个行业正走在这个拐点上。我说的“淘汰”淘汰的其实是冗余的、低判断力的、可替代的执行工作而不是淘汰“技术深度、业务判断和架构思维”本身。5.2 我亲眼见过的一次“危机反转”一个被低估者的翻盘去年我团队里有一个绩效一直处于中下的同事技术栈很普通就是那类“熟练使用框架、但说不出原理”的代表。在整组面临优化压力的时候他本来是那个最危险的。但他做了一个让所有人意外的动作因为效率焦虑他开始深度使用AI重构他的日常工作。他不是让AI帮他写代码就完了而是让AI把他过去工作里那些不理解的底层知识全部反推理解透彻。每拿到AI一段代码他会追问“为什么用这个本地缓存而不是分布式缓存”“为什么这个判断顺序影响性能”“这个锁粒度是否合理”然后逼着AI把原理讲到他完全明白为止。半年之后他的代码审查能力、系统设计判断力和技术深度几乎全面蜕变。他在组内分享复盘时说了一句让我印象很深的话“过去我学技术靠一本本读文档读一本忘一本现在我让AI给我当私人教师它什么都能讲就看你想不想追问到底。”我没有办法确认这是否适用于所有人但我亲眼看到了一个处在“将被淘汰”边缘的人借助AI完成了自我进化。所以说到底AI是工具它在放大你的焦虑和能力的同时也在放大你的学习速度和认知半径。5.3 面向未来五年一个朴素而务实的路线图最后我想给仍然在一线写代码、但对未来有些不确定感的朋友一个比较朴素、务实的路线图。它不需要你辞职、不需要你重学一个完全陌生的方向但它需要你从今天开始有意识地调整自己的工作方式。第一每周留出固定的“非产出时间”。什么意思就是那一两个小时不写业务代码、不做项目进度只用来补底层的专业知识、梳理系统架构图、复盘最近写过的代码有没有可以优化的部分。这个习惯看起来占用产能但它是你长期不被淘汰的复利来源。第二要求自己每个月淘汰一个旧技能、补一个新的思考模型。技术上的具体工具可以快速更替但思考模型是可以迁移的。比如你学会了“如何分析一个系统的吞吐瓶颈”这个思考模型那么你具体分析的是数据库还是消息队列并不重要重要的是你掌握了方法本身。加速学习新领域的核心不是背API而是提炼方法。第三把你的核心竞争力对外“产品化”。不管你是做业务的、做底层的还是做架构的都要学会把你最擅长的事情变成一个别人能感知到价值的作品。可以是开源项目、技术博客、公司内部的经验分享或者一个你独立设计并实现的系统。不是为了当网红而是让你自己不依赖于某一个具体的岗位环境也能被市场看见。做这些事不一定能让你在未来五年躺赢但至少能保证你在面对政策或行业变化时是有选择和主动权的。我最后想说的有一个场景我反复想起。上周我修复了一个线上的性能问题AI帮我把栈日志分析得很透甚至给出了三个可能的方向但最终定位到那个长期被低估的慢查询索引缺失是我一眼扫过表结构时发现的。那一刻我有一个很强烈的感受AI再强大它也只是一个没有项目所有权意识、没有对系统痛感、没有对用户期待的那种责任感的工具。写代码的尽头永远不是AI替你完成的完美代码而是你作为一个人对一套系统、一群用户、一个业务目标所拥有的独立思考、判断和担当。你以为你在写代码其实你是在构建自己面对复杂世界的能力体系。这个体系的深度才真正定义了你在未来是被淘汰的人还是掌握工具的人。跑了几趟方知路远写了十几年代码才明白代码写得好是手艺想得透彻是本事在两个之间游刃有余才是这个时代给真正技术人的新考卷。祝愿还在焦虑的你早日把这份焦虑转化成实打实的能力增量。