你的 AI 功能没有 DRI：为什么它在没有季度目标负责人的情况下处于漂流状态

走进一个季度业务复盘（QBR）会议，问问谁的名字写在那个 AI 功能旁边。看看会发生什么。PM 指向平台团队。平台团队指向编写评估工具集（eval harness）的研究工程师。研究工程师指向那个一直在发关于成本图表邮件的 FinOps 分析师。FinOps 分析师又指回了 PM。四个人，一个功能，零个负责人。评估分数已经连续六周下滑，却无人排查，因为监控仪表盘躺在一个上次更新还是发布次日的 Notion 页面里。

这是 2026 年各组织交付 AI 功能最可预见的结果。该功能是由一个攻坚小组（tiger team）发布的，而该小组在发布新闻稿发出的那一刻就解散了。埋点是由一个没有产品授权的基础设施团队生搬硬套上去的。Prompt 是代码库中的一个 prompts/v3.txt 文件，其 Git blame 记录分散在九个工程师身上，谁也不记得为什么第 47 行要写那些内容。面向用户的入口由一位 PM 负责，但他的 OKR 在两个季度前就已经转向了下一个发布项目。这个功能在技术上处于生产环境，技术上有负责人，但在结构上已经沦为孤儿。

组织中所有其他产品板块都有一个直接责任人（DRI），他们的晋升理由（promotion case）都系于此。结账流程有负责人。通知系统有负责人。搜索排名模型——甚至是那个早于 LLM 时代的模型——也有负责人。而 AI 功能只有一个组织架构图。这就是区别，也是为什么一组功能能季度性地变得更好，而另一组功能却在逐渐飘移。

被遗弃 AI 功能的症状

这种飘移很少是大张旗鼓的。它起初看起来毫无异样，接着表现为一系列微小而尴尬的事实，直到一次事故复盘迫使人们将它们联系起来。

我反复看到的一种模式：评估套件在周二捕获了一次退化。Slack 警报发到了一个名为 #ai-quality 的频道，里面有 23 个人，但没有一个人被 Call 到。警报挂了九天。终于有人在站会中注意到了，点进 Prompt 代码库，才发现一个无关的依赖库更新改变了模型客户端的 JSON 模式（JSON-mode）行为。修复只需两行代码。但修复延迟了九天，因为没有任何人的日程表上写着“如果 #ai-quality 报警，由你响应”。

第二种模式：Prompt 中堆满了 TODO 注释。// TODO: 搞清楚为什么在医疗免责声明的情况下仍会产生幻觉。// TODO: 当工具调用返回 [] 时增加兜底方案。这些 TODO 不断堆积，因为没有人拥有合并权限——或者更准确地说，没有人有责任去做决定。对 Prompt 的每一次修改都是一次伪装成配置编辑的低级别产品决策，而没有负责人的产品决策默认就是“保持原样并加个注释”。

第三种模式：事故复盘将“AI 团队”列为行动负责人。但其实并没有 AI 团队。只有一个平台组、一个研究组、一个产品组，以及一个值班 SRE 希望有人能解释清楚的功能开关（feature flag）。这个行动项在接下来的一个月里被重新分配了三次，最后以“延期”为由结案。

第四种模式：领导层询问 AI 功能的采用率数据，三个小组发来了三个不同的仪表盘。产品团队报告父级功能（AI 功能嵌套在其中的那个）的周活跃用户数（WAU）。平台团队报告原始 API 调用量。FinOps 报告接触过模型端点的独立计费账户数。这些数据没有一个是在衡量同一件事。它们都没错。但没有一个能回答问题。

如果以上情况发生了两种或更多，那么该功能就没有 DRI。组织架构图替代了具体的人，而组织架构图无法做决策，无法被 Call，也无法拥有晋升理由。

为什么 AI 功能特别容易出现这种情况

传统的产品板块能清晰地归入一个团队的职责范围。结账 PM 负责转化；结账 EM 负责可靠性；结账设计师负责表单。虽然仍有跨团队协作——支付基础设施、反欺诈、税务——但功能本身有一个重心。

AI 功能默认没有重心。它们横跨四个职能部门，且需要这四个部门全部运转才能生效：

• 产品（Product） 负责功能是否解决了用户问题。
• 工程（Engineering） 负责功能是否正常工作。
• 研究 / ML（Research / ML） 负责模型和评估工具集是否反映现实。
• 财务 / FinOps（Finance / FinOps） 负责单位经济效益是否合理。

每个职能部门都有自己的待办清单、自己的指标和自己的季度评审。如果 AI 功能不在他们任何人的核心 OKR 中，它就会存在于缝隙中。而缝隙正是功能开始飘移的地方。

还有一种发布动态让情况变得更糟。AI 功能通常通过攻坚小组（tiger team）交付——即为了推进高风险举措而组建的小型跨职能小组。攻坚小组非常适合发布。但由于在发布完成的那一刻小组就会解散，且没人计划交接工作，它们对于所有权的移交来说简直是灾难。Tempo 关于攻坚小组的指导建议非常明确：定义小组解散后由谁接管产出，否则你就是在制造一场移交噩梦。大多数发布都跳过了这一步。“移交文档”是一个在第二周之后就再也没人点开过的 Notion 页面。

Reforge 对 AI 原生产品团队的分析直言不讳：组织仍在针对那些已不再以原始形式存在的职位来评估员工。发布了 AI 功能的 PM 仍在被评估如何发布下一个功能。没有任何激励机制奖励他们去做那种让现有功能免于腐朽的、缓慢且平庸的工作。于是他们去发布下一个功能，而腐朽依然在发生。

一个真正的 DRI 拥有的四个数字

解决办法非常直接。指定一名 AI 功能 DRI，并在他们的 OKR 表上写下四个数字。如果你无法确定一个名字，那你并没有 DRI；你只是有了一张贴着乐观标签的组织架构图。

这四个数字是：

• 采用情况 (Adoption)。 AI 界面的周活跃用户数（WAU），对照 DRI 预先同意的分母进行衡量。不是父级功能的 WAU。不是 API 调用量。而是每周以同样定义方式确定的、真正从 AI 能力中获得价值的用户。
• 评估得分 (Eval score)。 来自维护的评估套件（eval suite）的综合质量指标，并带有一个明确的“低于此数值即回滚”的阈值。DRI 拥有该套件——这意味着他们负责确保它反映了用户的真实行为，也意味着当用户行为发生变化时，套件需要增加新的测试用例。
• 每活跃用户成本。 总的推理、检索和工具调用（tool-call）支出除以采用情况的分母。这是一个单位经济指标，它能告诉你你是在构建一个产品还是一个科研项目。麦肯锡的五层衡量框架将其称为“每次使用的价值捕获”——这是区分有前景的实验与持久业务的关键数字。
• 故障数 (Incident count)。 归因于 AI 功能的生产环境故障，包括由评估套件捕获的隐形质量退化，而不只是用户可见的停机。趋势比绝对水平更重要。

这四个数字并不新鲜。这种转变在于将它们放在同一个人的 OKR 表上。当同一个人对这四项指标负责时，过去存在于跨团队会议中的权衡就会汇总到一个人脑中。我们应该发布一个功能更强但更昂贵的模型吗？DRI 会权衡采用情况与每用户成本并做出决定。我们应该收紧护栏，虽然会降低评估得分但能减少故障吗？同样的人，同样的权衡，同样的决定。决策仍然由集体做出；它只是不再是每个人的工作，从而不再是没人的工作。

Worklytics 对早期 Copilot 采用情况的分析从另一个角度指出了同样的模式：那些将试点采用转化为持久生产力的组织，是那些拥有指定负责人且季度考评包含 AI 特定 KR（关键结果）的组织。没有这样做的组织，则没有获得成功。

相邻的投资：以 DRI 为客户的平台

当组织终于指定了 AI 功能 DRI 时，一个常见的失败模式是同时组建一个中心化的“AI 平台团队”——然后让平台团队试图拥有与 DRI 相同的界面。这产生了一个比解决掉的问题更糟糕的问题：现在有两个所有者，双方都有强烈的意见，但谁都没有最终决定权。

平台团队的工作是成为服务提供商，而不是共同所有者。它的客户是 DRI。它的产品是评估工具链、推理网关、提示词管理工具、成本仪表盘和故障排查手册。它不拥有功能；它拥有的是让功能负责人无需每季度从头构建观测能力就能开展工作的领域。

当平台团队开始试图在 AI 功能上强制执行自己的路线图时——例如挑选模型、规定提示词、拥有评估阈值——DRI 结构就会崩溃。Reforge 对 AI 原生产品团队的框架强调了这种拆分：基础设施和治理中心化，产品决策去中心化。平台团队的考核指标应该是来自 DRI 的内部 NPS、新 AI 功能从概念到部署生产环境所需的时间，以及平台的可靠性。而不是任何单个功能的成功。那属于功能 OKR 表上的那个名字。

来自 AI 基础设施领域的 2026 平台团队对齐分析将此视为一种反复出现的模式：当平台团队的 OKR 变成与具体功能成功脱节的“工程目标”时，他们就会失去与业务目标的对齐。解决办法是让他们的 OKR 为 DRI 服务，而不是与 DRI 平行。

影子测试 (Shadow Test)

对于不确定自己是否存在此问题的领导团队，我建议进行以下诊断。挑选一个你最引以为傲的 AI 功能，问三个问题：

1. 如果明天早上评估得分低于阈值，谁负责任？请说出一个人的名字，而不是一个团队。
2. 本季度该功能的每活跃用户成本是多少？不是总支出，也不是 API 调用量——而是单位经济效益。
3. 如果该功能因为采用率停滞不前而在两个季度内被悄悄弃用，谁的晋升评价会受损？

如果你能用同一个名字回答这三个问题，你就拥有一个 DRI。如果你能回答两个，你只有半个 DRI，该功能将在你无法回答的领域偏离轨道。如果你一个也答不上来，该功能已经在偏离轨道了；你只是还没发现证据而已。

AI 事件数据库（AI Incident Database）在 2025 年记录了 362 起 AI 事件——高于前一年的 233 起——这并非偶然。它们高度集中在没人拥有的功能上。案例研究中的模式是一致的：开发功能的团队已经离开了，负责运行它的团队没有权限去更改它，而拥有权限的团队又缺乏上下文。故障是最终迫使分配负责人的机制。到那时，代价已经很昂贵了。

真正行之有效的组织模式

能够经受时间考验的架构形式如下：

• 每个重要的 AI 业务面配备一名 AI 功能 DRI（直接负责人）。他们的 OKR 包括采用率、评估得分、每活跃用户成本以及事故数量。他们拥有对 Prompt、评估套件和模型选择的合并权限。如果功能是面向用户的，他们隶属于产品部门；如果是面向内部的，则隶属于平台部门。
• 一个以 DRI 为客户的平台团队。其 OKR 关注的是 DRI 发布和运行 AI 功能的速度和成本。它不对任何具体功能是否应该存在发表意见。
• 一个跨 DRI 进行咨询的研发/评估职能部门，其考核标准是方法论的质量，而不是任何单个功能的得分。该部门协助 DRI 构建和维护评估套件，但不拥有该套件。
• 深度集成的 FinOps，让 DRI 能够直接洞察每个用户的成本，理想情况下是近乎实时更新的同一个仪表盘，而不是三周后才送达的月度报告。

那些每个季度都在变得更好的 AI 功能，都是责任到人的。而那些产生偏差的功能，往往是只挂在组织架构图上的。如果你负责的 AI 功能正在偏离轨道，第一个要动用的杠杆不是模型升级、Prompt 改写或新的评估框架。而是在门上写下一个负责人的名字。其他一切都会随之而来。