第 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 setPM 确认覆盖度 ≥ 约定值——没有时间、没有规模、没有验收就不是契约只是愿望。三、自建 vs 外包模型能力边界决策模型能力是 AI 团队成本与差异化的最大变量。一个反复出现的错误是一上来就自研模型结果大量人力砸在基础设施上产品没人用另一个错误是永远只调 API核心能力被底座厂商拿走护城河为零。决策框架看三个维度差异化程度、数据私密性、调用规模经济性。差异化程度高模型能力本身就是产品卖点如特定领域的理解精度且数据私密不能出域且规模大到调用费超过训练摊销——这三项同时满足才值得自研。否则优先调用现成能力把工程资源压在数据闭环 评测 产品体验这三件别人抄不走的事上。多数早期团队误判自己处于必须自研象限实际只是想掌握技术的情绪而非业务真的被底座天花板卡住。判定维度倾向调用外包倾向自研自建决策权重差异化程度通用能力、竞品也能用模型即产品核心壁垒0.30数据私密性可出域、已脱敏不可出域、合规强约束0.25规模经济性调用量小、摊销不划算调用费 训练推理摊销0.25迭代控制权接受底座版本节奏需自定迭代、低延迟可控0.20总分 ≥ 3.05 分制倾向自研 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 篇。数据来源本篇角色矩阵、边界决策表、招聘评分表与组织摆法均为可操作框架示例数值已标注示例数据非真实数值。具体数值随技术迭代变化请以最新数据为准。
第 40 篇 AI 团队搭建与角色分工
第 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 setPM 确认覆盖度 ≥ 约定值——没有时间、没有规模、没有验收就不是契约只是愿望。三、自建 vs 外包模型能力边界决策模型能力是 AI 团队成本与差异化的最大变量。一个反复出现的错误是一上来就自研模型结果大量人力砸在基础设施上产品没人用另一个错误是永远只调 API核心能力被底座厂商拿走护城河为零。决策框架看三个维度差异化程度、数据私密性、调用规模经济性。差异化程度高模型能力本身就是产品卖点如特定领域的理解精度且数据私密不能出域且规模大到调用费超过训练摊销——这三项同时满足才值得自研。否则优先调用现成能力把工程资源压在数据闭环 评测 产品体验这三件别人抄不走的事上。多数早期团队误判自己处于必须自研象限实际只是想掌握技术的情绪而非业务真的被底座天花板卡住。判定维度倾向调用外包倾向自研自建决策权重差异化程度通用能力、竞品也能用模型即产品核心壁垒0.30数据私密性可出域、已脱敏不可出域、合规强约束0.25规模经济性调用量小、摊销不划算调用费 训练推理摊销0.25迭代控制权接受底座版本节奏需自定迭代、低延迟可控0.20总分 ≥ 3.05 分制倾向自研 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 篇。数据来源本篇角色矩阵、边界决策表、招聘评分表与组织摆法均为可操作框架示例数值已标注示例数据非真实数值。具体数值随技术迭代变化请以最新数据为准。