你的 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；你只是有了一张贴着乐观标签的组织架构图。

加载中…