模型团队与基础设施团队合并：AI 平台组的三类交付物
一、组织调整没法评价，交付清单可以写清
据公开报道，有公司把 AI 研究部门与基础设施团队打通，给出的说法是模型与应用要深度结合，而不是单纯追求算力规模。组织怎么摆，取决于各家自己的业务节奏和人手，本篇不作任何评价，也不写人数与结构比例。我们只讨论它落到工程上的那一半：合并之后，这个平台组到底要交出什么东西，交出的东西怎么算合格。
我们的判断标准很朴素：平台组只有三类交付物——可复用的能力接口、可复现的数据与评测流水线、可观测的运行底座。除此之外的所有”支持”，包括帮忙调提示词、帮忙跑一次评测、帮忙排一个环境，都是临时工。临时工不是坏事，但它不能是平台组的产出形态，因为它不可交接、不可度量，而且会随着业务增长线性消耗平台上的人手，最终让平台成为整条链路上最慢的一环。
判断一个组是不是真平台组，可以用一个更直接的问题：把它今天解散，哪些东西会立刻失效？如果答案是”某些接口没人维护、某些评测没人跑、某些服务没人回滚”，那是平台；如果答案是”有几个业务线的活儿没人干了”，那只是共享外包。
二、交付物一：能力接口，核心不是有接口，是有契约
接口这一类的典型成员：模型调用、检索、嵌入、工具调用、评测任务提交。每一项的内容物都相同，缺任意一项，接口就只是”能调”而不是”可用”。
| 内容物 | 具体要求 | 合格判据 |
|---|---|---|
| 调用契约 | 入参出参结构、错误码语义、幂等性说明 | 应用组能不看平台源码完成接入 |
| SLA | 可用性、延迟分位、配额与限流规则 | 数值来自实测而非承诺，有月度回顾 |
| 版本与弃用策略 | 版本号规则、变更日志、弃用通知与迁移窗口 | 存在一条被走完的弃用流程作为先例 |
| 可观测 | 请求级日志、用量与错误分布、成本归因字段 | 一次故障能在无人协助下定位到调用方 |
| 样例与最小接入包 | 能跑通的最小示例、失败示例 | 新人半天内跑通并理解限制 |
版本与弃用策略是最常缺的一项。模型链路和传统 API 的差别在于”同一个接口名的行为会变”，所以版本必须同时锁三个东西：接口结构、路由到的模型档位、以及评测集版本。只给接口打版本、不给模型和评测打版本，等于把”升级后为什么变差”的排查责任留给业务方。
弃用策略要能验证它存在过：至少有一条接口曾经正式宣布弃用、给了迁移窗口、有人迁移完、最后真的下线。没有先例的弃用策略，在第一次冲突时就会失效。
三、交付物二：数据与评测流水线，交付的是可复现
第二类包括数据清洗、标注、实验记录、离线评测与灰度发布。它的验收口径只有一个词：可复现。任何一个半年前的实验结论，今天能不能重跑并得到可比数字，就是这条流水线有没有价值的判据。
具体要有的东西：数据来源与口径登记表，写清每个数据源的负责人、字段语义、更新频率，以及口径变更时的通知方式；标注任务的规范版本与一致性抽检记录，一致性不达标时标注结果不能进入评测；实验记录里必须同时存在失败实验，只留成功实验的实验室会反复投入同一批错路；评测集必须版本化并冻结，包括题目、判分脚本、提示模板与解码参数四件，缺一件就无法解释分数变化；灰度发布要有分桶规则和回滚触发条件，而不是”先给一部分人用”。
最容易在这里出错的一件事，是评测集不进版本库。评测集一旦可被随意编辑，所有历史分数就失去意义，而这件事通常在模型升级需要论证时才被发现——那时已经没有可信基线了。
四、交付物三：运行底座，把成本与故障当作接口的一部分
第三类是推理服务、配额、日志与成本归因、故障与回滚。底座与接口的差别在于它面向的是”能不能一直跑”，因此它的验收要靠演练而不是文档。
我们要求底座至少做到：每个调用方有独立凭据与配额，用量能归因到申请方，这一点与前面聊过的用量归因是同一套字段；降级链路明确，主模型不可用时走哪一档、超时预算多少、什么条件下回退到缓存或不生成，都要写死在配置里而不是运行时决定；故障演练按季度做，演练内容包含”供应商接口整段不可用”和”响应延迟恶化但不报错”两种，后者比前者更难发现，也更贵；回滚要能在一次操作内完成，包括模型档位、提示版本、路由配置三者同时回退，任何需要手工改多处代码的回滚都不算回滚方案。
底座的观测数据要向应用组开放自助查询。这一条常被当成”额外要求”，实际它是防止平台变成瓶颈的主要机制：问题如果只能由平台的人回答，那平台的所有时间就会被回答占用。
五、边界判定：抽象的时机与责任的归属
合并之后最容易模糊的是边界。三条判定我们一直在用。
同一功能出现两次以上才抽象。第一次出现时写清实现，第二次出现时写一份对比，第三次才提接口。提前抽象的代价通常比重复实现大，因为它会把还没稳定的语义固化下来，后续每个业务方都得绕着它走。
提示词与业务规则归应用组。平台提供变量注入、长度预算、模板版本化与安全过滤能力，但不替业务决定”该说什么”。一旦平台开始维护业务提示词，它就在替业务方做产品决策，而这类决策的责任没人愿意接。
模型升级由平台发起、由应用组回归。平台给出候选版本与离线评测差异，应用组在自己的任务集上跑回归并决定是否接收。两边都不签字就不能上线，这一条看起来慢，实际是最省时间的机制，因为它把”上线后才发现”变成”上线前分歧”。
防平台变成瓶颈的四条：自助接入，注册即用，不依赖人工审批才能拿到测试凭据；默认安全路径可绕过但必须留痕，绕过要显式声明理由并计入日志，比”禁止绕过”更能拿到真话；需求分级与公开排期，把优先级展示给所有申请方，减少私下催办；把应用组的实验成本可见化，实验花自己的预算时，排队自然短。
内部服务化最常漏的四件，正好对应上面四项的反面：评测集不版本化、数据源口径变更不通知下游、模型下线不给迁移窗口、成本无法归因到申请方。这四件每件补起来都不难，难的是它们在没有事故之前看起来都不像问题。
六、小公司该不该建平台组，以及给客户交付什么
三个判据，满足两条以上再考虑单设平台组：是否有多个业务共用同一条模型链路；是否有人能专职负责推理服务的运维与演练；评测是否已经成为上线的阻塞项。只满足一条时，更合适的形态是指定兼任负责人并把他手上的业务工作量减下来，而不是起一个组的名字。名字不会带来产出，交付物清单才会。
对客户的实际意义是洹拓正在改的交付方式。以前交一套 AI 应用，验收书里写功能点；现在把三类交付物写进合同附件：接口清单与契约、数据与评测流水线的内容物、运行底座的观测与演练记录。附件的价值不在于多几页纸，而在于它把”上线之后谁负责什么”提前定下来：哪些版本由客户自己维护，哪些评测集归客户所有，哪些升级需要客户回归确认。
组织调整新闻里那些说法，隔几年就会换一种。能留下来的只有清单：谁交出什么，怎么算合格，不合格找谁。