18,000杯水：得来速语音AI总是搞错的到底是什么
2025年8月，一位顾客把车开到Taco Bell的点餐音柱前，点了18,000杯水。AI完全听懂了他的意思，把全部18,000杯都记进了订单。这段视频的播放量突破2150万次，Taco Bell随后暂停了AI的推广，以查清到底出了什么问题。
令人不安的地方在于：人工智能本身没有出任何差错。语音识别完美无缺，语言模型也完全按照顾客所说的把请求解析了出来。真正缺失的，是夹在AI与收银机之间的那一小段枯燥、基于规则的软件——它本应看一眼“18,000杯水”，然后说：“不，这不是一笔真实的订单。”而这样的软件，从来没有人真正搭建过。
我职业生涯的最近这一段时间，一直都投在得来速语音AI里——也就是当有人站在取餐窗口时，在点餐音柱那头接收你订单的那类系统——我想告诉你，为什么这些故障会一再发生，因为其中的教训并不是那些新闻标题所暗示的那样。问题几乎从来都不出在模型本身，而出在模型周围的架构。
AI正确地听清了订单。只是在整个系统里，压根没有任何一个环节被允许说出那句“这不可能是对的”。
这句话，道尽了得来速语音AI为何总是让部署它的连锁品牌出丑的全部原因。而这是可以修好的——靠的不是一个更聪明的模型，而是所有人在赶着做演示的路上都跳过的那些并不光鲜的工程工作。
无人愿意谈起的那三年瓶颈期
当我最初认真研究这个领域时，人人都拿来当作反面教材的，是麦当劳。他们与IBM在得来速语音上合作了三年，订单准确率却始终卡在80%–85%左右，并在2024年7月悄悄终止了整个项目。这一路上，系统曾给一辆车的订单加上了260块麦乐鸡，还往某人的香草冰淇淋上“点缀”了培根。如今，它已经被“失败博物馆”（Museum of Failure）收录在案。
我最初的直觉，和大多数工程师如出一辙：他们肯定是用了一个很弱的模型。于是我们从所有人都会起步的地方开始——拿一个强大的语音转文字引擎，把它接入一个能干的语言模型，再把输出接到POS收银系统上，然后让它跑起来。在会议室里，它确实令人印象深刻。它能处理复杂的订单、各种加料要求和替换要求。我一度确信，我们只用几周就把这件事搞定了。
然后，在一个寒冷有风的傍晚，我们把它搬到了真实的得来速车道上，它几乎立刻就崩了。
隔着两个车位有一辆卡车在怠速，系统就开始把它的引擎声转录成文字。一阵狂风被记成了一串语音。顾客车里的收音机开着时，AI还兴高采烈地把电台DJ的声音也混进了订单里。那个在室内表现出色的系统，到了室外几乎无法使用，而我本人早期还把整个路线图押在了“模型才是难点”这个假设上。它不是。真正的难点，是在模型听到声音之前，声音所经历的一切。
停车场里的那个夜晚，为我重新定义了整个问题，也正因如此，我们最终在Veriprajna所打造的，并不是一个更好的模型，而是模型周围那些缺失的层。
为什么点餐音柱是地球上最难“听清”的地方
得来速的点餐音柱，是你能要求一台机器去“听清”的、声学环境最恶劣的场所之一。这可不是一句修辞夸张。
引擎的轰鸣声集中在200–400Hz频段——而这恰好正压在典型男声的基频之上。所以，噪声并不是客气地待在一旁、方便你把它滤掉；它和真正承载词语的那些频率死死缠在了一起。风会制造出非平稳的压力波，以难以预料的阵势猛拍麦克风。雨则在整个语音频率范围内叠加上一层宽带嘶嘶声。而一个与之竞争的声音——一名乘客、一台收音机、隔壁的车道——所产生的声音，是标准的语音活动检测（VAD）根本无法与顾客区分开来的。
麦当劳与IBM的系统应对这一切的方式，是把原始的、未经过滤的音频直接送进语言理解层。这正是为什么它会“偷听”到相邻车道的订单，把引擎的瞬态噪声误读成有人开始说话，还会从零碎的音素片段中凭空捏造出菜单上的商品。当音频质量下降时，模型做了模型在不确定时都会做的事：它把这些垃圾信号匹配到概率最高的那些词元上，然后给出一个自信而错误的结果。
你没法靠提示词工程摆脱糟糕音频带来的问题。如果信号在模型看到它之前就已经被破坏，那么一个更聪明的模型，只会给你一个更流畅的错误。
解决办法是一条多级音频处理流程，而各步操作的先后顺序至关重要。我们把基于能量的语音检测——它会把任何大音量都当成说话——替换成了神经网络检测器（Silero这一类模型），它要求连续概率在400毫秒内持续超过阈值，才判定确实有人在说话。仅这一处改动，就消除了大部分“引擎在点鸡块”这类故障。在它之上，我们再运行频谱门控，在语音识别器收到信号之前就先剥离掉约75%的背景噪声；并通过麦克风阵列——Andrea DA-252或Veovox AudioBox——进行波束成形，在空间上把驾驶员的声音与车辆周围的其他一切分离开来。
其中的关键——也是供应商们最讨厌的一点——在于这一层必须针对每一种点餐音柱型号、每一种声学环境分别调校。用整洁的办公室音频训练出来的现成降噪方案，一到停车场就会失灵。这里没有捷径，而这恰恰就是为什么真正肯这么做的人寥寥无几。
那18,000杯水，是软件缺陷，不是AI缺陷
让我再回到Taco Bell，因为它是第二种故障模式最清晰的例证。
那段视频走红的那天早上，一位我一直在接触的连锁品牌运营方把它转发给我，直截了当地问：我们的系统会不会也干出同样的事。这是个合理的问题，而诚实的回答是，绝大多数已部署的系统都会这样，因为它们都存在同一个架构上的漏洞。
AI正确地理解了“18,000杯水”。这一点从来没有疑问。是这套系统没有任何数量校验、没有异常检测，也没有针对单次会话的频率限制。模型的输出直接流向了POS收银端，因为没有人搭建那层中间件，去在订单到达后厨之前先问一句：这单在物理上是否说得通。正是同样缺失的这一层，才让麦当劳把260块鸡块记进了一张账单、把培根加到了冰淇淋上。在上述每一个案例里，语言理解都是正确的，只是业务逻辑完全缺席。
令人抓狂的是，这个修复方案有多便宜。一个确定性的校验引擎——我指的是真正基于规则的代码，而不是再加更多AI——每个连锁品牌只需两到三周就能搭好。它会强制执行由真实订单分布推导出来的数量上限（在快餐店里，单笔点水订单的现实上限大概在八杯左右，而不是一万八千杯）。它会检查商品组合逻辑——在订单数据中，“冰淇淋加培根”出现的历史概率实际上为零。它会为每笔交易设定价格阈值，并强制在任何突破这些边界的情况下由人工介入。
在得来速语音AI里，最便宜、最快的那个修复方案，同时也正是能够避免那些收获2100万次播放的灾难的方案。它靠的是规则，而不是智能。
这就是让人们意外的那个反转。最炫的那部分——对话模型——如今基本上已是一项被解决了的、商品化的能力。真正保护品牌的，是那层确定性的护栏——没有人会把它放进演示里，因为它看起来一点都不惊艳。
当一位口吃的顾客把车开过来时，会发生什么？
第三种故障模式，是让我夜里睡不着的那一种，一部分因为它是个道德问题，另一部分则因为它即将变成一个法律问题。
Wendy's的FreshAI被口吃的顾客形容为“根本没法用”，而一旦你理解了背后的机制，原因就显而易见了。我们自己早期的版本里也有同样的缺陷，我之所以能发现它，只是因为我坐下来，把一段有人点“b-b-baconator（培根堡）”的录音反反复复地回放。我们的系统每一次都把他们打断了。
不流畅的言语会以三种截然不同的方式让语音AI失灵。当一个人重复某个音——“b-b-baconator”——时，识别器会产生重复的词元，把订单逻辑搅乱。当他们出现“卡壳”，也就是一个词中间的无声停顿时，语音检测器会把这段沉默读成他们说话轮次的结束，于是在订单说到一半时就停止了聆听。当他们把某个音拖长——“Mmmmilk（奶——）”——时，音素被拉伸得足够长，以至于系统听到的是一个完全不同的词（“Silk”）。这些都不是什么稀奇古怪的现象。它影响着全球约8000万口吃人群，此外还有远多于此的、带浓重口音、年长者语音模式或非母语发音的人。这些系统是用流利、标准的美式英语训练出来的，它们辜负了其他所有人。
我过去总把无障碍归到“有当然好，以后再说”那一类。我错了，而让我改变主意的，是监管的走向。如今，在《美国残疾人法案》（ADA）之下，餐饮业已成为数字无障碍诉讼第二大被针对的行业，约占全部立案的21%，而这些立案在2025年比前一年上升了40%。加拿大在2025年12月发布了CAN-ASC-6.2:2025——全球首个面向无障碍AI的国家标准——它要求无论用户是否残障都能获得平等的表现，并要求提供一个切实可行的选项，让用户可以拒绝AI、转由人工服务。欧盟《AI法案》的透明度义务将于2026年8月生效，要求必须告知顾客他们正在与一台机器对话。
目前还没有一起针对得来速语音AI的无障碍诉讼落地。但麦当劳的生物识别隐私案——一起指控其未经同意就采集声纹的集体诉讼——已经表明，得来速AI正好落在诉讼的准星之中，尽管那起具体案件最终被驳回了。而这里的成本账，朝着错误的方向算下来极为残酷：往一套已经部署的系统里事后加装无障碍功能，花费大约是从一开始就把它做进去的五倍。在第一天就为不流畅的言语做设计，并不是做慈善。它才是省钱的那个版本。
这套东西真的管用吗？管用——只要架构做对了
读到这里，很容易得出“得来速语音AI是个馊主意”的结论。但它并不是。那些把各个层都好好搭建起来的连锁品牌，正在交出那些失败部署从未达到过的数字，而两者之间的差距，恰恰正是重点所在。
Hi Auto在Bojangles约500家门店运行，报告称订单完成率为93%、准确率为96%，其整个门店组合每年处理超过1亿笔订单。SoundHound在White Castle的系统实现了90%以上的订单完成率，并称每家门店每年可节省约58,000美元。2025年Intouch Insight得来速研究发现，采用AI的车道平均总服务时间为3分53秒，而整体平均为4分15秒——每单大约快22秒——并且每小时能通过17到18辆车，而无AI时为16辆。采用AI的门店满意度约为97%，比传统车道高出好几个百分点。
看看这中间的差距。麦当劳与IBM停滞在80%–85%。Hi Auto与Bojangles则达到96%。这并不是弱模型和强模型之间的差别——到了2026年，底层模型大体上已经不相上下。这是“把原始音频直接丢给模型”和“把信号处理、确定性校验以及围绕它的集成都工程化做好”这两者之间的差别。
最后那个词——集成——正是许多美好愿望夭折的地方。一家大型连锁品牌大约75%到80%的营收都来自得来速渠道，而这份订单必须干净利落地落进该品牌现有的、无论哪一套POS收银系统里。NCR Aloha、Toast和Oracle Simphony各自暴露出不同的API，在加料信息如何流式传输、多车道会话如何保持相互隔离上，都有着不同的限制。菜单也不是一成不变的：限时优惠、分时段供应和区域限定商品每周会变动两到四次，而任何需要重新训练模型才能学会一个新商品的系统，都跟不上这个节奏。我们的做法则是把语言理解锚定在一个实时的菜单数据源上，这样一个新商品几分钟内就能上线，而不是几天。
运营方真正会问我的那些问题
每当我和为这些连锁品牌管理技术的人交流时，总会冒出同样的几点顾虑，所以就让我像在会议室里当面回答那样，把它们一一答复。
我们是不是直接选Google或者NVIDIA，然后就了事了？可以，而且很多品牌都这么做了——Wendy's跑在Google Cloud上，Taco Bell通过Yum!用的是NVIDIA的基础设施，Burger King面向员工的“Patty”助手则跑在OpenAI上。它的代价是平台依赖。一旦API发生变化，或者定价出现调整，你的整个部署都会暴露在风险之中，而且你拿到的是通用型模型，而不是为你自家车道声学环境专门打造的东西。供应商这块领域既拥挤又不乏实力——Presto在2026年1月融资1000万美元，并招来了FreshAI最初的创始人；SoundHound、Hi Auto、ConverseNow和Vox AI也都已在真实规模上部署——但它们每一家交给你的都是自己的整套技术栈，而不是一条定制的信号处理流程。我们的立场是供应商中立：先审计你现有的东西，再在任何平台之上把缺失的那几层搭建起来，而且绝不把你锁死。
那校验层和无障碍层，难道不会把整个流程拖慢吗？这才是真正的工程张力所在。低于300毫秒的响应是及格线，而你每加一层，都要付出延迟的代价。仅云端处理一项，就会增加100到500毫秒的网络往返；把推理搬到边缘设备上，能把这一数字压到5到10毫秒，但每家门店要多花500到1500美元的硬件成本。这项工作的目标，是在不让每小时通过车辆数跌破人工基准线的前提下，把这些护栏加上去，因为一套系统一旦拖慢了队伍，无论它准确率有多高，都会被撤下来。这种平衡是一个有着已知答案的工程问题，而不是跳过这些护栏的理由。
这到底是一项实打实的预算开支，还是一个科研项目？每家门店的语音AI，软件月费在200到500美元之间，把硬件都算上，全部合计是400到980美元。与之相对，各连锁品牌报告称，每家门店每月能带来3,000到18,000美元的额外营收，以及每月四位数的人力成本节省。这笔经济账是算得过来的。真正算不过来的，是把这份预算花在对话层上，却跳过那真正能让你不上头条的三层。
那些爆红故障的真正教训
把每一起上过新闻的得来速语音AI灾难重新捋一遍——那260块鸡块、那份培根圣代、那18,000杯水、那位口吃却被系统挂断的顾客——你不会找到哪怕一起是由“听不懂英语的模型”造成的。它们每一起都是架构上的失败：从未被清理干净的音频、从未被做过合理性检查的订单、系统从一开始就没有被设计去听清的一种声音。
在这件事上取胜的连锁品牌，买的并不是一颗更好的大脑。他们打造的是围绕这颗大脑的身体——在停车场里也管用的耳朵、能在一份荒唐订单抵达后厨之前就把它拦下的反射神经、以及分辨出一份真实订单该是什么样子的判断力。这正是我们在Veriprajna所做的工作，而它远远不如那些演示所暗示的那样光鲜。
用机器来接收一份得来速订单的技术，其实早就已经能用了。在大多数争相部署它的连锁品牌那里，仍然缺失的，是那个没有人会为上线公告拍摄的部分：被清理干净的音频、那条能拦住第一万八千杯水的规则、让一次口吃把它的词说完的那份耐心。把这些做出来，模型就从来都不是难点。跳过它们，那么这段视频会怎么结尾，你早就已经知道了。
