Your next job doesn’t have a title yet: Emerging role skills Q&A with Corey Hymel of Andela

你下一份工作还没有头衔：与Andela的Corey Hymel关于新兴角色技能的问答 - Stack Overflow

2026年10月14日

你下一份工作还没有头衔：与Andela的Corey Hymel关于新兴角色技能的问答

尽管有传言称每个人都在成为通才，但人员增长方向并非如此。

[

关于AI对就业影响的讨论层出不穷。是否所有人都会被裁员去训练AI？每个开发者都会成为超级通才吗？是否会有新角色在废墟中崛起？但Andela的研究主管Corey Hymel希望用数据验证这些传言。他和他的团队分析了近5万份职位招聘信息，寻找在行业尚未正式命名之前就已经出现的技能和角色。我与他进行了交流，了解这项研究对获得永久职位的新开发者技能组合有何启示。

—---------------------------------------

Q：你对技能如何在职位名称中转移和变化进行了研究。能否介绍一下这项研究？

A：在Andela，我们对市场的整体方法和研究方法是：目前世界上最好的最差的工具就是职位名称和简历。我们痴迷于理解人们能够做到的非常细致的技能。

这是第一个前提。第二个前提是，我们经常听到"哦，AI正在改变工作。哦，AI会淘汰工作"，或者"AI会创造新工作"。但这些说法都是轶事性的，缺乏数据支持。我们研究后认为："有没有办法深入进去，用一些数据和严谨的方法来理解所有这些工作背后真正发生的事情？"我们内部使用了一套技能分类和本体论体系，这为所有研究和数据结构提供了基础。

对我们来说，这非常重要，因为我们业务的另一大块是关于学习和技能提升。我们如何为客户提供关于行业发展方向的信息？这里有一些人们应该学习的技能，我们发现这些技能正在变得越来越普遍。这些就是角色。其中一些可能介于两者之间。

你可能会说："前端工程师需要去学习这个"，但事实上你可能还应该拉入产品经理。我认为职位名称一直落后于工作本身，但尤其现在情况越来越糟。

Q：所以这不仅仅是职位名称的变化，而是新技能被应用到现有职位名称以及中层角色的出现。我想你提到DevSecOps作为一个混合角色的例子。

A：完全正确。我在新闻中经常看到一个普遍的叙述：AI会让每个人成为通才，这使得这些工作变成灰色工作，技能可以四处渗透。

但数据表明这并不正确。存在非常细分的技能组合，这些技能要么形成新的、尚未被讨论过的净新增角色，要么历史角色中的基础技能开始发生变化。

从劳动力市场或招聘角度来看，一方面变化发生得太快，人们无法跟上；另一方面企业并不清楚人们应该学习哪些技能，于是直接给出"AI工程师"这样的通才头衔。这到底意味着什么？这可能有100种不同的解释。但对他们来说，直接说"我们需要一个能做AI的人"要容易得多。

Q: 在去年的 re:Invent 大会上，亚马逊首席技术官 Werner Vogels 提到了 T 型开发者，即在某个领域有深入专精，同时具备广泛的知识基础。你们的数据是否反映了这种趋势？还是说你们观察到的是更具体的技能组合集中？

A: 我之前多次收到过这个问题，坦白来说，我并没有像应该做的那样深入跟进。因为除了 T 型之外，还有 I 型，甚至可能存在星型。我收到过关于不同形状的提问，但从目前的数据来看，我认为 T 型通常与数据呈现的模式一致。不过目前我还没有确切的结论。

Q: 我很想知道这个问题，因为从经验来看，我经常听到人们讨论全栈开发者的定义正在扩展，涵盖从产品设计到 SRE 的多个领域。我想知道人们是否真的在招聘这类角色，还是这种现象只是在组织内部自然发生。

A: 我不确定。我们的数据中并没有发现所谓“全能通才”的概念。但根据我们观察到的情况，如果沿着软件开发生命周期的典型流程来看，将产品负责人、前端工程师、后端工程师、DevOps 和 QA 等角色按线性顺序排列，这些角色之间的交叉地带正逐渐成为技能组合最普遍的区域。

例如：前端产品工程师。这可能类似于一个 F 型工程师。这意味着他们倾向于某一侧——可能有前端工程的背景，但现在被要求拓展到产品角色，与客户沟通获取反馈、优先级排序和管理功能需求等。

我们在后端和 DevOps 领域也看到了类似现象。现在后端工程师需要了解如何将这些模型部署到生产环境，并思考可扩展性等问题——这种 F 型则朝另一个方向延伸。

我需要再仔细思考一下这些形状的定义。

Q: 这种形状很有趣，特别是 F 型。随着 AI 的发展，你现在可以触及到最贴近你的事物，从而扩展到其他领域，对吧？后端工程师现在可以开始接触数据库等。

A: 甚至在某种程度上，这种技能会延伸到生产环境，甚至前端领域。

Q: 在研究中，你们观察到哪些技能组合？

A: 其中一个我们客户经常描述但从未明确命名的技能组合是“大型语言模型应用工程师”。这类人非常擅长在大型语言模型（LLM）上构建产品，无论是使用 OpenAI API、开源权重模型还是 Claude 代码。他们知道如何接入 API，但还能更进一步，也就是懂得构建框架。

他们熟悉诸如评估（evals）之类的技术，而当我们与客户交流时，他们通常会将其视为后端工程师的职责。这是一种非常具体的技能组合。传统的后端工程师不一定了解如何构建代理评估框架或治理与防护机制。这个发现非常有趣，而且在数据中出现的频率相当高。

另一个我最近多次听到的说法是，2026年和2027年将成为CFO（首席财务官）的年份。如何应对消费支出问题，现在出现了许多基于消费模型的新产品，这些产品采用透传模式。不仅如此，开发人员正在消费这些新型的运营支出（OpEx）。FinOps可靠性工程师需要能够思考项目开发并核算成本——不仅仅是典型的终端用户消费（如云服务消费），还包括开发工具的使用成本。当我们构建AI原生的SDLC（软件开发生命周期）时，人们讨论如何以负责任的财务方式实现这一点。我们经常听到如何优化token消耗以及如何减少token消耗的问题。在这些场景中，需要工程角色具备敏锐的成本意识，例如使用更便宜或更快的模型并简化流程，或者设计需要Fable（某种复杂工具）的场景，因为这些任务高度复杂。

最后一个角色是文档即代码工程师。

我们经常听到关于规范驱动开发（spec-driven development）的讨论。这种模式通常被当作直接强加给开发人员的内容，但实际上，现在出现了一个新角色：那些从事传统技术写作或传统文档工作的人员，可能是最优秀的规范驱动工程师。他们能够比开发人员更好地构建上下文，为这些新模型提供输入，同时为大型代码库的长期智能代理开发设定上下文。

Q：AI应用工程师是一个有趣的角色——我经常听到有人认为每个人都应该建立自己的软件工厂。这似乎意味着作为个体工程师，无论做什么都必须完成这个任务，因为每个人都在通过代理进行操作，每个人都会对自己的代码进行评估。令人感兴趣的是，这些技能在数据领域被专门化了。

A：我认为这是所有这些讨论中的关键洞察。这挑战了现有的叙事和现状，即要么所有人都将成为扩展的全栈开发人员，要么所有人都只是通才，现在可以做任何事情。实际上，我们在招聘和职位数据中看到了统计上显著的趋势，即特定技能组合正在出现。

Q：你注意到职位名称有什么特别之处吗？职位名称对这些技能组合有影响吗？

A：在我看来，职位名称非常重要，尤其是在这种背景下，因为它为企业提供了一种更清晰描述需要完成工作的途径。当你观察企业如何创建职位，特别是职位名称的确定时，最接近工作的人通常是团队内部的某个人。

但上面还有层级，对吧？它需要经过HR、财务、采购，最终到招聘人员。你会看到这种责任链，随着责任链的传递，工作描述和角色理解都会变得越来越模糊。我看到的是，退回到通才角色变得更容易了。

我希望通过这些更具体的职位名称，从最接近工作的人员到边缘招聘人员，他们能够准确描述需要完成的具体任务。一个更好的职位名称非常重要。一方面，它能让招聘公司更加具体，节省时间，获得更好的候选人，从而更有可能成功。

从候选人的角度来看，假设我过去20年一直是一名后端工程师，现在看到一个后端工程师职位。我可能会因为需要找工作而直接申请。但我不成功的机会相对较高，因为底层技能、要求和理解可能有显著差异。

我认为在这种情况下，这些新职位名称的出现确实很重要。

Q：在你的研究文章中，你提到了“人才债务”。什么是人才债务？

A：人才债务的积累方式与技术债务类似。但人才债务的不同之处在于，技能的半衰期正在大幅缩短。过去，你可以成为一名Java工程师，工作20年并只做Java编程，这没问题。但现在我们看到变化速度如此之快，这些技能保持相关性的半衰期正在大幅缩短。

由此产生的技能压缩最终形成了人才债务。目前许多公司都面临这种情况，当突然进入AI领域时，他们查看现有团队成员，发现“天哪，我们几乎没有接近所需技能的人”。

他们只有两个选择。一种是尝试重新培训现有员工。优势在于可以保留团队成员的深厚领域知识，理解系统知识，这对员工发展是很好的投资。

另一种选择是尝试外包招聘。虽然更快，但缺乏领域知识，需要适应时间，还存在将错误的人放在错误位置的风险。所有这些因素叠加在一起，形成了与技术债务非常相似的概念——人才债务。

Q：开发者一直需要在工作中不断学习，对吧？即使你是一名Java工程师20年，你也在学习新框架、新特性、新库。这种加速是否意味着不同的情况，即不只是学习Java的新东西，而是每六个月就要学习全新的东西？

A：我认为是的。学习新框架是一回事，学习新编程语言是另一回事。我认为很多开发者对此是接受的。但现在最大的不同在于，你实际工作方式的基础发生了根本性转变。

这是巨大的、困难的转变。从过程式编程转向面向对象编程会迫使你从根本上思考这些事物是如何构建的，如何优化以提高效率。对很多人来说，这是一次巨大的转变。如果你曾经尝试过在过程式编程（如C语言）和面向对象框架之间切换，你会发现思维方式会有很大不同。

它从概念上重新思考了个人工作方式的规模问题。对于工程师而言，这不仅仅是重新学习语法、语言、框架或方法论，而是需要从结构上重新理解如何将这些新工具整合到工作中。我如何真正从代码中抽离出来？如何在脑海中调整责任归属，将其交给虚拟的合成知识工作者？

能够在两者之间灵活切换的工程师具有显著优势。我们网络中的一位工程师正在为我们的平台进行一些更新。他给我报了时间，因为需要添加一些排行榜功能，我说：“我们只需要添加一个排行榜。你把它交给Claude Code处理，这应该只需要一小时。”

他花了四天时间才完成，我问他：“为什么这么长时间？你用的是什么编码工具？”他使用Claude Code来理解代码，但仍然大量手动编写代码。他没有实践智能代理开发，主要是因为他对所交付的代码负有责任感。“如果我交付的代码有错误，那责任在我。”

我还有另一位开发者，他直接将任务交给Claude。只要功能能运行，通过单元测试、验收测试和冒烟测试，就直接部署到生产环境。谁会在意细节？

看到这些不同的动态很有趣，但另一个潜在的因素是，那位对使用工具非常犹豫的开发者已经使用这些工具一段时间了，但他拥有的令牌预算非常有限。我认为这里存在一种能力差距：那些能够完全拥抱新世界、有预算消耗令牌以获得熟练度的开发者，与大量没有这种预算的人群之间存在明显差异。这可能成为另一个研究领域。

Q：你谈到的是扩大工具使用范围并适应工具，但我听到很多关于AI影响开发者技能的说法，比如技能退化、认知卸载导致开发者变得懒惰、对代码了解更少。正如你提到的那位处于YOLO模式的开发者——只要能运行，谁会在意它如何运行？你认为AI会让技能重塑和扩展变得更难还是更容易？

A：我认为这个问题有很多不同的答案。从一个角度来看，AI会让技能提升变得更容易，对吧？你拥有一个个性化的导师，它可以向你解释各种概念。我见过优秀的工程师让Claude对他们进行代码测试，以确保自己有扎实的理解。

技能退化会发生吗？当然会。我认为这是任何新技术出现时的前提条件之一。Gartner提出了一个技能退化的洋葱模型：你拥有构成你身份的核心技能，这些技能是不可替代的。然后是你领域特有的技能，这些技能通常不会被取代。接着是中间层的技能，这些技能可以适当退化。对开发者而言，这可能包括理解语法的能力。如今我不一定需要了解Go语言就能编写Go程序。我们是否应该放弃这种能力？其中一些技能，比如通用的架构设计，仍然会触发直觉判断——这似乎不太对劲。

工程师如果能够接受放弃部分原有技能、学习新技能，将处于非常有利的位置，能够加速前进。我真正担心的是那些现在刚进入市场、尚未培养出对异常情况的直觉判断能力的人，他们只是盲目地采取“YOLO”（Just Do It）式的行为。当五年、十年后技能差距逐渐显现时，技能退化或衰退将成为一个严重的问题。

或者，谁还在乎这些呢？我们上学时不准用计算器，但现在每个人都有计算器，但我们依然发展得很好。

Q：现在没人再用汇编语言编程了吧？这不重要。

A：正是如此。

Q：对于那些对未来工作和技能前景感到焦虑的人，这些数据是否验证了他们的担忧？

A：我认为目前关于AI将使所有人变成通才的讨论存在很多噪音。围绕AI如何改变工作的言论也充斥着各种喧嚣。但我们的发现是，一些全新的特定技能正在变得非常重要。人们需要清楚自己适合哪些领域。我们还有另一个工具，你只需输入当前职位，我们就能展示它将演变出的新角色。

理解趋势走向，并作为工程师开始投入精力为自身做好准备，对每个人来说都将非常有帮助。