针对付费用户群追踪数据进行模型优化的团队，其实是在一个“简单分布”上给自己打分。付费用户已经形成了一套工作流。他们之所以选择这款产品，是因为产品中的某些特质证明了刷信用卡付费的合理性，这意味着当他们进入评估集（eval set）时，已经学会了哪些提示词（prompts）有效，哪些功能给力，以及哪些“坑”不该踩。而免费层用户完全不是这样。他们是匿名的、探索性的，通常带有对抗性，且往往是非英语母语者，正在用第二语言对产品进行压力测试，他们触发了评估集从未涵盖的长尾失败模式。
这种不对称性正悄无声息地吞噬着每一个免费增值（freemium）AI 产品的转化漏斗。团队针对主要从付费追踪数据中提取的精选样本对模型进行评分。而免费层的那些“古怪”追踪数据——那些没有模板、用户正真诚地试图搞清楚产品能做什么的数据——从未被标注，从未进行回归测试，也从未为下一次提示词修改提供参考。模型在付费分布上变得越来越好，但在决定免费用户是否升级的分布上却慢慢变差。
用户对 AI 功能的校准（calibration）是你交付的最昂贵的东西之一。这耗费了他们数周的注意力：学习哪些提示词有效、模型在何处可靠、何时需要复核，以及哪些内容应完全忽略。然后，一次显而易见的失败——生成的报告中出现错误数字、用户粘贴到演示文稿中的幻觉引用、或者是他们根据一个自信但错误的建议采取了行动——都可能在一次会话中让这一切化为乌有。恢复曲线是不对称的。用户的先验预期（prior）是“这是可靠的”，而这次更新并不是作为一个数据点出现的。它更像是一种背叛。
测量 DAU 的团队在数周内看不到任何异常。用户出于习惯继续打开应用，运行几次查询，不对输出结果采取行动，然后悄悄地停止使用。等到参与度指标（engagement metrics）出现波动时，导致这一结果的信任事件已经发生了两个月，团队中甚至没人记得当时发布了什么。
有一种特定的失效模式正在悄悄破坏 AI 产品的数据指标，却没有人察觉。你的仪表盘显示建议接受率为 34%、DAU 强劲、功能参与度持续增长。仪表盘没有显示的是：60% 被接受的建议随后被立即重写，参与度最高的用户正是那些点击 AI 输出、全选，然后自己重新输入的人；这个功能对下游任务完成率零可测影响。
这就是"安静放弃"模式：用户系统性地绕过 AI 功能，同时产生活跃用户的全部表面指标。他们不会禁用该功能——他们只是忽略其输出。在你的分析系统中，他们与最佳 AI 用户看起来完全相同。
大多数 AI 功能发布延迟，并不是因为它们有缺陷。它们延迟，是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升，评估指标持续向好。而"实验室表现"与"生产价值"之间的差距，却在悄悄扩大。
令人不安的事实是：最初的 500 名真实用户，在两周内发现的可操作问题，远比再花四周调优提示词要多。这不是在为发布劣质产品辩护，而是在说：你当前对"准备好了"的判断，几乎肯定是错误校准的——只有真实的使用数据才能纠正它。
在你的 AI 团队中，被低估最严重的资产是每周一小时，由三个人坐在房间里阅读你的产品实际对用户说了什么。不是综合评分。不是移动平均值。不是仪表盘。而是实际的对话记录。逐字逐句的输出。模型悄然形成的懒散措辞。你的分类体系中未涵盖的意图。用户尝试了三次，用三种不同的方式表达需求，而你的评估准则（eval rubric）却将这三次对话都评为“满意”。
将这一小时制度化的团队，能够建立起仪表盘永远无法呈现的 AI 功能心理模型。跳过这一步的团队，会根据看起来不错的指标发布六个月的产品，然后在下一次季度业务回顾（QBR）中发现，在无人察觉时，中位数体验已经漂移到了令人遗憾的境地。
一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出，将系统视为一个不可靠的助手，并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证，而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。
这就是 70% 的恐怖谷，也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率，看着数值超过某个“足够好”的阈值，然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间，产品随着准确率的提高反而变得更差，因为用户因疏于检查而导致的错误成本，超过了他们无需验证正确答案所带来的价值。
那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队，发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品：一个主要的失效模式是隐形的产品。
周二早上收到了一张支持工单：一名客户收到了关于退款期限的、言之凿凿的错误回答。工程团队调取了追踪记录，发现模型识别错了意图。产品 PM 查看仪表板，发现上个迭代发布的“极速退款”入口触发了一个 Prompt 从未针对其进行过调优的意图。平台 PM 指着评估套件（eval suite）说，测试全是绿色的。两人在技术层面都是正确的。但客户得到的回答依然是错的。
这就是“两个 PM 问题”，大多数 AI 团队都存在这个问题，只是没有给它命名。产品 PM 负责面向用户的界面——意图、成功指标、支持升级路径。平台或 ML PM 负责 Prompt、模型选择、评估套件和成本上限。两者的路线图在季度规划层面是协调的，但在每周发布层面却在背道而驰，因为两个 PM 在不同的仪表板上针对不同的指标进行优化，且有着不同的变更控制流程。
这种有趣的失效模式并不是因为两个 PM 意见不合，而是因为他们都在各自的职责范围内正确地完成了发布，却共同导致了一个无人负责的退化（regression）。
演示总是成功的。这是 AI 产品开发中最昂贵的一句话。产品经理看到模型处理好了理想路径（happy path），工程师发布了该功能的直观版本，六周后，支持队列里塞满了指标未能预见的投诉。模型本身没有退化。提示词（prompt）也没有变糟。只是该功能的形态并非模型所擅长的，而团队在工作开始前没有办法指出这一点。
相当大一部分已发布的 AI 功能都是以这种方式失败的——不是因为模型不好，而是因为任务错了。产品需要的输出是确定性的，而引擎是随机性的。用户对长尾误差的容忍度是千分之一的错误率，而模型的失败分布比这更厚。单位经济效益（unit economics）要求的延迟预算只有你在可负担范围内模型所能提供的一半。评估质量所需的地面真值（ground truth）并不存在，也无法低成本创建。这些都不是模型问题。它们是任务形态（task-shape）问题，应该在写下第一条提示词之前就被筛选出来。
在你发布 AI 写作助手六个月后，你打开分析仪表盘，发现了你想要的指标：平台上 40% 的用户生成文档现在包含 AI 创作的内容。董事会将此称为参与度提升。三周后，模型提供商涨价，单位经济效益发生逆转，有人提出了一个显而易见的问题：我们能把它关掉吗？你去寻找开关，却发现那并不是一个简单的开关。这是一次涉及产品、法务和 UX 层面的迁移，要干净利落地撤除它需要两个季度，并会耗费三个原本不知道自己是利益相关方的团队的政治资本。
这是 AI 产品生命周期中没人预料到的部分。发布手册涵盖了提示词工程、频率限制、评估框架和应对失控成本的紧急开关。但它没提到，当用户花了半年时间生成的产物仅因生成器的存在而存在时，会发生什么。现在，你档案库中的读取路径依赖于一个你想要退役的功能。“关闭开关”只是一个概念：它是配置文件里的一个标志。而实际的停用是一套关于存量兼容、版本化、内容溯源以及一场关于参与度提升究竟是价值还是仅仅是依赖的尴尬对话的协调决策。
看看你的团队最近发布的六份关于 AI 功能的实验报告。实验组都有哪些？很可能你测试的是“新提示词 vs. 旧提示词”、“GPT-5 路由 vs. GPT-4 备选”、“推理模型 vs. 快速模型”或者“有检索 vs. 无检索”。你报告了参与度、任务完成度或会话时长的提升。你称之为产品影响力。一个季度过去了。推理成本不断攀升。没人停下来问一个首席财务官 (CFO) 最终会问的问题：如果这个功能根本不存在，会发生什么？
这个问题就是那个缺失的实验组。你的实验不断衡量的提升是“更好的 AI vs. 较差的 AI”，但支撑你业务的是“AI vs. 什么都没有”——或者更尴尬的是，“AI vs. 我们从未记录下来的三行启发式代码”。这是结论完全不同的两种实验，而 2026 年大多数 AI 产品项目只运行过第一种。第二种实验才能告诉你，该功能是否配得上它的推理账单。
大多数团队决定开发一个 AI 功能，然后询问用户：“你想要这个吗？”用户说想。功能发布了。三个月后，周活跃用户（WAU）停留在 12% 且不再增长。复盘时将其归咎于实现或采用，但真正的失败在写下第一行代码之前就发生了——那就是在那些看起来很周全但方法论上存在缺陷的用户调研阶段。
核心问题在于：用户无法准确预测他们对从未体验过的能力的偏好。这并非小瑕疵。一项关于 AI 写作辅助的研究发现，基于用户表达的偏好设计的系统仅达到了 57.7% 的准确率——实际上表现甚至不如那些完全忽略用户表达偏好的原始基准方案。你可以进行长达数周的用户调研冲刺，收集广泛的定性反馈，但最终做出的产品却没人使用——这并非尽管做了调研，而是在一定程度上正是因为调研的开展方式所致。
你的 AI 搜索刚刚上线。它速度快、支持对话，能处理过去基于关键词的搜索从未能胜任的复杂查询。功能评审一片好评，发布文章广泛传播。然而两周后，工单开始涌入——不是关于搜索的，而是关于客服组件、帮助文档和通知中心的。没有人动过这些地方。但用户突然愤怒了。
欢迎来到 AI 能力棘轮的世界。当你上线一个可以令人信服地展示智能的功能，就已经永久性地重新校准了用户对整个产品的可接受标准。棘轮咔哒一声向上拨动，永不回头。
这一模式是 AI 产品开发中讨论最少的失败模式之一。团队们庆祝各自的功能发布，却没有意识到他们正在将预期债务分摊给每一个什么都没有发布的团队。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
