语音点餐智能体验收，要核对最终订单

餐厅语音 AI 能把订单复述得很顺，不代表厨房收到的订单正确。作者给出的验收标准是：从菜单匹配、加料和价格，到 POS 接单、厨房出票、最终通知，每一层都要保住顾客原本的意思。

这篇的价值是一套可以照着实施的验收思路。但要先划清证据边界：所谓 14 个测试场景是作者设计的合成用例，没有实际接入餐厅 POS 跑过，也不能证明任何产品已经可靠。

复述没错，订单为什么还会错

顾客说「不要洋葱，酱汁单放，薯条换大份」，听起来是一句话，系统却要完成三种操作：删除配料、调整出餐方式、选择可能涉及加价的规格。把它们写进备注，不一定等于完成了结构化下单。

作者把流程拆成四个独立状态：

• Heard：语音识别产生了文字。
• Understood：解析器确定了商品、规格、数量、修改项和履约意图。
• Accepted：POS 校验并接受结构化订单，包括必选项和价格。
• Visible to production：厨房打印机或厨房显示系统 KDS 收到了正确内容。

每跨过一个边界，都要有新的证据，不能拿上一层的成功代替下一层。

例如，识别漏掉「不要」，属于第一层的问题；沙拉选对、沙拉酱漏掉，是解析问题；POS 接单成功而厨房屏幕离线，则是生产交接问题。短信在请求超时后直接写「已确认」，又会制造一个与实际状态不一致的结果。

Square 的 Orders API 把商品放进 line items，把顾客选择放进 modifiers，modifier 也可以有自己的 quantity。Toast 的文档则说明，一个选项还可能触发下一层选择，比如选了沙拉后继续选酱汁。因此，「一个商品挂一个修改项」不足以覆盖真实菜单。

这些文档只能说明对应产品的表达方式。具体门店、渠道和集成是否支持同样的嵌套结构，仍要验证，不能照搬 Square 字段就认为对接完成。

验收要对三份订单，不能只看聊天记录

作者建议并排保存三份材料：员工审核过的预期订单、POS 实际接受的订单、厨房实际看到的订单。验收关注商品、数量、规格、删除项、价格和履约信息是否逐项对应。

先从当前菜单建立标准样本，记录门店、渠道、菜单版本或导出时间、商品 ID、规格、修改项分组、父子路径、允许重复次数、价格影响、履约方式和预期厨房文本。优先保留稳定 ID，因为名称可能重复或改名。

原文给出的归一化样本，把「删除洋葱」与「蒜味蛋黄酱单放」明确表达成不同操作：

{
  "currency": "EUR",
  "line_items": [
    {
      "item_id": "burger-01",
      "quantity": 1,
      "modifiers": [
        {"path": ["toppings"], "option_id": "onion", "action": "remove", "quantity": 1},
        {"path": ["sauce"], "option_id": "aioli", "action": "serve_on_side", "quantity": 1}
      ]
    }
  ],
  "fulfillment": {"type": "pickup", "location_id": "test-location"}
}

要看的是 path、option_id 和 action：选择属于哪个分组、操作对象是谁、到底如何处理，都不能压成一句模糊备注。这个 JSON 是示例契约，并非可直接提交给任意 POS 的请求体。

作者还提供了 check_order.py，用下面的命令比较标准样本与归一化结果：

python check_order.py expected.json observed.json

脚本递归比较类型、字段、值和列表顺序，遇到额外字段、缺失字段或数量差异都会失败。它的前提是先写适配器，把实际 POS 响应映射到同一份契约；把转写文本丢进去，不算 POS 验收。

归一化只能去掉订单 ID、创建时间等临时信息。删除价格可能漏掉多收费；把嵌套路径压成标签，可能掩盖酱汁挂错沙拉；统一排序，也可能隐藏有意义的顺序差异。比较失败后，应调查适配器、旧样本或集成错误，不能为了变绿直接修改标准答案。

原文称其为「14-case synthetic acceptance matrix」，列出了普通商品、数量、删除、替换、嵌套选择、缺货、纠正、重复提交和过敏升级等类别，但所给正文没有展开完整的 14 行用例表。 实施者仍需补齐每个场景的输入、预期结果和通过条件。

超时和过敏，为什么必须单独处理

下单流程应先澄清，再提交。确认门店和自取或配送方式后，读取当前菜单、库存和价格；商品名称含糊时提供候选项；必选项逐个询问，并记录对应标识。

复述的是结构化购物篮，方便顾客纠正。只有实际状态满足确认条件，才能说已经下单。

超时尤其容易出问题。请求没有返回，不代表 POS 没有创建订单。直接重放 create-order 请求可能生成两单，应先通过幂等键或查询核对。结果仍不确定，就保留草稿、说明状态并转人工，同时告诉员工 POS 是否可能已经接单。

过敏问题还要更保守。「不要番茄」通常是菜单操作；「花生过敏能不能吃」涉及配料、替换、制作方法和交叉接触，不能共用一个置信度门槛。

作者要求只从当前、审核过的过敏原记录回答，并保留审核时间。问题没有覆盖、资料含糊或已经过期，就交给受过培训的员工。菜名、营销文案和历史订单，都不足以支持安全承诺。

即使记录了过敏标记，也要验证它到达正确票据和厨房工位。口头说出来而厨房看不到，不能构成有效控制。原文引用的 Food Standards Agency 指引适用于 England、Northern Ireland 和 Wales，不能直接当作其他地区的法律要求。

我的判断

我认同作者把「对话表现」与「交易正确性」分开验收。只看通话演示，很容易被自然流畅的回答吸引；对照结构化订单和厨房输出，才有机会定位信息在哪一层丢失。

但这套方案的定位是验收协议，不是实测报告。作者明确说明，文章于 2026 年 11 月 9 日准备，未进行餐厅走访、实时 POS 测试、菜单导出或生产下单，也没有缺陷率、节省时间和收益的对照数据。它提出的方法有工程道理，实际效果仍待验证。

市场数据也要按原口径理解。National Restaurant Association 的 2024 年摘要来自超过 1,000 名消费者的在线调查，其中 45% 的配送顾客表示可能通过 Alexa、Google Home 或 Siri 等语音平台下单。这不能推出顾客愿意给餐厅 AI 打电话，更不能证明他们信任 AI 处理过敏问题。

相较完全自主下单，先收集草稿、再由员工确认，是能力不足时合理的退路。如果接口只读、无法表达修改项、拿不到最终订单或看不到厨房输出，就不具备证明整条链路成功的条件。只回答营业时间或处理预约的助手，则应使用相应业务的验收标准，不必硬套这份矩阵。

能拿来做什么

• 为 Node 订单服务定义一份归一化契约，保留稳定商品 ID、修改项父子路径、数量、币种、金额和门店，再分别适配 POS 响应与厨房输出。
• 在前端运营界面区分草稿、POS 已接受、厨房可见和待人工处理，让页面、短信与语音确认使用同一份真实状态。
• 给 AI 工具调用补上超时核对流程，覆盖重复提交、顾客中途纠正和要求人工等情况；转接时携带草稿、未解决问题及接单状态。
• 在沙箱保存脱敏证据包，记录菜单、POS、集成和 agent 配置版本。菜单树、价格、prompt、语音模型或厨房路由变化后重新验收；14 项全通过只能说明指定配置下这些用例通过，不能写成「100% 准确」。