为什么上下文工程是AI的下一个招聘挑战

# 为什么上下文工程是AI招聘的下一个挑战 来源：https://tech.yahoo.com/ai/articles/why-context-engineering-ai-next-080541249.html *当您通过我们文章中的链接购买商品时，Future及其联合合作伙伴可能会赚取佣金。* 一个机器人若有所思地站在巨大的数字显示屏前，屏幕上显示着代码。 图片来源：Getty Images 提示工程曾一度成为AI（https://www.techradar.com/best/best-ai-tools）就业热潮的焦点。 2025年，科技招聘公司SPG Resourcing报告称，英国AI提示工程师的职位列表比上一年增长了180%。 这是一个引人注目的数字，捕捉到了生成式AI第一波商业浪潮的情绪。企业试图理解如何与大语言模型（LLM）（https://www.techradar.com/computing/artificial-intelligence/best-llms）对话，并将早期实验转化为有用的东西。 这一需求并未消失。 根据普华永道（PWC）的数据，英国专业AI职位的招聘网站（https://www.techradar.com/best/us-job-sites）列表比去年增长了61%，显然好的提示仍然很重要。但大部分新增需求来自能在企业内部应用AI的人，而不仅仅是与模型对话的人。 许多组织已经超越了第一个演示阶段。他们现在正试图构建AI智能体、检索增强生成（RAG）系统，以及在企业内部运行的AI驱动工作流。 这造成了不同的技能缺口。 这正是我所称之为“上下文工程”背后的转变。尽管这个术语并未被普遍使用，但这种能力正变得至关重要。 想要有用的AI智能体和检索增强生成系统的公司，需要能够设计模型周围环境的人，而不仅仅是设计发送给模型的提示。 ## 从更好的提示到更好的上下文 提示工程关注的是指令，而上下文工程关注的是该指令周围的整个世界。 一个支持代理不仅需要一个写得很好的提示，它还需要正确的客户记录、政策、产品历史和权限边界。同样，一个开发代理需要相关的代码、测试、依赖项和部署约束。 在这两种情况下，输出质量都取决于上下文。没有上下文，模型就是在根据不完整的证据进行猜测。但上下文过多，系统就会变得嘈杂且难以治理。这项工作的关键在于让上下文有用、及时且可控。 这正是上下文工程与提示工程的区别所在。 ## 智能体提高了风险 AI智能体的兴起使这个问题更加紧迫。一个上下文质量差的聊天机器人（https://www.techradar.com/pro/best-ai-chatbot-for-business）可能给出一个糟糕的答案，但同样糟糕的上下文可能会导致另一个智能体犯下严重错误。 一旦AI系统能够调用工具、查询业务系统、维护状态并跨多个步骤执行操作，上下文就成为生产架构（https://www.techradar.com/best/best-architecture-software）中不可或缺的一部分。它决定了智能体能看到什么、能做什么，以及企业能对结果投入多少信任。 我想起了一个关于边界测试的笑话。一个开发人员走进一家酒吧，点了一杯啤酒，然后点了五杯啤酒，然后点了999,999,999,999杯啤酒，然后点了-1杯啤酒。酒保眨了眨眼，但一切正常。一个用户走进酒吧，问洗手间在哪里，整个酒吧爆炸了。 同样的原则也适用于AI项目。第一个原型可能在一小部分示例上运行良好，但遇到真实数据时就会变得脆弱。客户信息存放在一个系统中，运营数据在另一个系统中，而重要知识则存在于文档和文件中。智能体被期望跨越所有这些进行推理，但上下文层并未为此设计。 例如，金融服务团队可能需要连接CRM（https://www.techradar.com/best/the-best-crm-software）数据、现有数据平台和内部文档，智能体才能准确回答。困难的工作不仅仅是移动数据，而是对其塑形，使智能体能够检索到正确的证据，并保持在正确的权限边界内。 ## 职位名称仍在追赶 这造成了一个尴尬的招聘时刻。上下文工程的需求日益清晰，但职位名称却仍未确定。 一些组织可能会特意招聘“上下文工程师”，但许多组织不会。这种能力更可能出现在AI工程师、智能体工程师、AI平台工程师、应用AI工程师或数据工程师等职位中。在其他企业中，它将成为数据、平台、安全和软件工程团队共同承担的职责。 因此，领导者需要为工作本身而招聘，而不是为职位标签而招聘。候选人并不需要在简历上写“上下文工程师”才是有用的。更好的信号是，他们是否理解数据如何在系统中流动、权限如何被强制执行，以及原型如何转变为足够可靠的生产系统。 这也意味着人才库比许多公司想象的要广。机器学习专业知识很有价值，但上下文工程在很大程度上借鉴了现有的工程学科。数据工程师理解数据管道和检索。 平台工程师理解运维韧性。安全（https://www.techradar.com/news/best-internet-security-suites）团队理解访问控制和可审计性。软件（https://www.techradar.com/best/best-small-business-software）工程师理解如何将混乱的需求转化为可维护的系统。 最优秀的候选人可能看起来像全栈AI工程师。他们不需要成为每个模型、数据库或框架的专家，但确实需要足够的知识广度，将模型层与周围的业务系统连接起来。 ## Kubernetes的教训与领导者现在应该做什么 这一转变与向云（https://www.techradar.com/best/best-cloud-storage）原生架构和Kubernetes的迁移有相似之处。许多公司把Kubernetes当作一个需要安装的东西，然后发现更难的工作是改变团队构建和运行软件的方式。 AI也带来了类似的风险。公司可以购买工具并雇佣少数专家，但仍然无法改变围绕这些工具的工程习惯。上下文工程要求团队以不同的方式思考从文档、数据所有权到访问权限、测试和问责制的方方面面。 它还改变了软件开发的文化。工程师已经在使用AI来编写、审查和迭代代码。这可以提高生产力（https://www.techradar.com/best/best-productivity-apps），但并不会消除责任。在性能、可靠性或安全性至关重要的领域，人为判断变得更加重要。 CTO和CIO不应等待上下文工程成为一个成熟的招聘类别。他们现在就应该开始识别这种能力。 第一步是审视AI项目失败的地方。是模型本身确实很弱，还是系统检索到了错误的上下文？权限是否清晰？团队能否解释为什么智能体产生了某个特定的答案？ 第二步是构建跨职能团队。AI不能与数据、平台、安全和产品分开。在许多情况下，最好的方法是对已经了解组织系统的现有工程师进行技能提升。 最后一步是文化层面的。工程师需要在熟练掌握AI辅助开发的同时，对自己交付的系统保持责任。领导者需要为实验留出空间，但也需要为审查、评估和治理制定明确的标准。 ## 模型本身并不足够 AI招聘正在发生变化，因为AI本身正在进入生产环境。模型将继续改进，企业将有许多方式访问它们。更难的竞争优势将来自于知道如何将这些模型与正确的业务上下文连接起来。 理解这一点的公司将构建更有用、更安全、更容易治理的智能体和RAG系统。忽视这一点的公司会继续在真正弱点在于其运行环境时，去责怪模型。 *我们列出了最佳简历构建工具，让您可以简单轻松地制作简历，助力职业发展*（https://www.techradar.com/best/best-resume-builder）*。* *本文作为**TechRadar Pro Perspectives*（https://www.techradar.com/pro/perspectives）*的一部分制作，这是我们展示当今科技行业最优秀、最聪明人才的频道。* *本文表达的观点属于作者本人，不一定代表TechRadarPro或Future plc的观点。如果您有兴趣投稿，请访问：**https://www.techradar.com/pro/perspectives-how-to-submit*（https://www.techradar.com/news/submit-your-story-to-techradar-pro）