参差不齐的边界：为什么 AI 在简单任务上会失败，以及这对你的产品意味着什么

连贯性假设陷阱。 看到系统能处理难题的用户会断定它也能处理邻近的简单任务。在人类专业知识的世界里，这种行为是理性的，因为能力是相对平滑的。但这对于 AI 来说是错误的。一个能产出优秀长篇分析的写作助手，不一定能对同一段文本生成可靠的简短摘要。一个通过复杂算法挑战的代码智能体，在简单的数组遍历中仍然会引入细微的差一错误（off-by-one errors）。学会信任系统处理难题输出的用户会不恰当地延伸这种信任，并会在很晚之后——有时是非常晚之后——才发现错误。

过度依赖连锁反应。 在哈佛的研究中，过度依赖带来的伤害并不仅仅是人们在 AI 表现不佳的任务上使用了它。而是 AI 自信且流利的输出抑制了人类的独立判断。一位经验丰富的顾问，如果独自工作本可以发现错误，却因为 AI 的回答听起来很权威而漏掉了它。这是一个 UX 设计问题，不仅仅是模型问题。当你的界面将 AI 输出展示为完成的工作而非需要评判的草稿时，你就是在为过度依赖而设计。

利用不足的阴影。 导致在某些领域过度信任的同一破碎性，也会导致在其他领域信任不足。目睹过 AI 在他们预期能处理的任务上失败的团队，会避免在表面相似的任务上使用 AI——包括那些 AI 实际上会表现得比团队更好的任务。当用户无法区分边界究竟在哪里时，能力悬崖教给了他们错误的教训。

麦当劳问题。 麦当劳在 100 多家得来速餐厅部署了 AI 语音点餐。系统在受控条件下表现尚可。在生产环境中，背景噪音、地区口音和边缘点餐情况将其推向了边界之外。它下达了荒谬的错误订单——增加了数百美元的错误项目，进行了请求中并不存在的替换——这些失败在网上疯传。该计划于 2024 年 7 月撤回。错误不在于部署 AI 语音点餐，而在于在规模化发布之前，不知道该特定环境的边界在哪里。

如何在发布前绘制能力边界图​

大多数团队在发布前不绘制能力边界图，因为他们没有系统的绘制方法。这里有一个实用的框架。

任务拆解是起点。 将功能的工作流拆解为离散的子任务。文档摘要功能可能拆解为：提取核心观点、验证事实一致性、在不扭曲原意的情况下压缩、为目标受众调整格式。每个子任务相对于边界的位置都不同。不要只评估端到端的输出——这会将边界内的任务与边界外的任务混为一谈，直到用户发现失败，你才会知道哪个是哪个。

建立能力清单，而不是演示 Demo。 Demo 总是展示最好的情况。能力清单是系统的：针对每个子任务，建立至少 20 个真实的测试用例，这些用例应取自混乱的现实世界示例，而不是经过清理的展示用例。运行模型。衡量准确率，而不是感官印象。追踪哪些子任务类型会产生“自信且错误”的输出——这些就是你的边界交叉点。

专门探测那些不明显的失败模式。 空间和视觉推理、顺序多步规划、格式和编码边缘案例，以及涉及真实日期的跨时推理任务，即使模型在附近任务中表现良好，也极有可能落在边界之外。即使你的主要用例似乎不涉及这些，也要为它们建立显式测试。它们通常作为副作用而非主要任务出现。

在现实且混乱的输入上进行测试。 这与在困难输入上测试不同。越过边界通常不是因为任务难，而是因为输入略微异常——不同的文件编码、不常用的姓名格式、多句提问而非单句提问。你的评估集需要包含那些人类可以轻松处理、但在训练分布中属于边缘案例的输入。

将边界视为动态的。 模型会更新。边界会发生偏移——通常随着瓶颈能力的提升而收缩，但偶尔也会以某种方式偏移，导致之前在边界内的任务移动到边界外。你上个季度绘制的边界不一定是今天的边界。

围绕你发现的边界进行设计​

一旦你了解了功能集中的边界线，你有两种结构性选择：绕过能力悬崖进行设计，或在悬崖交叉点设计验证机制。

绕过意味着路由。 可靠性落在边界之外的任务不应单独交给 AI。研究表明，“半人马模式”——一种人机协作模型，人类和 AI 各自负责擅长的任务，并有明确的交接界限——的表现优于完全自动化和完全不自动化。这需要了解边界，在产品设计中显式地标记它，并让人类在那个点轻松接手，而无需重新构建上下文。

设计验证意味着增加摩擦。 在悬崖交叉点——即模型大多数时候有能力处理但在失败时会静默报错的任务——产品需要将输出呈现给人工审核，而不是作为最终结果。核心设计原则是降低验证的认知负荷：人类应该能够快速发现错误，而不是从头开始验证。差异对比视图、置信度指标、溯源引用以及强制确认流都具有这一功能。目标不是让人类验证所有内容，而是让验证在边界参差不齐的特定点变得快速可靠。

不要向用户隐藏边界。 产品管理中有一种强烈的直觉，即尽量减少 AI 功能中可见的局限性。这种直觉会导致过度依赖。如果用户理解系统擅长综合但提取精确数字不可靠，他们就会恰当地使用它。如果用户相信系统能力是均一的，直到产生下游后果，他们才会发现数字提取错误。对边界的透明化并不是产品叙事的弱点，它是保持用户信任与现实对齐的机制。

边界在收缩，但不会消失​

Ethan Mollick 曾协助提出了“参差不齐的边界”这一概念，他观察到边界正在收缩——十二个月前清楚说明 AI 缺陷的任务如今大部分已得到解决。o3 和 Gemini 2.5 处理的任务，在最初的边界研究发表时还需要谨慎的人工判断。

这产生了一种自然的诱惑，即把参差不齐的边界视为一个临时问题。事实并非如此。边界是结构性的。随着模型能力足以处理当前定义的边界边缘任务，新的能力会发展，新的粗糙边缘也会出现。具体形状会改变，但参差不齐性依然存在。

对工程师而言，绘制边界不是发布前的一次性活动。这是一个持续的运营过程，就像你持续监控模型输出质量或延迟一样。你今天发布时所针对的边界，将不同于下一次重大模型更新后你的功能运行所在的边界。建立测量基础设施，以便在其移动时察觉。

安全交付 AI 产品的团队，不是那些假设能力是连贯的团队，而是那些培养了找出能力到底在哪里缺失这一学科素养的团队。