1. 软件工程的自动化浪潮从手工艺到基础设施的必然之路最近和几个在头部大厂干了十几年的老同事聊天话题总绕不开一个词焦虑。不是对业务增长的焦虑而是对自身角色价值的焦虑。一个在阿里做P8的朋友说他团队里新来的校招生靠着GitHub Copilot和通义灵码一周就能搭出一个以前需要一个月才能搞定的基础服务框架。另一个在字节带基础架构团队的老哥更直接“现在招人我们更看重系统设计和故障排查的深度经验单纯‘能写代码’已经不够看了因为AI写得又快又标准。”这让我想起了EE Times上那篇观点犀利的文章以及Block原Square裁掉近一半员工的新闻。文章里把软件工程的发展轨迹类比成纺织、机械制造等传统行业的演进史发现、专业化、商品化、自动化。这个类比非常精准也戳中了很多从业者的痛点。我们这行正处在从“专业化”向“商品化”和“自动化”猛烈冲刺的阶段。早期程序员是稀缺的“神职人员”需要手搓机器码、理解每一个硬件时钟周期。后来有了高级语言、框架、云服务编程的门槛一降再降。到今天AI代码助手正在把许多初级、重复的编码任务变成一种按需生成的“标准件”。这个过程不会让软件消失就像缝纫机没有消灭衣服反而让服装产量暴增。但它的确在重塑价值链条编码Coding本身正在贬值而理解Understanding、设计Designing和整合Integrating的价值在飙升。未来的软件工程师可能不再是一个主要“写代码”的人而是一个“定义问题、选择工具、监督AI生成、并确保整个系统在复杂现实中可靠运行”的解决方案架构师和系统医生。这篇文章我就结合自己这些年的观察和踩过的坑聊聊在这个自动化浪潮里我们这些“手艺人”该如何自处以及哪些能力会变得真正稀缺。2. 历史镜鉴软件工程如何重走传统工业的老路要看清未来最好的方式是回顾历史。文章里提到了一个经典案例1860年纽黑文的一家衬衫工厂用400台缝纫机替换了1600名女裁缝周产量却持平。这个故事的结局不是服装业的消亡而是需求持续增长同时“熟练手缝”这项技能的高溢价消失了。软件工程正在经历几乎一模一样的剧本。2.1 行会时代1950s-1970s稀缺的“祭司”早期的程序员是真正的硬核极客。他们面对的是赤裸的硬件通过面板开关输入二进制指令或者在一叠叠穿孔卡片上打孔。那时候编程需要极其深刻的“第一性原理”知识内存布局、寄存器状态、指令周期、甚至电流时序。一个字节都不能错因为调试可能意味着用示波器去追踪物理信号。这个阶段的程序员像建造大教堂的石匠掌握着近乎神秘的知识数量稀少薪酬极高。他们的工作成果是直接作用于物理世界的“魔法”。我的体会是这个阶段的核心价值在于“对机器的绝对掌控”。虽然我们早已不用打孔卡但那种对底层原理的敬畏和追求是工程师精神的源头。我认识一些从那个时代走过来的前辈他们解决问题的思路往往直指本质这种思维模式在如今黑盒化的时代尤为珍贵。2.2 专业化时代1980s-2010s从手艺到科学随着C、C、Java等高级语言的普及以及计算机科学成为一门正式学科软件工程进入了专业化阶段。大学设立了标准的CS课程设计模式、数据结构、算法成了必修课。集成开发环境IDE的出现让编写、编译、调试变得一体化。这个阶段编程从一门“手艺”变成了一门可以教授和标准化的“工程科学”。然而专业化也带来了抽象层的增厚。垃圾回收机制让程序员不必手动管理每一寸内存操作系统内核封装了复杂的硬件交互各种框架如Spring, Django, React提供了构建应用的标准化“乐高积木”。生产效率大幅提升但代价是很多从业者与底层硬件隔了一层甚至数层“毛玻璃”。我面试过很多培训班出来的候选人能熟练使用Vue组件和Spring Boot注解但被问到“浏览器输入URL到页面展示发生了什么”或者“Java虚拟机的垃圾回收器如何工作”时往往一脸茫然。这不是他们的错而是教育和工作场景的导向使然——市场需要快速产出应用的人。注意这里存在一个巨大的认知陷阱。很多人认为“会用框架”就等于“会软件工程”。这就像会开自动挡汽车不等于懂得内燃机原理。在风平浪静时这没问题。但当系统出现诡异的性能瓶颈或难以复现的故障时缺乏底层知识的人往往只能束手无策或者进行盲目的、试错式的排查。2.3 商品化时代2010s-至今框架的盛宴与价值的扁平化这是我们现在身处的阶段。开源生态空前繁荣GitHub、Stack Overflow成了标配的“外接大脑”。几乎任何业务需求都能找到现成的库或框架。开发一个电商网站有Shopify、Magento的开源方案或者用现成的微服务架构拼装。需要机器学习模型TensorFlow、PyTorch加上预训练模型几行代码就能跑起来。商品化的最大特征是“可替代性”增强。当开发工作变成了主要是在配置文件里填参数以及把各种开源组件用API粘合起来时单个开发者的独特价值就被稀释了。企业不再需要为一个“能写CRUD增删改查接口”的工程师支付高昂的溢价因为市场上供给充足且产出同质化。文章里提到的数据很能说明问题美国入门级软件岗位在2023至2025年间减少了35%。公司们认为这部分工作可以由更少的人借助更高效的工具包括AI来完成。我亲身经历的一个转折点几年前我们团队评估是否要自研一个分布式任务调度系统。经过调研我们发现市面上至少有五六个成熟的开源方案如Airflow, DolphinScheduler, XXL-JOB能满足80%的需求。最终我们选择了一个进行二次开发。这意味着原本可能需要一个5人团队干半年的项目变成了2个人花两个月做集成和定制。节省了成本但也让团队里三位专注于中间件开发的同事不得不转型。2.4 自动化时代现在进行时AI作为终极抽象层如果说框架是把通用功能封装成库那么AI代码助手如GitHub Copilot、通义灵码、Amazon CodeWhisperer则是试图把“意图”直接映射成“实现”。你写一段注释描述功能AI就能生成大段的代码你遇到一个错误AI能给出修复建议甚至你画个草图AI能帮你生成前端界面代码。文章引用Stack Overflow的调查显示76%的开发者已经在使用或计划使用AI编码助手。但同时38%的开发者报告说这些工具至少有一半时间会给出错误答案。这恰恰说明了AI在当前阶段的定位一个强大但并非全知全能的“初级搭档”。它能极大提升编写样板代码、完成简单任务、查找API用法的效率但在需要深度上下文理解、复杂系统设计、以及涉及模糊业务逻辑的场景下依然力有不逮。然而管理层的视角往往是另一回事。Block的裁员就是一个强烈的信号。其CFO明确表示重组后的公司将“依靠更小、更高才华的团队使用AI来自动化更多工作”。这背后的逻辑很清晰如果AI能处理大量常规编码、测试用例生成、文档编写甚至初级调试工作那么公司为何还要维持一个庞大的、以执行这些任务为主的工程师团队呢价值将向两端聚集一端是能定义战略、设计复杂系统、解决棘手问题的顶尖高手另一端则是被AI工具武装起来的、人数更少的“执行单元”。3. 现实冲击当自动化成为裁员理由——Block案例深度拆解Block前身为Square由Twitter联合创始人杰克·多西创立在2026年初的裁员不是一个普通的互联网公司“降本增效”故事而是一个标志性事件。它清晰地展示了自动化尤其是AI如何从“生产力工具”演变为“组织结构重构的核心依据”。3.1 决策逻辑主动重构而非被动反应多西在股东信中的解释非常值得玩味。他说他本可以选择渐进式裁员但最终决定采取“强硬、清晰的行动”因为“一轮又一轮的裁员会摧毁士气、专注度以及客户和股东对我们领导能力的信任”。他进一步预测大多数公司将在一年内得出同样的结论。这透露了几个关键信息** inevitability必然性**管理层认为由于AI等自动化技术的成熟现有规模的团队结构已经变得低效甚至多余裁员不是周期性的调整而是面向未来的必然重组。Proactive主动性与其被市场或竞争对手逼着改变不如自己先动手。这赋予了裁员一种“战略升级”的正当性外壳。Talent Density人才密度CFO提到的“更小、更高才华的团队”是核心。公司不再追求人数规模而是追求单位人才的价值产出。AI被视作“力量倍增器”让顶尖人才的作用进一步放大。3.2 行业反应与个人启示知名科技投资者巴拉吉·斯里尼瓦桑将此举称为“第一次AI驱动的裁员”并警告这将“在整个行业引发冲击波”。他的建议简单粗暴“现在就变得优秀。变得不可或缺。熬夜加班学习。掌握AI工具提升你的水平。”这番话虽然残酷但点明了个人在自动化浪潮下的生存法则差异化。当编码能力被商品化和部分自动化时你必须拥有AI难以替代的“超能力”。对于工程师而言这意味着超越代码实现的理解力不仅要懂“怎么做”How更要深究“为什么这么做”Why以及“换了环境会怎样”What if。例如AI可以生成一个使用Redis缓存的代码片段但它无法告诉你在你这套特定业务数据模型和访问模式下是应该用String类型还是Hash类型缓存失效策略如何设计才能平衡一致性和性能以及在缓存集群发生脑裂时如何避免数据库被击穿。系统级的掌控力当所有组件都是开源或AI生成时整个系统的稳定性、性能、安全性就取决于那个能看清全貌的人。你需要理解从用户请求到数据库查询中间经过的每一个环节网关、负载均衡、服务网格、容器、虚拟机、物理机可能出现的故障模式并设计出弹性应对的方案。跨领域的整合力纯粹的软件问题越来越少。大部分高价值问题都处在软件与另一个领域的交叉点比如自动驾驶软件车辆控制传感器融合、量化金融软件市场微观结构、生物信息学软件基因序列分析。在这些领域AI可以辅助写代码但无法定义问题边界和约束条件。一个我经历过的教训我们曾有一个项目需要处理海量的时序数据。团队年轻工程师很快用AI助手生成了使用某流行时序数据库的代码初期测试性能很好。上线后不久在某个业务高峰时段集群突然整体响应迟缓。大家花了大量时间排查应用代码无果。最后还是一位有硬件和操作系统背景的资深工程师通过分析监控发现是磁盘的IOPS达到了瓶颈而数据库的默认压缩算法在那种数据模式下导致了异常的写放大。他调整了存储策略和压缩算法后问题解决。这件事告诉我们在自动化工具给你“最佳实践”代码的同时也可能给你埋下了对特定环境不适配的“地雷”。排雷的能力在AI时代反而更贵了。4. 未来图谱在自动化浪潮中什么能力会持续稀缺软件工程不会消失但它的内涵和重心正在发生迁移。价值从“生产代码”向“定义问题、确保系统在真实世界中可靠运行”转移。以下几个方向的能力我认为会变得越来越稀缺和重要。4.1 系统架构与深度调试能力这是最核心的护城河。当AI能够生成一个微服务的大部分代码时谁来设计微服务之间的边界、通信协议、数据一致性方案和故障隔离域当云平台提供了一键部署和自动扩缩容时谁来规划整体的混合云架构、成本优化、以及设计当云服务本身出现区域性故障时的降级方案具体来说稀缺性体现在性能深度优化AI可以建议使用索引但无法为你设计一个针对十亿级数据、读写比例9:1的混合负载场景下的数据库分库分表与索引综合方案。这需要对数据结构、存储引擎、硬件特性有穿透式的理解。复杂故障排查系统在凌晨三点钟出现间歇性延迟监控指标全部正常。AI能根据日志报错给出常规建议但无法像经验丰富的工程师那样通过分析内核线程调度、网络包重传、垃圾回收器STWStop-The-World时间等线索像法医一样还原事故现场。这种在混沌中建立因果联系的能力短期内无法被自动化。高可用与容灾设计设计一个能容忍数据中心级故障的系统架构需要理解网络分区、共识算法、数据复制策略的细微差别。AI可以生成Raft算法的实现代码但无法替你决定在CAP定理中你的业务应该优先保证哪两个属性。4.2 跨学科的问题定义与整合能力未来最具挑战性的软件问题往往不是纯软件问题。它们存在于软件与物理世界、与其他专业领域的交界处。能源软件编写控制智能电网的软件需要理解电力传输、储能技术、市场交易规则。生物计算为基因测序仪或药物研发平台开发算法需要基本的分子生物学知识。工业软件开发CAD/CAE/CAM软件或工业物联网平台需要懂一些机械、材料或控制理论。金融科技构建高频交易系统需要深入理解市场微观结构、订单簿动力学和合规要求。在这些领域AI可以作为强大的代码生成和数据处理工具但把模糊的领域问题转化为清晰的、可被软件解决的技术方案这一“翻译”和“定义”的过程必须由既懂技术又懂领域的人来完成。这类工程师将成为连接两个世界的桥梁价值巨大。4.3 技术决策、伦理与问责能力随着AI和软件系统更深地嵌入社会核心医疗、交通、金融、司法其决策的影响越来越大。这就带来了全新的挑战技术决策在众多技术选项自研 vs 开源A云 vs B云某种算法 vs 另一种算法中做出符合长期战略、成本、风险和维护性的选择。这不仅仅是技术问题更是商业和工程判断问题。伦理与公平性你训练的推荐算法是否无意中歧视了某一群体自动驾驶汽车在不可避免的事故中如何做出“抉择”这些没有标准答案的问题需要人类工程师与伦理学家、法律专家、社会学家共同介入。问责当AI系统出错谁负责是编写原始算法的工程师是调整参数的调优师还是使用它的最终公司建立可追溯、可解释的AI系统并在法律和伦理框架内明确责任需要深厚的技术理解与人文关怀。AI可以生成代码但无法承担这些决策带来的责任。能够驾驭技术复杂性同时对其社会影响保持敏感和负责的工程师将是不可替代的。4.4 下一代工具与抽象层的构建能力当现有的抽象层如Kubernetes、各种Serverless平台被广泛应用并逐渐“商品化”时价值会流向创造下一个抽象层的人。这些人能发现现有开发流程中的共性痛点创造出更高效、更强大的工具、框架或平台。例如容器技术Docker的发明者抽象了应用运行环境Kubernetes的创造者抽象了容器集群的管理。他们不仅解决了当时工程师的痛点更定义了一个时代的软件交付范式。在AI时代可能会涌现出能大幅降低AI模型训练和部署门槛的平台工具。能智能管理“AI生成代码”生命周期如验证、测试、集成、演进的DevOps新工具。能让人以更自然语言或可视化方式定义复杂业务逻辑并自动转化为可靠系统的“无代码/低代码”高阶形态。成为这样的“造物者”需要极强的抽象思维、技术前瞻性和工程实现能力是金字塔尖的稀缺人才。5. 个人行动指南如何成为自动化时代的“幸存者”与“受益者”面对不可逆转的自动化趋势抱怨或恐惧无济于事。最务实的态度是将其视为一次职业环境的升级并主动调整自己的技能树和定位。以下是我基于自身和周围人经验总结的一些建议。5.1 心态转变从“代码生产者”到“问题解决与系统保障者”这是最根本的转变。不要再把自己的核心价值等同于每天产出的代码行数。你的价值应该体现在你解决了多复杂的问题这个问题是业务上的模糊需求还是技术上的性能瓶颈你保障的系统有多可靠你设计的系统能否优雅地应对各种故障MTTR平均恢复时间是多少你带来的认知深度有多深你是否能一眼看穿表面问题下的根本原因把AI助手当作你的“超级实习生”它负责快速完成明确、重复性的编码任务而你负责分派任务、审核结果、并处理那些需要创造力、深度思考和跨界知识的“硬骨头”。5.2 技能投资构建“T型”或“π型”知识结构“T型”人才的概念大家不陌生一横代表知识的广度一竖代表在某一领域的深度。在自动化时代我建议向“π型”发展即拥有两个深入的专长领域并用广泛的知识面将它们连接起来。深度一技术纵深在你的主技术栈上向下钻探。如果你是后端工程师不要只满足于Spring Cloud。去深入理解JVM原理、操作系统内存管理、TCP/IP协议栈、分布式一致性算法。当出现全链路监控都查不出的诡异问题时这些底层知识就是你的“手术刀”。深度二领域知识或交叉技能培养一个与软件结合的领域专长。可以是业务领域如金融风控、电商供应链也可以是交叉技术领域如数据工程、机器学习工程、信息安全。这能让你在特定赛道建立起壁垒。广度连接能力了解与你工作相关的上下游。前端工程师懂一点后端API设计后端工程师懂一些基础运维和DBA知识数据工程师懂一些业务指标。这能让你更好地进行系统思考和协作。5.3 实践策略在项目中主动寻求“高价值暴露”不要只做分配给你的任务。在日常工作中有意识地去做那些AI不擅长、但价值高的事情主动参与架构设计讨论即使你不是架构师也要积极思考并提出问题。理解每一个架构决策背后的权衡。承担复杂的故障排查把线上故障当作学习的机会。主动请缨参与复盘深入分析根本原因而不仅仅是应用一个快速修复。推动流程与工具改进发现团队在代码质量、部署效率、监控告警方面的痛点尝试引入或改进工具链。这锻炼了你的工具构建和流程优化能力。深入理解业务花时间和产品经理、运营、销售聊天。明白你写的每一行代码最终是如何为用户和公司创造价值的。这能帮助你在技术决策时做出更优的选择。5.4 拥抱AI成为善用工具的“增强型工程师”抵制AI是徒劳的。正确的姿势是成为最会使用AI的工程师。将AI用于“增强”而非“替代”用AI写单元测试、生成文档初稿、解答简单的技术疑问、提供代码优化建议。把节省下来的时间用于思考更复杂的架构问题或学习底层知识。培养“提示工程”能力学会如何向AI清晰、准确地描述问题设定约束条件才能得到高质量的代码或答案。这本身就是一种重要的沟通和抽象能力。保持批判性思维永远不要盲目相信AI生成的代码。你必须具备审查、测试和理解其输出的能力。把它当成一个需要严格审核的初级同事。6. 常见迷思与认知陷阱在讨论软件工程自动化时有几个常见的观点需要仔细辨析它们可能误导我们的判断和行动。6.1 迷思一“需求在增长所以工程师永远缺工资永远涨”这是最容易被拿来反驳“工程师价值下降”的观点。但文章已经用历史数据驳斥了这一点缝纫机发明后服装需求爆炸式增长但熟练女裁缝的岗位和薪酬溢价却消失了。关键在于需求的增长不等于对“传统形式劳动力”需求的同步增长。在软件领域全球的数字化需求无疑在暴涨。但满足这些需求的方式在变更多的工作被云服务PaaS, SaaS、开源软件、低代码平台和AI自动化了。单位软件功能所需的人力投入在急剧下降。因此虽然总的代码行数在增加但雇佣的工程师数量增速可能放缓甚至结构性减少初级岗位减少。工资的增长将高度集中在那些拥有稀缺技能系统架构、复杂问题解决、跨领域整合的顶尖人才身上而广大执行层的工程师可能面临薪酬增长停滞甚至竞争加剧的局面。6.2 迷思二“AI写的代码 bug 多离不开人类工程师”没错目前的AI代码助手远非完美会产生错误、不安全或低效的代码。但这恰恰指出了人类工程师未来角色的关键转变从代码的“作者”转变为代码的“架构师、审核者和质量保证者”。未来的工作流可能是人类工程师提出高阶设计AI生成初步实现人类工程师进行严格的代码审查、测试设计、安全扫描和性能剖析。这个过程需要的不是“编写每一行代码”的能力而是“定义正确目标、识别潜在缺陷、确保整体质量”的更高级能力。这意味着只会写代码但不会审代码、不会设计测试用例、不懂安全规范的工程师依然会被边缘化。6.3 迷思三“只要不断学习最新框架/语言就能保持竞争力”在商品化阶段这或许有效。但在自动化阶段这个策略的边际效用递减。因为AI最擅长的就是快速学习并应用这些框架和语言的语法与常见模式。你花三个月精通了一个新前端框架可能AI在它发布当天就能熟练地用它生成代码。比学习具体工具更重要的是学习底层原理和元技能。例如与其追逐最新的状态管理库不如深入理解UI渲染的核心原理与状态管理的本质如单向数据流、不可变数据。与其学习又一个微服务RPC框架不如吃透网络通信、序列化、服务发现与熔断限流的根本机制。这些原理性的知识变化很慢并且是理解和驾驭任何上层工具的基础也是AI目前难以从海量数据中完全“领悟”的。6.4 迷思四“管理者/业务人员可以用AI直接生成软件不再需要工程师”这是一个过于乐观或悲观的想象。AI降低了从“需求”到“代码”的转换门槛但无法消除“模糊的业务想法”到“精确、完整、可执行的技术需求”之间的巨大鸿沟。这个鸿沟的填补需要深刻的业务理解、系统思维、以及将非技术需求转化为技术约束的能力——这恰恰是资深工程师和产品架构师的核心价值。未来可能会出现“提示词工程师”或“AI产品经理”这样的角色他们用自然语言与AI协作定义软件。但他们本质上还是在做“需求分析与系统设计”的工作只是使用的工具从UML图、PRD文档变成了结构化的自然语言提示。他们仍然需要强大的逻辑思维和一定的技术理解力否则无法评估AI输出的可行性也无法在出现偏差时进行纠正。软件工程正在从一门手工艺演变为一个高度自动化、工具化的现代产业。编码活动本身就像曾经的纺纱、织布一样正在被更高效、更标准的“机器”所接管。这并不意味着工程师的末日而是意味着职业内涵的升华。那些满足于在抽象层之上进行简单拼装、而不求甚解的“码农”将面临最大的冲击。而那些能够向下穿透层层抽象理解系统本质能够向上衔接业务与人性定义复杂问题能够横向整合多领域知识创造全新解决方案的工程师他们的价值不仅不会降低反而会在AI的加持下变得更为耀眼。这场变革不是未来时而是现在进行时。Block的裁员不是开始更不是结束。它是一声响亮的警钟提醒我们所有人是时候重新审视自己的技能栈思考在价值链条上我们究竟站在哪个位置又该向何处迁移。