星巴克短暂试行的 AI 库存管理项目本应减少缺货情况并实现门店运营现代化。然而，它反而暴露了企业 AI 中一个熟悉的问题：技术落地的速度超过了组织为支持它所做的准备。
在一个冬日的清晨，星巴克繁忙的后场里，一位值班主管站在狭窄的冰箱前，手持 iPad 扫描半空的牛奶箱，而手机订单正不断堆积。这样的场景印证了员工和分析师对星巴克这个短命 AI 库存项目的描述——该项目反复出现库存计数错误和标签错误，最终公司在北美全境将其弃用。
星巴克并没有遭遇什么神秘的 AI 失灵——尽管这是围绕这个故事流行的说法。关键的失败与其说在于技术本身，不如说在于实施方式：问题不是模型数不清牛奶，而是公司试图把精密的工具硬套在脆弱的系统和日益精简的人员配置上，而不是让工程师深入门店和供应链的真实环境中。
能数清一切——唯独数不清牛奶的 AI
2025 年底，星巴克在北美数千家门店推出了 AI 驱动的“自动计数”系统，作为其库存盘点自动化计划的一部分，旨在解决高管们所称正在拖累销售的产品短缺问题。
这款面向员工的工具在平板电脑上运行，用于扫描货架并自动统计牛奶和其他饮品原料——此前这些都需要员工手动清点。
该系统被宣传为能让星巴克更好地掌握门店级库存情况。然而，路透社的报道指出，星巴克的一段发布视频显示，该工具在扫描一排糖浆瓶时，正确数出了其中几瓶，却未能识别出中间的一瓶薄荷糖浆。
在实际使用中，这款工具表现不佳。它经常计数错误、标注错误，尤其是形状和外观相似的物品，比如燕麦奶和全脂牛奶。上线不到一年，星巴克便改变了方向。一份内部备忘录告知员工：“即刻生效，自动计数系统将逐步停用……饮品原料和牛奶今后将按照您门店内其他库存类别的相同方式进行清点。”
对外，星巴克表示终止该项目是“为了在继续强调规模化管理的一致性与执行力之际，统一各门店的库存盘点方式”，同时提到“更频繁的门店每日补货”和“持续的供应链改进”。
由于没有听取真正需要这款工具发挥作用的咖啡师和门店经理的意见，星巴克被迫在这项无法在其本应改善的环境中赢得信任的 AI 上紧急刹车。
以自动化作为人员配置策略，以及随之而来的公开撤回
库存系统只是星巴克更大规模自动化叙事的一部分。近年来，星巴克在其美国门店投入了新设备和自动化系统，包括 Siren Craft System，同时削减店内人力，其前提是机器能够弥补人力的减少。
到 2025 年春季，这一赌注已在公众面前崩塌。关于 CEO Brian Niccol 言论的报道引述他的话说，对星巴克而言，“以自动化取代员工的策略已经失败”。他承认，公司此前一直在“从门店中削减人力……希望设备能够弥补人力的减少”，并得出结论称“这一假设并不准确”。
Niccol 补充道：“设备无法解决我们需要提供的顾客体验，真正解决问题的是为门店配备人员，并在此基础上部署这项技术。”问题不在于星巴克买错了工具，而在于它让这些工具去做了错误的工作。
星巴克的 AI 落地究竟错在哪里
去掉那些缩写词和新闻标题，星巴克的失误看起来并不陌生：一个组织急于部署新技术，却没有确保它能在现实中最混乱的场景中经受住考验。
只有演示，没有可靠性
这款库存 AI 是作为解决产品短缺问题计划的一部分而推出的。在星巴克自己的发布视频中，该工具在清点几个糖浆瓶时，未能识别出摆放在它们之间的一个薄荷糖浆瓶。
运营级 AI 的标准不在于它能否在演示中令人惊艳，而在于员工在做其他事情时，是否敢放心地把后背交给它。
回避了最坏情况的测试
来自员工和评论者的描述显示，星巴克的后场环境杂乱、不一致，充满了让脆弱的计算机视觉系统难以应对的边缘情况。然而，该工具在尚未在这些条件下赢得信任之前就被广泛部署，其九个月的寿命和迅速退役便是明证。
并不是说 AI 原则上无法应对复杂性，而是它在真实环境中所面对的复杂性从未真正定义过它的需求。
用 AI 来修补结构性问题
在这款 AI 工具被弃用之前，星巴克高管早已将供应链问题和产品短缺视为拖累销售的因素。这意味着公司试图用一个 AI 层来提升一个本已承压的供应系统的可见性。
当不完善的流程输入到新的 AI 管道中时，结果往往是以更快的速度产生糟糕的数据。问题不在于 AI 是错误的工具，而在于它被用在了主要属于结构性的问题上。
自动化是榨取，而非协作
Niccol 自己的言论清楚地说明了问题：星巴克试图削减人力，并假设设备能够承担全部工作，随后不得不公开承认这一策略已经失败。员工们则被迫管理那些增加了复杂性而非减少复杂性的工具。
前沿部署工程师究竟是什么，以及他们如何发挥作用
“前沿部署工程师”并不是星巴克的术语，但它描述了一种本可以纠正该公司许多失误的模式。Silicon Valley Product Group 将前沿部署工程师定义为与客户深度嵌入式共处、投入大量时间的工程师和产品创造者，他们借此深入理解问题空间，并探索能够实现必要成果的解决方案。
传统工程师可能是在远方交付功能，而 FDE 则深入客户的业务流程和约束条件之中，根据一线实际情况实时调整产品。
这不是把工程师放得离业务更近一些，而是让工程师深入业务足够久，真正看清业务是如何运作的。
以这个视角来看，星巴克的几个失误本是可以避免的。
为“真实环境中的牛奶”而设计，而非“实验室里的牛奶”
一位试点 Automated Counting 的嵌入式工程师本应把测试重点放在最糟糕的后勤间：狭窄拥挤、光线昏暗、混放着纸箱和季节性商品的存储空间。这些正是报道中该工具失败时出现的典型场景。
这样的反馈本可以缩小推广范围或限制该工具的使用场景，直到其可靠性提升。并不是说你需要完美的 AI 才能上线；你需要的是缺陷已被清晰映射并得到安全控制的 AI。
把纠错和人工覆盖功能融入工作流程
咖啡师和评论者表示，他们经常不得不审核并纠正 AI 的计数结果，把一个承诺省时的工具变成了额外的工作。一位观察到这种情况的 FDE 本会优先考虑快速覆盖操作、清晰的不确定性提示，以及能从纠正中学习的反馈闭环——这些正是成熟的客户嵌入式工程模式中常见的做法。
这不是要求员工信任 AI，而是向他们证明：当他们纠正 AI 时，AI 确实在学习。
在人员配置稳定之前，让 AI 保持辅助角色
Niccol 已经承认，星巴克需要重新增加更多员工，并从部分自动化中回撤。一个嵌入式工程模式更可能会主张先衡量工具的真实收益，再将其作为裁减人力的依据。
并不是说自动化永远无法支持更精简的运营；而是过早地以它为借口裁员，几乎必然导致不稳定。
让 AI 适应实际存在的供应链
在解释停用 Automated Counting 的决定时，星巴克强调了标准化库存盘点以及更广泛的供应链改进。这等于默认承认：在任何 AI 部署的同时，流程和系统层面的变革也是必要的。
一名与运营和 IT 团队协作的 FDE 很可能早就发现，仅靠 AI 无法解决数据不一致和流程混乱的问题，并可能在试点之前或同时安排基础性工作。星巴克的 AI 抱负本身并没有错；问题在于公司选择部署和治理这些技术的方式未能为其提供充分支持。
押注 AI 的领导者应吸取的教训
星巴克并非特别笨拙，它的经历也不是反对在零售业使用 AI 的理由。它提醒我们，大规模 AI 项目往往在技术与现实之间的接缝处失败，而不是败于模型本身的抽象能力。
应避免的模式是：中央团队和供应商在远处设计，然后付出高昂代价才发现一线并不认同。值得效仿的模式则更为古老：派有能力的人驻扎在问题现场，直到他们对问题理解得足够深入，能够设计出真正契合的方案。
前沿部署工程师正是让这一习惯制度化的一种方式。他们把产品、工程和运营放在同一个空间，并让他们在其中待得足够久，使技术由工作的实际运作方式塑造，而不是由幻灯片上所说的“应该怎样”塑造。
通过把工程师放到一线来改变组织架构，可能比更换模型更重要。
星巴克的 AI 库存推广出了什么问题？
星巴克的自动计数系统对不同奶类等核心商品出现计数错误和标签错误，迫使咖啡师不断纠正错误，最终导致公司在上线不到一年后就关闭了该工具。
为什么这么多零售 AI 项目会失败？
零售 AI 试点常常忽视门店混乱的现实——光线、标签、边缘案例以及超负荷工作的员工——因此在实验室条件下看起来很准确的模型，一旦进入流程不一致的数千家门店就会失灵。
一名前沿部署工程师（FDE）本可以如何改变星巴克 AI 的结果？
FDE 会与咖啡师和运营负责人并肩工作，让 AI 适应真实的工作流程，并在生产环境中持续迭代，在缺陷系统推广到整个区域之前，就发现诸如纸盒误读和糟糕的用户体验等问题。
企业应向 AI 合作伙伴提出哪些要求，以避免重蹈星巴克式的反弹？
他们应坚持要求嵌入式工程团队、分阶段推广、针对准确性和故障模式的明确护栏，以及与一线员工进行真正的共同设计，而不是把 AI 当作一次性安装的软件。
在哪里可以找到 AI 原生的 FDE 团队，以正确的方式部署这一模式？
FullStack 等专业公司提供 AI 原生的工程小组和前沿部署开发人员，负责从试点设计到生产上线以及基于真实数据上线后迭代的完整生命周期。
如何在不更换模型的情况下降低 AI 编程成本？
本指南为您提供计算方法、有意义的基准数据，以及一个在不牺牲能力的前提下削减支出的六步计划。
喜欢这篇文章？订阅即可将新内容送达您的收件箱。
在下方订阅，随时获取最新的开发者指南和行业洞察。
感谢您！您的提交已成功接收！
哎呀！提交表单时出了点问题。
Iframe 被拦截。请接受 Cookie 以加载它。
感谢您！您的提交已成功接收！
哎呀！提交表单时出了点问题。