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

在 AI 产品开发中，有一个常见的假设：如果一个模型能处理难题，它就一定能处理附近的简单任务。这个假设是错误的，它导致了一类生产环境下的失败，而无论你读多少基准测试报告都无法为此做好准备。

这一潜在现象的研究术语是“破碎边界”（jagged frontier）——AI 的能力边界并不是一条平滑的线，并非难题在界外、简单任务在界内。它是一个参差不齐、不可预测的形状。AI 系统可以编写生产级别的数据库查询优化器，却仍然会算错图中两条线段是否相交。它们可以通过博士级别的科学考试，却在涉及空间关系的儿童谜题上失败。它们可以综合 50 页的文档，然后对自己刚刚读过的一段文字产生充满自信的幻觉。

这种破碎性并不是会在下一个版本中修复的 bug。它反映了这些模型学习方式的某种结构性特征，并且对你应该如何设计、测试和发布 AI 驱动的功能有着直接的影响。

概念的来源

“破碎技术边界”（jagged technological frontier）一词是由来自哈佛商学院、麻省理工学院和沃顿商学院的研究人员在 2025 年发表于《组织科学》（Organization Science）的一项实地实验中提出的。该研究招募了来自波士顿咨询公司（BCG）的 758 名知识工作者，让他们完成现实的管理咨询任务——市场分析、研究综合、报告撰写。

每个人都在引用的发现是：AI 辅助的顾问完成任务的速度快了 25%，产出质量被评定为高出 40%，成功率提高了 12.5 个百分点。但对产品团队而言，重要的发现是第二个：对于那些落在 AI 能力边界之外的任务，强行使用 AI 的顾问产出正确解决方案的可能性，比完全不使用 AI 的顾问低 19 个百分点。

AI 不仅仅是没能提供帮助。它让经验丰富的专业人士的表现比他们独自工作时还要糟糕。AI 输出的自信和流利掩盖了其错误性。

“破碎”在实践中究竟意味着什么

能力边界并不以人类直觉理解的任何任务复杂度来定义。这种破碎性源于训练数据的分布、目标函数的性质以及下一标记预测（next-token prediction）的特定失败模式。

几个说明这种形状的例子：

AI 经常超过人类专家表现的领域：

• 写作、编辑和商业构思（独立评审员对 AI 生成的创业想法的评分高于商学院学生的评分）
• 情感支持和重新评估（在受控研究中表现优于 85% 的人类）
• 对格式良好的文档的阅读理解
• 常见模式的代码生成（最先进的智能体在 SWE-bench 上的表现现已超过 80%）
• 数学竞赛题目（o1-preview 在 2024 年 AIME 中比 GPT-4o 高出 43 分）

AI 以令从业者惊讶的方式失败的领域：

• 空间推理：能够生成完美几何证明的模型，在被问及真实图像中渲染出的两条线是否交叉时却会失败
• 顺序规划：日历调度、迷宫导航和约束满足问题，即使经过扩展推理，也只显示出极小的改进
• 编码和格式的边缘情况：o1 和 o3 在处理具有隐藏编码问题的 CSV 文件时会静默失败
• 对细长或悬浮物体的视觉感知：Waymo 的第五代自动驾驶系统在 1,212 辆车与细障碍物（链条、电线杆、悬浮门）发生碰撞后被召回——尽管在标准障碍物上表现出色，但其感知栈无法可靠地检测到这些物体

这种模式并非随机。拥有大量、一致训练样本的任务往往位于边界内。需要基于现实世界的推理，或在没有捷径的情况下进行仔细的顺序逻辑的任务，往往位于边界外。但这种确切的形状无法从基本原理中预测，这正是产品团队的核心问题。

产品设计陷阱

一旦你理解了破碎边界，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 产品的团队，不是那些假设能力是连贯的团队，而是那些培养了找出能力到底在哪里缺失这一学科素养的团队。