AI工程师的薪资正在两极分化
我想给你讲两个我认识的工程师的故事。同一家公司。同样的头衔。同样在岗位上待了四年。其中一个刚刚晋升为 Staff 级别,总薪酬包达到 34 万美元。另一个则被列入了绩效改进计划。
几个星期以来,我一直在思考是什么将他们区分开来。不是因为结果令人惊讶——事后看来这几乎是必然的——而是因为他们都没有预料到。我怀疑读这篇文章的很多人距离这种不确定性比自己意识到的要近得多。
所以让我说出大多数职业文章不会直接说出来的话。
1、分裂已经在发生,大多数人只是还没有感受到
数据已经不再微妙了。
软件工程岗位的招聘量相比 2022 年的峰值下降了约 70%。入门级职位相比 2020 年下降了 34%。与此同时,自 2024 年中期以来,AI 工程师的岗位数量翻了一倍多。美国 AI 工程师的总薪酬中位数现在约为 24.5 万美元——前四分位数超过 35 万美元。
但让我第一次看到时感到震惊的数字是这个:AI 人才的薪酬已经分裂成了两个完全独立的市场。企业级 ML 工程师的总薪酬为 17 万至 24.5 万美元。而在前沿实验室的那批人,同样的职位名称却能拿到 60 万到 100 万美元以上。
同样的头衔。四到六倍的薪资差距。这不是薪资范围。这是两个不同的职业穿着同样的名牌。
而且这种分裂不仅仅发生在前沿实验室。2026 年,专业领域的 AI 工程师薪资同比增长了 9-12%。通用软件工程师的薪资呢?持平。这种分化是悄无声息的,而且无处不在。
让我感到担忧的是:处于错误一边的工程师在日常工作中不会感受到这种变化。他们会在下一次薪酬评审时感受到。或者在再下一次。或者在试图跳槽时发现,他们以为自己有资格胜任的岗位已经悄悄抬高了门槛。
2、我想坦诚地谈谈错误的那一边是什么样的
因为我认为大多数关于这个话题的写作都不够坦诚。
那个被列入 PIP 的工程师并不懒。他也不无能。他对自己十八个月前的那份工作确实很擅长——但那份工作已经不存在了。
他知道如何调用 OpenAI API。他构建过 LangChain 流水线。他能在一些指导下微调模型。他在概念层面上理解 Transformer 的工作原理。所有这些都是真实的。没有一样是无用的。
但令人不适的事实是:这些技能中的每一项,其商品化的速度都比任何人预测的要快。2023 年让你脱颖而出的东西,现在已经被列在了你想要的 2026 年岗位的"基本要求"之下。底线提高了。溢价转移到了别处。而没有人发出任何通知。
超过 75% 的 AI 岗位招聘现在要求的是领域专家,而不是通才。通才面临着来自拥有相同工作经验但薪资要求高出 30-50% 的候选人的日益激烈的竞争。这不是一个小差距。这是市场价值判断的结构性转变。
之所以难以察觉,是因为它不像是落后了。它感觉像是跟上了。你在学习新工具。你在交付功能。你的经理喜欢你。从内部看一切正常——直到某个时刻不正常了。
他之前感觉很好。直到晋升周期到来。然后十八个月来悄然扩大的差距一下子变得清晰可见。
这是我反复看到的模式。不是突然的跌落。而是一种缓慢的漂移,不断累积,直到有人给它定了一个数字。
3、那么另一边是什么样的呢?
她并没有在构建更花哨的东西。她也不更聪明。她在问一个不同的问题。
不是:我如何使用这个模型?
而是:我怎么知道这个模型是否真的在正常工作?
这种重新定位——从构建转向验证,从交付转向理解——现在被证明非常有价值。不是因为这在抽象意义上很稀缺,而是因为很少有工程师花足够长的时间思考这个问题,从而发展出真正的答案。
Karat 对 300 多位 CTO 的调查发现,73% 的人认为优秀的工程师至少值其总薪酬的 3 倍。他们描述的工程师不是那些构建令人印象深刻的 Demo 的人,而是那些能够将 Demo 变成一个在无人监督时也能可靠运行的系统——并且能够从系统内部告诉你什么时候出了问题的人。
这正是市场供不应求的能力。而这也是她过去一年一直在培养的能力,与此同时他却在深化市场已经供过于求的技能。十二个月后,她收到招聘人员的电话懒得回复。他在为自己仍未完全理解的 PIP 撰写自我评估。
我说这些不是为了苛刻。我说这些是因为我认为有必要清楚地指出:分化不在于天赋或努力。而在于你选择关注哪些问题,以及什么时候关注。
4、真正造成差距的三个因素
我想具体说明。因为"构建系统思维"这种建议听起来很有意义,但实际上什么也没告诉你。
第一个:学会定义"好的标准"是什么
想象这个场景。一个团队交付了一个 AI 功能。几周后,用户开始抱怨回答感觉不对。工程师们拉起了仪表盘。延迟正常。错误率为零。系统标记为健康。但回答仍然是错误的。
三周过去了,终于有人手动抽样输出了才发现,自从两个 Sprint 前一次悄无声息的依赖更新以来,模型一直在自信地幻觉某一类事实。
这个故事的变种我听过无数次。而每一次,事后分析都归结为同一件事:没有人以一种系统能够自动检查的形式定义过"正确答案"是什么样子的。
这就是我所说的评估架构。不是在基准测试上运行模型——那是基本门槛。我的意思是能够为特定系统在特定上下文中定义"好的标准"是什么,精确到计算机可以持续验证,然后构建实际执行验证的基础设施。
这项技能确实很稀缺。而且这正是目前那些努力从 Demo 走向生产环境的公司最迫切在寻找的。如果你能走进一个房间,解释你会如何衡量一个 AI 工具是否在工作——不是理论上,而是实践中,针对这个具体用例——你已经领先于大多数候选人了。
第二个:理解信息实际上是如何在系统中流动的
Agent 系统中有一类失败模式让我觉得 endlessly fascinating 且严重被低估。
一个开发者加入了一个新团队。他们接手的 Agent 系统已经运行了八个月。它在简单查询上运行得还不错。但在任何复杂或多步骤的任务上,它产出的输出在技术上是一致的、但微妙地错误——那种需要领域专家才能发现的错误。
他们花了两周阅读代码库。Prompt 看起来没问题。模型没问题。各个工具调用看起来没问题。
不正常的东西在任何一个单独的组件中都是不可见的。它存在于信息架构中——每一步加载了什么到 Agent 的注意力中,步骤之间丢弃了什么,在长会话中什么会退化,以及从一开始就没有在交接中被保留什么。系统在丢失上下文,而从未有人在设计时考虑到这个问题。
这就是我所说的上下文工程(context engineering),我想明确地说,它与 Prompt 工程完全不同。Prompt 工程是关于如何表述好单个输入。上下文工程是关于理解信息如何在整个系统中流动——以及如何退化。它需要一种不同的看待问题的方式。而培养了这种能力的工程师往往能在架构评审中捕捉到其他人完全忽略的失败模式。
第三个:能够看透一个运行中的系统
一个工程师在晚上 11 点收到消息。一个客户报告了 AI 助手给出的错误定价信息。工程师拉起日志。请求成功完成。响应格式良好。延迟 340 毫秒。
他们花了两个小时试图找出问题所在。无法复现。无法追踪。当成了偶发事件算了。这不是偶发事件。这是同一个底层故障第十七次发生了。他们没有办法知道,因为他们没有办法查看。
AI 系统的生产可观测性意味着不需要等别人告诉你就能知道系统什么时候出错了。它不是请求是否完成了,而是 Agent 是否以正确的方式、正确的原因做了正确的事情。
培养了这种能力的工程师,当出问题时,能够找到出问题的确切时刻——不是"输出很差",而是在链路中的哪里,哪一步,什么原因。这种精确性将两个小时的调试变成了十二分钟。而且它改变了团队对部署变更的感受,因为他们知道能在用户之前发现问题。
5、坦诚的职业建议
现在关于 AI 职业的大多数内容都在告诉你学习下一个框架,参加下一个课程,获得上个月发布的任何东西的认证。
我认为这些建议没有抓住重点。
处于薪资分裂正确一边的工程师不是那些拥有最长认证列表的人。他们是那些构建了在生产环境中失败的东西、诊断了原因、修复了问题——而且这一部分很重要——写下了他们学到的东西的人。
最后一部分不仅关乎可见度,虽然可见度也很重要。它关乎将经验转化为理解的自律。能够清楚地写出自己实际解决过的真实问题——尝试了什么,什么地方出了问题,现在看到了以前看不到的东西——的工程师,正在发展一种直接体现在他们如何处理下一个问题上的思维方式。
她一直在写。不是每天写,不是写给成千上万的读者。但持续地写,关于她实际在经历的真实事情。到她的晋升周期到来时,她未来的 Staff 经理已经读过了她的两篇文章。她不需要解释她知道什么。他已经知道她知道什么。面试是一场对话,而不是一场试演。
这是一种不同类型的职业资产。而且它以一种认证无法做到的方式复利增长。
6、一个值得深思的问题
我想用我在思考这种分化时反复回到的一个诊断性问题来结束。当你的 AI 系统在生产环境中产生错误输出——不是崩溃,不是错误,而是错误输出——你需要多长时间才能知道?
如果答案是几小时,你有部分可见性。如果答案是几天,你有日志但没有评估。如果答案是直到用户告诉你才知道,那你在自己的产品中是在盲目飞行。
这个差距不反映你有多聪明。它反映你一直在构建什么技能。而且它现在也是你处于薪资分裂的哪一边——或者正朝哪一边漂移——的最清晰信号。
我一开始提到的那两个工程师,不是被天赋、努力甚至机会区分开的。他们是被在结果显现前的十二个月里选择关注哪些问题所区分的。
好消息——我是真心这么说的——是这些都不是固定的。技能是可以学习的。问题是可以解决的。每个月都有工程师从一边移到另一边。
十二个月后,你最终会站在哪一边,很大程度上仍然是你可以做出的选择。
原文链接:The AI Engineer's Salary Is About to Split in Two. On Which Side Do You Want to Be?
汇智网翻译整理,转载请标明出处