AI 语音点餐的探索与思考

XeonYu

已于 2025-07-10 10:22:28 修改

阅读量1k

点赞数 25

CC 4.0 BY-SA版权

文章标签：人工智能 chatgpt AI 点餐

于 2025-07-05 20:11:17 首次发布

本文为博主原创文章，转载请注明本文转自 [喻志强的博客](https://blog.youkuaiyun.com/yuzhiqiang_1993)。如果文中有什么纰漏或错误,请留言指正。如果您觉得文章对你有帮助，请三连支持，谢谢！

本文链接：https://blog.youkuaiyun.com/yuzhiqiang_1993/article/details/149133098

背景-风起云涌

22年底OpenAI推出ChatGPT，AI可以说是一夜爆火。如果说过去的十几年是移动互联网的时代，那下一个时代的主角一定有 AI。

经过不到两年的发展，AI 交互的形式已经从最初的聊天问答的形式，到如今 Agent 能够的理解自然语言，做任务拆解，然后调用各种资源帮我们完成任务这种几乎全自动的形式，可以看到发展是非常快的，而且越来越多的 AI 相关的应用也是层出不穷。

在 AI 概念火爆的早期阶段，大家都在思考如何把肯德基的业务跟 AI 做结合，讨论过后决定以“语音点餐”作为一个试点场景，开展AI落地的探索与实践。

几个方面的考虑

语音交互技术较为成熟，用户认知度高，与AI结合后语音助手的能力会有很大的提升。
点餐本身具备高频刚需属性，餐品的个性化推荐也很贴合用户的实际需要，有较强的实用价值；
该场景可以充分验证AI在自然语言理解、意图识别与智能推荐方面的实际能力，为后续拓展更多业务形态积累经验与能力基础。

首次探索-小试牛刀

23 年的 6 月份，我们算是做了一次最原始的探索，当时还没有现在这么丰富的工具和框架供我们使用，我们只能通过比较原始的调用 openai 接口结合提示词的形式来测试可行性。
受限于当时模型的理解能力以及 token 的长度限制，实际的体验并不稳定，主要存在以下几个痛点：

菜单数据比较长，我们无法把详细的菜单数据给到 ChatGPT，即使是精简过后的菜单数据，在多轮对话后调用接口会失败
意图理解不是很准确，存在 “已读乱回” 的情况
无法稳定的返回我们期望的固定 json 格式的数据

虽然初次尝试效果不佳，但我们依然得出了一个重要结论：AI在理解用户语义后推荐餐品，这条路是走得通的。

再次尝试-峰回路转

合作背景

24 年的 10月份，联发科发布了旗舰芯片天玑 9400，因为 AI 的概念比较火，因此，芯片厂商在宣传芯片时，除了传统的 CPU、GPU 性能的提升以及功耗上的优化之外，AI 能力的支持也花了很大的篇幅做了重点介绍。

例如官方对天玑 9400 的宣传页面中，有一个专门的模块用于介绍 AI 的性能

https://www.mediatek.cn/products/smartphones-2/mediatek-dimensity-9400

在这里插入图片描述

包括芯片的架构图也是专门列出了 AI 处理器

在这里插入图片描述
超频版本 9400+ 的宣传页进一步把 AI 方面的宣传优先级提高。

https://www.mediatek.cn/products/smartphones-2/mediatek-dimensity-9400plus

预计在 25年的 9 月份或者 10月份，新一代的旗舰芯片 9500就会发布，AI 的性能会有进一步的提升
在这里插入图片描述

为了演示 AI 在手机端上的一些业务场景的落地，联发科找了几家 App 厂商合作，其中就包括肯德基。在 24 年的 8 月份开始，我们内部联合点餐团队跟联发科一起完成了 AI 语音点餐的 demo。
效果展示

天玑 9400 发布会

https://www.bilibili.com/video/BV1Qq2wYEEJc/?vd_source=7dd068fc5289ce35b6a9a515b2a3f36f

AI 场景落地宣传

https://www.bilibili.com/video/BV1cQ2RYSEZn/?t=0&vd_source=7dd068fc5289ce35b6a9a515b2a3f36f

整体的效果就是视频所示，用户只需要动动嘴就能完成点餐，订酒店或者导航之类的需求。

值得关注的点

交互入口前置到了系统层面
交互模式发生了变化
利用了端侧的 AI 能力（端侧模型）

核心架构解析：角色与依赖关系

看完宣传视频后，我们会发现，整体的效果似乎还不错，用户只需要动动嘴就能完成点餐，订酒店，或者导航等需求了。

下面来详细说一下整体的结构和交互流程

整体架构

在这里插入图片描述

核心组件解析：职责与依赖关系

终端设备: 整个交互流程的物理载体是手机。在其系统层，预置了端侧模型，为本地化AI能力提供了基础运行环境。
语音助手: 作为用户与系统进行语音交互的入口，语音助手是运行在手机系统层面的核心应用。它直接依赖并集成了 MTK Agent Server SDK。语音助手通过该 SDK 将用户的语音输入（经ASR转换为文本）传递给 Agent Server 进行处理。
MTK Agent Server SDK: 该SDK是系统层面的协调者与执行者。它接收来自语音助手的输入，并与模型进行通信以获取决策。其核心职责是根据模型的规划，通过MTK Agent Client SDK向目标应用（如肯德基 App）分发指令。
模型: 作为整个系统的思考者和规划者”，模型不直接依赖于任何特定App，而是由 Agent Server SDK 调用。它负责理解用户意图，并基于所有已注册App的能力清单进行智能决策，将用户请求映射为可执行的App操作指令。
肯德基 App: 作为具体的业务应用，提供了能力清单，用于告诉AI App 的类别以及具备哪些能力，并执行对应的业务逻辑返回结果。
MTK Agent Client SDK: 跟 Agent Server SDK 建立链接，负责接收指令接收与执行代理。它内置于业务App中，负责解析 Agent Server SDK 传递的指令，并触发App内部预定义的业务功能。
综上，MTK Agent Server SDK 负责系统层面的全局协调与AI决策流转，而 MTK Agent Client SDK 则作为业务App的适配器，确保指令能够准确无误地在应用内部得到执行。两者协同工作，实现了语音助手与业务App之间的联动。

详细交互流程：从语音到执行

以用户说了一句：帮我点一份肯德基香辣鸡腿堡套餐。为例

语音助手 (Voice Assistant)

用户行为: 用户发出语音指令：“帮我点一份肯德基香辣鸡腿堡套餐”。
语音助手职责: 捕获用户的语音输入，并利用其内置的语音识别 (ASR) 技术，将这段语音准确地转换为文本字符串。
执行结果: 生成文本字符串 "帮我点一份肯德基香辣鸡腿堡套餐"。
传递: 语音助手将此文本字符串传递给系统层面的 Agent Server SDK。
展示结果 :将收到的结果展示到 UI 上，或者跟用进行语音交流（TTS）

Agent Server SDK

接收: Agent Server SDK 接收到语音助手传递的文本 "帮我点一份肯德基香辣鸡腿堡套餐"。

核心机制 - 能力清单聚合

在系统初始化或 App 安装/更新时，能够收集到所有支持 Agent 交互的 App 具备的能力信息。
Agent Server SDK 会维护一个全局的能力清单库，其中包含了所有已注册 App 的名称、唯一标识以及它们各自支持的 action (功能) 及其 parameters (参数) 的详细定义。

例如，它可能聚合了以下简化后的能力清单：

// 肯德基 App 的能力清单 (KFC_APP_MANIFEST)
{
  "app_name": "肯德基",
  "package_name": "com.kfc.app", // 唯一标识
  "supported_actions": [
    {
      "action": "order_item",
      "description": "在肯德基App中点餐",
      "parameters": [{"name": "item_name", "type": "string", "required": true}]
    },
    {
      "action": "show_promotions",
      "description": "显示肯德基App的促销活动"
    }
  ]
}
// 麦当劳 App 的能力清单 (MCD_APP_MANIFEST)
{
  "app_name": "麦当劳",
  "package_name": "com.mcdonalds.app",
  "supported_actions": [
    {
      "action": "order_item",
      "description": "在麦当劳App中点餐",
      "parameters": [{"name": "item_name", "type": "string", "required": true}]
    },
    {
      "action": "find_store",
      "description": "查找附近的麦当劳门店"
    }
  ]
}
// ... 其他 App 的能力清单

构建提示词: Agent Server SDK 将用户输入的文本与这个聚合后的全局能力清单一起，构建一个详细的提示词 (Prompt) 发送给 模型。这个提示词会包含：
- 系统指令: 明确 模型 的角色（例如，作为智能助手，根据用户意图选择并调用合适的 App 功能）。
- 可用工具/函数定义: 将所有已注册 App 的 supported_actions 及其 parameters 以结构化的形式（例如，OpenAI Function Calling 或 Gemini Tool Calling 格式）提供给 模型。每个 action 会包含其所属 App 的信息（如 app_name 或 package_name）。
- 用户查询: 用户的原始文本输入 "帮我点一份肯德基香辣鸡腿堡套餐"。
传递: 将构建好的提示词发送给 模型。

模型 (Model)

接收: 模型 接收到 Agent Server SDK 发送的包含用户查询和所有可用 App 功能定义的提示词。
语义理解: 模型 对用户查询 "帮我点一份肯德基香辣鸡腿堡套餐" 进行深度语义分析：
- 意图识别: 识别出核心意图是“点餐” (order_item)。
- 实体抽取: 识别出关键实体“肯德基” (App 名称) 和“香辣鸡腿堡套餐” (餐品名称)。
App 匹配与功能选择: 这是模型精确决策的关键步骤。
- 模型 会遍历提示词中提供的所有 App 的能力清单。
- 它会根据用户查询中的“肯德基”这个关键词，精确匹配到 全局能力清单库 中 app_name 为“肯德基”的那个 App 的能力清单 (KFC_APP_MANIFEST)。
- 在匹配到肯德基 App 后，模型 会在该 App 的 supported_actions 中寻找与“点餐”意图最匹配的 action，即 order_item。
- 同时，它会从用户查询中提取“香辣鸡腿堡套餐”作为 item_name 参数的值。
- 为什么不是其他 App？: 模型 之所以不会选择麦当劳 App 或其他 App，是因为其强大的自然语言理解能力使其能够识别出用户明确提到了“肯德基”这个品牌。即使其他 App 也提供了 order_item 功能，但由于用户指定了“肯德基”，模型 会优先且唯一地选择与“肯德基”品牌关联的功能。如果用户只说“帮我点一份香辣鸡腿堡套餐”，那么 模型 可能会进入一个模糊状态，可能需要进一步询问用户，或者根据用户历史偏好、地理位置等信息进行推断（这属于更高级的 Agent 能力）。但在本例中，“肯德基”是明确的限定词。
生成动作指令: 模型 根据其理解和匹配结果，生成一个包含目标 App 标识和具体 action 及 parameters 的 JSON 格式响应。

执行结果: 模型 返回以下 JSON 结果给 Agent Server SDK：

{
  "app_package_name": "com.kfc.app", // 明确指定目标 App 的唯一标识
  "action": "order_item",
  "parameters": {
    "item_name": "香辣鸡腿堡套餐",
    "quantity": 1 // 默认值或模型推断
  }
}

Agent Server SDK - 指令分发与App启动

接收: Agent Server SDK 接收到 模型 返回的 JSON 动作指令。
解析: 解析 JSON，提取出 app_package_name (com.kfc.app)、action (order_item) 和 parameters。
App 识别与启动: Agent Server SDK 根据 app_package_name 识别出目标 App 是肯德基 App。
- 如果肯德基 App 当前未运行，Agent Server SDK 会触发系统的 App 启动机制，拉起肯德基 App。
- 如果肯德基 App 已经在后台运行，则直接与其进行通信。
指令传递: Agent Server SDK 通过 Agent Client SDK 将 action 和 parameters 传递给目标肯德基 App。

Agent Client SDK - App内部功能调用

接收: Agent Client SDK (内置于肯德基 App 内部) 接收到来自 Agent Server SDK 的指令 (action: "order_item", parameters: {"item_name": "香辣鸡腿堡套餐", "quantity": 1})。
功能映射: Agent Client SDK 内部维护着一个映射表，将外部的 action 字符串映射到肯德基 App 内部的具体业务逻辑函数或接口。
调用: Agent Client SDK 调用肯德基 App 内部预先注册的 orderItem 函数，并传入 item_name 和 quantity 参数。

肯德基 App - 业务逻辑执行与界面流转

执行: 肯德基 App 接收到 orderItem 调用，执行其内部的点餐业务逻辑：
- 在 App 内部的菜单数据中查找“香辣鸡腿堡套餐”。
- 将该餐品添加到用户的购物车。
- 更新 App 的用户界面，例如，自动跳转到购物车页面，或者在当前页面显示“香辣鸡腿堡套餐已加入购物车”的提示。
反馈: 肯德基 App 将操作结果（例如，成功加入购物车、库存不足等）通过 Agent Client SDK 返回给 Agent Server SDK，最终可以反馈给用户（例如，通过语音助手播报“香辣鸡腿堡套餐已加入您的购物车”）。

App能力清单

按照现如今AI 主流框架的角色来看，肯德基 App 承担的是一个类似于 MCP Server 的角色，根据联发科给的标准，App提供资源，Tools等能力。

下面是处理过后的模拟/脱敏的数据：

{
  "app_name": "通用功能型应用",
  "version": "1.0",
  "supported_actions": [
    {
      "action": "app_launch",
      "description": "应用启动控制",
      "type": "explicit",
      "intent": "android.intent.action.ENTRY_POINT",
      "target": "com.example.genericapp/StartupActivity"
    },
    {
      "action": "process_init",
      "description": "初始化核心业务流程",
      "type": "broadcast",
      "intent": "intent.action.FLOW_START",
      "parameters": [
        {
          "name": "operation_mode",
          "type": "int",
          "options": [0, 1],
          "description": "服务模式选择"
        }
      ]
    },
    {
      "action": "data_management",
      "description": "集合数据操作功能",
      "type": "broadcast",
      "intent": "intent.action.COLLECTION_UPDATE",
      "parameters": [
        {
          "name": "action_type",
          "type": "int",
          "required": true,
          "options": [0, 1, 2],
          "description": "操作类型标识"
        },
        {
          "name": "item_identifier",
          "type": "string",
          "required": false,
          "description": "项目唯一标识（操作0/1时启用）"
        }
      ]
    },
    {
      "action": "data_retrieval",
      "sub_actions": [
        "get_dataset_a",
        "get_dataset_b",
        "get_dataset_c"
      ],
      "type": "broadcast",
      "intent_prefix": "intent.action.DATA_FETCH_"
    }
  ]
}

以上就是整个 AI 语音点餐的大致流程，实际开发过程中，还是存在很多细节方面的东西的，特别是要适配不同状态下对不同指令的响应，这里就不多说了。

一些思考-见微知著

通过上述对AI语音点餐技术实现路径的剖析，我们看到了AI在用户体验上的显著提升。

仔细思考一下，背后所蕴含的行业变革、技术演进方向以及潜在的社会影响有以下几个核心点值得我们重点关注和探讨：

遇到的问题会随着时间的推移被自然而然的解决掉

比如在首次探索时，我们的痛点之一是无法通过提示词让模型给出稳定可靠的返回结构。但是后来推出的 function call 解决了这个问题。

再比如，当时跟联发科合作时，我们还在思考一个问题是，联发科是给了一个声明 App 能力的格式，那万一后面要对接其他厂商时，每个厂商的格式不一样的怎么办？
如果每个厂商的标准不一样，那岂不是要进行兼容，所以当时我们还在思考，怎么把 App 中的能力进行更高的抽象，以便于后续在适配各个厂商时，能尽可能的减少我们的工作量和对接成本。但是后来市面上出现了 mcp，那只要各个厂商支持 mcp 协议，那我们只需要充当好一个 mcp server 的角色，就可以对接各个厂商了，所以这个问题也就自然而然的解决了。

流量入口前置带来的影响以及语音交互对传统GUI交互的冲击

系统级别的语音交互以及“入口前置”这一点，不仅仅是用户操作路径的简单优化，对现有App生态和GUI（图形用户界面）交互模式会带来一定的冲击。

在现在的传统GUI的交互模式下，用户拥有明确的“App选择权”和“入口控制权”。

例如，当用户想点一份汉堡外卖时，他会主动打开“肯德基App”或“美团外卖App”，然后精准地在App内部完成点餐流程。此时，用户的消费意图和品牌偏好是直接且明确地导向特定App的。

然而，在系统级语音助手的模式下，这种“入口控制权”发生了根本性转移。用户只需一句“帮我点一份肯德基香辣鸡腿堡套餐”，语音助手便直接介入，并由背后的Agent和模型完成App的识别、唤起和功能调用。

思考：未来会不会更进一步，用户直接就在语音助手侧完成整个点餐流程？

技术上一定能做到

由此带来的问题：
1. 用户流量的截流：用户不再需要主动打开App，App的启动页、品牌形象展示、内部营销活动等直接触达用户的机会将大大减少。用户可能只记得“我通过语音助手点了餐”，而非“我打开了肯德基App点了餐”。
2. 数据与用户行为数据被阻断：语音助手作为新的流量入口和交互中枢，会掌握更全面的用户行为数据和消费偏好。App厂商与用户之间的直接数据连接和关系维护将变得更加间接，甚至可能被平台方（如手机厂商、AI助手提供商）所“中介化”。
3. 商业模式的变更：App的广告、会员、增值服务等商业模式，很大程度上依赖于用户在App内的停留时长和活跃度。入口前置会削弱这些基础。
4. 平台生态的中心化趋势：这种模式可能导致手机操作系统或AI助手平台成为新的“超级入口”，它们通过聚合和分发App能力，进一步巩固其生态位，形成更强的平台主导权。
存在商业博弈
大趋势，积极适配
手机端语音交互的场景有限，占比不会高。跟适合的场景是AI 耳机，AI 车机之类的场景。

端侧模型

端侧模型，即模型部署产生数据的边缘设备上。

边缘设备是指部署在网络边缘（靠近数据产生源头）的智能设备，能够在本地完成数据的采集、处理、分析和响应，而无需将所有数据上传到云端或远程数据中心。其核心特点是低延迟、本地化处理，弥补了云计算在实时性、带宽消耗和隐私保护上的不足。

当前，端侧模型仍处于发展的早期阶段。受限于手机等移动设备的硬件性能（如计算能力、内存、功耗），目前端侧模型的规模和能力远不及云端模型。例如，主流的端侧模型参数量通常在3B（30亿）左右，与云端动辄数百亿甚至上千亿参数的大模型相比，确实存在显著差距。

随着半导体技术的不断进步和AI芯片的快速发展，端侧模型的体验将持续提升。
能够确定的是，联发科在此次合作中采用的“端云协同”模式，我认为这也是未来的一个大方向，兼顾性能与效率

端侧处理：对于像“选择App”、“挑选要执行的指令”这类相对简单、对实时性要求高且涉及用户隐私的场景，可以充分利用端侧模型的低延迟和隐私保护优势。
云端协同：对于“选择餐品”这类涉及海量菜单数据、需要复杂推理和更长上下文理解的场景，则交由能力更强的云端模型处理，以确保准确性和丰富性。

端侧模型的优势与挑战：

隐私保护：数据无需上传云端，理论上能极大降低了用户隐私泄露的风险。
低延迟与离线支持：本地推理减少了网络传输延迟，提升了响应速度，并能在无网络环境下提供服务，优化用户体验。
个性化与定制化：端侧模型可以更便捷地学习用户本地行为数据，实现更深度的个性化服务，且无需担心数据传输成本。
成本效益：减少了对云端计算资源的依赖，长期来看有助于降低运营成本。

端侧 AI 对于手机厂商和芯片厂商算是一个利好，毕竟，又能促进用户换设备了。

尽管端侧模型目前在能力上仍有局限，且上述优点在用户决策层面可能尚未形成压倒性优势，但其在隐私、实时性和硬件生态构建上的战略意义还是非常重要的。
未来的发展趋势必然是端云协同，至于最终是“端侧为主，云端为辅”还是“云端为主，端侧为辅”，就取决于硬件技术的突破、端侧模型能力的演进以及不同应用场景对性能、隐私和成本的权衡。

个人认为相对可行的一种模式

系统层面提供一个相对能力较强的通用多模态的模型。
- 体积稍大
- 多模态，通用性强，能力强
App 针对自身业务训练垂类模型
- 体积相对小
- 针对性强，贴合自身业务场景，

细极思恐：用户自主性与隐私边界

AI的强大智能和所带来的便利性确实非常值得我们去使用。它能像一个无所不知的“分身”，帮助我们处理各种事务，让生活变得更加高效。但是，正是这种无所不能的“聪明”，也隐藏着其“可怕”的一面，尤其是在结合了“入口前置”和“数据聚合”的能力之后。

在当前的互联网环境中，虽然我们常说不存在所谓的 “隐私”，但至少每个App所关心的隐私数据是相对独立的、有边界的。例如，抖音可能知道你喜欢看美女，喜欢看搞笑视频，但它通常不会知道你的出行计划或健康状况。

但是，当AI通过语音助手成为主要入口时，情况就截然不同了。他完全可以做到以下几点

无死角的用户画像：通过对用户在不同App、不同场景下交互数据的整合（例如，语音助手可以访问你的日历、位置、通讯录、购物记录等），AI能够构建一个远超任何单一App所能企及的、极其全面和精准的用户画像。它将真正做到“了如指掌”，知晓你的一切喜好、习惯、行程乃至情绪波动。
自主选择权被削弱：结合入口前置的特性，AI可能在用户不知情的情况下，基于其对用户的深度理解，替用户做出“最优”决策。例如，当你说“我想吃汉堡”时，AI可能直接为你推荐并下单它认为“最适合你”的汉堡，而非让你自主选择品牌或店铺。这种“智能推荐”在带来便利的同时，也在限制用户的选择范围，甚至影响用户的决策自由，形成一种“AI给你什么，你就接收什么”的局面。用户的自主探索和选择权可能被智能代理所“剥夺”掉。
进一步被扒光：当AI能够无缝地访问和整合用户在各个App中的行为数据时，传统的隐私边界将变得模糊。用户很难清晰地知道哪些数据被AI收集或者说用户压根不知道哪些数据会被收集、收集的数据如何被分析以及用于何种目的，都是未知的。

仔细想一想还是很可怕的，这也是未来 AI技术发展需要持续关注和解决的问题。

感谢阅读，如果对你有帮助请三连（点赞、收藏、加关注）支持。有任何疑问或建议，欢迎在评论区留言讨论。如需转载，请注明出处：喻志强的博客