把餐厅管家塞进短信里：Zest 让 AI 替你订位，代价是交出你的信用卡账单

周五晚上七点，四个人的群里还在为“吃什么”吵。有人想吃辣，有人不吃海鲜，有人只想找个能安静说话的馆子。如果群里有第三个参与者——一个手机号，你把需求发过去，它翻出你们各自的用餐记录，给出三个都点头的选项，投个票，然后直接把桌子订了。这就是 Zest 想做的事。

一分钟速览

• 餐厅发现应用 Zest 上线“餐厅管家”，用户通过短信与 AI 对话，可直接完成订位
• 订位能力接入了 OpenTable、Resy 和 SevenRooms 等主流预订系统
• Zest 通过 Plaid 接入用户的信用卡消费记录，只读取餐饮类交易，用来判断口味
• 管家可以被拉进群聊，综合多人的偏好推荐，并在对话内投票决定
• 公司 2024 年 11 月成立，曾获 180 万美元 pre-seed 融资，订位与点单是它最先跑通的收入来源

它凭什么知道你想吃什么

Zest 最初的形态是一个餐厅推荐应用，特点不是算法多复杂，而是数据来源特别直接：它通过金融数据服务商 Plaid 读取用户的信用卡账单，只看餐饮类消费，从而知道你过去半年真正去过哪些店、多久去一次、客单价在什么区间。

这比让用户手动打分要诚实得多。一个人在点评软件上可能给某家店五星，但一年只去一次；账单不会说谎。基于这份历史，Zest 可以判断你偏好的菜系、价位和场景，甚至在你出差到另一个城市时，给出风格相近的替代选项。

新的短信管家把这套数据变成了对话界面。用户可以直接问“今晚两个人，想吃清淡一点的，别太吵”，它会结合时间、人数、位置、忌口给出候选，并告诉你有哪几个时段还能订。

为什么是短信，而不是又一个 App

这个选择背后是一个正在发生的判断：入口正在从应用图标，转移到对话框。过去一年，一批以短信为界面的 AI 助手开始出现，用户不需要安装、不需要学习界面，发一条消息就能用。

对 Zest 来说，短信还解决了它原来的一个结构性难题——使用频率。餐厅推荐是一个典型的高需求、低频次场景，用户一个月可能只打开两次应用，获客成本很难摊平。但群聊是高频的：朋友约饭、同事聚餐、家人周末出行，这些对话本来就发生在短信里。把管家放进群聊，等于把产品放进了需求发生的现场。

群聊场景还带来一个功能上的巧思：多人偏好的合并。四个人的口味冲突，往往比一个人的选择困难更难解决。管家把每个人的历史偏好加权，给出交集，再用手投票收口，最后直接下单。这套流程如果放在应用里，需要用户来回跳转；放在短信里，就是几句话的事。

商业化：订位是第一条收入线

据公司介绍，订位和点单是最先跑通的收入来源：用户通过 OpenTable 或 Resy 完成订位，Zest 从中获得分成，外送点单功能也在推进中。长期看，它不排除把推荐范围从餐厅扩展到其他本地商户。

这个模式的好处是现金流清晰，坏处是天花板受制于预订平台的规则。餐厅预订的佣金本来就薄，而 OpenTable、Resy 这些平台自己也在做 AI 推荐。Zest 真正的壁垒，可能还是那份“你实际去过哪里”的数据，以及它在群聊里积累的社交关系链。

需要正视的两个问题

第一是隐私。把信用卡账单交给一个聊天机器人，对很多用户来说仍是心理门槛。Zest 强调只读取餐饮类交易，但数据一旦进入模型，用途边界就需要非常明确的约束。

第二是可靠性。订位是一个“错了就很难补救”的动作：订错时间、订错人数，用户会立刻感知。AI 在对话里理解错一句“我们六点左右到”，代价就是一张作废的桌子。这类任务对准确率的要求，远高于推荐一家店。

这意味着什么

Zest 的转型说明了一件事：当模型能力足够好，产品的形态可以退到最薄的一层——一个手机号、一段对话。应用商店的流量逻辑、推送的唤醒逻辑，都可能被绕开。

但薄界面也意味着薄护城河。真正的竞争不会发生在“谁的对话框更好看”，而在于谁能拿到更真实的行为数据、谁能接进更多的预订库存、谁能把错误率压到用户愿意托付的程度。餐厅管家只是开始，接下来被塞进短信的，可能是挂号、租房和报税。