这几年我听到最多的一个词就是“焦虑”，但说实话，程序员这个行业的焦虑从来都不是新鲜事。从移动互联网到大数据，再到区块链和元宇宙，每隔几年就有一波“狼来了”的论调。但是当我仔细审视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替你完成的完美代码，而是你作为一个人，对一套系统、一群用户、一个业务目标所拥有的独立思考、判断和担当。你以为你在写代码，其实你是在构建自己面对复杂世界的能力体系。这个体系的深度，才真正定义了你在未来是被淘汰的人，还是掌握工具的人。
跑了几趟方知路远，写了十几年代码才明白：代码写得好是手艺，想得透彻是本事，在两个之间游刃有余，才是这个时代给真正技术人的新考卷。祝愿还在焦虑的你，早日把这份焦虑转化成实打实的能力增量。
