AI正在消灭中级软件工程师：唯一救命草是工程判断力

2026年，软件工程行业正在被AI工具以前所未有的速度重构。AI编码助手和智能代理让单日代码产出量暴增五倍以上，代码审查队列积压严重，单次合并请求的变动规模动辄超过两万行。

但代码能运行，工程师却解释不清它为何能运行。

系统越来越复杂，错误越来越隐蔽，而最致命的不是代码质量下降，而是整个团队的认知能力正在被AI工具瓦解。同时，旧金山和伦敦的科技公司依然为顶尖工程师支付六位数年薪，却同时大规模裁撤中间层开发者。

这背后隐藏着一个清晰而残酷的逻辑：AI并没有消灭编程，它只是在消灭不需要判断力的那部分岗位。

那个周一的早晨

2026年一个普通周一早晨。你泡好咖啡，打开电脑，代码审查队列里躺着7个待处理的合并请求。

你点开第一个。屏幕显示一行数字：+24506 -3938。两万四千五百零六行新增代码，三千九百三十八行删除。这是一个周末产生的变动量。就在两年前，你休三周假期回来，整个团队攒下的变动也没这么多。现在一个周末就超过了。

在软件工程里，合并请求是工程师提交代码改动时发起的审核请求。代码审查则是团队其他成员检查这些改动是否合理、是否引入错误的过程。这是软件工程最基础的协作单元。2020年你作为团队里最资深的工程师，负责把控代码质量，设定工程规范。你认真审查每个新人提交的代码，确保代码库保持健康。那时你休假回来发现代码乱成一团——有人乱加数据库表，有人为了省事做了反规范化处理，还有人没任何理由就塞进了一套消息队列系统。但至少，你能看懂他们在干什么，能动手修。

现在情况变了。那两万四千行改动的描述栏里，贴着一大段AI自动生成的说明文字！描述流畅、详尽、自信。但你没有时间细看。后面还有6个合并请求在排队。你发现整个团队在三天内完成的工作量，相当于过去好几周的产出。这不是效率提升，这是速度失控。

AI工具让每个人都能瞬间产出大量代码，但代码审查这个环节仍然要靠人脑一个字一个字地过。速度的剪刀差已经形成。

你开始审查那两万行代码！里面层层叠叠套着新的抽象接口，新增了四个你没见过的服务调用，还引入了一个全新的缓存策略。代码能跑——你拉下分支跑了一下测试，功能确实实现了。但你就是说不清它为什么要这么写？你问提交代码的同事，对方发回来一个链接。那是他和AI助手的对话记录，整整15轮来回。在那个对话里，AI先推荐了方案A，然后道歉，改成方案B，同事让AI重新考虑，AI又推荐方案C，再道歉，再改。最后那个被合并的代码，就埋在这堆来回扯皮的某个角落里。

同事们也不再讨论架构决策了。以前大家会围在白板前争论半天，现在各自对着AI代理敲指令/提示词，几个小时后就甩出一个巨大的合并请求。系统正在变成一个没人能完全理解的怪物。

而这种不理解，正在从一个隐患变成日常。

代码不需要被理解吗

“从来没人能完全理解大型系统”——这句话最近越来越多人拿来当挡箭牌。

确实，在微服务和分布式架构流行之后，任何一家中型互联网公司的系统都复杂到没有任何单个人能掌握全貌。但这里有个精微的区别：以前即便你个人不知道某个模块怎么工作的，团队里至少有人知道。你可以去问那个负责这块的人，他会给你讲清楚数据从哪来、经过什么处理、存到哪里去、为什么这么设计。

现在的情况变成了：你问负责这块的人，那个人转头去问AI。AI给出一段滔滔不绝的回答，语气极其自信，但你和你的同事都判断不了这个回答对不对。你问“这个数据到底从哪来的”，同事说“我也不确定，让Claude再解释一遍”。然后你俩盯着屏幕看一大段文本哗哗往外吐，谁也说不清里边哪些是真的，但Claude看着特别笃定。

这就是当前软件工程最吊诡的地方。

AI生成代码的门槛低到尘埃里，但它生成出来的东西，人理解起来反而更难。2020年一个普通工程师一天写一百行代码，这一百行他基本知道每行在干什么。2026年一个工程师一天能指挥AI生成两千行代码，但这两千行里有一半他可能从来没仔细看过。代码被生产出来的速度和它被理解的速度之间，裂开了一道巨大的鸿沟。而这道鸿沟正在被日常化——大家慢慢习惯了“先合进去再说，出了问题再让AI修”。

但问题来了。当系统复杂到谁都不理解时，AI修bug的能力也在急速衰减。你遇到一个诡异的线上报错，这是团队第四次试图修复同一个问题了。你打开那个模块，发现它嵌套了七层调用链，横跨三个不同的服务和两个数据库。没有一个人能说清当初这些层为什么要这么搭。于是你只能把完整的报错日志贴给AI，让它从头分析。AI给了一个方案，你们试着部署，结果把另一个不相关的功能搞挂了。再问，再改。就这么来回折腾。

你开始怀念2020年。那时候即便代码库乱了，至少乱得有迹可循——有人做了个草率的决定，你可以找到做决定的那个人，问他当时怎么想的。而现在做决定的是一段对话历史，是15轮提示词和回复的混合物。那些对话里不存在“当时怎么想的”，只有“AI当时怎么生成的”。这两者之间的差别，就是整场危机的根源。

AI移除了速度限制

AI工具做的第一件事，就是拔掉了软件工程的速度限制器。

时间退回2015年前后。一个工程师要往系统里加一套消息队列，得先写设计文档，跟团队开会讨论，确认真的有性能瓶颈需要引入这么重的组件，然后花一到两周时间慢慢实现、测试、代码审查、灰度发布。这个过程天然地设了一道减速坎。每一步都可能有人拦住你说：等等，我们真的需要这个吗？有没有更简单的办法？

现在这些减速坎全部失效了。

一个工程师对着AI代理说：帮我把这套消息队列集成进去。几个小时后，几百行配置和胶水代码就躺在合并请求里了。代码审查的人面对这几百行改动，背后是一个他从未参与讨论过的架构决策。他要在一杯咖啡的时间里判断这个决策对不对。以前那个决策是两小时会议+三天深思熟虑的结果，现在它是十五分钟提示词工程的产物。

更麻烦的是这种速度带来的错觉。如果你拉下分支运行一下，功能确实能跑通。这在浅层测试层面给了团队一种虚假的安心感：你看，代码能工作，那没问题啊。于是大家继续这么干。一个接一个合并请求被批准、合并、上线。每个单独看似乎都“能工作”，但三个月后系统变成了一个没人认识的怪物。就像一个用信用卡买豪车的人，你只看到车停在门口闪闪发光，看不到每月的债务利息正在悄悄吃掉你的工资。

那些在工程文化本来就不健康的团队里，AI加速的破坏力被放到了最大。一个原本就会乱加依赖的工程师，现在有了AI加持，他能以十倍速度乱加依赖。一个原本就不理解数据库事务隔离级别的程序员，现在能让AI帮他写出花哨的查询语句，然后合并进主分支。代码审查者发现问题的速度，远远赶不上问题被制造出来的速度。

这才是真正的债务。

技术债务这个词在软件工程里指的是为了短期速度而牺牲代码质量和长期可维护性所积累的代价。技术债务不总是坏事，有时你故意走个捷径，快速上线，心里清楚这是权宜之计，打算回头再修。但现在AI生成的债务是隐形的——你根本不知道这里有一笔债，因为代码看起来太工整、太流畅了。AI写代码不会在注释里写“这里我偷懒了”。每一行都长得很体面，像是一个深思熟虑的工程师精心打磨的结果。但大量代码背后没有深思熟虑，只有模式匹配和概率采样。

技术债务也有等级

修一笔AI加速产生的技术债务，比修一笔人工产生的技术债务要麻烦得多。

假设有人花十分钟让AI在数据库里加了三张表和十几个字段。十分钟，搞定。但三个月后，这些表和字段里存满了线上用户的生产数据。这时你发现当初的设计有严重缺陷，字段类型选错了，索引策略完全不合理，查询性能开始拖垮整个服务。

现在你要修它。你不能直接删表，线上几百万条记录在上面。你得写迁移脚本，把老数据转换格式搬到新结构里，还要保证迁移过程中服务不中断，因为用户每秒钟都在用。迁移万一失败了怎么办？你得准备回滚方案，还得确保回滚后不会留下一堆孤立的脏数据。这套迁移方案可能要设计两周，灰度发布再花一周，全量切换又一周。修一个十分钟生成的烂设计，花掉一个月的人工。

而在这一个月里，团队其他成员仍在用AI高速产出新的合并请求。你刚理清一团乱麻，五团新的乱麻已经被合进去了。你追不上这个速度。以前你追的是人，人的产出速度有限，你咬咬牙还能追平。现在你在追一个无限加速的机器，你在跑，它在飞。

更隐晦的代价是认知过载。一个工程师现在一天能指挥AI生成两万行代码。但代码审查者的脑容量和五年前没有任何区别。人的短期工作记忆还是那个狭小的窗口，你一次能装下的代码量就那么多。当合并请求从几百行膨胀到几万行时，审查已经名存实亡了。你扫一眼，觉得大概对，就点批准。因为你没有时间逐行看完，后面还有12个请求在等着。整个代码审查流程正在被洪水冲垮。

那些做重大决策的时刻也被AI稀释了。以前决定引入一个新技术栈要花很长时间斟酌，现在一个周末就能甩出一个完整实现。但实现出来不等于决策正确。你依然需要回答那个老问题：为什么选这个方案而不是那个？为什么现在需要这个而三个月前不需要？这些“为什么”才是工程师值钱的地方。AI能写出实现，但它做不了判断——它只是根据训练数据里的统计规律，给你一个最像“正确答案”的东西，那个东西不一定适合你的系统、你的团队、你的业务。

而现在最可怕的是，那些“为什么”正在从代码库里消失。它们被埋进了AI对话记录里，埋进了15轮来回扯皮的提示词里，没人记得当初为什么选了这条路径，因为连写代码的那个人自己也没完全理解AI为什么会给出这个方案。

谁才是真正被需要的

2026年科技公司的招聘逻辑正在经历一次剧烈翻转。

如果一个公司的需求仅仅是“把需求文档变成能跑的代码”，那这个需求已经被AI极大程度上满足了。为什么旧金山和伦敦的科技公司还要给软件工程师开六位数的年薪？为什么那些声称“软件已被解决”的巨头们，依然在花大价钱争抢最顶尖的那批人？

答案其实很清楚。公司付高薪买的东西变了，从“写代码的能力”变成了“做判断的能力”。判断一个AI生成的方案对不对，判断这个架构在长期会不会拖垮团队，判断什么时候该走捷径、什么时候该死磕质量，判断这个新工具是真正解决问题还是制造更多问题。这些判断力，AI没有，并且短期内不会有。

而判断力这个东西非常稀缺。它不是靠读几本书、刷几道算法题就能获得的。它来自在复杂系统里摸爬滚打多年的经验，来自亲眼见过好决策和坏决策在三年后的不同结局，来自被技术债务反复折磨后的痛感记忆。

所以AI正在做一件非常冷酷的事：它把软件工程师这个职业分成了两层。一层是那些拥有判断力的人，他们手里有了一个超级放大器，AI让他们一天能干过去十天的活；另一层是那些主要靠“写代码”来贡献价值的人，AI把这些人的核心技能商品化了。当你的价值曾经是每天稳定产出两百行可运行代码，而AI现在能以十分之一的时间产出同样数量的代码时，你在就业市场上的议价权就基本消失了。

那个两万行的合并请求里，真正需要人类判断的关键决策点可能只有三到五个。AI处理了剩下九千九百九十五个技术细节。也就是说，那个提交代码的人只是在五个关键路口做了选择，其余全是AI顺着铺的。但如果这五个选择都是错的，整个方向就跑偏了。AI可以铺路，但它选不了方向。

一个团队里如果只有一两个人具备这种选择能力，而其余人都在指挥AI铺路但判断不了方向，那这个团队的结构比十年前更脆弱。十年前，那些判断力稍弱的工程师至少还有一个缓冲期——他们写出烂代码后，会在代码审查环节被拦住，被指出问题，然后慢慢学会更好的做法。现在这个缓冲期被AI的超高速度碾碎了。你今天合进去的一个糊涂设计，明天就变成了整个系统的一个硬骨头，拔不掉、理不清。没有那个“慢慢学”的时间窗口了。

那些已经在用AI高速产出但缺乏判断力的人，面临一个残酷的处境：你的产出看着很光鲜，但每一行都在给团队积累隐形债务。你不是在帮团队前进，你是在帮团队挖坑，而且挖坑的速度远远超过其他人填坑的速度。公司迟早会发现这个账算不过来。那时候被请走的，往往不是那个产出最低的人，而是那个带来最多隐形维护成本的人——即便他看起来非常忙碌、非常高效。

代码审查挡不住洪流

代码审查这个机制，在AI时代正在失灵。

代码审查的本质，是让第二双眼睛在代码合并进主分支之前扫一遍，发现问题、讨论设计、传播知识。这套流程在设计的时候，默认前提是一个人一天大概产出几百行代码。审几百行，认真看，花二十分钟，是合理的。但当你面对一个两万四千行的合并请求时，审完它需要的不再是二十分钟，而是整整两天。而你的队列里有七个这样的请求在排队。

所以大家都在走形式。提交代码的人只是把AI生成的一大坨东西原样贴过来，审查的人点开看看大概思路，觉得功能没错，就点批准。代码审查从“严格把关”变成了“走个流程”。而更糟的是，连提交代码的人自己都没完整读过那两万行。他只是指挥AI做了这件事，AI给了结果，他测试了几个主要场景——能跑，就发了。

当被问到“为什么这里要引入这个新抽象”时，他把AI对话记录甩过来。而这个对话记录长达几十屏，里面AI一会儿说A方案最优，一会儿道歉改成B方案，一会儿同事说你再想想，AI又出了C方案。这个决策过程不是深思熟虑，而是一场随机游走。但代码已经合进去了，并且跑得很顺畅，所以没人有动力去质疑那场随机游走的结果——直到系统开始出一些匪夷所思的bug。

那些bug往往非常诡异。因为不是一个人的逻辑错误，而是AI在多层上下文中做的概率妥协，加上人类粗心的合并操作，再加上多次迭代后无人再碰的遗留代码。三样东西叠在一起，变成了任何人都解不开的谜。

这时你又要去请教AI。AI给了一个新方案。但你没法判断这个新方案会不会引入更诡异的bug，因为你看不懂它为什么这么改。你陷入了一个循环：让AI写代码，代码你读不懂；出bug了，让AI修；修完你又读不懂；如此往复。系统最终变成了一个由AI生成、由AI维护、但人类对内部状态一无所知的黑箱。而这个黑箱正在运行你们的线上业务，收款、发货、存用户数据。

这个局面下，老板如果问“这个系统到底怎么工作的”，你能给出的最诚实的回答是：我不知道，但它的API端点确实返回200状态码。这句回答听起来像个冷笑话，但2026年大量软件团队每天都在用这个笑话掩盖他们的真实处境。这不是效率，这是失控。

两万行之后还剩什么

那两万四千行代码背后，其实只藏着一件事：谁来做最后的判断。

AI可以生成全库表结构，但决定用哪个字段做主键、哪个做外键、数据一致性怎么保证，这需要判断。AI可以写出复杂的查询优化，但针对当前业务的读写模式和访问频率做取舍，这需要判断。AI可以搭出一套完整的微服务治理体系，但在系统刚起步的阶段是否需要这么重的架构，这需要判断。

判断力的本质是区分“这件事现在必须做”和“这件事现在只是能做”。AI没有时间箭头，它只知道给定输入输出一个统计上最可能的中间路径，但它不知道现在是一天中的什么时候、项目处于什么阶段、团队有多少人、明天会不会融资、下个月要不要迎接双十一流量。这些信息不在训练数据里，它们在活生生的现场判断里。

所以那些还在被高价雇佣的工程师，公司买的就是这个“现场判断”的能力。不是会写if-else，是会判断这个if到底该不该写、写在这里还是那里、不写行不行。后者才是今天最稀缺的东西。而前者，AI已经可以按吨批量供应了。

以前两者混在一起，你很难分清谁在提供判断力，谁只是在提供实现能力。因为大家看起来都在写代码。现在AI把所有“实现”部分剥离出去了，剩下的就是赤裸裸的判断力较量。两万五千行AI生成的代码一旦躺进代码库，那个点了“合并”按钮的人，就是在用自己的判断力为这两万五千行背书。他能背得动多少，决定了他值多少钱。

而那些背不动的人——他们要么根本不知道自己背了什么，要么知道但无力改变——正在从软件工程的中产阶层里被挤出去。这个阶层以前是安全的，他们不需要成为最顶尖的架构师，但只要能稳定产出可工作、可理解的代码，就能拿到体面的薪水。现在AI把“产出可工作代码”这个事变得太便宜了。稳定产出的市场价急剧下跌，唯一还在涨价的只剩下判断力本身。

AI没有消灭软件工程师这个职业。它只是在用一种冷酷的方式重新定价：如果你只能贡献AI已经能贡献的那部分价值，那你的价格会向零靠拢；如果你能贡献AI永远贡献不了的那部分判断，那你的价格会飞涨。中间地带正在消失。

2026年的那个周一早晨，你在七份合并请求面前坐着。每一份都是两万多行的AI生成物。每一份都功能完整。但没有一份你能安心看完。你突然意识到，你的新岗位已经不是“代码审查者”，而是“AI的保姆”——帮AI纠正它做的荒谬决策，替AI向业务方解释那些连你自己都不完全理解的逻辑，在AI撒完谎之后替它擦屁股。这份工比以前更难打，因为你面对的不再是一个想写好代码但能力不够的新人，而是一个没有任何意图、只是靠统计学猜答案、还永远自信心爆棚的黑盒机器。

这场游戏的规则变了。速度限制被撤掉了，减速带被铲平了，所有人都在狂飙。但终局只有一个问题：当车彻底失控的时候，坐在驾驶座上的人有没有能力把方向盘抢回来。能抢回来的人，会变得前所未有地值钱。抢不回来的，两万行代码就是他们留给这个行业的最后一封告别信。

软件工程的中产阶层正在消失。剩下的人站到了悬崖的两边——一边在飞，一边在坠落。

Hacker News 上关于“AI正在淘汰软件工程中产阶级”一文的讨论非常热烈，评论总数超过550条。

总体来看，评论区普遍认同原文的核心观察：AI极大地加速了“坏”工程师造成破坏的速度，同时也显著提高了对“好”工程师判断力的要求。

讨论主要集中在以下几个维度，观点涵盖了从共情、辩护到批判和未来预测：

1.  对“坏工程师被AI放大”的强烈共鸣

•  大量评论者分享了亲身经历，印证了原文描述的“AI生成海量代码导致系统迅速腐烂”的场景。他们指出，过去一名能力不足的工程师需要很久才能制造出问题，现在借助AI，一个周末就能生成数万行难以维护的“垃圾代码”，让整个团队陷入审查和修复的泥潭。
•  许多评论者认为，问题不仅在于“坏”工程师，更在于那些对工作失去热情、只求完成任务的资深工程师。他们将决策外包给AI，与AI形成了“共谋”关系，加速了项目的崩塌。

2.  对“入门级岗位消失与人才培养断层”的深切担忧

•  一个核心共识是，AI工具正在消灭初级和中级岗位，这不仅影响了当下的就业，更切断了未来高级工程师的培养管道。新手失去了通过写代码、犯错误和接受前辈指导来积累经验的机会。
•  有评论将这与历史上CAD软件对机械工程的影响相类比：初级绘图工作被自动化，行业门槛被提高。他们预测软件工程最终也会要求更高的学位（如硕士或博士），才能从事核心工作。

3.  对“优秀工程师价值提升，但技能也会退化”的辩证讨论

•   一方面，评论普遍认为AI是“放大器”，能让优秀的工程师效率倍增，因此他们变得更有价值。那些只懂执行、不思考的“中间层”工程师最容易被淘汰。
•  另一方面，也有尖锐观点指出，即使是优秀工程师，如果长期依赖AI进行规划、编写和分析，他们的核心能力——理解复杂系统——也在悄然退化。他们离真正理解系统的距离，并不比那些“中间层”工程师远多少。

4.  对“监管、职业化与行业历史”的延伸思考

• 部分评论将话题引向软件工程师是否应像律师、医生一样实行职业资格认证。支持者认为这能提高责任门槛，防止AI酿成大祸；反对者则认为这只会增加官僚主义，且效果存疑。
• 多位老工程师将当前现象与过去的技术浪潮（如互联网泡沫、外包浪潮）对比，认为每次行业危机后都会催生新的机会，现在的恐慌与当年并无本质不同。