Yelp助手用混合UI架构：原生控件配服务端渲染对话

Yelp 的 AI 助手用上了一套混合界面架构：移动端控件走原生，对话内容则由服务器下发渲染，借此让跨平台界面快速迭代。该方案依托 Yelp 的 CHAOS 框架（全称 Content Hosting Architecture with Optimization Strategies，带优化策略的内容托管架构）来渲染对话，导航栏和消息输入框仍保持原生实现。

Yelp 助手 2024 年先在 iOS 上线，用户可以通过它向本地服务从业者提交服务需求。之后它的能力逐步扩到查询商户信息，还能完成预订、预约、点餐等操作。CHAOS 覆盖 Web、iOS 和 Android 三端。服务器驱动 UI 的思路是后端说了算——客户端显示什么、交互怎么响应都由后端定义，界面改动不必发布新版移动应用就能到达用户。

问题是，现有的 CHAOS 框架缺了助手要用的几样东西，比如文本输入字段和网络请求。等框架扩展又太慢，于是团队选了混合做法：导航和消息输入保持原生，对话区域交给 CHAOS 渲染。

这套实现把视图配置和对话数据拆开了。聊天会话启动时，客户端先拉取 CHAOS 配置、初始化消息事件数据集；此后的消息事件直接更新已有视图，配置不用再拉一遍。事件类型包括持久化的用户消息和机器人消息、临时的输入指示器和快速回复，以及打开目标页面的链接。后端也能下发指令控制界面，比如某个项目请求完成时，它可以返回一条消息、一个查看匹配结果的链接，外加一个禁用聊天输入的动作。这种事件驱动设计让渲染和对话逻辑各管各的。

Airbnb 的 Ghost Platform 公开过相近思路，那套平台在 Web 和移动客户端上都用服务器定义的 UI。两家做法有个共同点：团队调整界面展示时，不用每次都打包发布新版客户端。Yelp 把这一模型用在对话界面上，同时保留原生控件，消息状态和交互处理留在客户端。

具体流程上，客户端先显示已提交的消息和输入指示器，禁用输入，再向后端发请求。收到响应后，展示回复和快速回复，输入重新启用。遇到可恢复的错误会自动重试；不可恢复的故障则禁用输入，并提示用户稍后再试。

Yelp 工程师也承认，这套架构带来了协同上的复杂度：工程师得花时间同时弄懂助手和 CHAOS，而且同一套逻辑在不同平台上仍可能表现不一致。视图配置与对话数据分离，换来了功能可以独立开发。该架构还让 Android 助手被复用来启动 Biz Ask Anything 试点项目。Yelp 表示，这项工作为下一代助手打了底，新版助手现在能把商家信息和用户可执行的操作连接起来。