当两个 AI 功能争夺同一次点击

用户落到一个搜索结果页面。A 团队的智能摘要在顶部横幅里弹出:"这是要点 —— 跳过列表吧。"B 团队的内嵌助手在侧边脉冲跳动:"留在这里,我陪你继续阅读。"两个提示争夺同一段 800 毫秒的注意力,用户被惹烦了,关掉了标签页。第二天早上,A 团队报告摘要点击率提升 6%;B 团队报告助手打开率提升 4%;会议室里没有人是错的,而产品却比一个季度前更糟。

这就是那种"独立功能团队 + 单一功能 A/B 测试"的标准打法看不见的失败模式。每个团队都针对自己的指标做了局部最优。用户 —— 只有一份注意力预算、一份心智模型、一次可以给出的点击 —— 替两个团队都不愿做的整合,买了单。

这个问题的形状并不新。产品蚕食(cannibalization)作为一个组合(portfolio)层面的问题,在零售和定价领域已经被讨论了几十年。新鲜之处在于,AI 功能之间互相蚕食的货币比营收更微妙。它们蚕食的是注意力、意图,以及用户对你产品里任何一个 AI 触面继续信任的意愿。而那些本该把冲突标红的指标,在团队层面根本不存在 —— 因为它们不可能存在于团队层面。

为什么本地 A/B 测试发现不了

A/B 测试本质上是一个处理组和对照组之间的比较,前提是"其他条件保持一致"。这句"其他条件保持一致"承担着大量工作,而当两个 AI 功能上线到互相重叠的触面上时,这句话悄悄就崩了。

A 团队对它的摘要横幅做测试时,对照组没有摘要横幅 —— 但仍然带着 B 团队的内嵌助手。B 团队对它的助手做测试时,对照组没有助手 —— 但仍然带着 A 团队的摘要横幅。两个团队都是在一个本身已经包含了对方功能的背景上衡量自己的功能。每一个测试回答的是一个狭窄的问题:"我的功能在当前产品之上有没有增值?"没有一个测试回答更宏观的问题:"当前产品,和我们其中一个不发布的产品相比,哪个更好?"

存在一种相当现实的可能性 —— 而且实际中很常见 —— 两个功能各自的 A/B 测试都通过了,但组合体验比任何单一功能存在时都更差。这背后的数学并不奇异。如果功能 A 在已经包含功能 B 的基线上带来 +6% 的参与度,而功能 B 在已经包含功能 A 的基线上带来 +4% 的参与度,你不能把这两个数相加。一旦你把另一个功能引入的用户摩擦计算在内,你甚至可能保不住其中任何一个。

那个能发现这一问题的平台级 A/B 测试 —— 四臂测试(都没有、只有 A、只有 B、两个都有)—— 很少有人真的做,因为它需要两个本身没有合作动机的团队互相协调。他们的目标、迭代周期、OKR,乃至 VP,通常都是不同的。

每个团队的胜利,是另一个团队的失败

这个问题更难的版本在于:两个团队不仅仅是缺乏协调 —— 而是在结构上被激励去互相唱反调。他们的指标就是镜像。

设想智能摘要团队。他们的论点是:用户不应该去读结果列表 —— 摘要抓住了要义,用户接受摘要,然后离开。对他们而言,合理的成功指标类似"摘要接受率"或"答到时长",而这两个指标都会在用户减少滑动时变好。

再来看内嵌助手团队。他们的论点是:用户应该在当前页面深度参与 —— 助手做评论、提问题、补充相关上下文,把用户留在阅读里。对他们而言,合理的成功指标类似"会话深度"或"页面停留时长",这两个指标都会在用户增加参与时变好。

用户只会做一件事。要么他接受摘要然后离开,要么他与助手互动并留下。无论哪种结果,一个团队的指标上升,另一个团队的指标下降。两个团队其实是在伪装成并行功能工作的零和竞争。而因为没有一个团队的仪表盘上能看到对方的指标,他们各自只看到了自己那一份移动 —— 这意味着两个团队可以同时相信自己的功能正在成功,即便实际上其中一个正在从另一个手里夺走用户。

这就是当局部最优与对方的局部最优在结构上不兼容时,局部优化呈现出来的样子。这不是任何一个团队流程上的 bug。这是缺了一层组织。

缺失的论坛

大多数工程组织都有一个解决数据层冲突的论坛("谁拥有客户表?"),有一个解决基础设施层冲突的论坛("谁为这个算力买单?"),也有一个解决品牌层冲突的论坛("这个 UI 符合我们的品牌声音吗?")。几乎没有一个组织有一个解决注意力层冲突的论坛 —— 那一层是两个产品触面争夺用户专注力同一瞬间的地方。

最接近的对应是设计评审,但设计评审一般是在孤立中评估一个触面的美学和人机工程质量。它们没有被设置来追问:"在用户花在这个页面上的 800 毫秒里,哪一个功能赢得了优先开火的权利?"它们没有被设置来下达裁决,比如"摘要横幅动画展开时,内嵌助手不能跳动",或者"页面加载的前 1.5 秒内,任何 AI 触面都不得打断"。

需要的论坛更接近机场之于空中交通管制。每一架飞机本身都没问题,每一位飞行员本身都很称职。管制员的工作是给他们排序 —— 决定谁着陆、谁起飞、谁盘旋,因为跑道是共享资源,而飞机彼此之间不会谈判。产品中的 AI 功能正是这样:每一个单独看都是称职的,而用户的注意力就是那条跑道。

实际操作中,这种论坛像是一个小型的、定期召开的会议 —— 有时叫做 AI 组合评审、体验委员会,或者交互预算评审 —— 由一个对多个 AI 功能团队拥有权威的高级产品负责人主持。议程是那些两个或以上 AI 功能可能同时触发的时刻。产出是一项排序决定、一条让位规则,或者在难题上,一道指令:某个功能必须搬到完全不同的触面上去。

注意力预算核算,是一个组合层的问题

一旦有了论坛,问题就变成你在论坛里量什么。团队级仪表盘是不够的 —— 它们正是把你带进冲突的根源。组合需要自己的一套度量。

一个有用的起点,是按财务团队思考预算的方式来思考注意力。每一次用户会话都有有限的"可打扰时刻" —— 页面加载、结果渲染、搜索提交、闲置停顿、点击返回。慷慨地估算,每次会话或许有十几个这样的时刻。每一个 AI 功能都是这份预算上的一笔支出。组合层面的问题是:"这次会话的十几个可打扰时刻里,我们花掉了多少、花在了哪些功能上、回报是什么?"

在组合层面,三个指标值得跟踪:

• 跨功能冲突率:两个或以上 AI 触面在同一 2 秒窗口内触发的频率。这正是那种 —— 当它上升时,两个团队的仪表盘看起来更健康,而用户体验在变差 —— 的指标。
• 每时刻净价值:在某一时刻所有可能触发的功能上,用户的下游行为是什么 —— 他们参与了、离开了,还是回来了?这是按时刻量的,不是按功能量的,这正是要点。
• 让位率:某个功能因为另一个功能优先而选择不触发的频率。一个健康的组合让位率不为零。让位率为零意味着没有任何功能在向其他功能让路,这意味着跑道被当成了无限的 —— 而它并不是。

这些指标只在组合层才看得见。任何团队级仪表盘都不会有它们,因为没有任何一个团队聚合地拥有"用户的会话"。必须有人显式地拥有这个视角,否则它就不存在。

领导层的那一步

领导层的领悟 —— 如果它到来 —— 是这样的:当初建立这些 AI 功能用的团队级成功指标,如今正是阻止 AI 组合自洽的东西。每一个团队都在做经理要求他们做的事。每一个功能都通过了上线标准。而合起来的产品却支离破碎、嘈杂,对那个只想做一件事的用户来说,略带敌意。

让这件事浮出水面 —— 在用户先发现之前 —— 的那一步,是把"哪个功能拥有哪个时刻"从一个偶然的协调问题,提升为一项刻意的评审。这意味着:一个论坛、一套组合层的指标,以及一个有权威告诉某个团队"你的 A/B 测试通过了,我们仍然不会把它发布到那个触面上,因为那个触面已经有归属"的高级产品负责人。

这种对话并不舒适。它为了全局的胜利覆盖一个局部的胜利。它告诉一个做了好工作的团队:你们的工作不能以你们造出的形式发布。它也是 2026 年,极少数能区分"AI 功能复合成一个连贯产品"的公司与"AI 功能复合成一团连贯混乱"的公司的组织实践之一。各团队继续在出货;差别在于有没有人在为跑道排序。