Yelp 的 AI 助手没有重写界面：导航留原生，对话交给服务器

一个 AI 助手上线之后，产品经理最常问的问题往往不是“模型准不准”，而是“这句话能不能改一下”。改文案、换按钮、调顺序，看起来都是小事，但在移动端，每一次改动都可能意味着一轮发版、一次审核、几天等待。Yelp 给出的答案有点反直觉：不把整个助手重写，而是把界面拆成两半，一半留在手机里，一半放到服务器上。

一分钟速览

• Yelp 的 AI 助手采用混合 UI：导航栏和消息输入框用原生控件，对话区域由服务器驱动的 CHAOS 框架渲染。
• 界面配置与对话数据分离，会话开始只拉一次配置，后续消息以事件形式增量更新。
• 后端不仅能发消息，还能下发“禁用输入框”这类界面指令。
• 好处是改界面不用发版，代价是工程师要同时理解助手和 CHAOS，跨平台表现仍可能有差异。

一个 2024 年上线的助手，长成了小平台

Yelp 的 AI 助手最早在 2024 年登陆 iOS，最初的定位很具体：帮用户把服务需求提交给本地服务从业者。后来它逐步扩展到查询商户信息，并可以完成预订、预约、点餐等动作。功能越加越多，界面也就越来越难改——这正是服务端驱动 UI 想解决的问题。

Yelp 内部的 CHAOS 框架（Content Hosting Architecture with Optimization Strategies，带优化策略的内容托管架构）本来就支持 Web、iOS 和 Android。它的思路是：由后端定义客户端显示什么、如何响应交互。换句话说，界面不再完全焊死在安装包里，服务器说变就能变。

为什么只做“一半”

问题在于，现成的 CHAOS 缺了助手最需要的两样能力：文本输入字段和网络请求。Yelp 服务技术负责人 Daniel Andrade Groppe 的解释很直接：扩展框架会拖慢交付，所以团队选择混合方案——导航和消息输入保持原生，对话区域交给 CHAOS 渲染。

这个选择背后是对“什么该动态、什么该稳定”的判断。导航和输入框是用户每天都在用的基础交互，原生实现更稳、更跟手；对话区域变化最快，今天加快速回复，明天改卡片样式，放在服务器上更划算。

一条消息，也是一条界面指令

这套实现把视图配置和对话数据拆开。聊天会话启动时，客户端先拉取 CHAOS 配置，并初始化消息事件数据集；之后的消息事件直接更新已有视图，不需要重新拉配置。事件类型包括持久化的用户消息和机器人消息、临时的“正在输入”指示器和快速回复，以及打开目标页面的链接。

更关键的是，后端可以发送指令来控制界面。举例来说，当一个服务请求完成时，后端可以返回一条消息、一个查看匹配结果的链接，外加一个“禁用聊天输入框”的动作。用户看到的是一次自然的对话收尾，背后其实是服务端在编排界面状态。这种事件驱动设计，把渲染和对话逻辑分离开了。

客户端仍然握着状态

混合架构并不意味着客户端变成纯展示层。用户提交消息后，客户端先显示已提交内容和输入指示器，禁用输入框，再向后端发请求；收到响应后显示回复和快速回复，重新启用输入。遇到可恢复错误会自动重试，不可恢复的故障则禁用输入并提示稍后重试。消息状态和交互处理仍留在客户端，服务器负责“长什么样”和“下一步能做什么”。

Airbnb 的 Ghost Platform 也公开过类似思路：在 Web 和移动客户端上使用服务器定义的 UI。两者都允许团队在不打包新版本的情况下调整界面。差别在于，Yelp 把模型用在对话界面上，同时保留了原生控件。

省下的发版时间，换来了协同成本

Yelp 工程师也没有回避代价：工程师需要花时间同时理解助手和 CHAOS；同一套逻辑在不同平台上仍可能表现不一样。视图配置与对话数据分离确实让功能可以独立开发，但这套架构对团队的分工和文档提出了更高要求。

这套底子还带来了复用价值：团队用 Android 助手启动了 Biz Ask Anything 试点。Yelp 表示，这项工作为其下一代助手打下了基础，新版助手可以把商家信息和用户可执行的操作连接起来。

趋势判断

AI 助手的竞争正在从“模型回答得好不好”转向“产品能不能快速迭代”。当对话成为主界面，界面配置就会变成产品迭代的核心资产。全原生太重，全动态又容易失控，混合架构大概率会成为移动端 AI 产品的折中答案：把稳定的交互留在本地，把变化快的部分交给服务器。真正难的不是技术选型，而是让两套系统在同一支团队里说同一种语言。