做AI项目这几年我经常被问到一个问题搞AI是不是只需要算法工程师每次听到这个问题我都想花半小时把团队里那些隐藏在背后的角色一个一个拎出来介绍一遍。真实情况是一个能稳定交付的AI团队极少是“算法工程师单打独斗”的配置。尤其当大模型、AI Agent、AI编程工具开始普及之后团队里的角色分工已经发生了非常明显的变化——算法工程师不再是唯一的核心AI产品经理、AI Infra工程师、数据处理工程师、甚至专门做AI效果评估的人都在各自的环节上卡着项目的命脉。这篇文章我想结合自己做AI工程实践、带AI团队的经验把当前AI团队里真正存在的角色、他们的职责边界、协作关系以及常见配置方式系统梳理一遍。无论你是正在组建AI团队的管理者还是打算转行进入AI领域、想知道自己该往哪个方向走的开发者这篇文章都能帮你建立一张清晰的角色地图。1. AI团队的角色版图从单点英雄到系统作战1.1 AI团队与普通软件团队的本质差异以前做普通软件项目团队角色相对固定产品经理定需求前端写页面后端写接口测试验功能运维管上线。大家的分工边界很清楚而且每个角色的交付物之间耦合度不算高——前端页面和后端接口只要按照约定好的数据结构对接就行。AI项目完全不是这个玩法。AI团队的核心交付物不是“功能”而是“能力”。什么意思呢普通软件团队交付的是一个用户能操作的界面或接口而AI团队交付的是一种模型能力比如“能识别图片里的猫”、“能根据历史对话生成回复”、“能从文档里抽取关键信息”。这种能力本身带有不确定性需要数据喂、需要调参、需要评估效果、需要持续迭代所以整个团队的工作方式更像是在“养一个系统”而不是“盖一栋楼”。这就导致AI团队的成员不能只盯着自己那一亩三分地。算法工程师不能只埋头改模型结构他必须理解业务数据长什么样AI产品经理不能只写需求文档他得知道模型的能力边界在哪里哪些需求当前技术根本做不到AI Infra工程师也不能只管服务器他得懂模型推理时的资源消耗逻辑否则可能把成本烧穿。角色之间既有分工又必须深度咬合这是AI团队和传统软件团队最本质的区别。1.2 角色分工的底层逻辑模型生命周期视角我习惯把AI团队的角色分工放在模型的完整生命周期里去理解。一个模型从无到有、再到稳定上线运行大致要走完这么几个阶段业务问题定义、数据采集与处理、模型训练与调优、模型评估与验收、部署上线与监控、持续迭代与运营。每一个阶段对应着一类核心角色。业务问题定义阶段需要AI产品经理和业务方深度沟通把模糊的“我想用AI提升效率”翻译成具体的技术指标数据阶段需要数据工程师、标注人员和分析师确保数据质量模型训练阶段是算法工程师和数据科学家的主场部署上线阶段AI Infra工程师和MLOps工程师开始接手后续的迭代运营则是整个团队一起协同同时还要有人专门盯着模型效果有没有衰减、有没有出现bad case。如果你觉得一个团队里同时存在这么多角色很臃肿那很正常。实际上小团队里确实存在大量角色兼任的情况一个算法工程师可能同时干着数据和部署的活这并不丢人。但理解模型生命周期中每个环节需要哪些技能栈是合理设计团队分工的前提。2. 核心角色解码每个岗位在做什么2.1 AI产品经理定义模型能力的边界AI产品经理这个角色经常被误读。很多人以为AI产品经理就是普通产品经理加一点AI概念实际上完全不同。一个合格AI产品经理的核心能力是能准确判断“哪些需求值得用AI解决哪些需求用传统规则就能解决哪些需求当前根本做不出来”。我见过最典型的AI产品经理翻车案例就是拿着大模型的demo去给客户画饼承诺了很多模型根本稳定做不到的事情结果算法团队追了好几个月都没能把效果稳定在客户要求线上最后项目搁浅。实际情况是大模型的能力存在天然的不确定性——同一句话问十次回答可能不完全一样同一个场景下昨天的效果很好今天换了一批数据可能就崩了。AI产品经理必须深刻理解这种不确定性并且把它翻译成业务方能听懂的语言。AI产品经理的实际日常工作包括梳理业务场景中的高频问题判断哪些可以借助大模型能力解决定义模型的输入输出格式明确模型回答的质量标准建立评估集和算法团队一起确定什么算“答得好”跟踪线上bad case推动模型迭代。此外在合规方面AI产品经理还要对生成内容的价值观、隐私边界等问题负责这些都是传统产品经理几乎不需要考虑的维度。跟AI产品经理配合最忌讳的是“需求一句话细节全靠猜”。好的做法是把用户输入的可能变体列出来把不接受的输出写明确甚至连语气风格都定义清楚。这些看起来琐碎的事最后都会直接影响模型微调的效果。2.2 算法工程师从论文到可运行的模型算法工程师是AI团队里技术门槛最高的角色之一。在大模型时代这个岗位的工作内容发生了显著变化。以前做传统机器学习的时候算法工程师要花大量精力在特征工程上——把原始数据清洗、转换、组合出能喂给模型的特征现在用大模型很多特征工程被模型的表征能力替代了算法工程师更多的工作变成了要不要微调模型、用哪种微调方法、训练数据怎么构造、学习率怎么设置、评估指标怎么设计。大模型的微调并不是一个无脑操作。很多人以为拿着开源模型丢进去一批数据就能训练出好效果实际上数据清洗、配比、去重、格式设计每一步都有讲究。举个例子做对话模型的指令微调指令数据里的“思想链”部分如果写得太长模型可能学会啰嗦如果写得过于简短模型又学不会推理过程。这些经验需要算法工程师在实际项目中一点点积累。另外算法工程师在团队协作中往往要扮演“技术翻译”的角色。AI产品经理说“客户想要机器人更智能”算法工程师要能理解这句话背后的技术含义是什么可能要做检索增强可能需要微调可能需要换更大的基座模型也可能只需要把prompt写得更精细。没有这种翻译能力很容易出现产品和技术两层皮的尴尬局面。2.3 AI工程师把模型塞进业务系统的人AI工程师也叫应用算法工程师在AI团队里是比算法工程师更偏向工程实现的角色。如果说算法工程师的核心任务是“让模型的离线指标跑得更漂亮”那AI工程师的核心任务就是“让模型在线上的业务系统里真正跑起来”。大模型落地到业务系统中间隔着一大堆脏活累活。比如模型推理服务的接口怎么设计如何处理并发请求如果模型响应太慢是排队还是降级模型输出格式不稳定如何在代码层兜底保证不报错用户输入的文本太长超过了模型上下文限制怎么截断才不会丢失关键信息这些问题的答案不会出现在论文里只能在真实的工程项目里一个个处理。尤其在做AI Agent类应用时AI工程师的价值更加突出。Agent需要调用外部工具需要解析模型返回的JSON片段需要处理多轮对话的状态维护需要在模型“幻觉”——即胡编乱造内容的时候通过程序逻辑做拦截。纯粹靠算法工程师去写这些工程代码效率往往不高而纯粹的软件工程师又不太熟悉模型输出的特性和坑所以AI工程师这个角色就变得很关键。我在带团队的时候会明确要求AI工程师掌握一套“提示词工程模型调用代码兜底”的组合拳。即先尽量通过优化提示词让模型输出符合预期然后在代码里做好防御式解析双重保险有效减少线上问题。2.4 AI Infra工程师算力与数据管道背后的无名功臣AI Infra工程师是目前AI团队里最稀缺、也最容易被忽视的角色。很多人以为Infra只是“运维换个名字”其实差距很大。普通的运维管的是Web服务AI Infra工程师管的是GPU集群、分布式训练、模型推理优化、数据存储与流转以及大模型本地化部署等一整套AI基础设施。举一个我实际经历过的情况。团队要训练一个7B参数的大模型用全参数微调的话单卡显存根本放不下必须做模型并行和梯度累积。如果不熟悉分布式训练框架随便把代码丢上去跑很快就会出现显存OOM或者训练速度慢到让人崩溃的情况。AI Infra工程师的工作就是提前设计好训练框架的并行策略规划好数据加载的吞吐量让GPU利用率尽可能跑满而不是3万美元一张的卡在那躺着摸鱼。模型上线后的推理优化更是Infra工程师的拿手好戏。一个大模型如果直接裸奔部署单次响应可能要好几秒吞吐量低得可怜。通过量化、vLLM之类的推理加速框架、批处理调度等技术可以把推理成本降到原来的几分之一。这个优化空间对线上运营成本的影响是巨大的。对于很多中小企业来说没有专职的AI Infra工程师往往让算法工程师兼着干活。我的建议是如果团队开始做私有化部署或者单个模型服务日调用量级上万就必须考虑投入专人来做Infra否则每次模型更新都是一次灾难。3. 新兴角色与协作模式AI Agent时代的分工变化3.1 Prompt Engineer是过渡性角色还是长期岗位Prompt Engineer这个词在过去一年里火得不行也争议颇多。我倾向于认为纯写提示词的高级工程师也许是个过渡性角色但提示词能力本身正在成为AI团队几乎所有技术角色的基础技能。就像今天没有人会说“Excel工程师”是一个独立的长期岗位一样但几乎每个白领都要会Excel。真正优质的提示词工作已经演变成了一项结合数据、评估和模型特性的复杂工程。以我自己写AI编程提示词的经验为例一个好的编码助手提示词不只是“帮我写个函数”而是要包含背景信息、约束条件、输入输出示例、错误处理要求、风格偏好等结构化要素。尤其在代码生成领域提示词设计的好坏可能直接影响生成代码的可编译率和可维护性。我在团队里推动过一个做法把高频使用的提示词沉淀为团队内部的“提示词模板库”并针对每个模板建立回归评估集。任何一次模板修改都要在评估集上跑一遍效果对比防止改了一个场景结果另外三个场景的效果崩了。这套思路本质上就是软件工程方法论在提示词领域的一次迁移效果非常显著。3.2 AI Agent带来的角色融合趋势AI Agent是当前AI应用最热的方向之一。Agent跟传统问答机器人最大的不同在于它有目标规划、工具调用、记忆管理、自我反思等行为链条。以Agent为核心的应用正在推动AI团队出现一些之前没有的角色配置。首先Agent交互设计师开始出现。这个角色不像传统UX设计师那样只关注页面的视觉和交互流而是需要设计“模型的行为流”——Agent在什么条件下选择调用工具用户意图不明确时如何澄清多步任务执行失败时如何向用户解释并恢复。这些设计决策对用户体验的影响甚至比界面细节更关键。其次Agent编排工程师的技术栈比较特殊。不仅要会常用的Agent开发框架懂RAG检索增强、工具协议还要有很强的流程设计能力能把复杂任务拆解成Agent可以去执行的一步步子任务。这个工作既像算法工程师又像后端工程师还带一点业务流程工程师的影子是典型的“角色融合”产物。再者Agent的安全性评估人员也变得重要起来。Agent可以调工具、访问外部系统这意味着它如果被恶意prompt注入诱导危害面比普通聊天机器人要大得多。所以现在不少团队已经单独设置了Agent安全评估的角色专门负责测试模型的安全边界、工具调用权限、越权访问等问题。3.3 人机协同全团队都在变成“AI辅助者”还有一个维度容易被忽略现在的AI团队里很多原本不是做AI的人也开始深度参与AI工作流。比如设计师开始用AI绘图工具做前期概念稿测试工程师开始用AI自动生成测试用例数据分析师开始借助大模型做报表解读和异常归因。这个趋势带来的结果是AI团队的角色边界正在从“少数人懂模型”变成“人人都会用AI工具”。作为团队管理者我觉得应该主动推动这种转变而不是抵触。比如在周会安排里轮流让成员分享各自领域用AI提效的经验建立团队的AI工具白名单方便大家共享效率工具甚至可以把“AI工具使用熟练度”纳入绩效评估的参考维度。当然人机协同的普及也带来一个管理上的新课题当AI工具提高了每个人的产出上限之后团队的工作流程、质量标准和考核方式都需要跟着调整。如果一个算法工程师用AI编程工具把编码效率提升了三倍那么他节省下来的时间应该投入到更深入的模型分析上还是应该被安排更多重复性任务这个问题的答案没有标准但我倾向于把AI释放出来的时间用来做更高价值的探索性工作这才能形成正向循环。4. 不同规模团队的配置实战从3人到300人4.1 创业公司小团队的通用分工样板小团队没有那么多人力资源可以铺开角色划分必须务实。我见过比较能打的小型AI团队配置是3到6人核心角色包括一个能做深度技术决策的算法/技术负责人一个产品兼项目经理以及一两个全能型AI工程师。如果涉及数据量比较大可能再加一个兼职的数据工程师。这个阶段最忌讳的是照搬大厂的组织架构搞出“内容安全组”“模型平台组”“算法策略组”一堆小组。3个人的团队互相之间沟通成本本来就低与其用流程约束不如让每个人负责完整的一条技术链路。比如一个AI工程师负责从数据清洗、微调训练到服务上线的完整链路虽然辛苦但它能培养出非常稀缺的全栈型AI人才。小团队在分工上还要格外注意外部资源的借力。比如开源大模型通常可以省去预训练的巨额成本AutoML之类的自动化调参工具可以降低对资深算法专家的依赖云服务商提供的托管模型服务可以让早期产品快速验证。这些都是小团队对抗资源劣势的有效手段。4.2 中大型企业的AI中台与业务团队协同企业规模大了以后比如上百人甚至几千人的组织AI团队通常会分化成两种形态AI中台团队和业务AI团队。AI中台团队负责搭建公共能力比如算力平台、通用大模型底座、模型服务网关、基础数据管道、AI工具链业务AI团队则聚焦具体业务场景比如智能客服、营销文案生成、风控模型等。这种模式的好处是能避免重复建设。如果没有中台每个业务线都自己去部署一套大模型服务算力浪费严重而且不同业务线的技术沉淀也无法互通。中台统一提供模型API、GPU资源调度和监控告警业务团队只需要专注自己的场景数据和应用逻辑效率会高很多。中台和业务团队的协同也是要命的难题。常见矛盾是中台更关注通用性和稳定性业务团队更关注专属效果和响应速度。双方在资源分配、模型迭代节奏上很容易扯皮。我的经验是中台团队一定要建立清晰的SLA服务等级协议并且定期跟业务团队开需求对齐会。中台不能只做“被动接需求”要去主动了解业务线的方向和痛点业务团队也要理解中台资源的有限性别把什么都往中台上扔。4.3 角色分工的动态调整经验一个AI团队的角色分工不是一成不变的它要随着项目所处阶段动态调整。我总结了一个大致规律在项目冷启动阶段产品角色和算法角色最重要要集中精力快速验证技术可行性进入开发交付阶段AI工程师和测试工程师的权重上来要保障系统稳定落地到了运维运营阶段Infra工程师和数据分析师的价值凸显要盯着线上效果和成本。团队规模扩张的时候角色再划分也要顺势而为。比如最开始算法工程师一个人把数据清洗、训练、部署全干了但模型服务上线之后告警不断、排障越来越频繁这时候就需要专门抽人出来做模型服务的稳定性保障。又比如评估集越来越大、人工抽检覆盖不过来的时候就需要有人去搭自动化评估平台这时候就该考虑新增一个模型评估工程师的岗位了。我常跟团队说一句话不要为了分工而分工角色是为项目服务的。如果加一个人不能明显提升交付速度和质量那就不如先维持现状让现有成员通过提升工具效率来缓解压力。5. 角色分工的常见问题与排查技巧5.1 需求方与算法团队之间的“翻译”断点AI团队协作中最常见的问题是需求方团队和算法团队之间的“翻译”断点。业务方说“我要AI帮我自动生成周报”算法团队说“你给的样例太少我不知道你想要什么风格”。一周下来双方都觉得很累但项目没有任何进展进度完全卡住。这类问题往往出在缺少一个能双向翻译的角色。AI产品经理如果到位应该承担起这个责任先自己理解业务方想要的周报包含哪些板块、语气、长度要求然后把它转成算法和AI工程师能落地的技术任务比如定义输出模板、收集若干个优质示例作为few-shot样本、确定模型温度和返回格式。如果团队里暂时没有专职AI产品经理有一个笨办法可以缓解这个问题需求方直接到算法团队的工作流里走一遍。让业务方亲手用几轮不同的提示词去生成他想要的周报内容亲自体验模型的优点和缺陷。这种体验式的需求对齐往往比写十页需求文档都管用。5.2 数据标注与质量评估经常被低估数据是AI项目最容易被低估、也最容易被拖垮的环节。很多团队一开始信心满满觉得模型架构选好了训练代码写好了项目就稳了结果数据一到位就傻眼重复样本到处都是标签体系不一致不同标注人员对同一份数据的理解偏差很大。我见过一个智能文档解析项目团队花了大半个月来清洗和标注数据反复跟标注人员对齐规则甚至还做了三审机制——初审、复审、抽检才算把数据质量稳定下来。这个阶段看起来“没有在写核心代码”但它的重要性远远超过后面调模型时那些微小的改动。与此同时质量评估也容易被敷衍。模型训练完随便抽一批例子看一眼就宣布“效果不错”这是非常危险的做法。更合理的做法是建立分层的评估体系先构造一个覆盖典型场景的回归评测集每次迭代都在它上面跑一遍用定量指标跟踪效果变化再配合人工抽检专门找bad case。大模型应用尤其要重视评估集的建设没有评估集你根本无法判断一次提示词修改到底是优化还是退步。5.3 跨角色协作的沟通机制设计最后想聊聊跨角色协作的沟通机制。AI项目周期长、不确定性高、角色之间依赖度深如果沟通机制设计不合理团队大概率会陷入低效的“群里扯皮会议满天飞”的状态。我实践下来比较有效的几个方法第一把需求口头沟通变成“结构化文档评审会”的形式哪怕只是两页纸的轻量PRD也要求写清楚背景、目标、验收标准、依赖条件第二建立“开发-联调-验收”的明确节点让AI工程师和算法工程师在联调阶段必须坐在一起过bad case这个习惯能省掉大量后期扯皮第三定期做“事后复盘”但复盘的重点不要放在追责上而是放在流程和分工哪里可以优化上这样团队才会越来越顺。针对AI Agent项目还有一个额外的建议因为Agent的行为链条长、不确定性更大效果验证不能只看最终结果还要看中间过程。所以协作时建议引入“轨迹追踪”机制每次Agent执行完任务都要把完整的调用记录和决策日志保存下来出了问题时可以回溯定位到具体是模型决策错了还是工具调用失败还是流程编排逻辑有误。6. 写在最后让角色分工服务于实际交付AI团队的角色分工说到底不是一张挂在墙上的组织架构图而是每天都在发生的协作方式和责任边界。最适合你团队的分工取决于你的项目阶段、团队规模、技术栈以及对交付时效的要求。小团队就别学大厂搞重流程大厂也别指望几个全能选手包打天下。我个人的建议只有三条第一所有角色都要围绕模型生命周期来定义职责谁对数据负责、谁对模型效果负责、谁对线上稳定性负责必须边界清楚第二AI产品经理和AI工程师这类“桥梁角色”一定要配好他们决定了需求能不能准确落地第三不论团队多大评估机制都必须尽早建立否则你连团队的产出是好是坏都说不清。最后再分享一个小经验如果你正在组建一支AI团队招人时不要只盯着技术栈是否匹配更要观察这个人有没有跨角色沟通的意愿。AI团队里最难的技术往往不是模型本身而是让一群思维模式完全不同的人围绕同一个不确定性问题持续协作。能把这件事做好团队就已经赢了一半。