一个故障率高达 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 产品开发中讨论最少的失败模式之一。团队们庆祝各自的功能发布，却没有意识到他们正在将预期债务分摊给每一个什么都没有发布的团队。
这里有一个令人不安的模式：你的团队计划在下个季度推出的 AI 功能，其实早在两年前就在公司里“死”过一次了。它当时以不同的名称发布，带着不同的提示词（prompt），解决一个略有不同的问题，并在经历了六个月的增长停滞后被悄然关停。没有人记录它，没有人把这些点串联起来。本可以拯救这个周期的领先指标，一直躺在那些随功能一起被归档的数据看板里。
大多数工程组织都是为了记住成功而设计的精妙机器。发布会有复盘、博客文章和内部庆祝。但那些被砍掉的功能——尽管有精美的演示，但周活跃用户仅为 12% 的功能；当 Token 成本在超预期的工具链中叠加时导致单位经济效益倒挂的功能；那些用户先是学会信任、随后失去信心、最后完全绕开的功能——几乎没有留下任何组织记忆。而这些“死亡”中蕴含的失败模式，恰恰是你的规划流程无法预估并纳入成本的。
两家公司的两个产品团队，各自构建了同一款 AI 写作助手。相同的模型，相近的功能面貌，相当的准确率指标。一个团队在上线时迎来创纪录的激活率，另一个团队则在三个月的沉寂推广和一次尖锐的全员大会质疑后，悄悄下线了这个功能。
那家苦苦挣扎的公司在工程复盘中聚焦于显而易见的变量：延迟、准确率、交互打磨。但这些因素都无法完全解释这道鸿沟。真正的关键变量是信任——更具体地说，是这个 AI 功能能否借用足够多的既有信任，换来在证明自身价值期间犯错的权利。
信任转移（Trust Transfer），是决定一个 AI 功能能否落地生根的无形力量。而大多数正在打造 AI 产品的团队，从未为此进行过明确的设计。
2025 年，42% 的公司放弃了大部分 AI 计划，高于一年前的 17%。令人震惊的不是放弃率，而是延迟。这些项目中的大多数在最终被叫停之前，已经处于各种“快准备好了”的阶段长达 6 到 12 个月。演示是成功的。指标看起来合情合理。团队投入了大量精力。于是，这个功能在证据早已指向关停之后，依然继续徘徊，消耗着预算和信誉。
AI 领域最难的产品决策不是构建什么，而是何时停止构建一个技术上可行但实际上无用的东西。
你的 AI 功能拥有 12,000 名月活跃用户。参与度图表呈上升趋势。演示每季度依然能让利益相关者印象深刻。而你的用户正悄悄绕过它。
这是产品团队会逃避数月——有时甚至数年——的下线决策，因为每个表面指标都显示该功能运行良好。仪表盘显示了采用率。但它没显示的是，支持工程师在将每个 AI 生成的摘要转发给客户之前，都在手动纠正其中的三分之一；或者高级用户已经发现，点击三次“重新生成”就能产生可以接受的输出，并默默接受了这种工作流负担。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
