发布于 2026-10-20 · 更新于 2026-10-20

文章目录

AI 写了90%的代码，未来软件工程师靠什么赚钱？

AI 写了90%的代码，未来软件工程师靠什么赚钱？¶

当 AI 承担越来越多的代码编写工作，软件工程师的价值如何变化？本文围绕开发效率、初级岗位、系统架构、领域知识和质量验证梳理研究证据，区分代码生成占比、任务完成率与实际商业产出，并分析就业、产品、结果分成和股权等价值分配路径。最后给出面向 AI Coding 使用者的实践建议，以及对未来变化的情景分析与研究局限。

深度研究报告
研究日期：2026年10月20日
研究范围：全球软件产业，以美国为主要实证市场，兼顾中国开发者的职业选择
研究方向：AI Coding、Agent、自主软件开发、初级岗位变化、系统架构和工程判断的长期价值

摘要：软件工程师的价值正在发生转移¶

核心结论：未来软件工程师仍然能够获得高收入，但市场支付报酬的依据，将逐渐从“编写代码的能力”，转向“利用技术交付可靠、具有经济价值的软件系统的能力”。

这并不意味着编程知识即将失去价值。相反，AI 越能大量生成代码，系统理解、需求定义、技术判断、质量验证和结果责任就越重要。

研究发现，五个变化已经出现：

代码生成正在迅速自动化。 2026年1月，Sonar 对1100多名专业开发者的调查显示，受访者估计其提交的代码已有约42%由AI生成或辅助，预计2027年达到65%。但这是调查估计，不是全行业的代码审计结果。Sonar 开发者调查
初级工程师的就业压力已有实证信号。 斯坦福大学2026年8月更新的研究发现，美国22—25岁劳动者在AI高暴露职业中的就业水平，相对于低暴露职业的同龄人，出现约19%的差距。这不是“19%的程序员失业”，研究也不能单独证明AI造成了全部差距。Stanford Digital Economy Lab
AI确实能够提高生产力，但效果取决于任务。 微软等企业的一项随机对照研究发现，AI工具使开发者完成的任务数量平均增加26.08%；但METR针对资深开源开发者的早期实验却发现，AI使任务耗时增加19%。这说明生产力提升并非无条件成立。Microsoft Research；METR
领域知识仍然具有价值。 Anthropic 2026年6月对约40万次 Claude Code 会话的分析发现，具备更强相关领域知识的使用者，通常更容易成功完成任务和纠正Agent的错误。Anthropic 研究
软件工程师并没有整体消失。 美国劳工统计局2026年发布的预测仍认为，2025—2035年软件开发者就业人数将增长约10%，显著高于全部职业平均水平。但这是预测，并不能保证初级岗位同样增长。美国劳工统计局

因此，需要同时接受两个看似矛盾的判断：软件开发需求可能继续扩大，而仅依靠基础编码技能进入行业的机会可能减少。

核心证据概览¶

指标	数值	性质与口径
2026年初AI辅助代码占比	约42%	Sonar 开发者自报估计
2026年AI编码助手使用率	66%	Stack Overflow开发者调查
高AI暴露职业年轻劳动者的相对就业差距	约−19%	Stanford，不是失业率
美国软件开发者就业人数预测	+10%	BLS，2025—2035年累计增长

重要限制： 开发者调查、行政就业观察数据与官方预测不属于同一种统计口径，不能直接相加或进行简单因果推断。

一、首先验证：“AI写了90%的代码”究竟是真是假？¶

1.1 这不是一个虚构数字，但不能推广到整个行业¶

2026年5月，Anthropic 首席财务官 Krishna Rao 在 Invest Like the Best 访谈中表示，公司内部超过90%的代码由 Claude Code 编写。

Anthropic 随后在《When AI Builds Itself》中披露了更严格的统计口径：

2026年5月，合并进入公司代码库的代码中，超过80%可归因于 Claude。
第二季度，典型工程师每天合并的代码行数约为2024年的8倍。
公司同时承认，代码行数增长8倍不代表真实生产力提高8倍，因为代码数量不等于质量和业务产出。

资料：Anthropic — When AI Builds Itself

换言之，在最先进的AI企业内部，“AI编写绝大部分代码”已经是现实，而不是单纯的未来预测。

但观察其他企业，比例并不统一。Sonar 的2026年调查估计AI贡献约42%的提交代码，说明行业采用水平仍存在巨大差异。

这里最关键的是区分四个指标。

衡量对象	能说明什么	不能说明什么
AI生成代码占比	自动生成代码的普及程度	软件开发有多少价值由AI创造
AI提交或合并的代码占比	AI产物通过了部分工程流程	产物没有缺陷或维护成本
AI独立完成任务的比例	特定任务上的自主能力	能否长期运营完整产品
实际商业产出	软件是否带来收入、成本节约或客户价值	价值一定由某个工程师独立创造

一个能够生成10万行代码的Agent，并不一定比一个删除5000行冗余代码、解决性能瓶颈的工程师更有价值。

代码生成能力正在快速商品化，但软件系统的经济价值并不由代码量直接决定。

1.2 Agent与传统AI编码助手的区别¶

传统的代码补全工具主要在人已经决定怎么写的基础上，提高输入效率。新一代Coding Agent则可以读取仓库、修改多个文件、执行命令、运行测试、定位失败原因并迭代。

这改变了工作的基本单位。过去，工程师常常把工作拆成函数、类、文件，再亲自实现。现在，一个明确的工程任务就可能成为AI接受的最小工作单位。

Anthropic 2026年6月对约40万次Claude Code会话的分析发现，用户平均承担约70%的规划决策，Claude承担约80%的执行决策。来源

决策类型	人类主导	AI主导
规划决策	约70%	约30%
执行决策	约20%	约80%

注意：这是研究中的决策分类统计，不是工作时间或经济贡献比例。

这是一个具有经济意义的变化：过去的工程师主要直接执行任务，未来的工程师可能越来越多地管理软件生产过程。但它还不等于完全自主的软件开发。

现实中的软件工程至少涉及六个环节：确定商业需求、定义技术目标、设计系统、实现代码、验证质量、部署与长期运营。一个Agent即使能够完成实现阶段，也不等于能够独立承担整个生命周期。

1.3 自主Agent究竟发展到了什么水平？¶

METR 使用“任务完成时间视野”（Task-Completion Time Horizon）衡量AI能力：观察AI能以指定成功概率完成多复杂的任务，再用人类专业人员完成同类任务所需的时间表示其难度。

截至2026年9月的公开评测表明，前沿模型已经能处理以人类数小时乃至更长时间衡量的任务，但研究明确提醒：

50%成功率的任务视野，不意味着可以可靠地完成同样长的完整项目。
评测任务通常经过清晰定义，主要集中于软件工程、机器学习和网络安全。
模型能力存在明显的不均衡性，不能把某类任务的成绩推广到所有工程工作。

Anthropic 2026年9月更新的内部评估显示，在其自身定义的开放式任务上，Agent的成功率已达到约91%。不过，这一指标依赖Claude进行评判，不能等同于独立第三方验证的长期生产可靠性。Anthropic

反面观点：人类规划与工程判断的优势也可能逐渐被AI侵蚀。 不能因为目前工程师负责定义目标，就假定这个分工十年后仍然存在。更稳健的判断是：在可预见的职业规划中，应该不断向更高价值的工程责任移动，而不是押注某项具体任务永远无法被AI完成。

二、AI究竟有没有提高软件开发生产力？¶

这是本研究最有争议、也最重要的实证问题。

2.1 三组研究，呈现三种不同结论¶

研究	样本与方法	主要结果
微软等企业，2025	4867名开发者、三个企业随机对照实验	完成任务数量平均增加26.08%
METR，2025	16名资深开源开发者、246个真实任务	使用AI后任务耗时增加19%
METR，2026更新	57名开发者、800多个任务	部分样本出现加速迹象，但结果不足以可靠估计真实幅度

资料：Microsoft Research；METR更新

表面上看，这些研究似乎相互矛盾，其实很可能测量了不同环境下的不同效应。

微软等企业的实验观察到，AI工具对经验较少的开发者帮助更明显。这符合一个合理解释：AI能迅速提供语法、框架API和常规实现方法，从而减少查找与试错成本。

而METR的早期实验中，参与者平均已在相关开源项目工作约五年。他们对代码结构、历史设计和质量要求非常熟悉。让AI介入，反而可能增加解释上下文、阅读生成代码、修改不合适实现的成本。

2026年2月，METR公布更新实验：原实验中继续参加的开发者样本出现约18%的耗时缩短点估计，新招募参与者出现约4%的耗时缩短点估计。不过，两组置信区间都跨过零，且越来越多的开发者拒绝在不能使用AI的条件下工作，造成严重样本选择偏差。METR明确表示，不能据此给出可靠的当前生产力增幅。

因此，不能继续把2025年的“AI让开发者慢19%”当作2026年行业的普遍事实，也不能用未经充分验证的自报加速倍数代替真实实验。

2.2 生产力提高，为什么不一定意味着软件交付更快？¶

因为编程只是软件生产链的一部分。

可以建立一个简化模型：

\[ T_{\text{交付}}=T_{\text{需求}}+T_{\text{设计}}+T_{\text{编码}}+T_{\text{验证}}+T_{\text{部署}} \]

假设某项目原本有30%的时间用于编码，AI将编码速度提高3倍，而其他环节完全不变，那么：

\[ \frac{T_{\text{新}}}{T_{\text{旧}}}=0.7+\frac{0.3}{3}=0.8 \]

编码速度提高200%，总交付时间却只缩短20%。

这只是说明机制的假设计算，不是实测数据。

如果生成代码进一步增加了验证、返工、集成时间，总收益还会下降。

Google 2025年DORA研究调查了近5000名技术人员。结果发现，AI采用与交付吞吐量、产品表现呈正向关联，但与软件交付稳定性仍存在负向关联。研究团队据此认为，AI更像一个组织能力放大器：已有良好架构、自动化测试和反馈机制的团队更能受益，流程薄弱的团队反而可能暴露更多问题。Google DORA

这解释了为什么AI能让个人感到效率飞跃，却未必使整个公司的交付效率同比例提高。

2.3 验证将成为越来越重要的瓶颈¶

Sonar 2026年的调查还有两个值得关注的数据：38%的开发者表示，审查AI生成的代码比审查人类同事的代码更费力；只有48%的受访者表示，自己总是在提交之前验证AI生成的代码。

这两个数字不等于AI代码的错误率。但它们提示，组织可能正在把成本从生成环节转移到审查环节。

与此同时，也不能武断地认为AI代码一定比人工代码差。Anthropic 2026年10月16日公布的内部研究，对同一工程师、同一月份、同一代码目录的AI与人工提交进行了比较，未发现两者在后续代码删除、回滚等代理指标上存在明显差异。研究也承认，这些指标无法覆盖所有代码质量维度。Anthropic研究资料

AI使代码供给快速增长，而可靠性和验证能力决定新增产能能否真正转化为价值。

三、就业市场：初级工程师是否正在成为最脆弱的一群人？¶

3.1 最重要的变化，可能发生在招聘入口，而不是大规模裁员¶

斯坦福大学Digital Economy Lab在2026年8月12日更新的研究，使用ADP覆盖数百万美国劳动者的工资行政数据，观察截至2026年6月的就业变化。

其中有三项发现尤其重要：

研究没有发现生成式AI已经造成全经济范围的大规模就业替代。
22—25岁年轻劳动者在高AI暴露职业中的就业表现显著弱于低暴露职业的同龄人，差距达到约19%。
差距主要表现为年轻劳动者招聘减少，而不是已有员工被大量解雇。

来源：Stanford Digital Economy Lab

这产生了一个值得重视的现象：企业可能仍然需要成熟的软件工程师，却减少了培养新人的意愿。

一个更加直接的案例来自Anthropic。2026年10月16日，公司公开其内部就业研究，披露如下变化：

Anthropic技术部门指标	2025年初	2026年观察值
初级员工占技术部门员工比例	21%	14%
初级岗位占技术部门新招聘比例	27%	9%

来源：Anthropic — How Employment Is Changing at Anthropic

这是一家高度使用AI的前沿企业，不能直接代表中国互联网公司或整个全球软件行业。不过，它显示出一种可能扩散的组织模式：企业继续扩张，却把招聘资源更多地投向能够独立承担复杂任务的人。

3.2 为什么初级岗位更容易被压缩？¶

传统软件工程的人才培养常依赖以下路径：

简单实现与修Bug：新人获得真实代码经验。
模块所有权与测试责任：逐渐理解依赖、接口及故障模式。
跨模块设计与系统决策：发展架构判断与技术取舍能力。

这个培养模式面临一种结构性冲击：AI正好可以处理许多过去分配给新人的常规编码任务。

但高级工程师所需要的系统知识、故障经验和责任判断，并不会因为新人跳过基础工作而自动获得。

Anthropic 2026年1月发表的一项随机对照研究，就专门分析了这种技能形成风险。参与者学习新的Python库时，使用AI辅助组在后续知识测验中的成绩比手动编码组低17%；AI组任务完成稍快，但这一速度差异未达到统计显著性。研究同时发现，主动要求解释、追问概念的AI使用方式，可以减轻学习效果下降的问题。Anthropic — AI Assistance and Coding Skills

这个结果并不能证明长期依赖AI必然导致能力退化，因为实验任务和观察期都有限。但它确实提出了一个教育与就业难题：

如果企业减少基础任务，而年轻开发者又缺少独立理解和验证代码的机会，那么未来高级工程师将从哪里培养出来？

这是未来软件行业需要解决的长期矛盾。

3.3 为什么仍不能断言程序员是衰落职业？¶

美国劳工统计局在2026年发布的2025—2035年就业预测中，预计软件开发者人数增长约10%。2025年美国软件开发者年薪中位数为135,980美元。BLS

这与初级岗位承压并不矛盾，因为两者衡量的对象不同。

一方面，AI能提高每名工程师的生产效率，企业可能用更少的人完成原有工作。

另一方面，软件开发成本降低之后，原本不值得开发的项目也可能变得经济可行，从而创造新的工程需求。

最终就业增长取决于两种力量的竞争：

\[ \text{劳动力需求变化}\approx\text{软件需求扩张效应}-\text{单位产出所需人工减少效应} \]

这一表达是经济机制的概括，而非可以直接代入数据的预测模型。

当软件成本下降引发大量新增需求时，就业仍可能增长；当需求增加不足以抵消自动化效率时，就业就可能收缩。

BLS预测是对未来经济的条件性判断，不是就业保障；Stanford研究则是过去数据中观察到的就业差异，也不是能够直接外推十年的趋势线。

综合证据：初级软件工程师的传统成长路径正在受到冲击，但软件工程职业整体进入长期萎缩尚未得到充分证实。

四、未来软件工程师真正值钱的六种能力¶

软件开发的经济价值并没有凭空消失，而是在软件生产链条上重新分配。

过去，编写代码本身是一项稀缺技能。未来，企业可能更加重视那些能够定义目标、处理复杂系统和承担结果责任的人。

4.1 六类能力的价值变化¶

下表是基于已有研究作出的定性预测，不是职业薪资排名。

核心能力	AI替代压力	未来价值判断
常规功能实现、样板代码	高	独立溢价下降
熟悉已有框架并完成开发	中高	需要向完整模块交付延伸
系统架构与技术取舍	中	复杂系统中仍有较强价值
性能、可靠性、安全工程	中	验证和运行责任的重要性提升
理解业务并交付产品	中	能直接创造商业价值
跨领域技术整合与决策	中低至不确定	可能形成较强竞争优势

这里的“替代压力”不是指AI能不能执行其中某些步骤，而是指企业是否容易以更低成本获得同等可靠的结果。

4.2 系统架构为什么仍然值得学习？¶

系统架构不是简单地画一张微服务图，也不是决定用Python还是Go。

真正有价值的架构能力，是在约束条件下作出可验证的技术取舍。

例如，一个视频监控系统需要把摄像头的实时视频保存下来，支持用户检索、下载和回放。

表面需求很简单：实现视频录制。

实际问题却包括：

H.264视频流中的关键帧如何影响分段与独立解码？
网络抖动、断流与重连会产生什么数据完整性问题？
写入数据库和写入视频文件之间如何保持一致？
用户请求回放时，如何避免读取到尚未完成写入的数据？
系统应该在低延迟、完整性、存储成本之间如何取舍？

AI能够针对这些问题提出方案，也能够实现大量代码。但是，如果没有明确的系统约束和验收标准，AI可能生成一套看似合理、实际上无法满足生产需求的方案。

架构能力的价值就在这里：不是知道某一种技术，而是能理解多种技术之间的交互，并在真实约束下作出可解释、可验证的选择。

未来，这种能力也可能被更先进的Agent部分自动化。因此不能把“架构师”视为天然安全的职位。真正有价值的是能够持续判断方案优劣，并对结果负责，而不是掌握一个固定的架构头衔。

4.3 领域知识可能比单纯的编程熟练度更有价值¶

Anthropic 2026年6月的研究在这一点上提供了很有意思的证据。

在涉及代码修改的Claude Code会话中，软件相关职业用户达到严格验证成功标准的比例约为34%，非软件职业用户约为29%。采用较宽松的“至少部分成功”标准时，两组分别约为89%和88%。Anthropic相关研究

这意味着：在该研究的会话层面，非程序员也能借助Coding Agent完成大量编程任务。但该研究同样发现，任务相关专业知识越扎实，成功率通常越高，遇到困难后恢复任务的能力也越强。

这使一些过去很难独立开发软件的专业人员获得了新机会。例如，金融分析师能够自己开发财务分析工具；硬件工程师能够利用AI快速构建测试软件；生物学研究人员能够制作数据处理和可视化系统。

他们的优势不一定在于会写多少代码，而在于知道结果应该满足什么专业标准。

不过，研究中的“成功”主要来自测试、提交记录和模型对会话的判定，并不等于实际商业成功。对任务的专业理解也不能代替大型系统所需要的全部软件工程知识。

未来更有竞争力的一类人才，将是领域专家与软件工程能力的结合体。

4.4 可靠性、安全和平台工程为什么可能出现溢价？¶

AI能快速生成大量功能，但软件一旦进入生产环境，就必须面对不确定性。

这些问题包括多用户并发、异常恢复、数据库一致性、授权验证、供应链漏洞、生产事故和长期维护。

此时，速度不再是唯一目标。

对于一家交易系统公司而言，开发新功能可能只需要几天，但因严重Bug造成一次错误结算，损失可能远高于开发成本。

当企业开发产能变得充裕时，它可能愿意为降低这种风险支付更高的费用。

Google DORA的研究和2026年软件开发AI投资回报框架，都强调自动化测试、反馈机制、平台质量以及把工程效率转化为真正的财务回报。Google DORA

因此，值得关注的方向包括平台工程、数据库与分布式系统、应用安全、可观测性、性能工程以及AI Agent评测与治理。

但这不是说学习这些技术就自动获得高薪。只有掌握它们并能够解决企业真实问题，才可能形成收入溢价。

五、软件工程师未来究竟靠什么赚钱？¶

从经济学角度，应该先区分两个问题：一个人能够创造多少价值，以及他能够从这些价值中获得多少收入，并不是同一回事。

AI降低软件开发成本之后，新增收益可能被客户、企业所有者、模型供应商和工程师共同分配。工程师的收入取决于自身技能的稀缺性、替代成本、议价能力以及是否拥有产品或股权。

5.1 第一种：通过就业获得专业能力溢价¶

这仍然是大多数工程师最现实的收入模式。但未来的高价值岗位可能不再围绕代码数量划分，而是围绕系统复杂度和业务责任划分。

方向	企业为什么愿意付钱
基础设施工程师	保证大规模系统的性能和稳定性
安全与可靠性工程师	降低可能造成重大损失的技术风险
平台工程师	提高整个研发组织的交付效率
AI应用工程师	将模型能力整合成可实际使用的产品
Forward Deployed Engineer（客户现场交付工程师）	直接解决客户复杂环境中的业务与技术问题
跨领域系统工程师	连接软件、硬件、行业技术与实际业务需求

这些岗位的共同特征，并不是不写代码，而是对企业价值链中的关键环节负责。

其中，Forward Deployed Engineer尤其值得关注。它通常要求工程师深入客户环境，理解业务流程、集成现有系统、部署产品并解决实际使用中的技术问题。

这类岗位体现了一种趋势：企业不仅需要有人制造技术，也需要有人把技术可靠地转化为现实生产力。

不过，它们的工资溢价仍需结合国家、行业和具体招聘数据判断，不能仅凭岗位名称推断收入。

5.2 第二种：通过产品所有权赚钱¶

AI可能显著降低个人创业的技术门槛。

过去，一个人要构建商业软件，常常需要前端、后端、数据库、测试和部署等多方面开发能力，或者雇佣一个团队。现在，个人能够借助Agent完成更多工作。

但这不意味着创业会普遍变容易。因为当所有人都可以低成本开发软件时，产品供给也会增加。单纯能够做出某个功能，就不再构成很强的竞争壁垒。

创业者依然要回答三个问题：谁需要这个产品、客户为什么愿意付款，以及竞争者为什么不能轻易取代它。

例如，一个普通待办清单应用的开发成本可能越来越低，但由此产生的市场竞争也会越来越激烈。相比之下，为某一行业解决复杂业务流程问题的软件，可能更容易形成客户关系、数据积累与工作流集成方面的壁垒。

未来独立开发者更应该追求的是：利用AI降低技术开发成本，把更多精力投入客户理解、产品分发、商业模式和长期运营。

当然，收入上限越高，商业失败风险通常也越高。

5.3 第三种：通过企业成本节约与结果分成赚钱¶

这是一条容易被忽略的路径。

假设某企业有一项业务流程，每年需要支付相当可观的人力成本。工程师不一定要创造新的消费产品，也可以利用AI和自动化技术，减少该流程的耗时、错误或重复劳动。

例如，通过自动化处理报表、合同流转、客户信息核对或内部知识检索，提高组织的实际运营效率。如果能够量化节约的成本，就更容易说明工程服务的价值。

这种商业模式可能表现为咨询费、项目交付费、维护订阅费，或者在合适的合同条件下按照实际节约效果分成。

关键不在于AI工作了多少小时，而在于客户实际获得了什么结果。同样，这条路径仍然需要客户信任、权限管理、数据安全、持续维护和售后责任。

5.4 第四种：通过股权分享组织生产力提升¶

如果AI能够使一个成熟团队承担过去几倍的开发任务，那么拥有团队产品或股权的人，可能获得与普通受薪员工不同的经济收益。

这也是为什么“AI让工程师效率提高三倍”不能直接推出“工程师工资提高三倍”。

企业可能选择减少招聘、降低价格、扩张业务、增加利润，或者将收益投入更多研发。

工程师能分到多少，取决于组织薪酬制度和资本结构。

从长期财富积累角度看，技能收入和资产所有权是不同的机制。前者依赖劳动市场定价，后者依赖资产及企业创造的剩余价值。

六、2026—2030年，软件行业可能发生的三种变化¶

以下全部属于情景推演，而不是已经发生的事实。不建议为三种情景随意分配百分比，因为现有证据不足以支持可靠的概率估计。

情景A：AI扩大软件市场，工程师总体需求继续增长¶

软件开发成本显著下降，大量中小企业开始购买或自建过去负担不起的软件。工程师人数可能增长，工作重点转向需求、集成和长期运营。

关键观察信号： 新软件企业数量、商业软件支出、开发者总就业人数持续增长。

情景B：行业出现明显分化¶

高水平工程师管理多个Agent，承担复杂系统交付；常规编码岗位的议价能力下降，初级招聘减少。就业可能继续增长，但机会向能够独立解决问题的人集中。

关键观察信号： 初级与资深招聘差距扩大、薪资分化，以及每名员工负责的系统范围增加。

情景C：Agent实现高度自主的软件生产¶

AI不仅能够写代码，还能可靠地完成需求分析、架构选择、故障处理和迭代规划。多数常规工程实施工作由Agent承担，人类团队主要负责战略、治理与少量复杂例外情况。

关键观察信号： 长期无人工干预的软件运行表现、独立审计的质量数据，以及企业软件工程岗位净需求变化。

从2026年的证据出发，情景B已经出现初步迹象，情景A和C都仍然有现实可能。

不能假设AI能力长期停留在现有水平。Anthropic自己的研究也指出，其模型在开放式工程任务和部分研究判断任务上的能力持续提升。Anthropic

但也不能因为模型在代码评测上取得高分，就断定真实企业已经能够完全取消工程团队。

例如，OpenAI在2026年7月公布对SWE-Bench Pro的审计，认为其中约30%的任务存在问题。该研究来自模型开发商自身，需要考虑利益关联，但它提醒我们：即使是高难度软件工程基准，也可能存在错误测试、任务定义问题和评价失真。OpenAI研究

因此，对未来职业风险的评估，应该持续观察真实生产环境中的成功率、长期维护成本和劳动力需求，而不应只看模型排行榜。

七、反面证据：为什么“只要有工程判断就永远不会失业”也是错误的？¶

本研究不能只停留在“AI负责写代码、人类负责思考”这个简单结论。它至少有四个问题。

第一，工程判断本身也是一种认知任务。 如果AI能根据日志、测试和约束条件不断改善决策，那么诊断、架构选择甚至需求规划都可能进一步自动化。人类当前拥有优势，不代表它永远不会缩小。

第二，专业知识并不必然转化为高工资。 某种技能很有用，不意味着它在劳动市场中足够稀缺。企业可能把专业流程标准化，再利用Agent降低对特定专家的依赖。

第三，提高个人生产力可能降低团队对新增员工的需求。 即使单个工程师产出更高，也不代表所有工程师都能分享增长收益。

第四，企业可以调整组织结构。 未来一些常规软件可能直接由业务人员利用Agent完成，不再经过传统软件开发团队。

Anthropic内部的研究已经记录了部分非技术员工利用编码Agent自主制作工具的现象，同时也观察到了技术团队初级岗位占比下降。Anthropic就业研究

这些事实意味着，“学习系统架构”“培养业务意识”都是相对更好的应对策略，却不是对未来工资和就业的保证。

真正更稳健的策略，是不断形成能够被外部验证的解决问题能力，同时保留跨行业、跨技术路径转移的可能性。

八、对正在使用AI Coding的大学生，具体应该怎么做？¶

这一部分属于基于前述证据的行动建议，而不是实验研究结论。

不建议现在放弃AI Coding，退回纯手写代码，那样可能会失去已经存在的生产力优势。

但同样不建议把绝大部分项目交给Agent完成，自己只阅读最终提交结果。

更有价值的方式是：让Agent承担大量实现工作，但自己逐步掌握需求定义、系统分析、验证方法和最终交付责任。

8.1 用一个已有项目训练完整工程能力¶

以视频录制与回放系统为例，完全可以建立一个真正的工程能力训练项目。目标不是重新写一遍已有代码，而是证明能够独立解释和验证整个功能链路。

周次	核心目标	交付物
第1周	完整理解系统	绘制视频输入、缓存、录制、数据库登记、文件下载、用户回放的端到端数据流图
第2周	理解核心协议	解释RTSP、H.264、关键帧、SPS/PPS和时间戳处理，自己复现至少一个边界问题
第3周	建立技术决策记录	选择一个关键技术方案，对比至少两种实现，写清性能、复杂度和失败风险
第4周	建立验证体系	设计正常场景、断流、并发、关键帧缺失、写入失败等测试，记录可复现结果
第5周	分析生产故障	基于日志与代码追踪真实问题，先提出假设，再让AI辅助定位和验证
第6周	进行性能评估	测量内存、CPU、延迟、吞吐量或存储开销，找到一个实际瓶颈
第7周	完成可验收改进	制定验收标准，提交改进PR，附测试和回归证据
第8周	输出工程案例	写一份技术复盘，说明问题、取舍、实现、验证、失败经验和最终价值

八周只是建议节奏，可以根据课程和工作量调整。这里最重要的是第3周、第4周和第7周，因为它们把工作从“完成代码”推进到了“独立作出决策并承担验收责任”。

8.2 把AI使用方式从“代写”转变为“带验证的协作”¶

每项较复杂的开发工作，都可以采用如下闭环：

人类定义需求与验收标准： 什么结果才算正确？有哪些不能违反的约束？
AI生成候选方案并执行： 实现、测试、工具调用、文档修改。
独立验证与反证： 检查边界条件、回归测试和失败模式。
人类决定是否交付： 对照目标、审查风险、记录取舍。
不满足标准就循环： 返回方案分析与实现阶段。

AI可以协助完成其中每一环，但使用者应该具备独立判断关键结果是否可信的能力。

特别需要注意一个区别：让第二个AI审查第一个AI的代码，并不等于独立验证。多个Agent可能共享相似的错误假设。

真正的独立验证需要尽可能采用外部证据，例如真实输入输出、测试用例、性能测量、静态分析、故障注入以及用户验收。

8.3 如何判断自己的AI Coding能力是否真的在进步？¶

不要只记录生成了多少代码、合并了多少PR，更应该记录以下指标：

指标	测量方式
系统理解	能否解释核心数据流、关键依赖和失败路径
独立诊断	不看AI结论时，能否提出合理故障假设
需求澄清	开工前识别了多少重要边界条件
交付质量	真实验收通过率、返工和回归缺陷
维护能力	能否快速定位并安全修改旧代码
业务贡献	是否减少成本、解决事故或提高用户体验

可以每个月挑选一个真实任务，尝试在不让AI直接给出答案的条件下，先完成需求分析和技术设计，再与Agent的方案比较。

这样既保留了AI带来的开发效率，也避免把整个学习过程外包出去。

九、哪些知识最值得作为长期资产积累？¶

在现有趋势下，更推荐一种“T型”能力结构：保持一定的软件工程通用深度，同时建立至少一个扎实的专业领域优势。

通用工程能力（横向）： 编程、数据结构、操作系统、网络、数据库、软件测试、AI Coding。

专业深度（纵向）： 真实业务领域或复杂工程系统，以及与之对应的独立判断和交付能力。

基础学科依然重要，但学习目标需要变化。

学习数据库，不只是为了会写SQL，而是要理解事务、一致性、索引与并发。
学习网络，不只是为了写HTTP请求，而是要理解连接状态、重试、超时与分布式故障。
学习操作系统，不只是为了记住进程线程的定义，而是要理解内存、调度、I/O及其对生产系统的影响。
学习软件架构，不是背诵设计模式，而是理解为什么某些设计能够降低长期变化的成本，另一些设计则会积累技术债务。

这些知识的长期价值，不在于AI不能回答相关问题，而在于它们能够帮助使用者识别AI提出的方案是否成立。

对具有光电与软件背景的人，还可以考虑将这种工程基础应用于智能传感、机器视觉、边缘AI、嵌入式系统、工业自动化等场景。

这些领域存在硬件、软件和物理环境之间的交互约束。实际设备测试、测量结果和部署环境可能成为重要的能力差异来源。

当然，它们不是天然高薪行业。应当进一步结合目标地区的岗位数量、薪酬、技术门槛和企业质量作出选择。

十、研究结论的可靠性与局限¶

这项研究使用的证据来自多个层次，因此不能简单把所有百分比拼在一起推出一个预测。

证据类型	代表资料	主要优势	主要限制
随机对照实验	Microsoft、METR	有助于识别特定条件下的因果效应	任务、参与者、工具版本限制外推
行政就业数据	Stanford与ADP	大规模实际就业记录	难以单独识别AI的因果贡献
官方就业预测	美国BLS	系统性职业统计与预测	不保证未来情景实现
开发者调查	Stack Overflow、Sonar	覆盖大量实际开发者	自选择和自报偏差
企业内部遥测	Anthropic	接近真实Agent使用行为	单一企业、内部统计口径及利益关联
软件工程基准	METR、SWE-Bench系列	可重复测量技术能力	测试集、评分标准及真实环境差异

尤其需要强调三项不确定性。

首先，技术变化速度很快。2025年的模型能力和2026年的模型能力不能视为相同，单个旧实验不能永久代表最新工具的效果。

其次，研究结果主要来自美国和国际化的软件开发环境。中国企业的招聘成本、行业结构、管理方式和工资形成机制不同，无法直接从美国数据推导国内程序员收入。

最后，创造价值和获得报酬之间存在分配问题。即使未来的软件工程生产率显著提高，也不能确定这些收益将以工资形式流向工程师。

因此，这份报告对未来方向的结论，应当理解为基于当前证据的条件性判断，而不是就业或收入预测的保证。

十一、核心参考资料¶

以下优先列出研究机构、数据发布者和企业的一手材料，方便进一步查阅。

文献	时间	研究价值
Anthropic — When AI Builds Itself	2026	AI代码占比、内部生产率和自主开发能力
Agentic Coding and Persistent Returns to Expertise	2026.06	40万次Agent会话、领域知识与人机分工
How Employment Is Changing at Anthropic	2026.10	AI对企业招聘、组织结构和生产率的影响
METR — Developer Productivity Experiment Update	2026.02	开发效率实验以及样本偏差
Microsoft Research — Three Field Experiments	2025	随机对照实验中的开发效率提升
Stanford — Canaries in the Coal Mine	2026.08	年轻劳动者与高AI暴露职业就业
Stack Overflow Developer Survey	2026	AI开发工具的使用、信任与任务分布
Google DORA Report	2025	AI与软件交付质量、稳定性的关系
US BLS — Software Developers	2026版	软件工程师薪酬与就业预测
Anthropic — AI Assistance and Coding Skills	2026.01	AI使用对技能学习的实验研究
OpenAI — Separating Signal from Noise	2026.07	软件工程评测的质量与局限

参考资料为报告整理时采用的研究链接。部分正文数据出自这些资料的调查页、企业研究或其对应的原始发布版本。引用中的各项统计必须结合原研究的样本、口径与方法阅读。

十二、最终判断¶

回到最初的问题：当AI可以写90%的代码，未来软件工程师靠什么赚钱？

答案可以归纳为三个层次。

第一，软件工程师过去赖以获得报酬的部分技能正在迅速商品化。 常规代码生成、基础页面实现和标准化开发工作，越来越难单独构成长期竞争壁垒。

第二，软件工程能力并没有因此变得无关紧要。 相反，在代码生成快速增长的情况下，系统理解、可靠性、验证、业务需求和复杂技术整合能力成为更加重要的价值来源。掌握AI工具，可以放大这些能力，但不能自动替代它们。

第三，未来高收入工程师未必是代码写得最多的人。 更可能是能够独立负责复杂系统、解决高成本问题、直接服务客户，或者拥有有竞争力的软件产品的人。

但还要保留一个重要警告：AI并不会永远停留在执行层面，今天的人类优势也可能继续被侵蚀。

因此，未来最值得建立的竞争力，不是某种工具使用技巧，也不是对特定技术岗位永远安全的信念，而是一种更深层的能力：

持续理解复杂问题，利用不断进步的技术找到可靠解决方案，并让解决方案真正创造可以衡量的经济价值。

如果把软件工程职业看作长期投资，值得追求的不是成为一个比AI更快的代码生产者，而是成为一个能够管理技术复杂性、承担真实结果责任，并参与价值分配的人。

研究完成于2026年10月20日。文中所有关于2027—2030年的判断均属于前景分析；已经发生的事实、统计关联、实验结果和未来预测在正文中分别作出了区分。