在 AI 功能感觉准备好之前就发布它

大多数 AI 功能发布延迟，并不是因为它们有缺陷。它们延迟，是因为团队仍在针对一套不能反映真实用户行为的测试集进行优化。每周基准分数都在提升，评估指标持续向好。而"实验室表现"与"生产价值"之间的差距，却在悄悄扩大。

令人不安的事实是：最初的 500 名真实用户，在两周内发现的可操作问题，远比再花四周调优提示词要多。这不是在为发布劣质产品辩护，而是在说：你当前对"准备好了"的判断，几乎肯定是错误校准的——只有真实的使用数据才能纠正它。

基准测试陷阱

当一个团队说 AI 功能"还没准备好"时，通常意味着两种情况之一：它在他们构建的评估案例中失败，或者在某个基准上的得分低于阈值。这两者都是合理的代理指标，但都不能可靠地预测生产成功。

基准性能与真实世界性能之间的差距是结构性的，而非偶然的。基准使用干净、标准化的输入。生产流量是杂乱的、富含上下文的，以及评估数据集无法捕捉的对抗性方式呈现。一个在分类评估中得分 87% 的模型，仍然可能让那些措辞与评估作者不同的用户感到困惑。一个覆盖你前十个用例的评估套件，仍然无法覆盖第十一个用例——而你不知道那是什么，直到用户告诉你。

这种结构性差距在部署中始终存在。仅使用已发布基准分数来选择模型的团队，对真实世界结果的满意度低于使用自定义评估的团队。但自定义评估仍然无法反映生产现实，因为数据是由了解系统的人选择的——而不是最终使用它的所有人。

更深层的陷阱在于基准是可以被"游戏化"的。不是通过欺诈，而是通过正常的优化压力。当一个团队针对同一套评估套件进行四周的提示迭代时，他们实际上就是在对那套评估套件过拟合。提示在通过测试方面越来越好，至于是否在服务用户方面越来越好，这是一个只有用户才能回答的独立问题。

500 个真实用户能告诉你什么

在生产中出现的失败类型，与你在实验室中预期的失败类型截然不同。

在实验室中，你测试你想到的输入。在生产中，用户构建你从未想过的输入。他们以意想不到的顺序组合功能，误读界面提示，并以 UI 设计无法处理的方向探索系统。他们在环境化的情境中使用功能——分心时、在手机上、用你未测试过的语言——这些都是你的评估场景所假设不存在的。

真实使用数据揭示的问题：

• 分布偏移：用户输入的实际分布很少与你测试的分布相匹配。用户倾向于发送比评估作者撰写的更简短、更模糊的请求。
• 失败模式聚类：真实失败通常围绕你未预料到的特定措辞或任务类型聚类。这些聚类在几天内就会在生产日志中变得可见。
• 延迟敏感性：在调查中告诉你延迟"不太重要"的用户，在留存数据中的流失率却讲述着截然不同的故事。
• 意外的高价值用途：真实用户会发现你的团队从未考虑过的功能应用。这些发现模式在功能上线之前是不可见的。

这些信息在发布之前都无法获得。再花四周进行提示优化的代价——在了解这些之前——是真实存在的：它延迟了本可以告诉你该把那四周精力集中在哪里的信号。

为什么工程团队会错误校准"准备好了"

有一个合理的解释，说明为什么团队比应该的时间更长地持有 AI 功能。失败模式感觉不同。

当传统软件功能有 bug 时，bug 通常是确定性的。你可以重现它、修复它、验证修复结果。当 AI 功能失败时，失败是概率性的和情境性的。你无法枚举它会失败的所有方式。这种开放式风险感觉不同于封闭的 bug 列表，它触发了不同的心理反应："我们还没有测试足够多的场景。"

但对于任何 AI 功能，"我们还没有测试足够多的场景"永远是真的。你永远无法达到那种让发布感觉安全的详尽覆盖——按传统软件标准。问题不是是否还有未知的失败模式存在，而是你是否已经耗尽了实验室环境中可获得的信息——以及生产中可获得的信息是否能更好地指导下一轮改进。

还有第二个因素：职业认同感。工程师被训练为发布能正确工作的东西。发布一个会在用户面前明显失败的功能，感觉像是违背了职业操守。这种直觉总体上是健康的，但对于 AI 系统却会产生误导，因为 AI 的"正确"是输入分布上的统计属性，而不是单个输出的二元属性。无论何时发布，功能都会在某些输入上失败。相关问题是：那个比例是否足够低，能产生比失败案例损失更多的信任——以及生产信号是否有助于你更快地降低它。

加载中…