Zest推出短信内AI餐厅助手，支持基于信用卡消费记录的个性化推荐与一键订座

Zest近日上线一项新功能：一个可嵌入短信对话中的AI餐厅助手。用户无需打开独立App，只需在iMessage或类似消息应用中向“Zest”发送请求，即可获得餐厅推荐并完成订座。这一设计标志着餐饮科技服务正从传统App界面转向更轻量、更自然的对话式交互。

该AI助手的核心能力在于“上下文感知”——它并非从零开始学习用户偏好，而是直接调用Zest已有的用户行为数据。Zest创始人兼CEO Mario Gomez-Hall指出：“代理本身就是产品。你发一条消息，它就能基于你本人及朋友的实际用餐历史作出回应，不需要数周对话来‘训练’。”

Zest于2024年11月成立，初期获得由Alexis Ohanian旗下776基金与Steve Jang的Kindred Ventures共同提供的180万美元种子前融资。其独特之处在于与金融数据接口Plaid集成，自动导入用户信用卡账单中属于“餐饮”类别的交易记录，从而构建动态更新的个人饮食偏好图谱。例如，若某用户过去三个月在纽约频繁光顾法餐与日料，系统便会优先推荐同类风格的新店；当用户旅行至夏威夷时，也能基于本地热门餐厅与朋友打卡记录生成定制化路线。

值得注意的是，Zest仅提取账单中明确归类为“餐饮”（Food & Drink）的条目用于分析，不涉及其他消费类别。所有数据处理均在本地设备或加密通道中完成，公司强调不会存储原始交易明细，仅保留脱敏后的场所标签与频次统计。

此次推出的短信AI助手进一步延伸了该逻辑：用户提出“周四晚上西村约会，要浪漫但别太正式”的模糊需求后，AI不仅返回文字建议，还会附上带图片预览的卡片式结果，并询问是否需要预订——确认后即自动对接合作餐厅的预订系统完成操作。如图所示，在一次测试对话中，AI推荐了格林威治村的Le Gigot，并注明“Maya去过四次，比其他地方都多”，同时提示招牌菜是蟹饼。

这种“发现+决策+执行”闭环的设计，直指当前餐饮服务链路中的断点问题。传统模式下，用户需在多个App间切换：先用Yelp或Google Maps查评分，再跳转OpenTable或Resy预约，过程繁琐且缺乏个性化衔接。Zest试图用一个统一入口解决全流程，其技术路径依赖三方面支撑：一是Plaid提供的结构化消费数据源；二是轻量级LLM模型对自然语言指令的理解与任务拆解能力；三是与主流预订平台（如Resy、OpenTable）的API深度集成。

行业观察者指出，Zest的策略反映了AI Agent落地的一个典型范式转变：从“增强现有工具”转向“替代交互入口”。此前类似尝试包括Poke（行程规划）、Instinct（健身指导）等，均将核心功能压缩进消息界面，降低使用门槛。据TechCrunch报道，Zest团队内部将此称为“无App体验”（Appless Experience），目标是让用户在不主动打开任何应用的前提下完成完整服务闭环。

不过，该模式也面临现实挑战。首先是数据覆盖局限：目前仅支持美国主流银行通过Plaid接入的信用卡账户，对现金支付、非Plaid合作银行用户或海外用户暂未开放。其次，预订成功率受制于第三方系统稳定性——若餐厅后台临时故障或库存同步延迟，AI无法实时回退方案。此外，隐私边界仍存争议：尽管Zest声明仅使用餐饮类交易，但部分用户对“信用卡数据用于商业推荐”持谨慎态度。

Zest并未披露具体合作餐厅数量或预订转化率，但表示已与纽约、洛杉矶、旧金山等主要城市的数百家餐厅达成技术对接。其商业模式仍以B2C为主，未来可能向餐厅端收取推荐曝光或预订佣金。短期来看，该功能将率先面向现有Zest App用户开放，后续计划拓展至WhatsApp、Telegram等国际主流通讯平台。

从更广视角看，Zest的探索呼应了人机交互演进的长期趋势：当AI具备足够上下文理解与任务执行能力时，传统App图标作为“功能入口”的地位正在被弱化。用户不再需要记忆“哪个App负责什么”，而是通过自然语言召唤对应服务。这种转变对垂直领域创业公司既是机会也是压力——能否在特定场景中构建不可替代的数据闭环与行动链路，将成为关键分水岭。

Zest的下一步计划包括扩展至酒水搭配建议、多人协同决策（如投票选餐厅）以及基于天气、交通状况的动态推荐优化。对于习惯用手机App点餐的用户而言，这或许只是多一种选择；但对于追求效率与无缝体验的高频食客来说，一条消息完成从“吃什么”到“已订好”的全过程，正在成为新的日常。