为什么人工智能尚未取代软件工程师，也不会取代软件工程师

人们对 AI 替代工作的焦虑和不确定性非常强烈。我们该如何摆脱那些含糊的警告和夸张的预测，转而用数据来回答这个问题？一个不错的办法，是观察 AI 能力发展最领先、采用速度也极快的职业：软件工程。

在这篇文章中，我们认为，已有足够证据可以驳斥这样一种叙事：一旦 AI 能力达到某个阈值，就会引发大规模裁员。既然在监管壁垒极少的行业里都如此，那么其他大多数职业大概率只会受到更强的保护。

我们也对其原因有较好的理解。我们可以把许多知识工作，包括软件开发，理解为一个“决策—执行—交付三明治”。AI 压缩了“执行”这一层——也就是三明治的中间部分——但另外两层对自动化具有很强的抵抗力，这种抵抗不会仅靠能力提升就被克服。

我们的结论是，对软件工程未来需求走势应保持谨慎乐观。本文是该系列的第一篇，下一篇将讨论：即便整体需求依然健康，单个软件工程师的职业生涯为什么仍可能充满波折。该系列基于经济学和软件工程领域已发表的文献、我们自己对 AI 智能体的评估和观察，以及许多软件工程师对 AI 影响其职业现状与未来的反思——这些反思既来自公开写作，也来自我们与社区的交流。

先看三则曾登上头条的故事，以及它们与现实的反差：

• 今年 2 月，金融科技公司 Block（Cash App、Square、Afterpay 等应用的母公司）宣布裁员 4,000 人。创始人杰克·多尔西表示，AI 正在“开启一种新的工作方式”，让团队“更小、更扁平”，并特别提到模型能力在2025 年末的改进。但后续报道揭示了截然不同的图景。疫情期间公司员工规模扩大了三倍多，随后便面临巨大的财务压力。Cash App 团队的数据科学家 Naoko Takeda 发帖称，Block“把 AI 硬塞进每个人嘴里”，但她看到的“生产力提升非常有限”。她拒绝了 75% 的留任加薪并离职。接受采访的其他员工则对 Block 的 AI 能力以及多尔西是否真正理解相关问题，持有截然不同的看法。正如 Aaron Levie 所指出的，CEO 对 AI 用途最容易产生独特的幻想，因为他们可以快速做出原型，却看不到把原型打磨成成品所需工作中那 90% 的部分。多尔西对 AI 的公开表态似乎正好符合这一模式。
• 今年 4 月，Snap 裁员约 1,000 人，CEO 埃文·斯皮格尔在裁员备忘录中主要把原因归于 AI。他还说，AI 生成了65% 的新代码。但实际上，这波裁员是紧随一场激进投资者运动，后者要求公司削减成本。（Snap 自 2017 年 IPO 以来，每个完整财年都录得净亏损，且其股价在 2026 年下跌超过 30%。）值得注意的是，此次裁员的性质，例如增强现实部门横跨多个岗位的 150 个职位，和我们若真是由 AI 驱动裁员时预期会看到的情况并不相符（也就是说，应该是全面波及编程及其他“AI 暴露度高”的岗位，而不是集中在某个业务单元）。
• 今年 5 月，Intuit 在宣布与 Anthropic 和 OpenAI 达成合作的同时，也宣布裁减 3,000 人。媒体将二者联系起来，将这些裁员描述为由 AI 驱动的重组。这一次，CEO 罕见地直接反驳了这种轻易得出的叙事，称“这和 AI 没有任何关系”，裁减针对的是“协调密集型岗位”和过多的管理层级。

这些例子并非挑选出来的个案。我们审视过的每一则关于 AI 驱动的软件工程裁员故事，都出现了同样的叙事偏差。事实证明，用 AI 来“洗白”裁员已经是整个经济体系中的普遍现象，多个调查都能说明这一点：

• 59% 的美国招聘经理承认，在解释冻结招聘或裁员时会强调 AI，因为这比直接说财务受限更容易获得利益相关方接受。
• 福雷斯特（Forrester）首席分析师 J. P. Gownder表示，针对那些据称由 AI 驱动的裁员计划的公司：“当我们问他们是否已经有成熟、经过验证的 AI 应用准备好填补这些岗位时，十次里有九次答案是否——而且他们甚至还没开始。”
• 在一项针对 1,000 多名全球高管的《哈佛商业评论》调查中，21% 的受访者已经“预先”进行了大规模裁员，另有 39% 进行了轻度或中度的预防性裁员。相比之下，只有 2% 的人已经因实际 AI 落地而进行了大规模裁员。这个 10 倍的差距表明，高管和其他人一样，也极易陷入“AI 替代工作”这类误导性叙事之中。

另一个有趣的数据点来自 WARN 法案。该法案要求对影响 100 名以上员工的工厂关闭和大规模裁员进行特定披露。2025 年 3 月，纽约州成为美国首个在 WARN 法案申报中加入 AI 披露勾选框的州。完整的第一年里，超过 160 家公司提交了 WARN 通知。没有一家勾选 AI 选项。1 我们联系了纽约州劳工部门，对方确认，截至 5 月下旬，只有一家企业 Nespresso 勾选了该项。2 如果这些申报属实，那么在相关期间纽约州约 2.5 万名被裁员工中，只有 46 人与 AI 有关，约占 0.2%。

更能说明问题的是：把裁员归因于 AI 驱动的大规模失业，本身就抓错了 AI 生产率提升的信号！研究已经很明确，这种影响是通过“放缓招聘，而不是增加离职”来体现的。解雇现有员工会恰恰丢失那些让员工能够有效使用 AI 的隐性知识和组织资本。此外，这样做还要付出高昂的遣散费、士气受损以及重新招聘风险。考虑到这些成本，既然自然流动在几年内就能达到同样效果，这种做法在很大程度上并无必要。

那么，如果我们不看裁员，而是看整体就业趋势，数据又告诉我们什么？美联储经济学家的一篇重要论文汇编了美国背景下的证据。软件工程师就业人数仍在增长，但他们发现，ChatGPT 之后的增速相较于“没有 AI”的反事实情景，每年约慢 3 个百分点。这项研究的一个重要局限是，其方法无法捕捉自雇情况，因此增长放缓的部分可能被创业活动吸收掉了。我们从其他研究中确实看到了 AI 能降低创业门槛的证据。因此，真实情况很可能比美联储的研究显示得还要更乐观。3

最后，还需要承认软件工程中有两类真实存在、但与“AI 取代软件工程师”不同的、间接受 AI 影响的就业损失。第一，AI 有时会直接摧毁某种产品的需求，例如 Chegg（作业辅导）或 Stack Overflow（技术问答），这两家公司都已裁员。AI 并不是直接替这些员工做了原来的工作，而是让这类工作不再有必要。历史上有很强的类比：在 1950 年美国人口普查列出的 270 个职业中，只有一个职业被自动化彻底取代——电梯操作员。但另一些职业则随着新技术的出现而变得过时，比如电报员。

另一类可信的 AI 驱动裁员故事，发生在那些出售 AI 而不是购买 AI 的公司中。因此，当 IBM 或 SAP 之类的公司宣布因为 AI 而裁员时，更准确的说法是：“我们把员工从传统职能重新配置到了增长最快的产品线上。”这属于围绕收入机会的常规企业重组，而不是技术把工人挤出了岗位。

像上面提到的 Snap CEO 一样，许多科技领袖在报告裁员或预测未来失业时，都会顺带提及“AI 生成的代码占比”。这强化了一种过于简单的心理模型：一旦 AI 写完所有代码，就不再需要程序员了。幸运的是，这种模型是错的。这个“AI 写代码比例”指标，与劳动替代真正相关的问题几乎完全脱节。原因如下。

写代码并不是、也从来都不是瓶颈。例如，一篇2019 年论文综述现有研究后得出结论：“开发者花在编码上的时间出奇地少，具体比例视研究而定，在 9% 到 61% 之间。”这一发现与论文作者基于微软 6,000 名开发者的数据结果一致。随着编码智能体开始普及，2025 年末大量博客文章开始指出，写代码并不是瓶颈，因为开发者逐渐意识到，让智能体完成大部分代码的编写，对整体生产力提升影响很小 [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 ]。

如果写代码不是瓶颈，那什么才是？任务拆解调查指向了会议或调试之类的工作。这立刻引出更多问题：开发者在那些会议里到底在做什么，为什么 AI 不能完成？随着能力提升，调试难道不会被自动化吗？要理解真正的瓶颈，我们必须回到定性分析，深入软件工程师自身对那些难以自动化的工作内容的理解。

当我们做了这样的分析后，发现真正的瓶颈有三类：（1）决定并定义要构建什么；（2）验证并对交付结果负责；（3）支撑前两者所需的深层人类理解——包括对代码库、业务和环境的理解。

换句话说，软件工程师的工作就是一个“决策—执行—交付三明治”（而理解能力是三层的前提）。AI 压缩了三明治的中间层，但两端基本没有变化。只要软件开发团队仍然负责决策，并对交付结果负责，工程师就仍然需要花时间建立对系统的深层理解。这就是三个瓶颈。

[https://substackcdn.com/image/fetch/$s_!sj-b!,f_auto,q_auto:good,fl_progressive:steep/https$s_!sj-b!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F71107c50-448e-49ef-a986-a7eb496906e1_1152x552.png)

图：软件开发由三层构成：（1）决策——问题界定、规格定义、规划；（2）执行——设计与实现；（3）交付——测试、验证、集成、维护等。注意，这些是概念层次，而非时间阶段。在项目推进过程中，频繁在这些层之间来回切换是很常见的。

AI 生产率“ 三明治模型 ”的证据来自一篇关于“写代码与交付代码”的最新论文。研究者在 GitHub 上观察了 10 万名开发者，发现 AI 智能体使代码行数增加了 8 倍，这与 AI 几乎完全压缩三明治中“执行”层这一判断一致。但这只带来了 30% 的发布量增长，强烈表明人类瓶颈（“决策”和“交付”两层）依然存在。4

三明治还能继续被压缩吗？我们认为不能。沿着流水线的一端，开发团队需要决定做什么。初级软件工程师学到的最重要经验之一，就是需求规格说明（该职业对这一层的术语）出人意料地耗时，而且如果这一环节被压缩，后面会带来更多痛苦。这一层之所以难以自动化，是因为它要求思考用户需求、市场信号、组织优先级，在某些情况下还要考虑监管约束。

随着 AI 能力提升，可以委派给 AI 的决策类型会逐渐增多。但这并不会让“决策”这一层变薄——一旦某个决策可以交给 AI，它就不再是竞争优势的来源，而人类决策的价值会向更高层迁移。软件本身会随着时间变得越来越复杂，因此这一过程没有上限。

在三明治的另一端，人类团队需要对交付结果负责。未来某天，团队或许真的能够在没有充分测试和理解的情况下发布关键任务代码，但今天的 AI 仍然极不可靠，这样草率的做法对软件团队及其客户都将构成生存性威胁。

即便未来技术障碍消失了，我们也不必把控制权让给 AI。《AI 作为常规技术》一文的核心洞见之一是：我们可以通过共同的规范、法律和政策，集体选择让人类继续承担责任。这比试图放慢技术能力发展，更能有效控制 AI 影响的速度并提升安全性，也更具韧性。由于责任法和行业监管，这些速度约束在很大程度上已经存在，但还可以进一步加强。（若想看这一论点的长篇版本，可参见原文。）

按照这一愿景，随着越来越多的执行层工作被交给 AI，未来软件工程师的角色会越来越像起重机操作员。AI 智能体将承担大部分认知劳动；监督智能体并确保其受控，将成为人类工作的主要内容。

一些评论者认为，一个由人类继续掌控的未来不太可能，因为请人来监管的成本太高。现实中已经出现了几则病毒式传播的故事，讲的是监管不力的编码智能体删除生产数据库或造成其他损害。但我们认为，这些更像是“狗咬人”式的新闻，而不是一种新常态。它们之所以能迅速传播，正是因为这种行为极其不负责任、极不寻常，具有很强的冲击力，同时也作为定期提醒和学习契机，帮助整个社区警惕对 AI 的过度依赖。俗话说，“上了新闻的事，反而不用太担心”。不过，能否识别出在高风险任务中、整个经济范围内是否出现了对 AI 的低监督使用抬头——而不仅限于软件工程——仍然是我们今天最关键的数据缺口之一。

顺带一提，三明治被压扁其实是一个新趋势，而且并不完全是 AI 造成的。二十多年前，美国劳工统计局就开始把编程与软件工程分开统计。粗略来说，程序员只负责执行，而软件工程师则负责更大一部分“三明治”。编程岗位不仅在萎缩，其薪酬也低得多，因为它被视为体力活式的苦工。AI 只是加速了这一长期存在的趋势，进一步贬低了纯技术技能的价值。

[https://substackcdn.com/image/fetch/$s_!vpJH!,f_auto,q_auto:good,fl_progressive:steep/https$s_!vpJH!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fed975481-276e-4dab-a340-e3fbd85d5c86_1108x1192.png) 软件工程师与程序员就业情况。华盛顿邮报📚 图表。

这种模式——即便 AI 越来越多地自动化中间层，人类仍深度参与“决策—执行—交付三明治”的两端——似乎广泛适用于大多数知识工作，只不过在软件领域进展最为明显。毕竟，复杂决策和责任归属几乎是所有行业的共同特征。未能认识到这一现象，导致人们对即将到来的失业做出过多自信的断言，例如 AI 会取代放射科医生 的预测。

之所以会对软件工程变化的程度产生混淆，其中一个原因是，人们对“vibe coding（氛围编程）”这个词的随意使用，把一整条实践光谱都囊括了进去，而这条光谱两端在概念上是不同的，彼此差异也大于相似之处。

在真正的 vibe coding 中，用户只是告诉智能体要做什么；运行时不监督它；不审查代码——甚至可能没有能力审查；也不会评估输出，最多只是等到明显出问题时才注意到。

这与大多数软件工程师实际使用智能体的方式完全不同——后者把智能体当作工具，而人类仍然掌控并对结果负责。幸运的是，“智能体式工程”这个术语正逐渐流行起来，用来描述这种实践。

随着智能体式工程成为常态，工程师们发现，监督编码智能体竟然出奇地耗时。例如，知名开发者、AI 变迁记录者 Simon Willison 就指出，到了上午 11 点他就已经因监督智能体而精神疲惫了。我们的经验也与此一致。

更具量化性质的证据来自 SWE-chat，这是一份由自愿接入日志工具的开源开发者所产生的编码智能体交互数据集。研究发现，智能体生成的代码只有 44% 最终进入用户提交；vibe coding 产生的提交引入漏洞的比例是仅由人类编写的 9 倍；而用户最常见的意图是理解已有代码，而不是生成新代码（19% 对 13%）。由于该数据集是自选择样本，我们不能仅凭这项研究得出强结论，但它确实印证了其他许多证据：vibe coding 与智能体式工程的模式截然不同。

[https://substackcdn.com/image/fetch/s_!_uJW!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdaee7fd7-e171-4904-9a87-02652428e96a_1616x2034.png](https://substackcdn.com/image/fetch/s_!_uJW!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fdaee7fd7-e171-4904-9a87-02652428e96a_1616x2034.png) 智能体式工程不是 vibe coding

再次强调，这不是两类截然分明的概念，而是一条连续光谱的两端，中间存在一个模糊地带。并不是每个项目都非黑即白，不是非一次性试验品就是关键任务。也不是每一种工作流都能精准落在表格的左列或右列。但对于“工作岗位是否会被替代”这一问题，关键结论依然成立——公司不可能通过雇佣不合格的 vibe coder 来替代软件工程师，从而交付生产级软件。

AI 乐观主义者可能会声称，大规模裁员即将到来；只是由于人类水平的软件工程能力出现时间太短（或者尚未真正实现），所以还没发生。但如果三明治模型正确，这些预测就不会成真。AI 其实已经在很大程度上压缩了三明治的中间层（而且这种压缩几十年前就开始了）。因此，即使把执行层做到瞬时且完美，也只会比现状有小幅变化。其他两层之所以抗拒 AI，并不是因为能力还不够。

事实上，软件工程岗位不仅不会因 AI 消失，需求甚至可能还会上升。当软件（或任何其他东西）因为技术提升而变得更便宜时，人们就会购买更多软件（用经济学术语说，软件的“价格弹性”很高）。而正如我们所论证的，AI 并不会取代软件工程师（“替代弹性”很低），因此，对更多软件的需求会进一步派生出对更多软件工程师的需求。一个相关但更具戏剧性的经济学术语“杰文斯悖论（Jevons’ paradox）”，在 AI 讨论中常被拿来使用来描述这种现象。

从历史上看，这一直是大势所趋——美国程序员就业人数从 1950 年前后的接近于零增长到今天的数百万。与农业等职业形成鲜明对比：农业劳动需求因机械化和自动化而著名地被摧毁。区别在于，人类摄入的热量总量相对固定——哪怕增加 25% 都已经导致了肥胖流行——而软件的产出量却增长了百万倍。现代汽车在其各种车载计算机上运行着大约一亿行代码。

如果代码需求存在上限，我们离那个上限还非常遥远。几乎所有认知工作都受益于软件。随着 AI 让编程变得更便宜，人们正在创造各种一次性工具——无论用于工作还是个人用途——这些工具在过去根本不值得被开发。

需要说明的是，虽然我们认为未来软件会更多，软件工程师大概率也会更多，但这并不意味着大型科技公司会变得更大。今天的大多数软件工程师已经在非软件企业内部任职，而这一比例未来可能还会上升。还有所谓“AI 整合收购”的想法，指的是风投或私募股权公司收购牙科诊所、会计事务所之类的“主街”业务，然后把这些业务从头重建为“AI 原生”——在这些企业中嵌入软件工程师或 AI 工程师。当然，这也可能最终只是炒作，尚难定论。

也有人预测，由于技术民主化，软件工程技能的需求会下降。他们承认未来软件产出会比以往更多，人们花在生产软件上的时间也会比以往更多，但这些工作会由非软件工程师来完成。其想法是，AI 会在一定程度上实现软件工程民主化，比如法律软件可以更容易由受过法律训练的人来创建，而不是由软件工程师来创建。

也许如此。但我们会押注于相反结论。在我们看来，这和把 vibe coding 与智能体式工程混为一谈、把执行层与整个“决策—执行—交付三明治”混为一谈，是同一种陷阱。事实上，回顾编程史，我们会发现人们总说自己已站在民主化门槛上——FORTRAN、COBOL、SQL 这类旧语言在诞生之初，也都伴随着类似的期待。但这种事从未真正发生。门槛并不只是学会语法，而是要具备足够成熟的判断力，在保持责任承担的同时做出正确决策。

最终，这种区别也许只是语义上的。显然，人们花在让计算机做新事情上的时间会持续增加。这种形式可能是构建软件，也可能是借助智能体管理复杂工作流，或者其他什么。它需要软件技能、AI 技能和领域知识的混合。今天的软件工程师是否最能适应并胜任这些新角色，仍有待观察。

关于“适应”的这一点，正好引出了本系列的下一篇文章。软件行业总体劳动需求大概率仍将保持强劲，这并不意味着大多数个体劳动者不会受到影响。我们将论证，AI 会带来软件生产方式的巨大结构性变化，这将深刻影响哪些软件工程师会受益、哪些会受损——取决于他们所在的公司类型、地理位置、资历，以及其适应变化的速度。

延伸阅读

Deena Mousa 指出，基于“AI 暴露度”等指标对 AI 影响进行宽泛的、全经济范围分析，存在表面化问题；她主张应开展“谨慎的、按职业细分的研究”。我们希望这一系列文章能为建立对 AI 改造软件工程的细致理解发挥作用。我们此前曾与 Justin Curl 合著一篇分析法律服务中的 AI的论文，认真讨论了使这一职业独具特色的监管及其他瓶颈。未来我们计划继续开展更多按职业深挖的研究。

40 年前，Fred Brooks 在一篇卓越的文章——📚 《没有银弹》——中区分了软件的“本质复杂性”和“偶然复杂性”。他认为，软件的某些复杂性是偶然的，源自当时技术的限制，例如编程语言笨拙难用；随着工具改进，这些复杂性可以逐步缓解。但另一些复杂性是本质性的，因为要准确指定软件应有的行为本身就很困难。他有力地阐述了为什么三明治中的“决策”层又厚又难以自动化。有趣的是，那时人们就已经普遍希望借助 AI 提升程序员生产力了！Brooks 认为，由于 AI 或其他任何技术只能减少偶然复杂性，因此不可能带来数量级的生产力提升。（Brooks 也是*《人月神话》*的作者，这部文集几乎可以肯定是有史以来最著名、最具影响力的软件工程著作。《没有银弹》后来也收录进了这本文集中。）

感谢 Felix Chen 对初稿提出反馈。