AI 企业中的产品团队：运营模型与组织结构

在普通软件团队旁边加一支数据科学小队，并不能变成 AI 公司的产品团队。工作的基本单位变了：从结果确定的功能，变成了随数据不同而表现不同的行为。同一个提示词，周一答对的问题，周五换了一批用户就可能答错。组织要是还按“功能做完即交付”来搭，计划、评审和值班都会在这一点上翻车。

一、分工与计划：先划边界，再定承诺

边界画清楚之后，计划才知道该承诺什么。

1.1 平台团队与应用团队之间那条线画在哪里

按技术与业务去切分平台和应用，几乎注定失败，因为模型相关的工作两边都占。可用的划法是按变更频率：一处改动会同时波及三个以上团队的，归平台；能在一周内独立改完并上线的，归应用。推理网关、模型注册表、评估框架、特征存储、成本归集属于前者；提示词模板、召回策略、降级文案、人工复核界面属于后者。这条线写下来之后要能回答一个具体问题：检索的分块参数改了，谁批准，谁值班。

这套划分和《团队拓扑》（Team Topologies，Matthew Skelton 与 Manuel Pais 著，2019 年）的思路一脉相承：应用团队相当于书里的流程对齐团队，平台团队的职责是减轻它们的认知负担，业务决策仍归应用侧。AI 场景多出来的麻烦在于，平台交付的能力本身会漂移，上游模型换个版本，同一个接口的行为就变了。所以平台与应用之间的契约，要比传统软件平台写得更细。

光有分工还不够，平台与应用之间如果只有一份 API 文档，冲突会在事故当天集中爆发。有约束力的契约要写清楚六项：P95 延迟上限、月度可用性、单次调用成本上限、模型版本变更的提前通知期、回滚时间窗，以及超限之后由谁承担。数字要具体到能被监控告警接住：P95 800 毫秒、可用性 99.5%、单次调用 0.012 元、版本变更提前 10 个工作日公告、回滚窗口 30 分钟。没有数字的契约，在评审会上只会被当作愿望。

1.2 模型工作估不出点数，计划靠什么排

检索效果的提升难以直接换算成故事点：工程任务可以估，研究结果却估不出来，没有人知道 Recall@10 从 0.61 提到 0.72 要花几天。可行的替代是时间盒加判定条件：两周，到期看指标是否越过 0.70，越不过就停，把结论写进文档，不再继续投人。容量按 70/20/10 分配，七成给确定性工程，两成给带判定条件的时间盒，一成还技术债。这套分配的代价是探索空间被压得很紧，真正需要三个月的研究型课题装不进去，只能单独立项。

计划排完，看板也得跟着分成两条轨道。探索轨的卡片只有两种结局，采纳或废弃，不允许长期挂着；交付轨的卡片走常规流程。两者混在一张板上时，探索卡会因为看起来没有进展而被反复追问，团队于是把它伪装成交付卡，计划的可信度就此崩掉。两条轨道的在制品上限要分开设定：交付轨按人数的一半，探索轨每个小队同时不超过 2 张。

一周里真正发生的是四件事。周一 45 分钟的接口会，平台与应用只谈契约变更和阻塞项，不谈进度。周三的评估评审只看失败样本，把最差的 20 条读出来，比盯着一个 0.83 的均值有用得多。周四是唯一的上线窗口，窗口外发布需要值班负责人书面同意。周五 30 分钟看成本与延迟曲线，单次调用成本环比上涨超过 15% 就要有人解释。四件事的总时长控制在 2 小时以内，超过这个量，团队会开始逃会。

季度层面能承诺的也不是功能列表。季度计划里写“上线智能摘要功能”没有意义，模型达不到质量就上不了。可以承诺的是能力边界：把摘要的人工可接受率从 68% 提到 80%，把长文档处理的 P95 延迟压到 3 秒以内，把标注成本从每千条 1200 元降到 800 元。功能是否发布，交给评估门禁去判断。这样做的代价是业务方一开始很难接受，他们要的是日期。折中的办法是承诺“到季度末给出可发布或不可发布的明确结论”，把不确定性显式写进承诺里。

同样的思路要落到路线图上：除了日期，还要给每个条目标注把握度。已验证的写具体周次；已有原型但没过门禁的写档期区间，例如第 7 到第 9 周；只有假设的写判定时点，例如第 5 周给出可行性结论。管理层真正需要知道的，是哪些条目会变、什么时候能定下来。按这种方式标注之后，季度中期的路线图调整从一场争论变成按预设时点做更新。

这套节奏并非处处成立。组织规模在 30 人以下时，平台与应用的划分只会带来纯粹的开销，一个团队直接做完更快。场景单一、模型半年不换的产品，三道门禁中的第三道可以省掉。强监管行业里，治理评审的周期由外部审计决定，周四上线窗口这样的安排要让位于监管节奏。把这套节奏当成模板照搬，往往在第二个季度就会因为会议密度过高而被团队自行废弃。

二、门禁与数据：尺子先要可信

门禁决定能不能上线，而门禁本身是否可信，取决于评估数据和标注的一致性。

2.1 评估门禁：位置、隔离与失灵

三道门的范围逐级放大。提交代码时跑冒烟集，120 条样本，5 分钟内出结果，挡住明显退化；合并前跑回归集，1800 条，约 40 分钟，任一核心指标下滑超过 2 个百分点就阻断合并；发布前跑对抗集加人工抽检，300 条由标注员打分，占用 2 个工作日。三道门里只有第二道有权阻断合并，第一道给信号，第三道握有发布否决权。分工不清的话，团队会把所有争议都堆到发布前一天。

门禁要可信，训练集和评估集必须分开，否则门禁是在骗自己。模型训练时见过的样本，评估时当然答得对。这时回归集的高分只说明模型记住了样本，说明不了泛化能力。一上线碰到没见过的流量，退化马上就会暴露。

这条线要靠机制守住，不能靠自觉。评估集从源头单独抽样、单独封存，进过训练的样本永远不进评估，两边由不同的人或流程维护。每次补充难例，先决定它进训练还是进评估，进了一边就不许再进另一边。

最隐蔽的污染，是拿同一批线上日志既做微调又做评估，而且采样时不去重。看上去是两套数据，其实是一套。

门禁也会失灵，通常有两种方式。一种是阈值定得比现状还松，任何提交都能过，团队看到的永远是绿灯。另一种是黄金集陈旧，样本半年没有更新，而线上流量分布已经变了，评估通过的模型在真实请求上退化 8%。对策是给评估集设定更新节奏：每月从线上采样 200 条难例补入，每季度淘汰一次失去区分度的样本（某条样本连续 6 次评估中所有版本都能通过，就不再提供信息）。

太严则是另一头的坑：阈值卡得比合理波动还紧，正常的模型抖动都会触发阻断，团队每天在处理假警报，几周之后就开始想办法绕过门禁：加白名单、手动放行、把阈值偷偷调松，门禁的权威一旦被绕过就再也立不起来。

合理的阈值要留出模型天然波动的空间：核心指标下滑超过 2 个百分点才阻断，是因为 2 个点以内大概率是噪声。定阈值前先测一下同一个模型重复评估的分数波动有多大，把阻断线画在波动之外。

门禁分数可信的另一个前提是指标口径统一，由平台实现、由治理组仲裁。幻觉率怎么算、延迟从哪一刻开始计时、成本是否包含重试，这些定义若由各团队自行解释，所有报表都会失真。可行的分工是：平台团队给出计算实现并开放代码，治理组在争议时仲裁，应用团队只能提出修改口径的申请而不能自行改动。改口径要留痕，每次变更记录生效日期，历史数据保留旧口径的一份副本，否则季度对比会出现无法解释的跳变。

2.2 标注数据归谁，尺子谁来校

一个应用团队花几周标出来的微调数据，是给自己场景用，还是全组织共享？不说清楚，就会出现两种浪费：要么各团队各标各的，同类数据重复标好几遍；要么有人拿了别人的数据去训，却没人对质量和授权负责。可行的归属是：标注数据默认进组织级的数据资产池，由平台登记和管理，但带着场景标签和授权范围，别的团队复用前要能看到它当初是为什么场景、按什么标准标的。跨场景复用最容易踩的坑是标准不一致：A 场景可接受的标注粒度，到 B 场景可能根本不够用。所以复用之前，先核对两边的标注标准。

数据的另一个断点在溯源，而且总是断在交接处。数据从哪来、授权到哪、能不能用来训练，在一个团队内部通常很清楚，一跨团队就断了。平台把数据接进特征存储时记了来源，应用团队取用时却只看到一张表，不知道授权边界在哪。等合规部门来问，谁也说不清这份数据当初是以什么名义采集的。

原因很简单：溯源信息在传递时被当成了可有可无的附加信息。所以契约里那条“平台记录溯源、应用声明使用范围”要落到具体字段：每份数据都带着来源、授权用途和保留期限一起流转。应用团队声明用途时，系统自动比对有没有越界。

数据之外，标注质量本身会随时间漂移。同一个标注员，三个月前和现在对“幻觉”的判定尺度可能已经不一样；新来的标注员和老人之间更是天然有偏差。靠入职时一次培训守不住一致性，它需要持续校准：定期让多名标注员标同一批样本，算一致性系数，Kappa 低于 0.7 就重写标注指南、重新对齐。

这条线并非拍脑袋：按 Landis 与 Koch 1977 年提出、至今最常用的分级，0.61 到 0.80 算“高度一致”，0.7 正好落在这一档中间。更实用的是在每批任务里掺一小撮已知答案的金标样本，标注员在不知情的情况下标到它们，用命中率实时监控谁的尺度开始飘。内部标注员和外包之间也要定期交叉核对，因为外包换人频繁，漂移比内部更快。评估集的可信度，归根到底立在标注一致性上，尺子自己在变，量出来的模型进步就都是幻觉。

标注还是节奏里最容易被漏算的约束，产能要提前一个季度排。评估集与微调数据都依赖标注。一个 4 人的内部标注小组，处理复杂场景每人每天约 120 条，一次 300 条的发布前抽检就要占掉全组大半天的产能，加上复核和排期，日历上就是第三道门的 2 个工作日。季度规划要把标注工时当成与工程工时同等的资源来排，否则会出现模型改完却等标注两周的局面。外包适合规模化的简单任务，难例和争议样本留给内部，两者的一致性每月抽查一次。

三、治理与组织形态：规则要落到人头上

谁来审、谁来复盘，和团队按集中式还是联邦式组织，是同一个问题的两面。

3.1 治理、红队与事故复盘

对抗测试和红队如果由应用团队自己做，天然会手软：没人愿意认真攻击自己马上要上线的东西。把对抗集的维护和红队的执行权放在治理组，让一个不背发布 KPI 的角色来找茬，才测得出真问题。原因在激励：应用团队的目标是上线，红队的目标是拦下不该上线的东西，两个目标必须由两拨人扛。治理组握有发布否决权，红队的结论要能直接触发这个否决，而不是提个建议由应用团队自行决定改不改。涉及对外生成内容和个人数据的场景，红队参与是同步评审里不能省的一环。

治理评审本身也要防着退化成盖章。通过率 100%、材料评审当天才发、评审人没有否决权，这三条同时出现，评审就只是仪式。改法有四条：材料提前 3 个工作日提交，不提交就顺延；结论增设“有条件通过”一档，附带 30 天内必须补齐的项；评审记录写明被拒的具体条件，而不是“建议进一步完善”；每季度抽 2 个已通过的项目做回溯，检验当初的判断是否成立。回溯是让评审认真起来的关键，评审人知道自己的结论会被检验。

出了事之后，复盘要改的是流程。模型类事故的复盘容易滑向“提示词写得不好”。有用的复盘要回答三个问题：这次失效为什么没有被三道门禁中的任何一道挡住；从异常出现到有人知晓花了多久；回滚是否在承诺的 30 分钟内完成。产出必须是具体的机制变更，例如把这类样本加入回归集、给该指标加上环比告警，而不是培训与提醒。一次复盘只提交 1 到 2 项改动，提交 8 项的复盘，三个月后一项都不会落地。

红队用例最好全组织共用一份清单，按风险类别分栏：虚构内容、信息泄露、知识产权、有害偏见，每一栏下面挂具体的攻击样本和对应的处置动作。各团队各写一套，口径很快就对不上，事故复盘时也找不到共同的分类可以归档。清单由治理组维护，应用团队补充本场景的难例，新增的类别要经治理组确认才算数。

3.2 集中式、联邦式与切换顺序

集中式的断点是排队。一个 12 人的中心团队服务 9 条业务线，需求排队普遍超过 6 周，业务线的反应不是等待，而是自己招人组建影子团队。影子团队用不上平台的评估框架和成本约束，半年后组织里会出现 5 套互不兼容的提示词管理方式，治理组无从审起。集中式的有效期通常止于组织需要支撑第 4 到第 5 个应用场景的时候。

联邦式的断点则是重复与不可比。每个团队自建评估集，幻觉率的判定标准各不相同，A 团队的 3% 和 B 团队的 3% 不是一回事，管理层拿到的横向对比表是假的。成本上同样吃亏，各团队分别谈下来的推理配额，谁都拿不到量价，单价自然高于统一采购。联邦式要成立，前提是有人对口径拥有强制权：评估指标的定义、成本归集的方式、事故等级的划分，这三样必须由一处统一给出。

什么时候该从集中式转向联邦式，三个信号足以判断：中心团队的排队时长连续两个月超过 4 周；出现第二个绕过中心团队自行开发的场景；中心团队超过一半工时花在解答问题而不是构建能力上。任何一条持续出现，就该把与业务贴得最近的那部分能力连人一起迁出去。反向的信号是重复建设，两个团队做出功能重叠度超过 70% 的组件，说明该往回收一点。

无论往哪个方向调，切换顺序都是先立门禁，再动组织结构。先改汇报线的重组大多会反弹，因为新结构缺少共同的判定标准可依，顺序应当反过来。第一步统一评估口径与门禁，让所有团队用同一把尺子，约需 6 到 8 周；第二步把共享组件从最拥挤的那个团队里剥出来，成立平台小队，规模控制在 8 人以内；第三步才是调整汇报关系。这个顺序的好处是每一步都能单独产生价值，中途停下来也不至于留下半成品。

四、人、运营与供应商：让结构天天转起来

最后是日常层面：招什么人，平台怎么运营，供应商怎么选，变更怎么放量。

4.1 人和小队怎么排

以一个 600 人的研发组织为例（数字为示意），AI 相关人力约 90 人，一种可运转的排布是：平台小队 12 人，拆成推理与网关 5 人、评估与数据 4 人、成本与可观测 3 人；应用侧 6 个小队共 54 人，每队 8 到 10 人并配 1 名嵌入式数据科学家；标注与质量 14 人，其中 4 名内部标注员专攻难例，其余外包并由内部抽检；治理组 6 人，专职 2 人，其余从法务与安全兼任。兼任比例超过一半时，治理评审的排期总会被本职工作挤掉。

那名嵌入式数据科学家到底归谁管，是个绕不开的问题。每个应用小队里配一名数据科学家，好处是模型工作离业务足够近，坏处是这个人夹在两套标准之间。业务催他快出效果，平台要求他守评估口径和成本约束，两边的诉求经常打架。

比较稳的做法是双线：行政上向应用负责人汇报，绩效也由应用团队打；专业上受平台的评估规范约束，评估集、指标定义和上线门禁都必须用平台那一套，不能自己搞一套宽松的。

这条线画得对不对，看一件事：业务想跳过门禁抢上线时，这位数据科学家站在哪边。如果他因为绩效握在应用手里就默许放水，双线就名存实亡，评估口径必须收归平台强制执行。

这套结构对人的要求和传统软件团队不一样。时间盒到期就停、指标不达标就砍、承诺的是能力边界而不是功能日期，这些都要求团队能安然接受不确定。招平台的人，看的是他能不能把一件模糊的事拆成可判定的门槛；招应用的人，看的是他愿不愿意让评估结论而不是自己的直觉来决定上不上线。最难招的是那种既懂模型的不确定、又肯守工程纪律的人，这类人稀缺，通常要靠内部培养而不是市场上现挖。

一个把“这个季度一定上线”当成本事来许诺的人，在这套结构里会反复承诺自己交付不了的东西。

至于绕过中心团队冒出来的影子团队，目标是收编。业务线绕过中心团队自己招人，多半是因为等不起六周的排队，一味封杀只会把他们逼得更隐蔽。更现实的做法是：承认他们跑得快这件事有价值，把他们的提示词管理、评估方式接进平台的统一口径，人可以继续贴着业务坐，但用的是同一套评估框架和成本约束。收编的前提是平台先把排队时间降下来，如果接进来之后他们反而变慢了，下一个影子团队马上又会冒出来。判断收编成不成功，看半年后组织里还剩几套互不兼容的提示词管理方式，从五套收敛到一套，才算真的收编了。

4.2 平台的日常运营

模型服务的值班不该挂在应用团队。可行的分层是一线由平台承担，覆盖网关、限流、模型不可用；二线由应用承担，处理输出质量类问题；升级到三线需要业务负责人参与，触发条件写死为影响用户数超过 1 万或涉及对外生成内容。三层的响应时间承诺分别是 15 分钟、1 小时、4 小时。没有触发条件的升级路径等于不存在，所有事故都会堆在一线。

应用团队向平台提需求也得有通道，否则平台若对所有请求来者不拒，两个季度内就会退化成工单团队。可用的做法是把请求分成三类：接口内能自助的，直接查文档；需要平台改动但有先例的，走排期，承诺 2 周内给出档期；没有先例的新能力，进季度规划，且需要至少 2 个应用团队联署。联署这道门槛能挡掉大部分只服务单个团队的定制需求，也让平台的路线图有依据。

平台自己的技术债也要进季度账。那条 70/20/10 里给技术债留的一成，最容易在忙起来的时候被借走。平台的技术债有它自己的特点：它不像业务功能那样有人天天催，欠着看起来没事，直到某次模型升级或流量翻倍时集中爆发：评估框架跑不动、成本打标漏了新场景、网关扛不住并发。这类债要显式记账，和功能需求放在同一个待办里排优先级，而不是等出事了当救火处理。

Google 的工程师早在 2015 年 NIPS 会议的论文《机器学习系统中的隐藏技术债》（Hidden Technical Debt in Machine Learning Systems）里就点过这一点：真实的机器学习系统里，模型代码只占一小块，债务主要堆在周边的数据管道、配置和监控上，而这些恰好都归平台。判断平台是不是在偷偷借债，看一个信号：每次上游模型换版，平台侧要手忙脚乱多久才跟上。跟得越吃力，说明欠得越多。

推理成本按什么口径分摊，同样落在平台身上。把推理账单平摊到各团队会消灭一切节省的动机。按调用量分摊更接近真实，前提是网关能按团队和场景打标。实践中还要留一块公共池，占总预算的 10% 到 15%，用于评估、回归和压测这类不属于任何单个业务的消耗。超支的处理方式写进契约：连续两个月超出 20% 的场景，自动触发一次架构复核，而不是直接砍配额。

算一笔账。平台月推理预算 50 万元，公共池按 12% 留出 6 万元，剩下 44 万元按调用量分给 6 个应用小队。某个小队上月调用占比 25%，分摊 11 万元；它连续两个月实际花到 13.2 万元以上，也就是超出 20%，复核自动启动。复核最常见的结论是改参数，很少需要砍人：如果超支来自把检索 top-k 从 5 调到 8（后文会提到，这一改动可能让单次成本上涨 30%），调回去就能让成本回落约 23%，因为 1/1.3 约等于 0.77，这支小队基本回到预算线以内。

衡量平台干得好不好，成功指标不该是上线数量。用交付了多少组件来衡量平台，会促使它不停造新东西。更贴近实际的指标有三个：接入的应用团队数量与它们的自助率，例如 80% 的常规请求不需要平台介入；从新场景立项到跑通首次评估的天数，目标压到 10 天以内；平台侧引发的事故占比，控制在总量三成以下。这三个指标彼此制衡，单追其中任何一个都会让另外两个变形。

而估算能同时支撑多少个应用场景时，容易只盯着业务侧的承接能力，漏掉平台自己的运维产能。每多接一个场景，平台的值班面、要维护的评估集、要盯的成本曲线都跟着增加。一个控制在 8 人以内的平台小队，能稳当支撑的场景数是有上限的，硬塞第七、第八个进来，先垮的往往不是业务而是平台的响应时间：门禁开始积压，事故响应变慢，成本打标跟不上新场景。新场景接入前，除了问业务能承接多少商机，还要问平台自己还剩多少运维余量，余量见底时先扩平台，别先扩场景。

4.3 供应商选择与安全发布

只用一家供应商，口径统一、集成简单，代价是把命脉交给别人：它涨价、限流、出故障，你没有退路。同时跑两家，换来韧性，代价是几乎所有东西都要维护两套：两套提示词、两套评估基线、两套成本口径，网关还得抹平它们的行为差异。折中的常见做法是主用一家、备一家常温待命：备选供应商只承接一小部分常态流量，保证它随时能扩，但不为它维护完整的功能对等。这个选择该由平台统一做，不能让每个应用团队各自决定用哪家，那样组织里会同时出现四五家供应商，统一口径彻底失守，采购也拿不到量价。韧性买多少，取决于这套系统一旦断供，业务能忍多久。

备着一家还不够，换供应商要提前演练。把主模型切到备选供应商，第一次做通常需要 3 到 6 周，大部分时间花在提示词行为差异和输出格式的适配上。等到被迫切换时才动手，风险不可控。可行的节奏是每半年做一次切换演练，只切 5% 流量，跑完整套回归集，记录质量差异与成本差异。演练的产出是一张对照表，让紧急切换时的决策有据可依。

具体到每一次放量，都要有一条写死的爬坡曲线。模型或提示词的变更不该一次切满，也不该凭手感放量。可执行的做法是：先 1% 流量跑满 24 小时，核心指标不掉再到 10%，稳住一到两天到 50%，最后全量。每一档都有明确的驻留时间和回退条件，任一档触发指标下滑就自动退回上一档，而不是继续往前。

爬坡的意义在于把问题挡在小流量里，1% 的时候发现退化，受影响的用户不到百分之一，回滚也快。看量级：日活 50 万的产品，1% 流量跑满 24 小时约覆盖 5000 名用户，足以让 120 条冒烟集覆盖不到的长尾请求露头，而出了问题，波及面也只有这 5000 人。省掉爬坡直接全量，等于把整个用户群当成第一批小白鼠，出了事回滚窗口那 30 分钟根本不够用。

爬坡要管住的不只是代码，提示词与配置的变更也要有版本。线上行为的变化，一半以上来自提示词、检索参数和阈值的调整，而这些改动常常不走代码评审。把它们纳入版本管理是整套节奏能否成立的前提：每次变更带上作者、生效时间、关联的评估结果，灰度期不少于 24 小时。一个只把检索 top-k 从 5 改到 8 的提交，可能让单次调用成本上涨 30%，而在没有版本记录的情况下，成本曲线的异常要排查好几天。

新应用团队接入平台的头四周有固定节奏。第一周只做一件事，把该团队的场景样本灌进评估框架，拿到基线分。第二周接入网关与成本打标，此时并不上线。第三周在灰度环境跑通三道门禁，并故意制造一次失败，确认门禁真的会拦。第四周才开始正式迭代。跳过第三周的团队，往往要到两个月后的第一次事故里才发现门禁配错了。

五、落地过程中最常被问到的问题

平台团队多少人合适？ 起步 6 到 8 人，覆盖推理网关、评估框架、成本归集三块。超过 15 人却还没有服务到 4 个以上应用团队，说明它在做本该由应用团队做的事。

评估集需要多大？ 冒烟集 100 到 150 条足够，回归集在 1500 到 2000 条之间，再大只会拖慢合并。质量比数量重要，难例占比低于 30% 的评估集挡不住退化。

探索时间盒到期但指标接近达标怎么办？ 只允许延长一次，时长不超过原时间盒的一半，并且要提前写明第二次的判定条件。缺少这条限制，时间盒会变成没有终点的项目。

治理评审能不能异步？ 低风险场景可以走异步审阅，承诺 3 个工作日内出结论。涉及个人数据或对外生成内容的场景保留同步会议，这类判断需要当场追问。

应用团队想自己改推理参数怎么处理？ 开放参数区间而不是开放参数本身。平台给出允许区间和超出区间的申请通道，应用团队在区间内自行调整，不需要审批。