AI 能力棘轮：一个聪明功能如何拖垮整个产品

你的 AI 搜索刚刚上线。它速度快、支持对话，能处理过去基于关键词的搜索从未能胜任的复杂查询。功能评审一片好评，发布文章广泛传播。然而两周后，工单开始涌入——不是关于搜索的，而是关于客服组件、帮助文档和通知中心的。没有人动过这些地方。但用户突然愤怒了。

欢迎来到 AI 能力棘轮的世界。当你上线一个可以令人信服地展示智能的功能，就已经永久性地重新校准了用户对整个产品的可接受标准。棘轮咔哒一声向上拨动，永不回头。

这一模式是 AI 产品开发中讨论最少的失败模式之一。团队们庆祝各自的功能发布，却没有意识到他们正在将预期债务分摊给每一个什么都没有发布的团队。

参照点问题

这背后发生的事，行为经济学术语叫做参照点偏移。丹尼尔·卡尼曼的前景理论指出，人们评估结果时是相对于参照点的，而非基于绝对标准。软件用户也不例外。他们不是孤立地体验功能，而是对照内心中"好软件是什么感觉"的模型来体验。

当这个模型更新时，所有东西都会被重新打分。

在你的 AI 搜索上线之前，用户评价帮助文档时，参照的是他们在其他地方见过的帮助文档——也许还不错，也许令人沮丧，但都在同一条评分曲线上。你的 AI 搜索上线后，他们对"产品够不够聪明"的参照点更新了。现在，帮助文档被放在新的曲线上打分。帮助文档本身没有变差，是曲线超过了它。

哈里·赫尔森提出的适应水平理论解释了为何这是单向的：人类会适应新的刺激，并将适应后的水平视为中性。一旦用户在你的产品任何一处体验过 AI 级别的交互，这种感受就成为了基线。低于这条线的任何东西，都不会被感知为"一般"，而是"明显有问题"。

这就是棘轮。你只能把它拧紧，无法松开。撤回导致偏移的功能也无法松开它——那只会在投诉清单上再添一条"你把好东西拿走了"。

生产环境中的真实样子

棘轮效应最有文献记载的案例是 Google Photos。当 Google 引入由 Gemini 驱动的 Ask Photos 自然语言搜索时，它对某些查询效果不错，对另一些则表现欠佳。但这里最关键的发现不是 AI 搜索的准确率。而是在用户体验了 Ask Photos 之后，经典搜索"也"开始让人觉得不够好用——即便是那些经典搜索多年来一直表现尚可的查询也不例外。两个单独来看都可能获得及格评价的功能，因为 AI 体验移动了参照点，而双双被感知为"坏掉了"。

到 2026 年 3 月，Google 为用户添加了一个可见的切换按钮，允许他们回到经典搜索——这承认了 AI 功能在没有改善经典功能的情况下，污染了它的用户体验。

微软在操作系统级别进行了同样的实验。在记事本、画图、文件资源管理器和 Windows 通知中心嵌入 Copilot 按钮，制造了对整个操作系统都具有智能行为的预期。当标准 Windows 界面无法匹配这些预期时，非 AI 功能反而比加入任何 AI 之前显得更加破烂。微软最终开始从内置应用中移除 Copilot 集成，承认能力棘轮的移动速度超过了产品跟进的能力。

客服领域的这一模式尤其具有破坏性。Klarna 部署了一个 AI 助手，将问题解决时间从 11 分钟压缩到 2 分钟。速度提升确实有效。但它带来了预期转移问题：客户随后开始期望人工客服以相似的速度解决复杂问题。当 AI 在困难查询上失败并移交给人工时，这种交接看起来是灾难性的——不是因为人工解决时间延长了，而是用户正在把它跟一个之前根本不存在的 2 分钟基线相比较。

参差前沿使问题更糟

AI 的能力在不同任务类型上是不均匀的。一个能处理复杂推理的模型，仍然可能在人类觉得微不足道的任务上失败。研究人员将其称为参差前沿——能力边界在某些方向上惊人地突出，在另一些方向上又出人意料地不足。

用户不知道前沿在哪里。他们看到 AI 在某件困难的事上成功了，就得出结论说它应该能做到某件简单的事。当你上线一个擅长复杂分析的 AI 功能时，用户会假设产品整体上是有能力的。那些落在前沿之下的功能——包括从未被设计成具有智能的功能——现在相比之下显得坏掉了，即便困难推理的成功和简单任务的失败共存于同一个模型中。

这产生了一种特定的组织陷阱：你的 AI 功能的令人印象深刻，变成了那些仅仅足够好的相邻功能的负担。AI 功能看起来越聪明，它制造的差距就越大。

光环效应，反向运行

尼尔森诺曼集团对产品用户体验中光环效应的研究精确地记录了这一点。当用户对产品某一部分产生强烈印象时，他们会将其转移到相邻功能上。但当一个高性能功能创造的良好印象随后被相邻功能打破时，光环就反向运行了。那些期待产品够聪明的用户，开始有意识地记录每一个它表现不聪明的地方。

NNGroup 的一个例子：糟糕的搜索结果会让用户得出结论说整个公司都一团糟。将"糟糕的搜索结果"替换为"与我刚才在产品其他部分体验过的 AI 质量不匹配的搜索结果"，你就得到了能力棘轮在规模上产生的效果的准确描述。

重要的是，反向光环往往随时间推移而放大。被一个出色的 AI 功能激活预期的用户，不会默默接受差距——他们会去寻找差距的佐证。预期债务在复利积累。

三种应对策略及其适用场景

当团队意识到其 AI 功能已经移动了产品的预期基线时，有三种可防御的策略。

全面升级意味着将整个产品的 AI 能力对齐作为优先约束。Shopify 明确采取了这一立场：CEO Tobias Lütke 在 2025 年宣布 AI 使用在全公司范围内不可选，要求团队在申请额外人手之前证明他们已经穷尽了 AI 的方法。其逻辑在于，一旦参照点移动，只有让整个产品向前推进才能阻止差距扩大。风险在于并非所有产品表面都能在相同成熟度水平下从 AI 中获益。团队会为了 AI 而上 AI，在 AI 比其替代的基线更差的表面上制造新的能力棘轮问题。

围堵与标注意味着让能力边界清晰可见，并由用户控制。Google Photos 的切换按钮是最清晰的例子。当用户可以通过一个可见的控件在 AI 行为和经典行为之间切换时，他们就是在管理自己的参照点，而不是让产品静默地移动基线。当 AI 功能替代现有行为而非叠加于其上时，这种方式效果最好。失效场景是当切换按钮被藏起来时——如果用户找不到逃生出口，预期债务仍然积累，他们只是不知道当想回到旧行为时该去哪里。

沟通预期意味着明确告知用户（以及内部即将承接预期溢出的团队）每个表面被设计成做什么、不被设计成做什么。只有大约三分之一的组织会主动向用户沟通 AI 的局限性——大多数团队只管发布。实际影响是支持团队会继承一波关于他们没有改动过的功能的工单，来自那些带着新参照点却无人警告他们将应用于其他表面的用户。

这三种策略都无法消除棘轮，只是管理它。棘轮会咔哒作响，不管你有没有准备好。

没有人追踪的组织性债务

能力棘轮最深层的问题在于预期债务落在哪里。发布 AI 功能的团队获得发布庆祝。承接预期溢出的团队——拥有帮助文档的团队、拥有通知中心的团队、拥有引导流程的团队——收到的是支持工单和流失信号。

这不是边缘情况，而是结构性的。当一个功能在整个产品范围内移动参照点时，每个什么都没发布的团队，都在用他们原有的资源对抗一个更高的标准。

德勤关于 AI 团队结构的研究发现，跨职能团队从 AI 中获得显著效率提升的可能性高出 30%——不是因为技术在跨职能设置中运行更好，而是因为孤立的团队在系统性地无法满足跨越职能的预期。预期棘轮既是协作问题，也是产品问题。

具体症状是：AI 功能发布后，关于非 AI 功能的投诉开始激增。如果你在发布 AI 搜索两周后，帮助文档的工单量上升了，这两件事很可能相关。没有一个明确的追踪机制——一种将预期驱动的工单归因于移动基线的功能的方式——团队会花数月优化他们没有造成、也无法通过改进自己拥有的功能来解决的问题。

真正有帮助的事

有一些做法可以减少组织损伤，同时不阻止能力获益。

首先，在发布 AI 功能之前，明确绘制出用户将与之比较的功能地图。问自己：如果用户体验了这个功能然后立刻使用了[相邻功能]，他们会感知到什么差距？无论你是否计划，这个差距都会出现在你的支持队列中。

其次，在替代现有行为的 AI 功能中内置逃生出口。切换按钮不是失败——它是产品在承认自己移动了用户可能并未同意的参照点。可见的切换按钮也给了你一个信号：如果 40% 的用户切换回经典行为，你就知道 AI 功能实际上还没有跨越预期门槛，即便你的发布指标看起来不错。

第三，将预期驱动的工单作为独立类别追踪。当一张工单的本质是"为什么 X 不如 Y 好用"，这是一个与"X 坏掉了"不同的问题。前者需要产品层面的响应，后者需要工程层面的响应。将二者混为一谈意味着两者都无法得到解决。

第四，当一个功能发布会移动基线时，向每一个拥有用户可能将其与之比较的表面的团队做说明。听起来像是显而易见的沟通，但几乎从来不发生。产品发布在拥有功能的团队内部协调，而不是与那些拥有用户将在新曲线上评价的相邻功能的团队协调。

棘轮本身并非坏事

预期棘轮不是避免发布优秀 AI 功能的理由。用户对产品要求更高，从整体上看，是软件应该前进的正确方向。当团队将每个功能视为独立发布而不考虑它在整个产品中制造的预期外部性时，棘轮才成为问题。

真正有帮助的思维模型是：把你发布的每个 AI 功能，视为与用户关于整个产品质量水平的契约，而不仅仅是这个功能本身。用户会执行这份契约，不管你是否有意为之。做好规划的团队会创造出更好的产品。没有做好规划的团队会制造出支持队列、流失，以及一串搞不清楚为什么用户讨厌他们根本没有改动过的功能的士气低落的工程师。

棘轮会咔哒作响。规划好它会咔到哪里。