从写代码到对结果负责:AI时代软件工程师的能力迁移

AI时代下工程师的“转业”

这样一种落寞，让人联想起了10年前AlphaGo横空出世时的一幕场景。2017年5月，在浙江乌镇，当时世界排名第一的柯洁与升级版 AlphaGo 进行了三番棋较量，最终以 0:3 的总比分落败，他浑身颤抖，冲出对局室在角落里痛哭，反复说：“我做不到，我赢不了”。他后来感叹“十几年的努力失去了意义”。这种“幻灭感”不仅源于输棋，更在于他赖以生存的、通过数万盘对局积累起来的对围棋的认知体系，在 AI 面前被彻底颠覆了。

作为极具实力和竞争力的软件工程师，文章作者尚且需要“转业”，将键盘让位给机器，而软件开发领域的众多工程师和从业者，等待他们的将是什么呢？软件编程这个职业将如何走向？软件工程会大面积被AI取代而失业吗？他们该如何转型呢？

历史上的技术革命究竟告诉了我们什么

回看过去两百年的技术革命，会发现一个职业面对新技术时，并不存在唯一的结局。有些职业几乎消失了，有些职业只是换了一种工作方式，还有一些职业反而因为技术降低了成本、扩大了需求，获得了新的增长。

真正值得研究的不是“机器最终有没有取代人”，而是技术究竟改变了一个职业中的哪些任务，以及这种变化又如何传导到整个行业。

第一种情况，是一个职业最核心的任务被机器直接自动化，这个职业本身就可能大幅萎缩。

第一次工业革命中的手工织布工就是典型案例。纺纱率先机械化以后，纱线变得更便宜、供应量迅速增加，手工织布工一度反而更加抢手。但随后动力织布机开始直接自动化“织布”本身，情况便发生了变化。英国手工织布工人数从 1820 年的约 24 万下降到 1850 年的约 4.3 万，收入也大幅下降。

这里真正重要的并不是“机器出现了”，而是机器开始进入这个职业最核心、最能够创造收入的任务。当一个职业的大部分价值都建立在某一种技能上，而这种技能又能够被机器以更低成本稳定完成时，这个职业本身就可能受到根本性的冲击。

第二种情况，是职业消失了，但这个职业原先承担的任务并没有消失，而是扩散到了更多人身上。

计算机和通信技术革命中的打字员就是如此。专业打字员今天已经很少见，但“打字”并没有消失，恰恰相反，它变成了几乎所有办公室工作人员都必须具备的基本技能。这件事对今天的软件工程尤其值得思考。

未来即使“以编写代码为主要工作的程序员”减少了，也不意味着编程这件事会变得不重要。另一种完全可能出现的结果是：越来越多的产品经理、设计师、数据分析师、研究人员乃至普通业务人员，都能够借助 AI 创建软件。也就是说，技术有时消灭的并不是一种“任务”，而是围绕这项任务形成的专业分工。

第三种情况则更加复杂：机器确实降低了完成单位工作的人工需求，但成本下降之后，总需求却扩大了，最终抵消了部分替代效应。

自动柜员机（ATM）的普及就是一个经典案例。ATM 自动化了大量原本由银行柜员完成的存取款和标准化交易，但银行柜员的总就业量在相当长一段时间内并没有随之同步崩塌。

其中一个重要原因是，ATM 降低了银行网点的运营成本，银行因而能够开设更多网点；与此同时，柜员的工作也从简单的存取款操作，逐渐转向客户服务、金融产品推介和客户关系维护。

于是，一个看似矛盾的现象出现了：机器减少了完成一项任务所需要的人，却未必同比例减少整个行业所需要的人。

农业机械化则展示了另一种更长期、更彻底的变化。当机械大幅提高单个农业劳动者的生产率之后，一个社会不再需要让那么高比例的人口从事农业生产。大量劳动力在几十年的时间里逐步流向制造业和服务业，其中既包括在职劳动者的职业迁移，也包括老一代逐渐退出、新一代不再进入农业。

因此，技术革命对就业的影响，至少可以拆成三个不同的力量：

其中，替代效应意味着完成同样数量的工作需要更少的人；需求扩张效应意味着成本下降以后，原来“不值得做”的事情开始值得做，从而产生更多需求；新任务创造效应则意味着技术改变生产方式以后，会产生过去不存在或者并不重要的新工作。

软件行业很可能同时受到这三种力量的影响。

AI 显然正在减少完成相同软件开发任务所需要的人工时间。如果过去五个人一个月才能完成的项目，未来两个人借助 AI 就能完成，那么这是明确的替代效应。

但另一方面，当软件生产成本大幅下降之后，过去大量“不值得开发”的软件需求也可能被释放出来。

一个只有十几个人的小企业，也许过去不值得开发专属 ERP；一个老师不会专门雇工程师为自己的课程制作一套教学工具；一个小社区也不会投入几十万元开发自己的物业管理系统。但当 AI 将开发成本降低一个数量级以后，这些原本没有进入软件市场的需求可能开始变得经济可行。

与此同时，新的工作也正在出现。AI 并不只是帮助工程师更快地完成过去的任务，它也正在改变软件生产本身：如何组织智能体、如何提供上下文、如何评估结果、如何建立安全边界、如何让人和 AI 协同工作，都逐渐成为新的工程问题。

所以，对于软件工程师来说，真正的问题可能并不是一个简单的：

软件编程的进化

从前面的分析来看，未来十年最可能被大幅压缩的，不是“软件工程师”这个职业本身，而是“以亲手编写代码为主要价值来源的“编码型程序员”这一职业形态。

软件生产会越来越多，但完成同样数量软件所需要的人工编码时间会显著下降。

工程师的价值重心会从： 写代码 → 驾驭 AI 生产代码 → 判断代码和系统是否正确 → 定义应该解决什么问题 → 对最终系统负责。

因此，最值得担心的不是“AI 把所有程序员消灭”，而是软件行业可能出现一次类似工业革命的职业内部重新分工：低上下文、规格明确、容易验证的任务大量自动化；高上下文、模糊、跨系统、涉及责任和商业判断的任务反而成为新的稀缺能力。

斯坦福大学发布的报告也支持了这个判断，截至2026年6月更新的数据显示，虽然没有发现全经济范围的大规模就业替代，但是早期职业软件开发者就业下降比较明显。

衡量当前 AI 软件工程能力时，一个经常被引用的指标是Model Evaluation & Threat Research (METR) 提出的“任务完成时间跨度”（Task-Completion Time Horizon）。

这个指标并不是说 AI 可以连续自主工作多长时间，而是衡量：对于一项需要人类专家花费一定时间才能完成的任务，AI 有多大概率能够独立完成。过去几年，这个指标呈现出了非常明显的指数增长趋势，说明前沿模型能够独立完成的软件工程任务正在迅速变长。

但这里有一个非常重要、也很容易被忽略的限制。METR 自己反复强调，他们测试的大部分任务是相对自包含、规格比较明确、成功标准清楚，而且能够自动评估结果的任务。这些任务通常不要求模型长期参与一个真实项目，也不依赖大量过去的会议、设计决策、组织规则和业务背景。

因此，如果一个模型的“任务时间跨度”达到 8 小时，并不能简单理解成：它已经能够替代一个熟悉业务和代码库的资深工程师一天的工作。

真实的软件工程恰恰包含大量测试基准很难覆盖的东西：为什么三年前选择了这套架构、哪些看似无用的字段实际上被其他系统依赖、某个客户合同里有哪些特殊约束、过去发生过什么生产事故、团队有哪些能力边界，以及什么样的结果在商业上才真正算“正确”。

换句话说，任务的长度并不是决定 AI 是否容易替代它的唯一因素，上下文密度同样重要。

这也解释了一个看似矛盾的现象：AI 已经可以独立完成越来越长的软件开发任务，但在真实的大型系统中，经验丰富的工程师仍然具有很高的价值。

因为 AI 最先突破的，往往不是“最困难的工作”，而是那些能够被清楚描述、能够被独立完成、能够快速验证、又不需要大量隐性上下文的工作。

随着任务越来越模糊、越来越依赖长期上下文，涉及的系统和现实后果越来越复杂，人的作用也会逐渐从“亲自完成实现”，迁移到提供上下文、补全约束、判断结果和承担责任。

这种变化也可以从真实的 AI 编程使用数据中看到。

2026 年，Anthropic 对大约 40 万个 Claude Code 实际使用会话进行了匿名化分析。他们发现了一个很有意思的分工模式：在典型的 Agent 编程过程中，人更多负责决定"做什么"，而 Claude 更多负责决定“具体怎么做”。

更值得注意的是，专业知识并没有因为 AI 能够写代码而失去价值。Anthropic 的数据反而显示，一个人在相关领域拥有越多专业知识，通常越能够通过一条指令让 Claude 完成更多工作；领域经验更丰富的用户，任务最终成功的概率也更高。

这意味着一个很重要的变化正在发生：AI 并没有简单地消灭专业能力的价值，而是在改变专业能力发挥作用的位置。

过去，一个资深工程师的经验很大一部分体现在“自己如何完成实现”上。他知道代码应该怎样组织，Bug 在哪里，某个库应该怎样调用，一个复杂功能应该怎样一步一步写出来。而在 Agent 编程模式下，这些经验越来越多地表现为另外一种能力：

你是否知道该让 AI 做什么；

能不能把问题描述得足够准确；

能不能告诉它哪些约束绝对不能违反；

它走错方向的时候，你能不能及时发现；

它给出一个看上去完全合理的方案时，你有没有能力判断哪里不对。

于是，AI 越来越强之后，经验丰富的工程师与普通工程师之间的差距未必只是“谁能写出更好的代码”。

差距可能逐渐变成：

从这个角度来看，AI 并不是简单地把软件工程师从生产过程中拿掉，而是在把人的工作不断向生产链条的上游和下游推移：中间的“实现”越来越多地交给机器；上游的需求定义、系统设计和约束建立，以及下游的验证、判断和责任，则越来越成为人的工作。

这也是为什么，AI Coding 越来越成熟之后，软件工程师真正需要迁移的并不只是工具，而是自己的能力重心。

编译器之所以让工程师可以逐渐忘记汇编，是因为它自动化的是一个已经被形式化的问题；AI Coding 正在试图自动化的，却恰恰包括“把模糊现实转化为形式化程序”这个软件工程最困难的部分。

自然语言与形式化程序之间存在着语义鸿沟，只要输入仍然是不完备、含糊并依赖上下文的自然语言，AI 系统就必须进行推断，而不只是翻译。因此即使未来模型输出可以做到高度稳定甚至表面上确定，需求理解、约束补全、架构选择和实现之间仍然存在不可避免的不确定性。这恰恰需要资深工程师的工程能力来填补，包括定义问题、建立约束、提供上下文、验证结果和承担系统级判断。

未来的软件工程的另外一个发展趋势是人与AI高度协同，软件工程师会越来越像技术负责人和管理者，但管理的不是人，而是 AI Agent。未来的工作模式也许是，软件工程师管理和协调一个后端Agent，一个前端Agent，一个测试Agent，一个安全Agent，一个研究Agent来进行项目开发。工程师亲自实现的比例大幅下降，相反，其工作变成分解任务、提供上下文、提供隐含的约束、监督 Agent 执行、检查结果、发现异常、重新规划和最终的验收。

也就是说，工程师逐渐转变为 Agent 的管理者，但他不是传统意义上的管理者。他仍然需要懂得代码，因为 AI生产的代码经常看起来非常合理但却包含错误。在2025年，Stack Overflow的开发者调查也很好地说明了这一点：84%的开发者已经开始使用或者计划使用AI，但只有约33%的人信任AI的输出准确性，约46%表示不信任。其最大痛点是，AI给出的答案几乎正确，但却并不完全正确。这会导致一个反直觉的结果：AI写代码的能力越强，判断代码是否真的正确的能力反而越重要。

在这种趋势下，资深工程师的价值可能会发生反向的上升。所以企业可能不再需要大量主要写代码的人，但可能仍然非常需要少数几个真正理解系统的人。

随着编程 Agent 的长任务能力不断增长，软件工程师可能逐渐由软件制造者，变成软件生产系统的操作者和负责人。这非常类似于工业革命中，手工业者先是变为机器操作者，然后变成工业工程师。未来软件工程师的的变化路径则是：从编程者，到 AI 辅助编程的开发者，到组织管理编程代理的管理者，最后成为软件系统负责人。

AI时代软件工程师的能力模型

当前的AI技术革命与工业革命对比，最相似的点不是单纯的“机器取代工人”，而是一种工程能力的迁移。在机床出现以前，一个熟练工匠会亲手加工零件；在机床出现后，机器承担越来越多的加工。最终，值钱的能力逐渐迁移到设计、流程、质量、材料、生产系统。同样，随着AI技术的发展和成熟，软件生产的高价值能力也从简单的编码手艺逐渐迁移到问题定义、产品判断、系统架构等高价值能力领域。

具体来说，在未来十年，软件工程师的能力最有可能向以下三个方向迁移，

1、产品与领域工程（Product / Domain Engineering）

这个方向的核心问题是“我们究竟应该解决什么问题”。典型的能力集合包含理解用户、理解业务、理解行业、发现真正的问题、定义产品行为、领域建模、优先级判断、商业与技术权衡等。AI可能很容易解决“怎么做”，而实际昂贵的是“到底应该做什么”，这通常需要软件工程师的业务理解和领域经验来回答。

2、系统和基础设施工程（System / Infrastructure Enginerring）

这个方向的核心问题是“怎样让系统在真实世界长期正确地运行”。典型的能力集合包含架构、性能、可靠性、安全、数据库、分布式系统和观测性基础设施。例如，让AI去编写一个转账的功能是很容易的但是真正的困难在于：

• 两个请求同时转账怎么办？

• 服务宕机一半怎么办？

• 消息重复消费怎么办？

• 数据库切换主节点怎么办？

• 网络发生分区怎么办？

• 如何保证不多扣钱？

AI Coding 的能力越强，这方面的工程问题反而变得越重要。因为当代码生成的效率越来越高，就会导致系统的体量和复杂度快速上升，从而导致集成问题快速上升，并且运行风险大大增加。

3、AI原生工程（Agentic Engineering）

今后，优秀工程师不一定亲自完成所有的实现，越来越可能是设计一个让AI智能体来完成实现，所以这个方向主要包括了：

• 智能体设计

• 上下文工程

• 工具调用

• 工作流

• 评估

• 安全边界

• 人在回路

• 模型选择

• 多智能体系统

在任何一个方向中，都需要四种高级工程能力，包括，

1、规范化能力（Specification Engineering），即把模糊问题变成可执行、可验证的问题。例如用户说“搜索要快一点”，资深的软件工程师首先会问：什么叫做快？例如 P50 < 100ms，P95 < 300ms，或者 P99 < 1秒；数据规模是多少？允许缓存吗？允许结果延迟吗？

最终将这个模糊的目标变成一个工程规格：P95 < 300ms，1亿条记录，峰值 10 KQPS，成本增加不超过 20%。

2、上下文工程能力（Context engineering）。它解决了一个工程师或者 AI 到底掌握了多少真正影响决策的信息。真实软件系统的上下文可能不仅仅包含代码，而事实上也包含架构、数据库模式、API契约、历史、设计决策、生产事故、业务规则、合规要求、用户行为、成本限制、组织约束等等。

例如，当一个 AI编程智能体看到数据库表中的一个字段没有被使用，决定删除的时候，资深工程师却知道每个月的财务系统会通过 ETL 离线来读取这个字段，因此这个字段是不能被删除的，这就是隐含上下文。未来高级工程师的能力之一，就是将组织隐性知识转变为机器和人都能使用的显性上下文。

3、验证工程（Verification engineering）。未来的问题很可能不是代码生产率不够高，而是代码生产的太多太快从而检查不过来。比如过去5个工程师每天产出3个PR，而现在1个工程师加3个Agent 每天可以产出30个 PR。这时候的实际的瓶颈就变成：谁来证明它们是对的。未来的一条工程规律很有可能是：代码生产能力增长得比验证能力快，因此验证可能成为新的系统瓶颈。于是，对正确性的验证成为新的稀缺资源，验证工程能力则成为一种稀缺能力。

4、工程判断力（System judgment）。这是四项能力里最难训练也最难形式化的一个。也许 AI 可以告诉我们 Redis、Kafka、PostgreSQL、ClickHouse 各自有什么优缺点，但最后必须有人决定这个项目到底要选哪一个。这涉及到性能成本、团队能力、业务增长、复杂度、可靠性、交付周期、维护成本等等因素，不存在一正确答案，而这恰恰就是权衡（trade-off）。所以未来高级工程师的核心价值不是知道的最多，而是在信息不完整的情况下做出足够好的工程决策。

那么 coding 到哪里去了呢？其实 coding 并没有消失，但以代码产量为核心价值的差异化能力持续下降。所以，未来的高级工程师需要具备很强的软件工程判断力，加很强的 AI 杠杆，再加足够强的代码理解能力。

更进一步来讲，未来软件工程师的底层必须要有软件工程的基础能力栈。这不仅包含编程语言能力，还包含数据结构、算法、操作系统、网络、数据库、并发、分布式系统、安全架构设计等更加基础的能力。AI可以帮我们调用这些知识，但如果软件工程师完全不理解，他们就无法完成验证和判断。

这也直接回答了 DeepSeek 工程师在文章中所提到的另外一个问题：

作者提到的这个问题实质上是在问，学生究竟是否需要从基础开始自底向上扎实的学习还是简单直接遇到问题找AI要结果。前者在一步一步的细节过程中，逐步积累起对于系统的理解以及对于工程能力的扎实掌握。而对于使用AI的学生而言，如果把思考、建模、调试和验证本身外包给了 AI，虽然也暂时得到了一个非常正确的结果，却对于基础能力的建立并无实质性帮助，也因此，在面对更加复杂的大型系统时，会失去验证能力和判断能力。

所以未来这些基础能力的意义也在发生变化：过去是为了生产代码而学习基础，未来是为了理解、判断和验证AI生产的系统而学习基础。

另外，最顶层还有一个容易被忽略的能力：ownership。也就是对结果负责的能力。事实上，在实际的系统当中，编译器不会对结果负责，编程框架不会对结果负责，AI也不会对结果负责。最后必须要有人来对结果负责。所以，未来对软件工程师的定义，可能越来越接近于“对软件系统结果负责的人”，而不是“写软件代码“”的人。

所以，将以上的三个方向和四种能力综合起来，得到了一个未来软件工程师的能力模型，

在这个模型当中，横向三个领域定义了未来软件工程师的能力迁移方向，是这个职业的主要价值领域。纵向的四种能力定义了软件工程各个阶段所需要的不同能力，在前面的三个领域中都会贯穿始终。底层的软件工程基础决定了软件工程师能不能真正地理解和判断系统，是这个职业的地基。最上层的“为结果负责”，决定了工程师能否成为一个真正意义上的高级工程师，也是这个职业最终的落脚点。

所以，软件工程师不应该再简单地定义为能够写复杂代码的人，更准确的定义可能是：

结语

回到文章开头 DeepSeek 工程师提出的那个问题。当一个曾经需要工程师多年训练才能掌握的能力，开始被 AI 迅速追上甚至超过时，那些为此付出的时间和积累，是否真的像标题所说的那样，被“埋葬在昨天”了？

从技术发展的历史来看，类似的事情已经发生过很多次。熟练的手工织布曾经是一种稀缺能力，后来不再是；专业打字曾经是一份职业，后来变成了所有人的基础技能；程序员也曾经需要直接面对机器指令，而今天绝大多数软件工程师已经不再需要熟练编写汇编代码。技术一直在使某些曾经稀缺的能力变得廉价。AI Coding 可能也不会例外。代码生成正在迅速变得便宜，以“把明确需求翻译成代码”为主要价值的工作，也很可能因此被大幅压缩。对于很多软件工程师来说，这种变化并不是遥远的未来，而是已经发生在今天的工作之中。但这并不等于软件工程本身正在失去价值。恰恰相反，当代码生产越来越容易以后，那些过去被编码工作掩盖在下面的问题开始变得更加突出：

我们到底应该解决什么问题？一个模糊的需求怎样变成可以执行和验证的规格？哪些没有写进代码和文档的上下文会影响决策？AI 生成的系统究竟是不是正确的？当性能、成本、复杂度和可靠性发生冲突时应该怎样权衡？以及最后，当系统真正进入现实世界运行以后，谁对结果负责？

这些问题过去就存在，只是大量工程时间和注意力曾经被“如何把系统写出来”占据了。当 AI 逐渐接管实现过程之后，它们反而会更加清楚地暴露出来。因此，我越来越倾向于认为，AI 给软件工程带来的真正变化，不是工程能力正在消失，而是工程能力的价值位置正在发生迁移。一些曾经处于价值链中心的能力会逐渐成为基础能力，一些过去隐藏在编码之后的能力则会走到前台。软件工程师也可能因此经历一次职业定义上的变化：从“负责把软件写出来的人”，逐渐变成“能够定义问题、设计系统、组织 AI 完成实现、验证结果，并最终对软件系统负责的人”。

如果一定要回答那句“才华是不是被埋葬了”，或许更准确的说法是：被技术带走的，往往不是一个人的全部能力，而是某一种能力曾经拥有的稀缺性。

真正困难的，是在这种稀缺性发生迁移的时候，重新找到自己的位置。

参考资料

[1] Research Insight: What can the early Industrial Revolution teach us about technology and work in the age of AI? https://shapingwork.mit.edu/research/research-insight-what-can-the-early-industrial-revolution-teach-us-about-technology-and-work-in-the-age-of-ai/?utm_source=chatgpt.com

[2] Learning From Ricardo and Thompson: Machinery and Labor in the Early Industrial Revolution and in the Age of Artificial Intelligence,https://www.annualreviews.org/content/journals/10.1146/annurev-economics-091823-025129

[3] Occupational Switching During the Second Industrial Revolution https://www.chicagofed.org/publications/working-papers/2024/2024-01?utm_source=chatgpt.com

[4] Toil and Technology Finance & Development https://www.imf.org/external/pubs/ft/fandd/2015/03/bessen.htm?utm_source=chatgpt.com

[5] No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19% https://digitaleconomy.stanford.edu/news/canariesaug26/?utm_source=chatgpt.com

[6] 2025 Developer Survey https://survey.stackoverflow.co/2025/ai?utm_source=chatgpt.com