一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出，将系统视为一个不可靠的助手，并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证，而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。
这就是 70% 的恐怖谷，也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率，看着数值超过某个“足够好”的阈值，然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间，产品随着准确率的提高反而变得更差，因为用户因疏于检查而导致的错误成本，超过了他们无需验证正确答案所带来的价值。
那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队，发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品：一个主要的失效模式是隐形的产品。
2025 年 8 月，当 OpenAI 试图从 ChatGPT 中移除 GPT-4o 时，遭遇了强烈的抵制——有组织的标签、付费用户威胁取消订阅、几天内的公开反转——最终迫使公司将其恢复为默认选项，并承诺在未来任何移除之前提供“实质性通知”。替换它的模型在团队关注的每一项基准测试中都表现得更好。但这并不重要。用户已经花了几个月的时间来了解该模型的怪癖，根据其失效模式校准自己的判断，并将它的特定措辞整合进团队从未检测过的工作流中。用“更好的版本”替换它，会让这种校准归零。
这种失效模式是标准的弃用策略手册所未涵盖的。下线一个常规的 SaaS 功能——宣布、迁移、灰度发布移除、退役——假设用户契约是 API 接口。而对于 AI 功能，契约是模型的观察行为：措辞、倾向、失效模式，以及它处理歧义的特定方式。用户在这些行为之上构建了“脚手架”，而这些脚手架大多存在于他们的头脑中、笔记本电脑上以及你的团队从未触及的下游系统中。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
