组织架构问题：为什么 AI 功能会死在团队之间

模型跑通了。流水线运行正常。演示效果很好。然后这个功能就在数据团队的 Slack 频道和产品工程师的 JIRA 看板之间悄然死去。

这是大多数 AI 项目失败背后的规律——不是技术失败，而是组织失败。2025 年的一项调查发现，42% 的公司那年放弃了大多数 AI 项目，而上一年这一比例仅为 17%。每个被放弃的项目平均沉没成本高达 720 万美元。当事后复盘被写出来时，列出的原因是"数据准备不足"、"职责不清"和"缺乏治理"——这三种说法其实是同一件事的不同表达：没有人真正负责把这个功能交付出去。

工程团队埋怨数据团队的流水线不稳定。数据团队埋怨 ML 平台的部署工具太慢。ML 平台团队埋怨产品方需求总在变。功能就卡在这个缝隙里，慢慢腐烂，直到有人认为继续下去的成本高于放弃的成本。

三个团队，零个负责人

扼杀 AI 功能的经典套路是这样的：ML 平台团队负责基础设施，数据团队负责流水线和训练数据，产品工程团队负责面向用户的代码。从纸面上看，这是专业化分工；在实践中，这看起来像是三个群体，没有一个有动力去承担掉落在它们之间的那些棘手问题。

那些棘手问题并不光鲜。谁来调试模型训练精度与生产行为之间的差异？谁来写一条在凌晨两点模型开始退化时能叫醒人的告警？谁来决定模型质量何时"足够好"可以上线？谁在产品经理从用户研究中发现失败案例时迭代 prompt？

每一个问题都有现成的推脱方式。ML 团队会说模型评估是他们的事，但生产监控属于平台。平台会说他们提供基础设施，但不管业务逻辑。产品工程会说他们负责 API，但不管模型。数据团队会说他们负责训练时用到的特征，但不管线上服务时发生的事。

这就是组织问责空白在实践中的样子。没有人在撒谎，每个人都准确地描述着自己角色的边界。但真正需要交付的功能，恰恰活在那些边界之间的空间里——而那个空间没有主人。

康威定律的模型难题

康威定律指出，系统会反映构建它们的组织的沟通结构。每一个在微服务公司工作过的工程师都对此有直觉：服务边界往往沿着团队边界划分。

对 AI 系统来说，康威定律的作用更为强烈。大众 Cariad 的灾难是教科书式的案例：三个组织孤岛（奥迪、保时捷和大众品牌团队）在一家公司内部构建了三套独立的架构方案。内部人士描述，他们入职时没有职位说明，不清楚自己的角色，只能默认"做我在原来品牌积累的那套东西"。结果是重复的模型、不兼容的架构，以及一个从结构上反映组织功能失调而非工程决策的系统。

当你把 AI 所有权拆分给 ML 平台、数据和产品工程时，你得不到专业化的好处。你得到的是：模型服务层与训练流水线不匹配，数据 schema 是为分析查询而非特征服务设计的，产品团队把 AI 当成无法调试的黑盒 API 来消费。每个团队都在针对自己的成功指标进行优化，没有人负责整体的一致性。

那些能把 AI 功能做成功的团队往往长得不一样：规模小、跨职能，端到端地负责这个功能。一个 ML 工程师、一个产品工程师、一个数据工程师、一个 PM。一个团队，一个功能，对每一个跨学科问题都有明确的负责人。

没人负责的最后一公里

AI 的"最后一公里"问题，是指从一个可用模型到一个已上线产品功能之间的鸿沟。产出了可用模型的 AI 项目中，不到 50% 最终进入了生产环境。原因几乎从来不是技术问题——模型能用，基础设施也在。缺失的是有人负责集成。

想想集成到底需要什么：

• 模型需要像应用代码一样进行版本管理和部署。
• 生产服务路径需要有监控，且告警得有人真正响应。
• 当模型失败或退化时，功能需要有降级方案。
• 有人需要在模型精度指标和产品业务指标之间建立桥梁——它们不是同一回事，但都重要。
• Prompt 的变更需要有一条部署路径，而不是"让 ML 工程师去合并一个 PR"。

这些问题都不需要专业的 AI 技术，它们需要的是所有权。它们需要一个团队为功能的端到端、在生产中、随时间运行负责。

当 ML 平台负责基础设施、数据负责流水线、产品负责 UI 时，没有人负责集成。功能在 staging 环境通过，在生产环境失败，事后复盘产出的是一份"各方因素"清单，而不是一个明确的责任人。

那些不会出现在复盘会上的摩擦点

扼杀 AI 功能的问责空白，很少会把自己标榜为失败的根本原因。它们以团队习以为常的摩擦形式出现。

训练-服务偏差（Training-serving skew）。 数据科学家用 SQL 提取训练用特征。到部署时，有人需要把那段逻辑重写成生产服务的版本——通常是不同的语言、不同的依赖，针对延迟而非吞吐量优化。这次重写会引入 bug。模型在生产中的表现与训练时不同。谁来负责这个差异？在分团队结构中，这个问题会一直悬而未决，直到什么东西砰地炸掉。

Prompt 迭代速度。 在生成式 AI 产品中，prompt 是功能的核心组件——但它往往没有明确的负责人。产品经理无法在没有工程周期的情况下修改它。ML 工程师可以修改，但可能缺乏领域上下文。平台团队负责部署机制，但不负责内容。结果是 prompt 修改需要两周才能上线，而本该两小时搞定。

没有归属的 on-call。 当一个模型在生产中退化，谁会被叫醒？如果答案是三个团队收到同一条告警，你会得到三个团队互相等对方先动。如果答案是没有人，你会在用户投诉时才知道模型退化了。生产 AI 系统需要像后端服务一样的 on-call 归属，而且这个归属必须属于一个真正能处理告警的团队。

指标翻译。 ML 团队衡量精度、F1 分、BLEU，或者模型训练时针对的任何领域特定指标。产品团队衡量转化率、参与度、任务完成率和用户满意度。这些指标并不自动对应——模型精度提升 3% 可能在产品指标上看不出来，而模型处理得很糟糕的某个特定失败模式可能正在摧毁用户信任。没有一个团队负责在这两个指标空间之间架桥，模型通过验证后就会在生产中表现不佳。

能填补空白的所有权模型

有几种组织模式确实有效，它们有一个共同特点：把端到端功能的问责权落在一个团队身上。

嵌入式 ML 工程师模型。 ML 工程师坐进产品团队，与产品和软件工程师并肩工作，把 AI 功能作为主要职责。他们不是平台团队借调给产品的人——他们是拥有 ML 专业能力的产品团队成员。数据团队提供支持，平台团队提供基础设施，但嵌入式 ML 工程师负责这个功能：它在生产中的质量、迭代速度、业务指标。

这种模式快速且清晰，但很难扩展到少数功能以上，因为每个功能都需要一个专属的 ML 工程师。

跨职能功能小组（Feature Squad）。 一个由四到六名工程师（一名 ML、一到两名软件、一名数据、一名 PM）组成的小组，端到端地负责一个或一小组相关功能。小组是永久性的——不是项目结束就解散的临时团队。他们从研究到生产监控，包括 on-call，全程负责这个功能。

将 Spotify 的小队模型应用于 AI 功能是这样运作的：小队自主运作，具备无需外部依赖即可交付和维护功能的完整能力。行会（Guild）提供跨小队的知识共享，防止孤岛而不造成瓶颈。

中心辐射型卓越中心（Hub-and-Spoke CoE）。 一个精干的中央 AI 团队制定治理标准、管理模型基础设施，并负责安全和合规等横切关注点。嵌入各产品线的从业者负责具体功能。中心不负责功能交付——嵌入式从业者负责。中心负责跨功能需要保持一致的事情。

这种模式能扩展到功能小组触达不了的规模，但需要在中心控制什么（基础设施、标准）和辐射端负责什么（功能结果）之间做到纪律严明的分离。

几乎普遍失败的模型：平台团队提供一切，产品工程通过消费平台 API 来交付功能。这在纸面上看起来高效，在实践中制造瓶颈。平台成为每个功能的制约。功能团队无法在没有平台介入的情况下迭代。on-call 问责依然模糊。训练-服务偏差没有负责人。

AI 功能的直接责任人

单个功能的直接责任人（DRI）概念并不新鲜。苹果的管理哲学就建立在这之上，许多工程组织也在应用某种版本。

AI 功能需要一个 DRI，其负责范围不止于代码。AI 功能的 DRI 对模型的生产行为、训练数据质量、prompt 策略、业务指标影响和运营健康负责——不是作为这些方面的专家，而是当其中任何一项出问题时承担责任的那个人。

这是大多数工程组织不习惯的问责模式。后端工程师负责服务，ML 工程师负责模型，数据工程师负责流水线。而 AI 功能的 DRI 对所有这些负总责，并协调做具体工作的专家。

那些能高速交付 AI 功能的组织往往有这样的问责结构，即便他们不叫它 DRI。他们有一个人——通常是高级 ML 工程师或者具备强 ML 素养的技术 PM——是"功能出问题时我们打给谁"的答案。

让这个人不清晰的组织架构，就是产出 720 万美元烂尾试验的组织架构。

本周可以改变什么

如果你是一位工程领导者，眼看着一个 AI 项目停滞不前，答案几乎从来不是增加流程或设立一个新的治理委员会。答案是明确所有权。

看看你当前的项目，问自己：

• 如果功能在凌晨两点退化，谁会被叫醒？
• 谁来决定模型质量足够好可以上线？
• 谁来负责在模型精度和业务指标之间建立桥梁？
• 谁能在不等待一个工程周期的情况下修改 prompt？

如果这些问题中有任何一个的答案是"需要跨团队协调"，你就存在问责空白。通过指派一个有足够权限全面负责的 DRI，或者通过重组团队把所有必要能力放在同一个地方，来填补这个空白。

AI 功能的技术在很大程度上已经趋于成熟。把组织与只做试验的组织区分开来的，是组织架构是否足够清晰地分配了所有权，让一个团队能把功能一路推到终点。