你雇用的 ML 工程师并非你所需的 AI 工程师

一位工程副总裁决定公司需要“做 AI”。公司已经有一个机器学习团队——三个人，他们构建了推荐模型，调整了反欺诈分类器，并维护着一个特征存储（feature store）。显而易见的举措是让他们负责新的 LLM 项目。他们懂数学，也发布过模型。能有多大区别呢？

六个月后，原型演示效果惊艳，但在生产环境中却惨遭失败。没人能解释为什么智能体（agent）偶尔会订错会议，每个请求的成本是预估的四倍，而且根本无法判断上周的提示词（prompt）更改是让情况变好了还是变坏了。机器学习团队感到很沮丧，因为他们擅长的所有工具——梯度下降、数据流水线、超参数搜索——在他们既无法重新训练也看不透内部构造的模型上都派不上用场。

这是目前 AI 领域最常见的组织架构错误，它源于一个听起来很合理的假设：构建模型的技术与基于模型构建应用的技术是同一份工作的不同标签。事实并非如此。它们之间的重合度甚至比“前端工程师”和“后端工程师”还要低。

两种共享词汇但几乎毫无共同点的技术

看清这种分歧最简单的方法是看每个人整天实际接触的是什么。

机器学习工程师（Machine Learning Engineer）研究的是模型。数据集通常以表格形式存在——可能有数百万行，但规模是有界的且属于你。训练需要几分钟到几小时。手中的杠杆是特征、架构、损失函数和权重。核心技能是统计学、线性代数，以及不被带有数据泄漏的验证集所蒙蔽的自律。当出现问题时，修复方法存在于模型内部：更多的数据、更好的特征、不同的目标函数。模型本身就是交付物。

AI 工程师（AI Engineer）研究的是围绕模型封装的系统，而这个模型他们既没有参与训练，也无法重新训练。这个“模型”是经过数万亿 token 预训练后交付的，表现为一个 API 端点，对于相同的输入可能会返回不同的输出。没有权重可以调整。手中的杠杆是上下文、工具、检索、编排和防护栏。当出现问题时，修复方法几乎从不在模型内部——而在你喂给它的内容、你设定任务的方式、你提供的工具以及你对输出的处理方式中。系统是交付物；模型则是供应商依赖。

将两者并列对比，差异显而易见。一份工作是关于从数据中生成一个函数；另一份工作是关于如何让一个租来的黑盒表现出可靠的行为。统计学对前者是核心支柱，对后者仅是辅助工具。分布式系统直觉、延迟预算和对故障模式的偏执对后者至关重要，而对前者则几乎无关紧要。

市场已经察觉到了这一点，即使你的职级阶梯（job ladder）还没有。AI 工程师岗位的增长速度远快于机器学习工程师——需求曲线正向那些能够集成基础模型的人倾斜，而不是那些从头开始训练模型的人。这并不意味着机器学习工程过时了；它意味着这两个角色正在分化成不同的招聘漏斗，将它们视为可以互换，会让你在真正需要其中某类人才时陷入短缺。

职级阶梯上缺失的一环

人事错误背后的结构性问题在于：大多数工程职级阶梯仍然没有为这个岗位留出位置。通常只有软件工程师（SWE）轨道，或许还有一个机器学习工程师 / 数据科学家轨道。“AI 工程师”被强行塞进其中之一，这种生拉硬拽对双方都会造成伤害。

将其归入机器学习轨道，你会筛选错方向。面试会要求候选人推导反向传播或解释偏差-方差权衡——这些问题完全无法说明他们是否能防止智能体陷入死循环，或者能否设计一个评估（eval）在客户发现之前捕捉到回归。你筛选的是模型训练的深度，最后招到的人虽然技术过硬，但他擅长的技术你的产品却几乎用不到。

将其归入普通的软件工程轨道，你会低估这项工作的难度。招聘经理会将“调用 API”视为初级胶水代码，忽略了生产级 LLM 系统是一项真正的专业技能，并让一个从未思考过非确定性、Token 经济学或当模型自信地返回垃圾信息时该怎么办的人来负责。系统发布了，然后悄无声息地恶化，因为没人负责确保其可靠性的部分。

这个职级缺失的原因在于该角色很新，其核心竞争力——让概率性系统的表现达到足以用于生产的水平——无法对应到现有任何轨道的晋升标准中。在公司明确定义这项能力之前，无法对其定级，无法对其进行面试，也无法区分一个强大的 AI 工程师和一个仅仅是满怀热情的业余爱好者。缺失的职级阶梯并非 HR 的形式主义。它是错位招聘不断发生的根本原因。

评估设计是试金石

如果你只能筛选一项技能，那就筛选评估素养（evaluation literacy）。这是判断一个人是否真的在性能指标要求下发布过 LLM 系统，而非仅仅看过教程的最强信号。

这之所以是一个清晰的信号，是因为你无法伪造设计真实评估的经验。任何人都可以说“我们测试过了”。但实战者能告诉你他们定义了什么指标以及为什么，他们是如何构建测试集的，为什么随着数据漂移需要更新测试集，以及——只有在生产环境中踩过坑才会知道的部分——该评估是专门为了捕捉哪种特定的失败模式而构建的。他们经历过“新提示词感觉更好”这种无谓的争论，深知没有数字是赢不了的，所以他们构建了这些数字。

这直接指向了一个现在已有名称的学科：评估驱动开发 (eval-driven development)，它是测试驱动开发 (test-driven development) 在 LLM 时代的演进形式。在构建之前，你就决定了成功的定义以及如何衡量它，因为面对一个非确定性组件，否则你将没有基准事实（ground truth），也无法知道某次更改是否真的起到了帮助。请注意，这项技能与训练模型毫无关系。它是一种衡量和系统设计技能。机器学习工程师可能具备这项技能，但他们的机器学习背景并没有赋予他们这项技能——许多资深的机器学习工程师并不具备这项技能，因为在他们的世界里，框架已经提供了清晰的训练/测试集划分和准确率数值。

一个有效的面试策略：让候选人详细讲解他们实际构建过的一个评估。追问数据集的基本原理和它捕捉到的故障模式。做过的人会两眼放光，谈论细节。没做过的人则会退缩到关于“准确率”的泛泛而谈中，背后没有任何方法论支撑。大约五分钟，差距便一目了然。

实验室产品与生产级产品的其他本质区别

评估设计（Eval design）是核心，但还有一些其他能力可以可靠地区分“已经交付产品的开发者”和“仅停留在原型阶段的开发者”。这些能力都不属于模型训练技能。

• 将成本视为一等指标。 生产级 AI 工程师能够对功能的每项任务损益（P&L）进行建模——输入 token、输出 token、缓存命中率，哪些调用路由到昂贵模型，哪些路由到廉价模型。从未考虑过推理成本的人，构建出的东西可能在演示时效果不错，但在大规模运行时却不具备经济效益。
• 上下文工程优于提示词技巧。 “提示词工程”的成熟版本并非魔咒；而是决定模型看到哪些信息、以什么顺序、如何检索以及如何裁剪以适应窗口。优秀的实践者会像评审代码一样对系统提示词（system prompts）进行版本控制、评审和测试，因为未经评审的提示词等同于未经评审的生产逻辑。
• 对智能体（Agent）失效模式的直觉。 多步智能体的失败方式与单次调用不同：循环、复合错误、工具误用、看似合理实则错误的静默输出。了解失效分类——并围绕其设计恢复机制、超时和人工检查点——是中级和高级工程师的分水岭。
• 最小权限的工具设计。 这是资深水平的标志。一个拥有广泛工具访问权限且没有熔断机制（kill switch）的智能体，是一个随时可能引发事故的隐患。考虑到过度代理（excessive agency）、作用域权限和断路器的工程师，是在为模型做出产生实际后果的蠢事那天做准备。
• 前沿模型熟稔度。 这个领域每周都在变。优秀的候选人会阅读原始文档，了解当前的模型阵容及其权衡。一个简单的造假检查——让他们说出当前的模型代次和粗略定价——就能区分出哪些是追踪领域动态的人，哪些是只会复述过时二手摘要的人。

浏览这份清单，看看缺少了什么：没有损失函数，没有优化器，没有数据标注流水线，没有分布式训练。使 AI 工程师高效的技能栈与使 ML 工程师高效的技能栈完全不同。虽然在边缘地带存在交集——两者都受益于统计直觉和整洁的代码工程——但它们的重心相去甚远。

究竟该如何应对

解决方法不是解雇你的 ML 团队并雇佣一批新人。而是停止混淆这两个角色，并有意识地为每个角色配置人员。

首先从命名角色开始。写下 AI 工程师负责的内容——可靠的 LLM 系统、评估（evals）、成本、智能体安全——作为区别于模型开发的能力。一旦你能清晰地表达它，你就可以对其进行分级、面试，并区分这两条职业路径。你最优秀的 ML 工程师中，有些人会想要转型，有些人会非常擅长；让这成为一个带有独立起步阶段的有意识转型，而不是默认技能可以无缝迁移。

面试时，从评估和成本入手，而不是模型理论。询问他们构建过的评估体系，以及他们必须为其单元经济效益（unit economics）辩护的功能。针对资深职位探测智能体失效模式，针对 Staff 级别职位探测工具权限设计。这些问题能挖掘出生产经验，而关于反向传播推导的问题则会完全忽略这些。

在规划组织架构时，将两者视为偶尔交付工作的并行梯队，而不是一个带着新指令的单一团队。ML 团队仍然负责你实际训练的模型。AI 工程职能则负责基于非自研模型构建的一切。如果将两者混为一谈，你将不断交付演示极其精美但在生产环境中夭折的原型——并纳闷为什么构建了最强模型的人似乎无法让其上层应用变得可靠。他们做不到，是因为那从来不是他们的专业领域。那是另一种手艺，现在它需要在门上挂起属于自己的招牌。