伪效率陷阱：为什么 AI 有时比人工更不靠谱

一家拥有数万家门店的全球咖啡巨头，用 AI 管库存，结果关停了系统；一家估值数百亿美元的金融科技公司，用 AI 替掉 700 名客服，结果半年后又把人招了回来；一项覆盖数千名知识工作者的调研显示，用上 AI 工具之后，67% 的人工作时间反而变长了。

这些不是段子，而是过去两年里真实发生的事。在它们背后，藏着一个被系统性低估的问题。

一、从星巴克说起：当 AI 不可靠时会发生什么

2024 年，星巴克开始在全美门店部署 AI 库存盘点工具。这套系统基于计算机视觉和机器学习，目标很明确：让门店员工告别手持扫描枪的低效日子，用摄像头自动识别货架上的杯子和咖啡豆，实时更新库存数据，减少缺货和浪费。

听起来很美。CEO 在公开场合多次为这套系统背书，称之为"数字化转型的重要里程碑"。CTO 也在内部通讯中力推，将这套工具定位为门店运营标准化的核心基础设施。

根据 Reuters 的独家报道、CEO 和 CTO 的公开原话、以及 NomadGo（技术供应商）的新闻稿，这套系统的技术路线并不复杂：在门店仓库和货架区域部署摄像头，通过图像识别模型检测商品种类和数量，数据实时同步到库存管理系统。在试点阶段，系统表现尚可——毕竟试点门店通常选择条件较好的旗舰店，环境可控，SKU 相对规整。

但大规模铺开后，问题开始涌现。

一线员工的反馈揭示了多个具体的故障场景。高峰时段的模糊识别是最常见的问题——当货架上的商品被频繁取放、摄像头视野被遮挡时，系统会给出明显偏离实际的数字。更隐蔽的问题是累积偏差：单次盘点误差可能只有几个百分点，但如果系统每天都在"自动"运行而没人核查，误差会像滚雪球一样积累。到月底对账时，才发现库存数据和实际库存之间已经出现了无法解释的缺口。

还有一类更微妙但更具破坏性的问题：系统本身在"看起来正常运行"的情况下，悄悄改变了员工的行为模式。过去，员工手动盘点时自然会注意到异常——某个 SKU 的数量"感觉不对"会触发警觉。但引入 AI 后，员工逐渐放弃了对数字的独立判断，转为"系统说什么就信什么"。这种认知卸载在系统正常时是效率提升，在系统出错时就成了灾难放大器。

2025 年下半年，负面反馈持续积累。2026 年初，星巴克悄然关停了这套工具。

关停的具体原因涉及内部商业决策，公开报道中的信息并不完整。但从已有信息可以提取出一条清晰的逻辑链：当 AI 输出的可靠性不足以支撑自动化决策时，人不得不介入核查——而这套"核查-修正"的隐性成本，在组织层面往往远超 AI 在生成阶段节省的时间。

这不是一个"AI 还不够成熟"的老生常谈。星巴克的案例指向了一个更深层、更普遍的结构性问题。我把它叫做验证税（Verification Tax）。

二、效率崇拜的盲区

过去两年，AI 行业的主旋律是"更快、更便宜、更强"。每一家 AI 公司的融资 PPT 里，都有一张对比图：左边是传统流程的漫长耗时，右边是 AI 加速后的闪电速度。

这张图在多数情况下是对的——在理想条件下，AI 确实快得多。GPT-4 可以在几秒内生成一份报告的初稿，Claude 可以在一次对话中审阅完几十页的合同条款。如果只测量"从输入到 AI 输出"的时间，效率提升是显而易见的。

但图上漏画了一样东西：验证环节。

真实的 AI 工作流不是"输入 → AI 输出 → 完成"，而是"输入 → AI 输出 → 验证输出是否正确 → 如果不正确则修正 → 可能还要再验证一轮 → 完成"。而这个验证环节的时间成本，很少被计入效率计算的分子。

Klarna 的案例就是教科书级的演示。2024 年，这家瑞典金融科技公司高调宣布用 AI 聊天机器人替代了 700 名客服人员，号称处理了三分之二的客户咨询，将客服响应时间从分钟级降到秒级。CEO 在多个场合将其描述为 AI 驱动运营效率的标杆案例。

半年后，剧情逆转。Klarna 开始重新招聘人类客服。根据 Digital Applied 和 Customer Experience Dive 的报道，逆转的原因并不复杂：AI 在标准化问答上表现不错——“我的账单什么时候到期"“怎么修改地址"这类问题，机器人确实能快速准确地回答。但一旦遇到稍复杂的交互场景（退款纠纷、账户异常、跨部门协调），AI 就频繁出错，要么给出不完整的答案，要么在需要判断力的节点做出错误的流程选择。

结果是，本该被消灭的客服工作量变成了"先跟 AI 聊、聊不通再转人工"的双重负担。客户体验没有提升，反而多了一层摩擦。对于最终需要人工介入的复杂案例，总耗时从"直接找人工"变成了"先跟 AI 绕一圈再找人工”，反而更长。

Klarna 的教训不是"AI 不能做客服”，而是在流程设计时，把"验证 AI 输出"的环节完全交给了终端用户——让客户自己去判断"AI 给的答案对不对"。这对标准化问题可以工作，但在需要判断力的场景中，终端用户恰恰是最不具备验证能力的一方。

更广泛的图景：生产力悖论

Klarna 不是孤例。2025-2026 年间，多项独立调研指向同一个现象：引入 AI 工具后，个人层面的效率确实有所提升，但组织层面的总工作时间并未减少，甚至增加了。

Fortune 在 2026 年 3 月的报道中引用了一组令人意外的数据：67% 的受访劳动者报告称，使用 AI 工具后工作时间反而变长了。MIT Sloan 在 2025 年 7 月发表的研究进一步拆解了这一现象——虽然 AI 在特定任务上平均节省了约 8% 的时间，但这些节省并没有转化为工作时间的减少，而是被以下三个机制吞噬：

棘轮效应：AI 提升了个人的单位产出，管理层随即调高了产出期望。“你既然有了 AI，那这份报告以前要两天，现在半天能搞定吧？“最终工作量不降反升。

范围蔓延：AI 降低了某些任务的门槛，催生了大量原本不会存在的衍生任务。过去"不值得做"的数据分析、报告生成、文案润色，现在因为"AI 可以快速完成"而变成了必须做的事。

验证开销：这是最容易被忽视、也是成本最高的一项。审核 AI 输出的时间和认知资源消耗，往往接近甚至超过从零开始做这件事的成本。HBR 在 2026 年 2 月的文章中明确指出了这一点，Workday 与 PwC 的联合调研也给出了量化佐证：在需要高准确率的业务场景中，AI 节省的初稿时间，几乎全部被延长的人工审核所吞噬。

这三个机制共同构成了"伪效率陷阱"的核心：你在局部看到的效率提升，在全局被系统性抵消了。

三、确定性幻觉与成本转移

如果说星巴克和 Klarna 的案例展示了"验证税"在实践中长什么样，那么我们需要更深入地理解一个问题：为什么 AI 的输出特别难以验证？

答案指向一个我称为"确定性幻觉"的现象。

数据库领域的图灵奖得主 Michael Stonebraker 在 2025 年的一次访谈中，提到了一个耐人寻味的测试：让大模型直接写 SQL 查询语句，在 MIT 的数据仓库实测中，据他称准确率为 0%——不是 90%，不是 70%，是零。

需要说明的是，这个"0%“是 Stonebraker 在特定测试条件下报告的结果，不代表所有 SQL 生成场景。当前的大模型在简单查询上已有不错的表现。但 Stonebraker 的观点值得认真对待，因为他的身份——图灵奖得主、PostgreSQL 联合创始人、数据库领域五十年的研究者——意味着他对"什么是正确的 SQL"有极高的判断标准。

Stonebraker 在 DBOS 2025 年度回顾的演讲中，以及在 The Peterman Pod 的采访中，反复强调一个核心观点：大模型的本质是一个只读的知识检索系统，它缺乏对业务逻辑和数据语义的确定性理解。当你让 AI 生成一条 SQL 语句去查财务报表时，它可能在语法上完全正确——甚至能通过格式检查——但语义上完全错误。比如它可能把"季度营收增长率"理解成了"季度营收金额”，或者把"去重后的活跃用户数"统计成了不去重的总登录次数。

这种错误比语法错误危险得多，因为它看起来是对的。SQL 跑得通，返回了一个数字，这个数字落在了"合理"的范围内——但它的含义和你想要的东西完全不同。如果你没有逐字检查 SQL 的逻辑，你根本不会发现这个问题。

这就是确定性幻觉的本质：AI 的输出往往在表面上流畅、自信、格式工整，让人产生一种"这应该是正确的"的直觉。这种直觉在高压力、高节奏的工作环境中尤其危险，因为人们倾向于把"看起来专业"等同于"值得信任”。

验证税的本质：从创作型劳动到审核型劳动

当我们讨论 AI 效率时，通常只计算了"生成"的效率，却忽略了"验证"的成本。这不是一个微不足道的遗漏，而是一个系统性的认知偏差。

在传统的人工流程中，验证是内嵌在创作过程中的。写代码的人在写的同时就在做逻辑检查，写报告的人边写边校对。创作和验证是交织的、并行的心智活动，边际成本很低。

但在 AI 流程中，生成和验证被拆成了两个独立步骤。AI 负责"快但不确定"的生成，人负责"慢但靠谱"的验证。而人的验证速度是有上限的——阅读速度、理解深度、注意力持续时间都是硬约束。

换句话说，AI 不是消除了工作，而是把创作型劳动转化成了审核型劳动。

问题在于，审核别人的输出（尤其是看起来很专业的输出）并不比自己从头做更轻松。认知心理学的研究早就发现，发现别人错误比避免自己犯错的认知负荷更高——因为你需要先理解对方的思路，再在自己的知识体系中定位可能的错误，最后确认这确实是错误还是只是思路不同。这就是为什么"审代码"往往比"写代码"更累。

当 AI 把海量的生成工作倾泻到人类审核者面前时，它不仅没有减少总工作量，反而制造了一种新的、更容易被低估的工作形态。

四、人机协同验证闭环：一个建设性的思路

认识到验证税的存在，并不是要否定 AI 的价值。AI 在代码补全、文档初稿生成、大规模数据分类、翻译辅助等领域的效率提升是真实且可量化的。问题不在于"要不要用 AI”，而在于"怎么用"。

核心思路是：与其让人去验证 AI 的每一个输出，不如设计一个分层的验证体系，让机器先完成尽可能多的确定性检查，人只介入真正需要判断力的环节。

我把它称为"人机协同验证闭环"，分为三层。

第一层：格式验证——让机器检查机器

这一层解决的是"输出是否符合基本规范"的问题。具体来说：

• AI 生成的数据是否是合法的数字格式？字符串里有没有混入不可见字符？
• 必填字段是否都有值？枚举值是否在允许范围内？
• 日期、编码是否符合业务规则？金额字段是否有异常的负数？

这些检查的特点是：规则明确、逻辑确定、完全可以用程序化手段自动完成，不需要人的判断力。

在技术实现层面，Python 生态中的 Pydantic AI 框架提供了一个很好的参考。Pydantic AI 基于 Python 的类型注解系统（Type Hints），在 AI 输出之后自动执行结构化验证——如果输出不符合预定义的 schema（比如一个字段应该是整数但 AI 返回了字符串），就自动触发重试，而不是把错误传递到下游。这种"生成-验证-重试"的循环完全在机器层面完成，对使用者透明。

举一个具体的例子：假设你让 AI 从一篇文章中提取关键信息，返回一个包含"标题"“日期"“作者"“摘要"四个字段的结构化对象。如果 AI 返回的日期格式是"2024年三月"而不是标准的 ISO 8601 格式，Pydantic AI 会自动拦截并要求 AI 重新生成，直到格式正确为止。人不应该为这种低级格式问题浪费时间。

第二层：规则验证——业务逻辑的防火墙

第一层保证了"输出格式正确”，但格式正确不代表内容合理。第二层解决的是"输出是否符合业务逻辑"的问题：

• AI 生成的 SQL 是否只查询了授权范围内的表？有没有试图访问敏感数据？
• AI 生成的合同条款是否与公司政策冲突？有没有自相矛盾的条款？
• AI 的推荐结果是否违反了硬性约束（如预算上限、合规底线、物理定律）？

这一层需要将业务规则显式编码为可执行的校验逻辑。它比第一层更复杂，因为业务规则本身可能有模糊地带，但核心思路是一样的：把可编码的确定性检查交给机器。

Pydantic AI 的 Guardrails（护栏）机制和 Deferred Tools（延迟工具）提供了一个技术参考。当 AI 尝试执行高风险操作时（比如修改数据库记录、发送对外邮件、执行金融交易），系统自动拦截并触发额外的验证步骤，而不是直接放行。requires_approval=True 这个标志位的本质，就是在流程中插入一个"等等，这件事需要再想想"的强制检查点。

在实际业务中，这一层的实现不一定需要特定的框架。关键在于建立一种工程文化：每一条业务硬约束都应该有对应的自动化校验，而不是依赖人在审核时"记得"去检查。 人的记忆是不可靠的，尤其是在疲劳、赶工、或者面对看起来"差不多"的 AI 输出时。

第三层：人工闸门——人介入的关键节点

前两层可以挡掉大部分问题，但总有一些场景需要人类独有的能力——经验、直觉、对上下文的理解、对"合理"与"不合理"的判断。第三层解决的就是这些：

• AI 生成的客户回复在技术上正确，但在当前的情绪语境下是否得体？
• AI 的投资建议在历史数据上合理，但是否符合当下的市场情绪和宏观环境？
• AI 标注的数据异常在统计上显著，但是否值得进一步调查，还是只是噪声？

关键的设计原则是：人不是被拉来给 AI 擦屁股的，而是在流程设计之初就被嵌入关键决策节点。 这意味着人工闸门不是"出了问题才找人"的应急机制，而是"在关键路口预设人"的流程设计。

Pydantic AI 的 HITL（Human-in-the-Loop）机制中，requires_approval=True 的 Deferred Tool 设计体现了这一思路——AI 可以准备方案、分析数据、提供建议，但执行必须经过人的确认。这种"AI 提案、人类决策"的模式，比"AI 全自动、人出问题再介入"的模式要健康得多。

漏斗而非瀑布

这三层验证不是串联的瀑布流——一层通过了才到下一层——而是一个漏斗：

• 格式层自动挡掉大部分低级错误（可能占总错误的 60-80%）。
• 规则层过滤掉业务违规和逻辑矛盾（可能再挡掉 10-20%）。
• 最后只有真正需要人类判断的少数案例（可能只有 5-15%）才会到达人工闸门。

这样的设计，既避免了"全靠人审"的低效（把人的时间浪费在机器能检查的格式问题上），也规避了"完全信任 AI"的风险（在关键节点保留了人的判断力）。

五、一些需要诚实承认的边界

在提出上述方案的同时，有几件事需要坦诚说明。

第一，量化数据的局限。 本文引用的案例（星巴克、Klarna、Stonebraker 的 SQL 测试）均有明确的公开信息来源，但具体的效率损失数字在不同来源中存在差异。例如星巴克关停 AI 库存工具的具体财务影响未公开，员工反馈的具体数量也仅限于报道中引用的样本。Stonebraker 提到的"0% 准确率"是特定测试条件下的结果，他本人也未详细披露测试方法论。本文在引用时采用了归因表述（“据 Stonebraker 称”），而非将其呈现为普遍性结论。

第二，技术方案的成熟度。 Pydantic AI 作为本文引用的主要技术案例，其核心功能（结构化验证、Guardrails）已相对成熟——Pydantic 库本身是 Python 生态中下载量最高的验证库之一，Pydantic AI 在其基础上添加的 Agent 能力也已有 Overjoy、Lema AI、GIC、Datalayer 等 7 个公开的生产案例。但其 Harness 能力库中的许多组件（记忆系统、子代理编排等）仍在开发中。其 HITL 机制目前主要聚焦于工具审批场景，通用性不及 LangGraph 等更成熟的 Agent 框架。在本文中引用它，是因为它在"类型安全 + 结构化验证"这个特定方向上提供了清晰且可参考的实现模式，而非因为它是一个通用解决方案。

第三，反方视角不应被忽视。 也有充分的证据表明 AI 在特定场景下确实带来了显著的效率提升。GitHub Copilot 在代码补全领域的研究显示，开发者完成任务的速度平均提升了 55%。McKinsey 的多份报告指出，AI 在客户服务、营销内容生成、软件开发等领域的 ROI 是正向的。本文聚焦于"伪效率陷阱"这个特定问题，并不意味着 AI 的整体价值需要被否定。事实上，正是因为 AI 在这些场景中表现优异，才更需要警惕在它不擅长的领域盲目照搬同样的期望。

第四，“验证税"本身也是可以优化的。 本文提出的分层验证方案不是终极答案，而是一个思考框架。随着模型能力的提升（比如更好的指令遵循、更低的幻觉率），第一层和第二层可以覆盖的范围会持续扩大。人工闸门的介入比例不是固定的，而是应该根据具体场景的容错率和 AI 表现动态调整。

结语

AI 不是效率的银弹，也不是需要抵制的威胁。它是一种能力极强但确定性不足的工具。

当我们在讨论 AI 落地时，与其问"AI 能不能做这件事”，不如问一个更实际的问题：“我们有没有设计好一套体系，让 AI 做它能做的，让机器验证机器能验证的，让人只做只有人能做的？”

验证税不是不可承受的成本，但它需要被看见、被设计、被管理。那些成功落地的 AI 项目，往往不是选了最强模型的那个，而是在流程设计上投入了最多思考的那个。

人机协作的关键，从来不是让机器更像人，而是让合适的验证出现在合适的环节。

本文引用的主要信息来源：

• Reuters 关于星巴克 AI 库存系统的独家报道（2024-2026）
• 星巴克 CEO/CTO 公开讲话及内部通讯
• NomadGo 关于星巴克 AI 盘点工具的新闻稿
• Klarna 公开财报及 Digital Applied、Customer Experience Dive 媒体报道
• Stonebraker 在 DBOS Data 2025 Year in Review 演讲中的原话
• Stonebraker 在 The Peterman Pod 采访中的观点
• 36Kr 编译的 Stonebraker 观点汇总
• Pydantic AI 官方文档及 7 个生产案例（pydantic.dev/case-studies）
• Fortune (2026-03)、MIT Sloan (2025-07)、HBR (2026-02)、CMR (2026-01) 相关研究
• Workday / PwC 联合调研报告