一则近期案例，把难点放在了对话框背后
Google Cloud 7 月 23 日披露的 Voicify 案例，聚焦餐饮和医疗行业的电话 AI。与常见的产品演示不同，这个案例强调的不是机器人能说多少，而是四个生产问题：交易精度、突发流量、响应延迟，以及安全与合规。
在餐饮点单中，其对话编排平台会先把订单与 POS 系统核验，再提交交易。面对大型、复杂菜单，系统也没有把全部菜单塞进一个提示词，而是先载入必要信息，再随着对话进展获取相关部分。案例称，这种架构用于降低响应时间和复杂度。
Voicify 还披露，迁移后模型相关成本较此前方案降低约 25% 至 30%；餐厅取得 POS 接入后，进入测试的准备时间从一至两周缩短到一至两天；其在感恩节前一天的历史峰值中没有遇到限流问题。这里的数字来自供应商与客户联合案例，不是独立对照实验，也不能直接作为其他企业的收益承诺。
但它呈现出的设计选择值得关注：真正可用的交易型 AI，不是一个大模型独自完成所有工作，而是语言理解、确定性规则、实时业务系统和交易确认共同组成的服务。
对话成功与交易成功，是两套标准
一个回答型助手说错一句话，通常可以重新提问；一个交易型助手选错规格、承诺了不存在的库存，或重复提交订单，损失会立即进入经营现场。
因此，企业需要把一次自然语言交互拆成至少四层状态：
大模型擅长处理第一层的开放表达，却不应凭记忆猜测后面三层。商品价格、可预约时间和客户资格必须来自当时的权威系统；订单计算、约束检查和最终写入，则应由可验证的程序与接口完成。
这也是“企业上下文”需要重新定义的地方。上下文不是越多越好，而是要在正确时点取得完成当前交易所必需的最小信息。把整个目录、所有规则和客户历史一次性放进提示词，既增加延迟与成本，也扩大过期信息、相互冲突和越权暴露的风险。
- 客户意图：客户想完成什么，哪些条件是必须满足的；
- 业务对象：意图对应哪个商品、服务、门店、账户或时间段；
- 可执行状态：当前库存、价格、资格、风险限制和可用时段是否允许执行；
- 交易结果：是否已确认、提交、扣款、写回，以及失败后处于什么状态。
建立一份可恢复的“交易草稿”
普通聊天记录面向阅读，交易过程则需要面向执行。企业可以为每次会话建立结构化交易草稿，持续记录：
这份草稿的价值不只在于让模型“记住上下文”。它使对话被打断、客户改口、人工接手或下游超时后，系统仍能判断交易进行到了哪里，而不是从一段聊天文本中重新猜测。
尤其要防止两类常见错误。第一类是静默替换：系统找不到客户指定对象，却自作主张选择了近似项；第二类是重复执行：客户因等待而再次确认，系统把同一意图提交了两次。前者需要显式展示差异并重新确认，后者需要幂等控制和明确的交易状态。
- 已确认的商品、数量、规格、地点与时间；
- 仍存在歧义、需要客户补充的字段；
- 每个关键字段来自客户表达、业务系统还是推断；
- 已执行的库存检查、价格计算和规则校验；
- 客户最后确认的版本及其时间；
- 已提交动作的唯一标识和系统返回结果。
确认不应只剩一句“好的”
客户在自然对话中说“可以”“就这样”，并不总能构成有效交易确认。确认机制应与后果相匹配。
对于低金额、可撤销的操作，可以让客户确认一份简洁摘要；涉及过敏信息、医疗预约、金融交易、不可退款服务或重要合同条件时，则应单独确认关键字段，并在必要时交由人工处理。
确认页面或语音播报需要回答三个问题：将要发生什么、关键条件是什么、发生错误后如何撤销或求助。企业还应保存客户实际确认的结构化版本，而不只是保存整段录音或聊天记录。
这并不意味着每一步都增加繁琐确认。相反，好的设计会把确认集中在不可逆、成本高或风险高的节点；对可自动纠正的中间步骤，则让系统快速推进。目标是在转化率与错误代价之间建立清晰边界。
交易型 AI 应该怎样衡量
如果仍然只统计回答率、平均响应时间和转人工率，团队很容易优化出“听起来顺畅”的系统，却无法说明它是否创造了可靠收入。
更适合的指标组合包括：
Google Cloud 的对话式商务产品也把目标明确指向从发现走到购买，并以每位访问者收入为优化方向。其披露的 Albertsons 早期使用情况显示，超过 85% 的 Ask AI 对话从开放式或探索性问题开始，部分用户会向购物车增加额外商品。这说明自然语言确实可能改变发现与购买过程；但“多加商品”仍不等于最终收入，更不等于长期客户价值，企业仍需连接支付、履约、退货与复购数据进行验证。
NIST AI RMF 的测量要求同样强调，应在实际部署情境中评估系统，并持续跟踪生产表现及用户反馈。对于交易型 AI，这意味着测试集准确率只能证明上线资格，真实交易结果才能证明经营价值与风险是否可控。
- 从意图出现到有效交易完成的转化率；
- 无需事后人工修正的订单比例；
- 关键字段首次识别正确率与重新确认率；
- 重复提交、错误替换和价格不一致的发生率；
- 交易中断后可继续完成的比例；
- 峰值时段的完成率、延迟与单位交易成本；
- 因 AI 交易产生的退款、投诉、取消和客户流失。
从一个高频、低风险、可核验的交易开始
企业不必一开始就让 AI 覆盖整条客户旅程。更稳妥的起点，是选择一个需求表达复杂、人工压力明显，但结果可以被现有系统核验的交易闭环。
例如，先限定一个地区、一个商品类别或一种预约类型；接入实时目录和交易系统；列出必须确认与必须转人工的条件；用历史订单、口音、噪声、改口、缺货和接口超时构建测试集；最后在小流量中同时观察转化、准确、延迟、异常与后续经营结果。
只有当系统能够证明“说对了、算对了、写对了，并且失败后能恢复”，企业才应逐步扩大自主执行范围。
生成式 AI 让客户不必学习企业的菜单、筛选器和流程，可以直接用自己的语言表达需求。这是客户体验的重大变化。但对企业来说，优势并不来自把一个聊天入口放到更多渠道，而来自把自然语言可靠地接到真实供给与交易能力上。
当 AI 开始替客户下单，它就不再只是品牌的数字接待员，而成为收入系统的一部分。此时，最值得管理层追问的不是“它像不像真人”，而是：它完成的每一笔业务，是否和真人负责时一样可确认、可执行、可追溯、可恢复？
