01 触发事件

本周，星巴克正式终止其在北美门店使用的 AI 库存自动盘点工具。

已知原文信息很简单，但已经足够关键：这套系统通过平板拍照，自动统计牛奶、糖浆等门店物料库存；上线 9 个月后，因为频繁出错，被正式叫停。

真正重要的数字不是“AI”两个字，而是“北美门店”“9 个月”“频繁出错”。

这意味着它不是一个停留在 PoC 的 demo，也不是一个还没推开的试点，而是已经进入真实门店 workflow，然后被业务侧判定不值得继续承受。

我没在内部跑过这套系统，所以不能判断它具体是 CV 模型识别精度不够，还是门店拍摄流程、光照、遮挡、容器规格变化、SKU 映射和回传系统集成出了问题。

但有一点很清楚：星巴克没有因为“AI 是未来”而继续容忍它。

频繁出错，上线 9 个月后被叫停

这句 callout 的分量，远大于一条普通产品下线新闻。

因为 enterprise software 可以容忍一点体验差，consumer app 可以容忍一点 bug，但门店运营系统不能容忍会把人重新拖回手工盘点的自动化。

02 这事的真正含义

表面上看，这是“星巴克的一个 AI 工具做砸了”。

这不是重点。

重点在于，physical-world AI 在高频、低毛利、低容错的线下场景里，仍然没有穿过 reliability threshold。

很多人谈 AI 落地，习惯把“能不能识别出来”当成问题。

但在零售门店，问题从来不只是识别。

问题在整个链条：

  • 店员是否会按规范拍照
  • 货架、冰箱、容器是否标准化
  • 不同门店的 lighting、摆放密度、遮挡程度是否可控
  • 模型输出能否直接映射成可执行库存数据
  • 错误发生后，谁来兜底
  • 兜底动作会不会比原来的人工流程更慢

这才是 AI 应用层最容易被低估的部分：模型 accuracy 不是产品 truth，workflow reliability 才是产品 truth。

如果一个盘点系统在 80% 场景里节省时间，但在 20% 场景里要求员工返工、复拍、手动纠错，门店 manager 最终感知到的就不是 automation，而是 friction。

那个真正会被定价的，不是“单次识别成本”，而是“错误一次对门店节奏造成的打断成本”。

我可能误判的一点是，星巴克下线也可能有组织层面的原因，比如门店培训不足、系统 rollout 过快、与既有 ERP/采购流程耦合太深，而不完全是模型能力问题。

但即便如此，结论也没变：AI 在企业内被采购，靠的是 demo；AI 在企业内被续费，靠的是稳定嵌入流程。

这正是现在很多 AI startup 最危险的误区。

在 SaaS 世界里，卖给总部就够了。

在 operational AI 世界里，总部签单不代表门店 adoption，门店 adoption 不代表持续使用，持续使用也不代表业务信任。

最后拍板的，往往不是 CIO，而是前线员工有没有绕开它。

03 历史类比 / 结构对照

我更愿意把这件事类比为早期企业移动化，不是类比 2022 年 ChatGPT。

2007 年 iPhone 的意义，是把计算平台带到个人手里。

但直到 2010 年代中期，企业才真正理解：移动 app 不是把 PC 流程搬到手机上，而是重做 interaction model、权限结构、通知逻辑和现场操作路径。

今天的门店 AI 也一样。

很多公司以为，给现场员工一个 camera + model，就等于把“看库存”这件事自动化了。

其实不是。

这更像 2014 年 AWS 之后的一波错觉：大家以为有了 cloud，企业 IT 就会自动转型；后来才发现，真正的迁移成本在组织、架构、流程和 ownership。

星巴克这件事暴露的是同一个结构性矛盾：foundation model 或 CV model 的能力进步是连续的，但企业 workflow 的容错阈值是离散的。

没跨过去，就是没跨过去。

95 分和 99 分，在 benchmark 上看差距不大。

但在线下盘点、支付风控、医疗文档、合规审阅这类任务里，可能就是“可用”和“不可用”的差别。

这也是为什么很多 AI infra 投资人和应用创业者会高估 adoption 速度。

技术曲线是平滑的。

商业曲线不是。

我没见过这套工具的实际 error taxonomy，所以不能断言它的失败一定来自最后 2% 的 accuracy gap。也可能是前端设计、异常处理和 human-in-the-loop 没设计好。

但历史经验通常站在一个更冷的结论那边：凡是需要前线员工额外理解、额外配合、额外纠错的 AI 系统，都会被实际 workflow 惩罚。

04 对 AI builder 意味着什么

如果你在做 AI 应用，这周真正该调整的，不是对模型能力的看法，而是对交付单位的定义。

你卖的不是识别、总结、生成。你卖的是一个被接住的结果。

这会直接影响产品、定价和 go-to-market。

第一，别再用“替代人工”写 PRD，先用“减少复核时间”写。

尤其是线下、供应链、客服质检、财务审核这类场景，先把 AI 定义成 copilot 而不是 autopilot，通常更容易穿过 adoption 门槛。

第二，重新计算你的 ROI 模型。

不要只算 token cost，不要只算 inference latency。

要把以下几项一起算进去：

  • 人工复核率
  • 异常 case 占比
  • 二次录入成本
  • 培训成本
  • 系统切换带来的 switching cost
  • 错误导致的业务损失或信任折价

很多 AI startup 看起来 unit economics 很漂亮，是因为把“人工兜底”藏进客户组织里了。

这不是真毛利。

这是把成本 externalize 给客户。

第三，如果你的产品要进入 physical workflow，优先做“结构化约束”，而不是盲目追求更强模型。

比如固定拍摄角度、限定容器规格、减少 SKU 变体、做强输入校验、引导用户补拍，而不是期待模型 magic 解决一切。

这听起来不性感，但 moat 往往就在这里。

不是模型 moat。

是 workflow moat。

第四，toB 销售上要更警惕“总部买单，基层弃用”。

对 AI builder 来说，最该追踪的不是签约门店数，而是：

  • 周活跃使用率
  • 人工 override 比例
  • 完成一次任务的总时长
  • 错误后回退到旧流程的频率
  • 续费前 90 天的 usage retention

如果没有这些数据，ARR 可能只是暂存，不是收入质量。

第五，对做 model access、routing、AI infra 的团队也是提醒。

不是每个应用层失败都能被归因于模型不够强，因此也不是每个需求都值得用更贵的模型去堆。

有时候，GPT-5 级别能力不是答案，better UX、narrower scope、hard-coded guardrail 才是答案。

问题不在 token，而在 task design。

05 反方观点 / 风险

我刚才的判断，最容易错在两个地方。

第一，我可能高估了“这是一种结构性失败”，低估了“这只是一个糟糕执行”。

原文没有提供供应商名字、模型架构、准确率、部署范围、是否分阶段 rollout，也没有说清楚是识别错误、数据同步错误，还是员工使用错误。

如果这是一个特定 vendor 的实现问题，而非零售 AI 的普遍瓶颈，那么把它上升到行业判断，会过度解读。

第二，我也可能低估了未来 12 到 24 个月多模态模型的改善速度。

如果更强的视觉模型、on-device inference、低延迟 edge deployment 和更好的 prompt caching/本地校验机制结合，今天导致失败的 friction，可能会迅速下降。

届时，星巴克这次叫停未必是“这条路不通”，而只是“第一代产品太早了”。

但即便站在反方，我还是会保留一个偏冷的结论：企业不会因为模型进步就自动重写流程，只有当 AI 让现有流程变得更稳、更快、更少争议时，它才配被称为基础设施。

这才是这条新闻真正值得 AI builder 记住的地方。

不是“又一个 AI 项目翻车”。

而是：现实世界里，最贵的不是 inference，最贵的是不被信任的自动化。