点餐车道与餐厅点单智能体

挑那个真正撬动损益表的指标。

准确率是被引用得最多、却最不决定什么的那个数。2026 年的一项研究把纯 AI 点餐车道的订单准确率放在约 83%，普通订单约 87%，而有店员支持的订单约 95%；2025 年 Intouch Insight 的点餐车道研究也发现了相近的六个百分点差距，混合模式则为 97%。仍有约 21% 的 AI 订单需要员工支援。这组数字里没有任何一个能告诉你这条车道是否赚钱。

能告诉你的有四个，而且从第一周起它们就该在同一张看板上：

• 自助完成率。无需店员经手即告完成的订单占比。Yum 曾公布其语音 AI 点餐车道部署的订单自助完成率高于 90%——一次铺开的成败就系于这个数，因为它才是能换算成人工工时的那个。
• 介入率与介入成本。五单里有一单需要帮忙，如果帮忙只值八秒，那没问题；如果帮忙意味着一名店员得一直戴着耳机站着，那就是灾难。一次介入的成本是一项设计产出，不是给定条件。
• 点单时长。Wendy's 在其 2025 年投资者日报告称，FreshAI 门店的每单平均时长比人工车道少 22 秒。秒数就是每小时通过的车辆数，而每小时车辆数就是这门生意的全部。
• 搭售率。同一份报告提到搭售附加率提升 15%。一个总会提一句套餐的智能体，是一台晚上十一点也不会累的营收机器——而一个把套餐提了三遍的智能体，是一个你在准确率里看不到的顾客满意度问题。

那次交接才是产品。

店员介入时从 83% 跳到 95%，是这个领域里最有用的一个事实，而对它的惯常解读——「AI 还得再强点」——是错的。它说的是：混合系统已经能用了，而它的质量由交接做得多好来决定。一个从 83% 提到 86% 的识别器，几乎挪不动那个混合数字。一次从四秒缩到一秒的交接，能挪动很多。

所以先把升级路径设计出来，配一组明确的触发条件和一套定义好的店员体验：

# order/route.py — escalate on structure, not on ASR confidence
def route(order, turn):
    if turn.unresolved_modifier:      # "no ice, actually light ice"
        return ESCALATE
    if order.item_not_in_menu_version: # LTO ended Tuesday
        return ESCALATE
    if turn.repeat_count >= 2:         # asked twice, still unsure
        return ESCALATE
    if order.total > LANE_MAX:         # catering-sized, wrong channel
        return ESCALATE
    return CONTINUE

• 按结构升级，不按置信度分数升级。「模型不太确定」是个弱信号，它会被口音和引擎噪声触发。「顾客已经第二次修改同一个配料项」是个强信号，它只会被真正难的订单触发。
• 店员接手时，订单必须已经在屏幕上。只把音频交过去，等于逼他们重开一次对话，而那正是你想省掉的那八秒。把半成品订单、有争议的那一行交过去，别的都不要。参见升级与热转接。
• 升级通路必须对顾客开放，而不只对模型开放。一位恼火的司机说出「叫个人来」，就是一个触发条件。永远不要把它做成一个菜单选项。
• 退回人工车道，是那条降级通路。智能体宕掉时，这条车道就按 2019 年的方式跑。要有意地把这个开关建出来并测试它，而不是在午餐高峰时才发现它——这就是普通的优雅降级，而一个车道级熔断开关该待在店长的屏幕上，而不是在你的发布流水线里。

难的是配料语法，不是转写。

团队带着「难点在语音识别」的预期进场，发现难点其实是组合学。一张点餐车道订单，是针对一份目录的结构化交易，其中单个商品挂着一棵选项树——规格、做法、替换、去除、酱料、每项配料的份数——而顾客用的是一套菜单并不使用的语法来表达它们。「三号餐，不要洋葱，换成大份，酱能单放吗」是对同一行商品的四次变更，顺序还是乱的，其中一项（「换成大份」）指向的字段与它看起来指向的并不相同。

• 把每一个商品接地到当前生效的菜单版本上。限时优惠每周出现又消失，供应情况因门店、因时段而异，而一个爽快接下了周二就已结束的商品的模型，产出的是一张 POS 会在取餐窗口驳回的订单。在这里，对当前菜单的检索不是优化项，而是正确性边界——与结账前先把商品接地是同一套纪律。
• 要穿过 POS 写入，绝不绕过它。POS 是价格、税、促销与后厨小票的记录系统。智能体的输出是一笔 POS 交易，而任何 POS 表达不了的东西都不是订单——它是一次升级。
• 把订单建模成状态，而不是对话记录。每一轮都在变更一个结构化的购物篮；确认是对那份结构的一次读取，而不是对听到内容的一次回放。这正是显式对话状态为你买到的东西，也是为什么「把订单复述一遍」容易做对，而「记住他们说过什么」不容易。
• 让确认屏去做确认。车道上本来就有一块屏，边点边显示订单。它是一条远比语音更好的确认通道，不花一秒钟，还能把一次口头更正变成一个手指的指点。为它来设计，而不是把订单念一遍。

这是你这辈子要面对的最差音频。

让语音变难的一切在此同时出现：一只装在户外箱体里的远场麦克风、引擎与路面噪声、车载音响、风、天气、盖过司机说话的乘客，以及三米开外另一条车道正在进行的另一段对话。那只喇叭还在把智能体自己的声音播进同一个箱体，这意味着声学回声消除是一项正确性要求，而不是音质要求——参见全双工语音，看看当模型开始边听边说之后，这件事为什么只会更难而不是更易。

• 在车道上测，不要在办公室里测。干净音频上的词错率在这里什么也预测不了。用真实车道录音跨天气、跨时段、跨车型来搭你的评测集，并保持分层——一个中午很棒、凌晨两点很差的模型，是一个只有你看得见才排得了班的人力问题。
• 乘客串音是标志性失败。后座有人在为自己点单，这既不是该被抑制的打断，也不是该被采纳的更正。把多说话人订单处理好是一项差异化能力；处理糟了，就会产生"它加了一杯我压根没点的饮料"这类投诉——社交媒体上关于这个品类的报道，多半就是它。
• 语言混用是常态，不是边角情形。许多市场需要的是订单中途切换语言，而不是开头选一次语言。把它当作基线能力，并单独度量；参见多语言语音智能体。

延迟预算由车决定，不由对话决定。

在呼叫中心，延迟是个礼貌问题。在车道上，它是一个挂着物理队列的吞吐问题：点单慢，车就会堵过菜单板、堵过入口，最终堵到马路上，而到那时司机就走了。放弃排队（drive-off）是那个没人埋点、直到过了糟糕的一周才想起来的指标。

• 从车辆检测开始计，不要从第一句话开始计。运营方在意的那块表，是在地感线圈触发的那一刻起跳的。问候延迟——从检测到第一个字——与响应延迟是两个不同的数，而顾客口中的「它好慢」通常说的是前者。
• 给整条车道做预算，不是给模型做预算。这里的延迟预算包含菜单查询、POS 写入与确认屏刷新。一个 300 毫秒的模型架在一趟 1.2 秒的 POS 往返前面，就是一个 1.5 秒的智能体。
• 打断不是可选项。司机时时刻刻在句中更正，而一个非要把话说完的智能体，损失的秒数比任何模型优化能追回的都多。这是这个领域里价值最高的单项交互行为——参见轮次切换与打断。
• 别在排队时把秒花在搭售上。附加率的提升是真的，而当四辆车在等的时候，它不如吞吐值钱。把要不要开口推荐，做成对队列深度的条件判断——那个数你本来就知道。

录音、告知，以及那些被你改了工作的店员。

这套部署上压着两类义务，而两类都是上线前处理比上线后处理更便宜。

• 录音与声音数据。车道音频会被录下并留存用于改进模型，这就把你带进了同意与生物识别隐私的地界，而各法域的规定差别极大——而且，用来识别回头客的声纹，与用来修一个菜单 bug 的转写文本，在法律上是截然不同的对象。定下你留什么、留多久，以及其中有没有哪一项能识别到个人；参见录音、同意与脱敏。
• 告知。司机应当知道自己在跟一套系统说话，在第一句话里，在他正使用的那条通道上。而人人都想援引的那条豁免——「这还用说」——随着声音越来越好，每个季度都在变弱。

运营的那一半同样要紧。店员的工作从接单变成了监管一队例外情况，那是一份更难、需要更快上下文切换的工作，而且是在高峰时段完成的。如果介入体验很糟，店员就会绕开智能体——抢先接管，或者干脆把它静音——而你的自助完成率会因为看板上看不到的原因悄悄衰减。盯住各门店的人工接管率，并把接管率正在爬升的门店当作一个产品缺陷，而不是一个培训问题。