夜雨聆风今天聊一个所有AI团队负责人都绕不开的问题：到底该招什么样的人，怎么搭这个团队？
先给结论：AI团队的配置，不是从岗位出发，而是从阶段出发。
一个真实的数字
麦肯锡2026年4月的报告显示：75%的中国企业在招聘AI人才时感到困难，91.3%的企业面临AI人才缺乏的问题。
但另一组数据更有意思。我们在德灵AI的实践中发现，团队成功的瓶颈几乎从来不是"缺一个算法大牛"，而是三个更朴素的问题：
产品经理不懂AI的边界在哪里 工程师不碰客户，写的系统没人用 业务方认为AI是"IT的事"，配合度接近零
先搞清楚一个问题：你在搭什么阶段的团队？
这个问题比"该招几个人"重要十倍。
很多团队负责人一上来就想照搬大厂配置：AI产品经理、数据科学家、ML工程师、数据工程师、领域专家、MLOps……一张图列十几个人。结果呢？半年下来，模型没上线，人先走了三个。
说到底，AI团队的配置应该跟着阶段走，而不是跟着大厂的组织架构走。
这就好比装修房子。你不会在打地基的时候买沙发，也不会在刷墙的时候选窗帘。每个阶段有每个阶段该干的事，对应的人也不一样。
我把AI团队分为四个阶段：
阶段一：验证期（0-3个月） 目标不是"做好"，而是"能不能做"。1-3个人，一个懂业务的产品经理加一个能跑通demo的工程师就够了。这个阶段不需要全职算法人员，用API调用的方式快速验证业务场景。
阶段二：打磨期（3-6个月） 目标从"能不能做"变成"能不能用"。这时候需要补充工程能力，把demo变成可部署的产品。团队扩展到5-7人，核心是产品经理+后端工程师+1名懂AI的工程师。
阶段三：稳定期（6-12个月） 目标从"能不能用"变成"能不能扛"。引入专职AI工程师做模型优化和部署，建立监控和迭代机制。团队8-12人。
阶段四：扩张期（12个月以上） 目标从"能扛一个场景"变成"能扛多个场景"。引入数据工程师、MLOps、领域专家等角色，支撑产品线扩张。
这张图的关键信息是：不是所有角色都在第一天就需要。
四个核心角色，各有各的坑
四个阶段里，有四个角色贯穿始终。每个角色都有自己独特的"坑"。
AI 产品经理
这个岗位的招聘市场上有个怪现象：会写PRD的产品经理一抓一大把，但能判断"这个场景该不该用AI"的产品经理凤毛麟角。
传统产品经理的核心能力是"定义功能"。AI产品经理的核心能力是"定义边界"。
什么叫定义边界？就是知道AI在这个场景里能做什么、不能做什么、做不好的概率有多大。这不是看几篇论文就能学会的，需要在真实项目里踩过坑才能长出来。
AI产品经理最贵的不是"懂AI"，是"知道AI在哪儿会翻车"。
招聘建议：优先从内部转。找一个做过2年以上业务的产品经理，花3个月让他跟AI项目，比空降一个"AI产品经理"靠谱得多。因为后者懂技术但不一定懂你的业务，前者懂业务学技术的成本更低。
AI 工程师
这个角色最容易被误解。很多团队以为"AI工程师 = 训练大模型的人"，招进来才发现日常工作中90%的时间在做数据清洗、API对接、部署运维。
AI工程师实际上是一个"三栖"角色：
懂模型（知道怎么选模型、怎么调参、怎么评估效果） 懂工程（能把模型变成可用的API，能处理并发、延迟、容错） 懂业务（知道模型输出的结果在业务场景里意味着什么）
三栖里缺任何一个，产品都会出问题。只懂模型的，模型跑得漂亮但集成不了；只懂工程的，系统能跑但效果拉胯；只懂业务的，需求写得漂亮但没人能实现。
招聘建议：不要迷信算法题面试。让候选人拿一个真实的业务数据集，用2小时做一个简单的分类或者检索demo，比刷十道LeetCode有用。
数据工程师
数据工程师是AI团队里最不"性感"但最不可或缺的角色。
所有AI产品的底层都是数据。数据质量决定了模型效果的上限，这句话不是一句正确的废话，而是每天都在被验证的真理。我们见过太多AI项目，模型调了几十轮，效果始终上不去，最后发现是数据源的字段定义变了没人通知。
数据工程师的职责不是"写SQL"，而是确保整个数据管道从采集、清洗、标注到存储的每个环节都可靠、可追溯、可复现。
招聘建议：找一个有数据仓库建设经验的人，比找一个会写SQL的人重要。数据治理的意识比查询的技巧更难培养。
领域专家
这个角色最容易被忽略，但也最容易被误配。
很多团队把"领域专家"定义为"业务部门的对接人"，平时不参与，有事才拉进来开会。这种配置方式几乎是无效的。领域专家不是"顾问"，而是团队成员。
一个合格的领域专家需要深度参与三个环节： - 需求阶段：判断AI方案是否真正解决了业务痛点 - 开发阶段：提供标注数据的质量校验和业务逻辑判断 - 验收阶段：基于实际使用体验给出改进方向
招聘建议：从一线业务人员中选拔，而不是从管理层中指定。一线人员知道真实的工作流是什么样，管理层知道的是"理想的工作流应该是什么样"。AI需要的是前者。
常见误区
误区一：先招人，再想做什么
这是90%的企业在犯的错误。
看到大厂在搞AI，就觉得自己也要搞AI团队。于是先发招聘JD，再想业务场景。结果人招来了，没想清楚让他们做什么，三个月后项目搁置，人又走了。
正确的顺序是：先验证场景，再扩充团队。用1-2个人做一个最小化验证，确认业务价值后再按阶段扩充。宁可用3个人做透一个场景，也不要用10个人铺三个半成品。
误区二：过度专业化
在AI技术栈半年一变的今天，过度追求专业化是一种奢侈。
有的团队在产品还没找到PMF（产品市场契合点）的时候，就开始招NLP专家、CV专家、推荐系统专家各一个。问题是，技术栈每半年迭代一次，去年招的NLP专家可能今年发现RAG比微调更实用。
这就有意思了。你花高薪请来的专家，在技术快速迭代的领域里，优势衰减的速度比你想象的快。
在AI团队里，能快速学习的人比已经很专业的人更有价值。
务实的做法是：70%通才，30%专才。通才负责快速搭建和迭代，专才在需要提升最后5%性能的时候介入。
一张表格说清楚不同阶段的配置
三句话总结：
验证期只做一件事，证明这条路走得通。打磨期只做一件事，把demo变成产品。稳定期只做一件事，让产品不崩。
一个人顶三个人的情况
实际操作中，很多企业没有预算按上面这个配置来。尤其是To B企业，AI团队往往是3-5个人的小团队，要支撑多条产品线。
这种情况下，有两种策略：
外部借力
模型能力用API调用（如通义千问、DeepSeek），不自己训练。数据标注用外包或者内部兼职。MLOps用云平台的托管服务。
核心团队只保留两个角色：AI产品经理（懂业务+懂AI边界）+ AI工程师（能集成+能调优）。其他人按需外部协作。
内部转型
选2-3个有工程背景的业务人员，用3-6个月培养成"AI应用工程师"。他们可能写不出最优的微调脚本，但能判断"这个场景用RAG还是微调"，能把模型集成到现有业务系统里。
这两种策略可以组合使用。先借力验证，验证通过后再内部转型培养。
最后一道关：考核方式
AI团队的考核方式和传统研发团队完全不同。
传统团队考核交付质量和速度：需求有没有按时做完，Bug率多高。
AI团队需要额外考核三个维度：
- 效果漂移
：模型上线3个月后，效果有没有下降？下降了多少？ - 业务采纳率
：业务方实际使用AI功能的频率，不是"部署了多少个API" - 迭代速度
：从发现效果下降到修复上线，需要多长时间？
这三个指标才是AI团队真正的"交付质量"。一个模型上线后无人维护、效果持续衰减的AI团队，和一个按时交付但产品没人用的传统团队，本质上犯的是同一个错误。
AI产品没有"上线"这个终态，只有"当前状态"。
AI产品经理系列写到这一篇就收尾了。八篇文章，从角色定义到团队搭建，覆盖了一个AI产品从0到1的完整链路。
回过头看，这八篇的共同主题只有一个：AI产品不是传统产品加了AI功能，它是一套完全不同的工程体系。 从需求定义、效果评估、定价策略、开发周期、幻觉管理到售前交付，每个环节都有自己独特的规则。
理解这些规则，比掌握任何具体的AI技术都重要。
微信 ID：hanxin1987216
- 推荐阅读 -
