AI 工程团队的人员配置：每个功能都有 AI 组件时，谁负责什么

三年前，"AI 团队"意味着一群藏在组织架构角落里的专家，对产品工程师基本不可见。如今，一位金融科技公司的高级软件工程师，周一用微调模型上线欺诈评分功能，周三为客户支持搭建 RAG 管道，周五调试 LLM 延迟问题。专家并没有消失——但"AI 工作"与"产品工程"之间的边界，消失得比几乎所有人预想的都快。

大多数团队的应对方式是把新头衔贴在旧职位描述上，然后宣告完事。这是错误的答案，功能失调很快就会显现：所有权不清、工具重复，以及一个 ML 平台团队把半数时间花在解释"为什么产品团队不能直接调 OpenAI API"上。

本文探讨如何把结构搭对——不是抽象地谈，而是针对大多数工程组织实际经历的 AI 采用阶段。

真正重要的角色

LLM 工具链的爆发催生了令人困惑的职位分类。你会看到 AI 工程师、ML 工程师、LLM 工程师、GenAI 工程师、AI 平台工程师等职位，往往被交替使用。这些区别比标签本身更有意义。

AI 工程师（有时也称 LLM 工程师）在应用层工作。他们集成 LLM API、构建 RAG 管道、搭建工具调用和 Agent 工作流、管理提示词版本，并拥有评估框架——用来判断功能是否真的在正常运行。他们来自全栈或后端背景，精通 Python 和 TypeScript。他们不训练模型，而是使用模型。

ML 工程师在模型层工作。他们构建和维护训练管道，在私有数据上做微调，管理嵌入模型，设计特征存储，并运营以规模化提供预测的推理基础设施。在客服记录上微调基础模型、从行为日志构建推荐引擎、为搜索产品优化重排序器——这些都是 ML 工程的工作。

数据工程师构建让上述两者都成为可能的基础设施。没有可靠的数据管道，AI 工程师的 RAG 索引和 ML 工程师的训练集都会悄然退化。这不是 AI 专属角色，但它成为瓶颈的速度往往超出团队预期。

产品工程师是这其中的变量。他们一直存在，但 LLM 大幅拓展了他们无需求助专家就能构建的东西。一个理解提示设计、基础评估方法论和 API 成本管理的产品工程师，现在可以独立拥有两年前需要 ML 工程师才能完成的功能。这是能力的跃迁，不仅仅是效率提升——它有深刻的结构性含义。

核心洞察：LLM 商品化了大量过去需要专业 ML 知识才能完成的工作。情感分类、实体抽取、意图路由、摘要、基础问答——这些现在都是产品工程任务。ML 工程师的角色收缩到了真正困难的问题上：私有模型适配、规模化推理基础设施，以及让你相对于使用同款基础模型的团队拥有真正护城河的训练管道。

谁负责什么：团队最容易搞错的所有权问题

所有权混乱是 AI 工程组织中最常见的功能失调。具体表现为：

• 产品团队直接调用模型 API，积累出无人审计的提示债务
• ML 平台团队拥有评估框架但不拥有功能，导致质量信号永远无法到达能采取行动的人
• 数据工程师维护着喂给 ML 模型的管道，却从未见过那个模型

根本原因在于，大多数 AI 所有权地图是为"AI 是专项附加功能"的世界绘制的，而不是"AI 是每个功能的组成成分"的世界。解决方法是明确定义三个不同的所有权区域：

功能所有权归产品团队。他们拥有用户体验、AI 功能本应撬动的业务指标，以及判断功能是否正常的评估标准。他们不必然拥有模型或基础设施。

平台所有权归 ML/AI 基础设施团队。他们拥有模型注册表、评估框架、推理网关、成本归因系统，以及让产品团队能安全高效地交付 AI 功能的工具链。他们不拥有功能。

模型所有权是有争议的中间地带。当产品团队为其领域微调了一个模型，谁拥有产出的制品？当 ML 团队发布一个新的嵌入模型，改变了六个产品功能的检索行为，谁来审查这个变更？这些问题需要在演变成事故之前有明确的答案。

实操解法：模型制品归训练者所有，但对共享模型的变更需要经过评审流程，所有下游功能负责人都要参与。这听起来显而易见，但大多数团队没有把它写在任何地方。

三种结构模型及其失败方式

随着 AI 采用规模扩大，团队通常会落入三种结构模型之一。每种都有其自然的失败方式。

集中式 AI 团队

一个团队负责所有 AI 工作。产品团队提需求，AI 团队构建和维护一切。在 AI 使用稀疏、团队正在建立标准的极早期阶段，这种方式有效。当产品团队开始以中央团队无法跟上的速度推进时，它就会崩溃。积压填满，产品团队开始绕过瓶颈直接调 API，中央团队对实际在构建什么失去了可见性。

具体失败模式：集中式 ML 团队历史上对产品影响的交付不足，因为他们优化的是模型质量指标，而这些指标不直接映射到业务结果。研究表明，集中式 ML 团队往往被有趣的模型问题吸引，而非最高杠杆的产品问题——不是因为工程师做了错事，而是激励结构奖励算法进步而非已上线功能。

完全嵌入式 AI 工程师

每个产品团队有自己的 AI 工程师，端到端拥有一切。这给了产品团队最大速度和紧密的所有权。失败模式是碎片化：每个团队重新发明评估框架、自建提示词版本管理系统、独立处理模型升级。技术标准漂移。AI 功能的安全审查变得不一致。当模型提供商变更 API，你要通知十二个团队而不是一个。

知识共享也会退化。嵌入式工程师与做类似工作的同行失去联系，这对 AI 工程来说比大多数专业更重要，因为这个领域变化足够快，跨团队边界的非正式知识传递是重要的学习来源。

中心辐射型

一个中央 AI 平台团队拥有共享基础设施——评估框架、模型注册表、推理网关、成本归因、安全审查流程。产品团队嵌入 AI 工程师，这些工程师拥有领域内的功能，通过定义清晰的接口使用平台能力。中央团队的客户是内部工程师，不是终端用户。

这是大多数组织在尝试过另外两种之后最终收敛的模型。Facebook 的集中式数据工程团队就是这样运作的：所有团队采用的标准化工具，每个团队在其上构建的东西保留自主权。Uber 的 Michelangelo 平台在 ML 基础设施上遵循同样的模式。

中心辐射型的失败方式是组织层面的：平台团队优化开发者满意度指标（采用率、NPS），而忽视了他们的投入是否真正在创造业务价值。为没有产品团队真正需要的功能构建精妙 API 的平台团队，是真实存在的现象。通过要求平台团队至少共同拥有一个生产功能来应对这一点——这让他们与实际约束保持连接。

三个阶段的人员配置

正确的团队结构取决于你在 AI 采用上所处的位置，而不是什么在组织架构图上好看。

早期阶段（前 1-3 个 AI 功能上线）

雇用 AI 工程师，而非 ML 工程师——除非你的产品假设从第一天起就需要私有模型训练。AI 工程师能更快交付 LLM 驱动的功能，从 AI 工程到 ML 工程的技能差距比反方向更容易之后弥补。保持团队集中，并在需要之前就构建评估基础设施——在截止日期压力下构建的评估工具通常质量很差。

在这个阶段，你的瓶颈几乎不是模型质量。而是工具、评估和反馈回路。能交付功能并衡量它是否在工作的团队，比能微调模型却无法告诉你用户是否满意的团队更有价值。

成长阶段（AI 在 5-15 个功能中，多个产品团队）

大多数团队在这里发现他们需要中心辐射型结构，因为集中式模型造成太多延迟，完全嵌入式模型造成太多碎片化。这个过渡很痛苦，因为它需要明确定义平台拥有什么、产品团队拥有什么——这个对话会暴露大量关于责任的隐含假设。

当你至少有一个案例，私有训练数据能给你带来相对通用基础模型的有意义优势时，才引入 ML 工程。不要投机性地雇用 ML 工程师。ML 工程技能组合昂贵，在你拥有真实训练数据和真实模型适配需求之前，这份工作很稀少。

规模阶段（AI 在大多数功能中，推理成本显著）

在这个阶段，你可能需要专职的推理基础设施专家——有人专注于 GPU 利用率、批处理策略和模型服务优化。这与 ML 工程不同，与 AI 工程也不同；这是基础设施工程中恰好应用于模型的一个专门子集。

你还需要将从生产到模型改进的反馈回路正式化。规模阶段的大多数团队坐拥能改善模型的行为数据，却没有让这些数据到达训练管道的架构路径。这是数据工程成为瓶颈的地方：不是因为数据不存在，而是让它可用于训练的管道从未被构建。

要避免的组织反模式

重新贴标签而不是重新设计角色。 把软件工程师称为"AI 工程师"不会改变所有权、激励机制或他们对什么负责。结构性变化比头衔变化更重要。

为了组织架构的视觉效果优化人数。 2024-2025 年有几家公司做了 AI 驱动的裁员，结果发现为时过早，正在悄然逆转。AI 工具带来的生产力提升是真实的，但分布不均——在某些任务类别中非常显著，在其他任务类别中完全没有。在改变人数之前构建衡量基础设施，而不是之后。

忽视领域知识差距。 纯粹由工程师设计的 Agent 和 AI 功能，往往缺乏处理金融、法律、人力资源或销售中边缘情况所需的领域特定知识。知道为什么某个边缘情况重要的人，在功能构建时很少在场。通过在上线前进行结构化的领域审查来解决这个问题，而不是在功能在生产中失败之后。

用前 AI 时代的指标衡量 AI 团队产出。 故事点和 PR 数量无法准确捕捉 AI 工程工作。构建评估框架、防止三次生产事故的 AI 工程师，比在没有任何质量基础设施的情况下交付五个功能的工程师创造更多价值。基于结果的指标——功能采用率、质量指标、每次推理成本——能给你更好的信号。

完成过渡

顺利完成这一转变的团队有一个共同实践：他们在调整组织架构之前先绘制能力变化图。问题不是"我们想要什么团队结构"——而是"既然我们的工程师现在能做 X（过去需要专家才能做的事情），这让什么变得多余，又创造了哪些新的所有权空白？"

从一个 AI 与产品工程边界已经非正式模糊的团队开始。记录他们实际在做什么、谁对什么负责，以及哪里的交接在崩溃。以此为基础进行更大范围的结构性变革。没有这种实证依据的重组，通常会产生一个新结构，却带着同样的功能失调，只是组织架构图的方框上换了不同的标签。

目标不是一张完美的组织架构图。而是一个组织，让最接近用户问题的人也拥有构建解决方案 AI 组件的工具和权力——无需重新发明本应共享的基础设施，也无需等待一个离上下文太远、无法正确优先排序的中央团队。