第 40 篇 AI 团队搭建与角色分工
小系列〔组织与战略〕第 1 篇 · 定位：AI PM 的搭档们该怎么组、各自管什么；衔接《第 16 篇：转型路线图》的能力模型与《第 20 篇：跨团队契约》------把"该有什么能力"落成"该招什么人、怎么分工"。
一、最小 AI 产品团队构成
AI 产品不是一个人能交付的，但也不是一开始就要五脏俱全。最小团队的核心矛盾是：概率系统的质量无法靠单一角色兜底，又不能在没验证需求前堆满人头。结论先讲：一支能跑通"定义---建造---评测---上线"闭环的最小团队，由六个角色构成，其中 PM、工程、评测三者几乎不可省，算法与数据可随阶段外包或合并，设计视产品形态而定。
为什么是"概率系统"决定了团队结构？传统软件里，一个功能对不对，工程写完测试过就能确认；AI 功能对不对，取决于模型在你的数据上表现如何，这没人能凭经验拍板，必须有人专职建评测集、跑回归、定义什么叫"错"。于是"评测"从传统 QA 的边缘角色，变成 AI 团队里与工程平起平坐的核心。同时，质量不再只由 PM 写需求定义，而要先由 PM 定义维度与阈值，再由算法在真实数据上证明达标------这就拆出了"质量定义"和"质量验证"两个原本合一的动作，对应 PM 与评测两个角色。数据角色的独立同理：AI 的表现上限由数据决定，数据权限、质量、标注一致性若没人专门负责，系统会在上线后悄悄退化。
判定"是否必需"要看两个变量：质量责任是否必须由专人扛、以及工作是否会卡在无人负责的断点上。质量定义没人管就会扯皮（呼应《第 20 篇：跨团队契约》的验收三件套），数据没人管就会上线即退化，评测没人建就会"改了不知道变好变坏"（呼应《第 09 篇：没有评测就没有迭代方向》）。下面这张表给出每个角色的必需性、可省条件与核心职责，作为组队第一刀。
| 角色 | 是否必需 | 何时可省 / 合并 | 核心职责 |
|---|---|---|---|
| 产品经理（AI PM） | 必需 | 不可省 | 定义问题、质量基线、范围、验收、上线节奏 |
| 算法 / 模型 | 阶段必需 | 早期用现成 API 调用可外包；进入自研或微调才专职 | 方案选型、模型训练 / 调优、评测脚本 |
| 工程（推理 / 平台） | 必需 | 不可省 | 推理服务、降级链路、监控埋点、上线 |
| 数据 / 标注 | 阶段必需 | 数据已齐且量小可合并到算法；用量大需专职 | 数据清洗、标注、golden set 维护 |
| 评测（QA / 质量） | 必需 | 极早期可由 PM 兼，但规模一大必须独立 | 建评测集、跑回归、定义失败口径 |
| 设计（交互 / UX） | 条件必需 | 后台 / API 型可省；面向终端用户必设 | 交互、容错表达、人在环界面 |
这张表的价值不在"照单全收"，而在逼你回答：如果某个角色被标成"可省"，那它本该负责的断点由谁暂代、到什么规模必须补。最危险的省法，是把算法、数据、评测三件事都压给一个人，结果质量、数据、验收全在一个人脑子里，团队失去客观校验。一个可操作的判定尺：当你的评测集规模超过若干百条、或每周有超过一次上线变更时，评测就必须独立；当你的训练 / 微调数据需要持续采集与清洗时，数据必须独立。用这两个信号点触发"补人"，而不是凭手感。
二、角色职责细分与交接面
组队之后真正的麻烦不在"缺人"，而在"职责交叠处没人认领"。AI 产品有四个经典的责任断点，必须明确写进契约，否则每次出事都是甩锅现场。传统软件里"谁写的模块谁负责"能大致运转，因为逻辑确定、责任链清晰；AI 产品里一个失败可能源于数据脏、模型偏、评测漏、降级没接，四者纠缠，不预先切分就会集体无责。
谁定义质量：质量维度与阈值由 PM 在立项时定义，但"能否达成"由算法在 golden set 上验证。PM 定标准、算法证达标，二者不可互换------PM 不能替算法拍胸脯说"能做"，算法也不能私自放宽阈值说"够用了"。这是《第 20 篇》验收纪律的团队版：凡是形容词都要追到一个数字加一个数据集加一个口径，质量定义才算落地。
谁建评测集：评测集归评测角色（或早期归 PM）建与维护，算法可以提议新用例但不得单方面删除失败用例。黄金法则：出题人和答题人不能是同一人，否则评测会无意识地"避开自己的弱点"。一个真实翻车模式是算法既出题又答题，把难例悄悄移出测试集，上线后这些难例在真实流量里炸开。
谁管数据：数据资产与标注质量归数据角色；算法只消费数据不拥有数据。数据权限、脱敏、版本由数据角色对法务口径负责，算法调用前必须拿到"可用"的书面确认。数据版本失控是另一类隐形坑：训练用了一份数据、线上推理喂了另一份脏数据，评测全绿但线上全错，根因在数据与线上数据源没对齐。
谁管上线：上线开关归工程，但"是否达到灰度条件"由评测出报告、PM 拍板。工程负责把降级链路接好，PM 负责定义扩量阈值，评测负责证明当前指标在阈值内。三者少一个，上线要么卡死要么裸奔。
下面用一张交接面矩阵把"四个断点 × 三个动作"钉死，任何一项空缺都标红。
| 责任断点 | 定义方 | 执行方 | 验收方 |
|---|---|---|---|
| 质量维度与阈值 | PM | 算法（在集上验证） | 评测（回归报告） |
| 评测集构建与维护 | 评测 | 数据（提供样本） | PM（覆盖度确认） |
| 数据权限与质量 | 数据 | 法务（授权） | 评测（一致性检查） |
| 上线与扩量 | PM（拍板） | 工程（执行） | 评测（达标证明） |
契约写法铁律（呼应《第 20 篇》：跨团队契约每条 = 交付物 + 时间 + 验收标准）。把上面四个断点各写成一条三元组，评审时逐条对，缺验收标准的那条就是隐患。例如"评测集：评测在 M1 前交付 300 条覆盖核心场景的 golden set，PM 确认覆盖度 ≥ 约定值"------没有时间、没有规模、没有验收，就不是契约只是愿望。
三、自建 vs 外包模型能力：边界决策
模型能力是 AI 团队成本与差异化的最大变量。一个反复出现的错误是：一上来就自研模型，结果大量人力砸在基础设施上，产品没人用；另一个错误是：永远只调 API，核心能力被底座厂商拿走，护城河为零。决策框架看三个维度：差异化程度、数据私密性、调用规模经济性。
差异化程度高（模型能力本身就是产品卖点，如特定领域的理解精度）且数据私密（不能出域）且规模大到调用费超过训练摊销------这三项同时满足才值得自研。否则优先调用现成能力，把工程资源压在"数据闭环 + 评测 + 产品体验"这三件别人抄不走的事上。多数早期团队误判自己处于"必须自研"象限，实际只是"想掌握技术"的情绪，而非业务真的被底座天花板卡住。
| 判定维度 | 倾向调用（外包） | 倾向自研（自建） | 决策权重 |
|---|---|---|---|
| 差异化程度 | 通用能力、竞品也能用 | 模型即产品核心壁垒 | 0.30 |
| 数据私密性 | 可出域、已脱敏 | 不可出域、合规强约束 | 0.25 |
| 规模经济性 | 调用量小、摊销不划算 | 调用费 > 训练+推理摊销 | 0.25 |
| 迭代控制权 | 接受底座版本节奏 | 需自定迭代、低延迟可控 | 0.20 |
总分 ≥ 3.0（5 分制）倾向自研，< 2.5 倾向调用，中间先做"调用 + 自研探针"双轨。注意该表是战略判断而非技术炫技许可：即便三项都满足，自研也要先证明调用方案的天花板确实卡住了核心指标，而不是"想掌握技术"的情绪驱动。一个稳妥的双轨做法：主路径调用现成能力快速出产品，同时用一小部分资源跑自研探针，只在探针在核心指标上稳定超过调用方案一个阈值时，才把主路径切过去------这样自研决策由证据而非愿景驱动。
呼应选型与部署形态（见《第 38 篇：AI 产品架构设计》的组件视角）：自建意味着你要养推理集群、版本管理、评测回归全套组织；外包意味着你要把"底座变更"当成外部风险写进路线图缓冲（见第 41 篇技术依赖）。两种选择都不是免费午餐，区别在于成本发生的时间和可控性。
四、招聘什么人：能力画像与评分表
组建团队最贵的错误是招错人。AI 岗位的水很深，同名"算法"可能是训练大模型的人，也可能是调 prompt 的人；同名"数据"可能是标几百条的人，也可能是搭数据管线的人。更隐蔽的是"简历光鲜但和你的场景错配"------一个发过顶会的人不一定能帮你把客服摘要做稳定。下面给三类关键角色的能力画像与可量化评分表，满分 5 分，用于面试横向比较，防止"面感好"压过"能力缺口"。
算法岗看三件：是否理解业务指标（而不只是 loss）、会不会用评测集自我验证、能否把不确定性讲清楚。第一件决定他会不会为了"模型好看"牺牲"业务有用"；第二件决定质量系统能不能自转；第三件决定他能不能和 PM、客户正常对话，而不是甩一句"模型就这样"。数据岗看：是否懂标注一致性、能否设计数据采集闭环、有没有数据治理意识。评测岗看：是否本能地想"怎么证明它错"、会不会写失败定义、能否守住"出题人不答题"的独立立场------评测岗最怕招到"老好人"，为了团队和谐删掉难例。
| 角色 | 评估维度 | 1 分（弱） | 5 分（强） | 权重 |
|---|---|---|---|---|
| 算法 | 业务指标对齐 | 只谈模型指标 | 能用业务指标反推模型目标 | 0.35 |
| 算法 | 自驱评测习惯 | 等别人测 | 自己建集自证达标 | 0.35 |
| 算法 | 不确定性沟通 | 报"准确率"了事 | 讲清置信区间与失败面 | 0.30 |
| 数据 | 标注一致性设计 | 无概念 | 能定一致性阈值与仲裁 | 0.40 |
| 数据 | 数据闭环设计 | 一次性采集 | 设计持续采集与更新 | 0.35 |
| 数据 | 治理与合规意识 | 忽视权限 | 主动识别脱敏与授权 | 0.25 |
| 评测 | 失败定义能力 | 写"效果良好" | 写出可计数失败定义 | 0.40 |
| 评测 | 独立性 | 顺算法改口径 | 守独立、不删失败用例 | 0.35 |
| 评测 | 回归工程化 | 手工跑 | 自动化可重跑 | 0.25 |
总分 = Σ(分 × 权重)。招聘不是找每个维度都满分的圣人，而是看"团队缺哪块、候选人补哪块"。一个常见陷阱是全员招"算法明星"，结果没人建评测集、没人管数据------质量系统塌在最短的板上。面试时建议让候选人当场做一件小事：算法写一条你的失败定义、数据设计一张标注一致性表、评测针对一个真实 bad case 写验收口径，比聊项目经历更能暴露真实能力。评分表的价值是把"我觉得他行"变成"他在维度 X 拿了 4 分、维度 Y 拿了 2 分"的可比记录，避免群体面试被最会讲的人带节奏。
五、绩效与度量：度量团队而非个人
AI 团队的绩效考核若沿用手工软件的"功能数 / 故事点"，会直接扭曲行为：算法会挑容易刷分的场景、PM 会堆数量忽视质量方差、评测会被边缘化成"上线前的麻烦"。结论是：AI 团队的考核主体应是"质量基线的持续达标与业务贡献"，而非个人产出计数。
具体做法，三层挂钩：第一层，团队级质量指标（如核心场景的忠实度、幻觉率、P95 延迟）进团队 OKR，达标才谈奖金，把"概率系统的稳定性"变成集体责任。第二层，把"评测集覆盖率提升""失败面收敛速度"列为改进型指标，奖励"让系统更可测"的行为，而不是掩盖问题。第三层，个人考核看"在其责任断点上的可信度"------算法看"承诺阈值是否言出必行"、数据看"标注一致性是否达标"、评测看"是否拦住了回退"。这三层合起来，个人不会因"少做功能"被罚，团队不会因"堆功能"被奖。
必须避免的三种考核陷阱：以功能数定优劣导致质量被牺牲；把模型准确率当唯一 KPI 诱使私下放宽失败定义；只奖上线不奖"主动降级暴露风险"。第三种最易被忽视------一个工程师主动报告"某场景不达标、建议降级"，在功能数导向下算"没交付"，但恰恰是对系统最有价值的诚实。质量指标的口径一旦进考核，就绝对不允许事后改------呼应《第 20 篇》验收纪律：看到结果再改标准，毁掉的是整个团队对数字的信任。考核设计的一个反向检查：如果某人把失败定义放宽 10%，他的指标会更好看、奖金更多，那这套考核就在奖励作弊，必须重设。
六、组织位置：AI 团队放在哪
AI 团队在组织里的位置，直接决定它和外部的协作摩擦与话语权。三种典型摆法各有代价：产研一体（嵌入业务线）、中台（横向支撑多条业务）、独立 BU（自负盈亏做 AI 产品）。
产研一体下，AI 工程师紧贴场景，需求失真低，但容易重复造轮子、难沉淀通用能力。中台下，能力可复用、标准统一，但离业务远，容易做成"谁都不急"的支撑部门，需求排队、响应慢。独立 BU 下，目标最清晰、能拿完整价值链，但获客与商业化压力直接压到团队头上，容易为营收牺牲长期质量投入。选位不是一次定终身，而是随阶段演化------早期验证期嵌入最快出证据，中期多场景收口中台避免碎片，后期产品化独立 BU 承接完整价值。
| 摆法 | 适用阶段 / 条件 | 协作优势 | 主要代价 |
|---|---|---|---|
| 产研一体 | 单业务线、场景明确 | 需求失真低、迭代快 | 重复建设、能力难沉淀 |
| 中台 | 多业务线、需复用 | 标准统一、杠杆高 | 离业务远、响应慢 |
| 独立 BU | 已有成型产品、要规模化 | 目标闭环、权责清晰 | 商业化压顶、易牺牲长期 |
选位要随阶段演化：早期（验证期）嵌入业务线最快出证据；中期（多场景）收口中台避免碎片；后期（产品化）独立 BU 承接完整价值。切忌在验证期就搭中台------还没证明价值就先建层级，组织成本会拖死探索。一个判断信号：当你的 AI 能力被三条以上业务线重复调用时，是中台化的时机；在此之前硬中台，多半变成"没人用的公共平台"。反过来，当单一 AI 产品已能独立营收、需要完整 GTM 时（见第 42 篇），是独立 BU 的时机。摆法的代价也体现在招聘上：中台难招到懂业务的 PM，独立 BU 难养起纯研究的算法------位置决定你吸引谁。
七、成长路径与梯队
AI 团队不是招满就完事，能力会随技术迭代快速折旧。今年稀缺的微调技巧，明年可能被底座能力覆盖；今年有效的评测方法，明年因多模态输入要重写。梯队建设要解决两件事：新人如何上手、老人如何不被单点绑定。结论：用"评测集 + 场景库"作为组织记忆，降低对个人经验的依赖；用"双轨成长"（专业深与广）留住人。
具体机制：把每个核心场景的"能力边界、失败定义、评测口径"沉淀为文档资产，新人通过跑通历史评测集来对齐标准，而不是靠老人带教口口相传。这样老人离职，标准仍在集子里。老人向"宽"发展做技术负责人（管多场景质量），向"深"发展做算法架构（管模型能力演进）。关键岗位必须设备份，避免"某模型只有一个人懂"的单点风险------这是 AI 团队最隐蔽的组织脆弱点，平时无事，一人离职或休长假即断供。
梯队健康度的反向指标：评测集只在一个人电脑里、上线决策靠某人口头拍板、离职即断供。出现任一，说明组织记忆没沉淀，必须补文档化与交叉授权。一个低成本但高效的实践：要求每个核心模块的" owner "必须配一个" backup "，backup 每季度重跑一次该模块的评测集作为练习，既验证备份可用性，又让新人借真实集上手。把"能不能离开你团队还转"作为 leader 的考核项，组织韧性才会真正长出来。
模板：AI 团队角色职责矩阵（直接复制填）
AI 团队角色职责矩阵 · ［项目/团队名］ 版本 v__
─────────────────────────────────────
角色 必需性 可省条件 核心职责(1-3条) 本阶段担任人
PM 必需 --- 定义/验收/上线节奏 ___
算法 阶段必需 [早期调API可外包] 选型/训练/评测脚本 ___
工程 必需 --- 推理/降级/监控/上线 ___
数据 阶段必需 [量小合并算法] 清洗/标注/golden维护 ___
评测 必需 [早期PM兼] 建集/回归/失败口径 ___
设计 条件必需 [后台可省] 交互/容错/人在环 ___
责任断点契约(每条=交付物+时间+验收标准)：
1. 质量定义: PM定义 ___ / 算法证达标 ___ / 评测出报告 ___
2. 评测集: 评测建 ___ / 数据供样 ___ / PM确认覆盖 ___
3. 数据权限: 数据梳理 ___ / 法务授权 ___ / 评测一致性检 ___
4. 上线扩量: PM拍板 ___ / 工程执行 ___ / 评测达标证 ___
自建or外包判定(三项加权): 差异化__ 私密__ 规模__ → 结论[调用/自研/双轨]
组织位置: [产研一体/中台/独立BU] 阶段理由: ___
梯队风险: 单点人?___ 评测集沉淀?___ 备份?___一页速查
AI 团队搭建与角色分工 · 一页速查
─────────────────────────────
最小六角色：PM/算法/工程/数据/评测/设计
不可省：PM、工程、评测(早期PM兼)
可省合并：算法(调API)、数据(量小)、设计(后台)
四责任断点(必写契约)：质量定义/评测集/数据权限/上线扩量
铁律：每条=交付物+时间+验收标准；出题人≠答题人
自建vs外包：差异化×私密×规模 三项加权≥3.0自研 <2.5调用
招聘评分表：算法(业务对齐/自驱评测/不确定性) 数据(一致性/闭环/治理)
评测(失败定义/独立性/回归) 总分=Σ(分×权)
考核主体=团队质量基线达标，非个人功能数
禁：功能数定优劣 / 准确率唯KPI / 只奖上线不奖暴露风险
组织位置：验证期嵌入 / 多场景收中台 / 产品化独立BU
梯队：评测集+场景库作组织记忆；双轨(深/广)；去单点人
自查：六角色齐？四断点契约齐？自建判定写了？考核不数功能？常见坑
- 把算法、数据、评测三件事压给一个人，质量与验收全在一个人脑子里，失去客观校验。
- 出题人和答题人同一人，评测无意识避开自身弱点，指标虚高。
- 一上来就自研模型，人力砸在基础设施，产品没人用；或永远只调 API，护城河归零。
- 招聘全员"算法明星"，没人建评测集、没人管数据，质量塌在最短的板。
- 考核用功能数 / 故事点，诱使牺牲质量方差换数量。
- 模型准确率当唯一 KPI，私下放宽失败定义，毁掉团队对数字的信任。
- 验证期就搭中台，还没证明价值先建层级，组织成本拖死探索。
- 评测集只在一个人电脑里，离职即断供，组织记忆没沉淀。
- 上线决策靠某人口头拍板，无文档化与交叉授权，单点风险隐蔽。
- 数据权限与脱敏无人对法务口径负责，上线触发合规事故。
结语
AI 团队不是把"会 AI 的人"凑一起，而是把质量、数据、评测、上线四道责任断点用契约钉死------谁定义质量、谁建评测集、谁管数据、谁管上线，比"招到多牛的人"更决定一个概率系统能不能稳定变成产品。
本文为「AI 产品经理入门与进阶」系列第三季·小系列〔组织与战略〕第 1 篇（总第 40 篇）。数据来源：本篇角色矩阵、边界决策表、招聘评分表与组织摆法均为可操作框架，示例数值已标注"示例数据，非真实数值"。具体数值随技术迭代变化，请以最新数据为准。