1. 未来两年行业到底在淘汰什么样的人1.1 一个让人睡不着的会议上个月参加了一个内部技术规划会散会之后和一个工作五年的老同事在楼下抽烟。他说了句话让我记到现在我忽然发现自己引以为傲的CRUD熟练度好像快要没有意义了。他不是在矫情。过去半年组里陆续上了AI辅助编码工具简单业务需求的交付速度起码快了一倍。以前一个后端接口从建模到联调要两天现在半天就能跑通。老板在会上问了一句很扎心的话那我们要这么多写接口的人干什么这个问题其实就是软件工程未来两年的核心命题。它不是某个新框架的发布不是某个新语言的流行而是一整个生产方式的底层变化。所有还在写代码的人不管你是刚入行的应届生还是干了十年的老开发都得回答一个问题当工具越来越强我的不可替代性到底在哪这篇内容就是围绕这个命题展开的。我会从技术栈、工程能力、学习路径、职业定位四个角度说说未来两年软件工程师怎么调整自己的方向哪些东西要赶紧补哪些东西可以放心放下。1.2 被淘汰的不是程序员这个职业而是只会按需求搬砖的工作方式先说一个观点软件工程作为一个行业不会消失未来两年消失的是一批特定工作方式的人。什么叫按需求搬砖就是拿到需求照着文档写代码写完提测改bug上线等下一个需求。这种工作方式的特征是——你只负责把需求翻译成代码不负责判断需求是否合理不负责设计方案是否最优不负责上线之后系统是否稳定。以前这套模式能跑通是因为把需求翻译成代码本身有门槛。你得懂框架、懂数据库、懂接口协议光学习成本就劝退了一大批人。但现在不一样了AI编码助手把翻译门槛拉得非常低。你跟它说清楚上下文它能给你生成一大段结构完整的代码。这周我们组有个实习生来公司之前几乎没写过Java靠AI辅助硬是三天完成了一个报表模块的后端开发。这件事让我意识到翻译需求正在变成一种廉价能力。当廉价能力被工具替代剩下真正值钱的是需求之上的东西知道为什么要这么做——能判断需求背后的业务价值知道不这么做会怎样——能预见技术方案的长期后果知道出了问题怎么查——能在系统异常时快速定位根因知道怎么让团队更快——能优化整个研发流程而不只是自己手速这些能力AI暂时给不了你。它能在你提问的时候给出答案但前提是你得会提问。而会提问恰恰需要你对系统、业务、代码有真正的理解。1.3 招聘市场的信号从会什么框架到能交付什么结果我最近帮朋友公司筛了一批简历感受特别明显。两年前的简历大家写的是熟悉Spring Cloud微服务体系熟练使用Redis、MQ有三年订单系统开发经验——全是技术栈罗列。现在不一样了。同样三年的简历开始出现这种描述负责订单链路性能优化QPS从800提升到5000主导了支付模块的稳定性治理线上故障率下降60%搭建了一套自动化测试体系版本回归时间从2天缩短到4小时。这种变化背后是招聘逻辑的转变。框架人人都会用AI更是随手就能生成。但**把系统做成什么样解决了什么实际问题带来了什么可量化的结果——这些才是机器替代不了的东西。** 未来两年简历上技术栈的名字会越来越不值钱描述结果的能力会越来越值钱。对还在学校里的人这个信号同样重要。很多软件工程专业的同学问我毕业论文怎么选题、毕业设计做什么方向我的建议从来都是不要选一个实现XX系统的题目要选一个解决XX问题的题目。前者是搬砖后者才有工程价值。这个区别后面我会单独展开说。2. AI辅助编程之后纯编码技能还剩多少价值2.1 编码工具到底改变了什么先别急着一味焦虑。我用了大半年的AI辅助编程工具实事求是的结论是它改变的是编码环节的效率不是整个软件工程的价值链路。一个完整的软件交付流程大致是需求分析→方案设计→编码实现→测试验证→部署上线→监控运维。编码只是其中一环而且从来不是最贵的一环。真正的成本藏在需求反复、设计返工、线上故障、运维救火这些地方。AI解决的是编码实现这一环的提速。它让你从一个需求到一段可用代码之间的时间变短但不改变你知不知道这个需求该不该做这个方案靠不靠谱这个系统上线后稳不稳定这些更上位的问题。打个比方以前盖一栋楼砌墙师傅很重要因为砌墙又慢又累墙砌不好楼就歪。现在发明了一种自动砌墙机墙砌得又快又直。结果你发现真正决定这栋楼价值的是图纸设计、结构计算、材料选择、施工管理——从来不是砌墙本身。砌墙师傅不会消失但只把自己定位成砌墙的人竞争力确实在下降。对软件工程师来说这个道理一模一样。你不是写代码的人你是用工程手段解决问题的人。代码只是你的表达方式问题解决才是你的价值。2.2 代码审查与重构能力成为新的分水岭AI写代码有一个典型特征它写出来的东西语法是对的逻辑是通的但风格是乱的边界是模糊的长期维护性是不确定的。我让AI帮我生成过一个订单状态机转换的模块。代码本身跑通了单测也过了但等我人肉review的时候发现两个问题第一它用了一个全局变量来缓存中间状态并发情况下会有数据竞争隐患第二异常分支处理得太笼统所有异常都被吞成了同一个错误码出了问题根本没法排查。这个经历告诉我AI生成代码的能力越强代码审查能力就越值钱。因为它会把大量看起来能用但经不起深究的代码交到你手上而分辨这些代码是否真正合格需要的是对并发、事务、缓存一致性、异常处理这些底层原理的深刻理解。我在团队里给新人做指导的时候常说一句话别急着让AI帮你写代码先让它帮你review你写的代码。你把自己的实现贴进去问它这个方案有没有边界问题这个写法有没有更好的替代你会发现AI给出的建议往往能帮你打开思路。当你具备批评AI输出的能力时你就从被工具替代的人变成了驾驭工具的人。代码重构也是同样的逻辑。AI能重构一个函数能提取一个公共方法但它不知道你的业务上下文不知道哪些模块即将被替换不知道你的性能瓶颈在哪。重构方向的判断、重构范围的划定、重构风险的评估这些还是要靠人。未来两年能不能安全地改代码和能不能干净地写代码会变成两种完全不同的定价。2.3 提示词工程与上下文管理给AI当导演而不是打字员说一个经常被低估的技能提示词工程。很多人用AI编码工具方式是把需求描述往对话框里一贴回车等结果。出来的代码往往离题万里于是得出结论AI写代码不行。我的经验是AI编码工具的能力上限很大程度上取决于你给它多少高质量上下文。同样是写一个用户登录接口你直接说写一个登录接口和你给它这是一个Spring Boot项目登录接口需要支持用户名密码和手机验证码两种方式需要校验账号锁定状态失败超过5次锁定30分钟需要返回统一响应体CommonResult项目里已有的用户表结构是xxxx请基于以上信息实现UserController中的login方法——出来的代码质量天差地别。这背后涉及一个能力上下文管理。你要能说清楚业务背景、技术约束、边界条件、验收标准AI才能生成贴合实际的代码。这种能力本质上还是你对业务和系统的理解深度。这里有个常用的上下文模板我贴在下面供参考上下文要素示例项目背景这是一个电商交易系统订单模块采用Spring Boot MyBatis Plus功能目标实现订单取消功能超时未支付订单自动取消并释放库存技术约束数据库使用MySQL缓存使用Redis接口需要幂等边界条件订单状态为已支付/已发货时不允许取消取消需要记录操作日志验收标准单测覆盖取消成功/取消失败/重复取消三种场景5分钟写好这段上下文比你反复调教对话30分钟要高效得多。未来两年能把话说清楚会变成一个硬技能。以前这个技能用来给产品经理提意见现在这个技能用来给AI提需求。本质没有变都是通过准确表达来获得正确的结果。3. 软技能的硬价值用例设计、边界思考与需求辨析3.1 从用例图说起为什么画图能力突然重要热搜词里有头歌软件工程用例图头歌软件工程画图大概很多学生正在被软件工程导论里的UML用例图折磨。我当年也一样觉得画用例图是应付作业的形式主义。直到我工作第三年接手一个订单退货流程重构项目才意识到当年没好好学的图论思维其实是工程沟通的地基。UML用例图的核心是两件事识别参与者Actor识别用例Use Case。翻译成大白话就是——搞清楚谁会跟这个系统交互交互的每一种场景是什么。我见过太多代码返工的案例根本原因就是参与者没认全。举个例子做一个后台管理系统的内容审核功能。你以为参与者只有审核员一个人。但你仔细想——还有管理员要查看审核记录、被审核用户要看审核不通过的原因、客服要催办未审核的内容。每一种参与者对应一套不同的用例、不同的页面、不同的接口。漏掉任何一个上线之后就是返工。现在有了AI编码工具这种返工成本被放大了。因为AI是根据你的需求描述生成代码的你的需求描述里如果漏掉了某个参与者它会一本正经地把那个用例做成一个没有权限校验的后门接口。你需求想得越糙AI给你埋的雷越多。所以在未来两年用例设计这种基础能力不仅没被淘汰反而因为AI的放大效应变得更加重要。我建议每个软件工程专业的学生尤其是正在做课程设计和毕业设计的同学别跳过画图这一步。你画用例图、画E-R图、画时序图的过程就是你在给未来两年的自己省debug时间的过程。图不是画给老师看的是画给自己的思考框架。3.2 性能测试与可观测性未来两年必须补的短板热搜词里有一条GB/T 39788-2021《系统与软件工程 性能测试方法》这条进了软件工程领域的热词榜有意思。它说明了性能测试正在从高级话题变成基础要求。过去很多团队的节奏是功能上线能跑就行。性能问题等到用户投诉了、老板怒了、系统崩了的时候再处理。这种模式在业务扩张期勉强能撑但在未来两年会越来越危险。原因很简单AI让代码生成变快了业务需求迭代变快了系统变更频率变高了性能问题的暴露速度也会变快。未来两年我判断性能意识会成为一种基本的工程素养。你不用精通LoadRunner那种重型工具但你至少要知道压测怎么设计场景并发数、持续时长、峰值流量模型知道看什么指标RT响应时间、QPS/TPS、错误率、CPU/内存/磁盘IO知道怎么定位瓶颈是数据库慢查询是缓存命中率低是线程池打满还是网络带宽受限知道怎么给结果下结论这个系统到底能扛多大的流量需不需要扩容这里要给做毕业设计的同学一个非常具体的建议如果你的课题是XX系统的设计与实现强烈建议在论文里加一章系统性能测试。哪怕只是用JMeter做一个简单的并发压测画一张QPS和RT的曲线图论文的工程价值就会明显上一个档次。因为大多数本科毕业设计只做到了能跑做到可测的非常少。性能问题还有一层可观测性。也就是系统出了问题你能不能快速定位。我见过太多系统日志一坨浆糊、监控面板空白、告警规则靠拍脑袋。结果线上出故障了一堆人围着服务器敲命令像无头苍蝇一样。这种排队查日志的场面在未来两年会越来越不被容忍。3.3 需求沟通与验收标准避免代码写完才发现问题我有一次印象深刻的经历。一个产品经理要给会员体系加一个积分逾期清零的功能需求文档写得很简单每月1号清理过期积分。我们技术团队花了两天做完了结果验收的时候发现一堆问题是清理全部过期积分还是部分过期积分积分有剩余和冻结两种状态要不要区别处理清理动作发生在凌晨如果数据库正在做备份怎么办清理结束之后要不要通知用户通知渠道是短信还是站内信如果用户当时有正在进行中的订单积分被清掉了会不会造成客诉这些问题需求文档里一个都没写。我们只能一个一个去找产品经理确认每确认一个就要改一轮代码。本来两天的活最后拖了一周。这个案例说明需求不明确从来不是产品经理一个人的问题工程师也有责任。未来两年AI能把代码写得飞快但如果你不去追问需求边界AI只会帮你在错误的方向上做得更快。所以需求辨析能力会成为工程师的核心竞争力之一——不是被动地接需求而是主动把需求问到可执行、可验证、可测试的程度。具体操作上我有个习惯接到任何一个需求先写一个验收条件清单。列出这个功能做出来之后必须满足哪些条件才算完成。条件写得越具体后面返工越少。比如上面那个积分清理的功能验收清单可以是所有逾期且未冻结的积分在每月1日凌晨被清零冻结中的积分不清零解冻后若已逾期则立即清零清理操作有完整的日志记录清理完成后发送站内信通知用户清理过程中的系统性能不受影响这个清单既是你开发的指引也是你和产品经理对齐的契约。在我个人经验里未来两年工程师之间拼的不再是谁代码写得快而是谁能在开工之前把问题想得足够透。代码可以由AI生成但验收清单AI给你生成不了因为清单背后是对业务的理解和对风险的预判。4. 面向未来两年的个人学习路线4.1 算法与数据结构之外还要学成本思维现在很多人一提到学习路线第一反应是刷LeetCode、学新框架、看源码。这些当然有价值但如果你想在未来两年这个时间窗口里建立不可替代性我建议把精力重新分配一下。算法与数据结构是基础中的基础这个没有争议。但单纯会写算法题和能在工程里做出好的技术决策中间还隔着一个东西成本思维。举个例子一个电商后台的订单列表页需求是支持按时间、状态、金额筛选。刚毕业的我可能会想这还不简单写一个动态SQL把筛选条件拼进去就行。但如果你有成本思维你会先问几个问题订单表数据量多大分页深了会不会慢筛选字段有没有索引要不要走ES当前数据库连接池的压力如何与其在慢SQL出现之后优化不如在设计阶段就把方案选对。成本思维的本质是对每一行代码的代价有感觉这段逻辑放数据库算还是放应用层算这个数据是实时查还是缓存这条消息是同步发还是异步发这些决策AI不理解你的系统全貌做不了。我给一个相对具体的学习建议把SQL索引机制搞清楚。建索引、联合索引最左匹配、覆盖索引、回表这些概念比背十种设计模式有用学一下缓存的基本套路。缓存穿透、缓存击穿、缓存雪崩每个都配一个真实场景能讲明白来龙去脉理解异步化。消息队列在系统里到底解决了什么问题削峰填谷是什么意思为什么分布式系统绕不开这个这些内容不是高级架构师才需要学的而是未来两年普通后端开发也要掌握的成本常识。因为当AI帮你把实现代码写完你需要的是判断哪个实现方案更经济、更稳健、更符合系统当前所处的阶段。4.2 测试思维从写完代码到证明代码是对的另一个我要强烈建议大部分人补的方向测试。我说的测试不单指会写单元测试、会用JUnit或pytest而是一种验证思维。未来两年AI生成代码的速度越来越快但代码质量参差不齐验证的环节会变得越来越关键。谁能更快更准地验证一个实现是否满足需求谁就能在团队里拿到更高的议价权。我建议软件工程的学生和初级开发者把学习和练习测试当作一个正式项目来做。具体来说至少精通一种单元测试框架Java生态就JUnit MockitoPython生态就pytest mock学会写接口集成测试不光是单测要能把一个模块从入口到数据库完整地跑一遍理解测试金字塔底层单元测试数量最多往上接口测试减少最上层端到端测试最少有条件的话接触一下自动化回归把核心链路的用例自动化每次发版自动跑在软件工程专业的毕业设计里如果一个系统能附带一套像样的测试用例说明作者真正理解了工程二字。绝大多数毕业设计只有实现没有验证你做出来了验证质量自然就超过平均水平了。热搜词里有python软件工程说明很多人学软件工程会搭配Python。那我多说一句Python生态里做工程化验证pytest unittest.mock 是关键组合。很多学生学Python只学到能用requests调API、能用pandas处理数据但工程上的核心是能证明你的处理逻辑是对的——这就要靠测试思维。4.3 毕业设计与课程项目怎么把作业变成作品热搜词里好几个都是关于毕业论文选题、课程设计、头歌作业的说明学生群体占比不小。作为一个看过不少简历、也面试过不少应届生的人我特别想给这个群体说一段话你的毕业设计是你求职时最能证明工程能力的一块敲门砖。但前提是它得看起来像一个作品而不是一个作业。什么叫作业选题是基于Java的图书管理系统有登录、增删改查、一个MySQL数据库页面用了Bootstrap论文里贴几张截图。这种项目每年全国毕业设计里至少有几万个招聘官看到标题就知道内容是什么。什么叫作品同样是图书管理系统你可以升级成面向校园的二手图书交易平台加上用户信用体系、订单状态机、消息通知、性能压测、自动化部署。或者换个思路做一个基于协同过滤的图书推荐子模块把问题聚焦在一个点上做出深度。关于毕业论文选题我有个直接的建议选题的最好策略是小切口、深挖掘。与其做一个超市管理系统不如做一个超市会员积分系统的设计与实现——基于Spring Boot和Redis缓存方案。题目越小你越容易在某一个点上做到别人做不到的深度导师也越容易给高分。还有一个细节建议毕业设计里一定要有问题与解决的记录。什么东西曾经搞不定你是怎么排查的最后怎么解决的——这一部分口述出来比贴十页代码都管用。面试官最爱问这类问题因为这里面藏着真实的工程思维。5. 职业定位与决策未来两年具体怎么走5.1 深耕一个行业领域比追逐技术潮流更抗淘汰聊完学习聊聊职业选择。未来两年技术圈最大的噪音就是新工具、新框架层出不穷。今天这个LLM框架明天那个Agent平台追是追不完的。我的判断是与其横向追新技术不如纵向深耕一个行业领域。技术在变但行业问题是不变的。金融领域要解决的是并发、安全、合规电商领域要解决的是大促秒杀、库存一致性、推荐精准度医疗领域要解决的是数据孤岛、隐私保护、系统集成。一个深耕电商订单领域五年的工程师和一个追着新技术跑五年的工程师遇到大促秒杀时如何保证库存不超卖这个问题前者的经验值是无价的。AI可以告诉你分布式锁有几种实现方式但它不知道你们公司实际的库存扣减流程、不知道订单和支付的对账链路、不知道历史上出过哪些灰度发布事故。这些场景经验AI给不了。所以如果你想在未来两年稳一点请认真想一想你所在的行业最核心的那个业务痛点是什么你在解决的是不是那个痛点附近的问题如果是你就是安全的。如果不是你只是在做一个随时可以被人和AI替代的翻译官。5.2 内卷时代的外向价值让工作成果被看见工作五六年、技术不错但晋升停滞的人往往不是输在技术上而是输在成果没有显性化。我见过很多勤恳的老开发业务理解深、代码质量高、团队离不开他。但每次绩效评审他的manager只能用踏实肯干、交付稳定这种词来形容他听起来没有任何冲击力。而另一个同事技术可能不如他但每次做完事情都会主动同步结果性能提升了多少、故障率降了多少、效率提高了多少全部用数据说话。未来两年当AI让完成需求变得更轻松时完成度的价值会下降影响力和可见度的价值会上升。你要学会把自己的工作成果转变成别人能感知到的东西。我不太喜欢向上管理这个词但把工作成果讲清楚本来就是职业素养的一部分。具体怎么做从最小的地方开始每次性能优化、稳定性治理结束之后写一份简短的复盘文档把优化前和优化后的数据对比放上去在团队内部做一次技术分享讲讲你不会的问题是怎么被解决的而不是怎么被解决的这一步代码长什么样把一次踩坑经历写成一篇文章发布到社区既帮助你梳理思路也能让更多同行看到你这不是教你作秀而是说你做了十分有价值的工作如果表达不出来那在职业市场上就是零分。酒香也怕巷子深这个道理在软件工程行业一样成立。5.3 面试里的交付证据链未来两年最大的求职优势最后聊一个很实操的话题面试。未来两年面试软件工程师如果候选人还在背八股文——Spring事务传播机制有哪几种、HashMap的底层结构是什么——我会觉得非常失望。不是说这些不重要而是这些知识AI都能秒答你作为候选人得让我看到AI给不了的东西。我给的建议是每一次重要项目经历都要准备一个交付证据链。这个词是我自己想出来的意思是你能围绕一个项目讲清楚四件事背景当时系统/业务处于什么状态为什么要做这个项目问题你具体负责解决什么问题有没有依赖别人有没有被坑过动作你做了哪些关键决策为什么选A方案而不是B方案有没有考虑过C方案结果做完之后有没有数字可以证明变好了有没有遗留问题拿毕业设计举例。你可以说我的毕设是校园二手书交易平台。当时我面临的核心问题是线下交易缺乏信任机制所以我设计了实名认证信用评分体系。技术上我采用了Redis来缓存热门书籍列表把首页响应时间从800ms降到了200ms。过程中遇到最大的坑是Redis缓存和数据库的一致性问题我最终采用了Cache Aside Pattern加延迟双删的策略并且在实验部分对比了三种不同方案的数据。这套话术讲下来面试官听到的就不是我做了个毕设而是这个人具备完整的工程思维链路。未来两年AI会填平大部分人的技术下限但填不平你把一件事想透、做完、讲清的能力上限。这才是真正的护城河。写在最后回到开头那个会议室。那次会议之后我没急着去追各种新的AI框架而是做了一件看起来很低调的事把我们老系统里最核心的两张表的索引和慢SQL全部重写了一遍然后把优化的结果用数据表发给了全组。老板看到之后在周会上点名说了一句这种工作很有价值。我当时心里特别平静。因为那一刻我确认了一件事与其担心被AI取代不如把自己变成那个更会定义问题和验证答案的人。AI是答案生成器而软件工程的未来两年稀缺的是问题定义者、方案决策者和质量守门人。最后分享一个再小不过的习惯每天抽二十分钟不看任何技术文章就盯着自己最近写的代码想想如果这个模块未来要支撑十倍流量我会怎么改。这个习惯是我觉得这两年我做过最有用的事情。希望你也能找到一个属于自己的支点在这个变化极快的行业里站稳脚跟。