深度学习探索之AI点菜助手智能体/小程序

在B站看完AI智能体相关课程的时候，感觉全世界都在创造自己的智能体，我也想把手上的数据资源和观察到的小痛点结合，做一个有机会变现的智能体。我想了一下，还是觉得跟顾客有直接连接的方式是最容易传播，也最容易被快速接受的。至于痛点，作为一个被选择困难症和挑食的朋友环绕，经常担当点菜任务的人，我想试着用AI解决他们的问题。

选好了方向就是选择平台了，我当时希望选择可以免费快速上手，最好在线云端操作，不需要额外配置的平台，所以试了两个平台，Mulerun和扣子。

先从Mulerun入手，Mulerun的界面看着还是很整洁的，做出来的东西审美也还可以。当时的想法是顾客到店，拍照或上传菜单图片，提出需求（人数/预算/过敏原/特殊需求等），然后系统生成推荐菜单。

菜单图片的文字识别是一个很大的问题。

只有快餐店或小店才会是非常直观的一面墙、一个屏或者一个黑板写下所有的菜和价格，这种情况大多数是1-2人用餐，点自己的菜就好了，根本不需要AI帮助。

而真的需要点菜帮助的，要么是一张正反面写满的、带设计带菜品图片的菜单，要么甚至可能是一整本。拍照上传一整本菜单显然不可能，而拍正反面带设计带图片的菜单，系统经常不能正确识别文字和数字的对应关系，有时候甚至文字也识别不对。要知道我用来测试的图片，相当一部分甚至是源文档而不是拍出来的图，如果正确率无法保证，那完全就是个笑话。

第一版测试到这里，Mulerun的免费积分用完了。刚好朋友推荐说扣子Coze还不错，于是转战扣子试试。扣子的功能还挺丰富的，能做小程序、网页、APP也能做智能体、工作流和Skill。

有了上一版的经验，这次我想改进一下操作的逻辑。拍照上传是行不通的，拍整本菜单更是不可能，那么扫码获取完整结构的菜单有没有可能呢？想象中似乎用小程序比较适配这个功能，所以开始用扣子做小程序。

很快小程序就按照要求做出来了，这次的流程是先填写偏好，再扫码获取菜单明细，然后AI生成最佳组合。为了方便测试看效果，我还申请了实名小程序，但实际一测，新的问题又出现了。

国内大部分的桌边二维码，直接用微信扫码之后会首先弹出餐厅小程序隐私政策或注册登录信息，需要客人先点同意，再点注册登录，再选择用餐人数，然后才会跳入菜单页面。这就意味着我的小程序扫码之后，不仅没有办法直接获取菜单，小程序甚至还会呆住几秒然后报错。只有少数使用非常淳朴的自研二维码的外企连锁餐厅，或许是为了和国外的简易菜单二维码保持一致，才可以顺利扫出来。

国内能适配的餐厅太少了，完全没有可用性，这个版本的方案也失败了。

第三个版本，我再次调整了思路，改为做一个依附于餐厅原有小程序的类似客服智能体的东西。

客人的使用路径是，点开小程序，登录之后进入菜单页面，客人不知道怎么点菜又不想招呼服务员口头交流，此时点击边上的小气泡，呼出点菜小助手智能体，提出要求，智能体给出推荐，然后回复确认下单，智能体把菜品加入购物车并下单。

理论上说这个版本需要对接的菜品、价格、库存数据都可以通过接口对接，加购物车下单的过程也都可以通过接口打通。更进一步的话，品牌方可以先设置好必点菜、根据原料库存情况主推去库存菜品、设置好每道菜的理论成本，规定组合出的菜品保持在合理的毛利率或是根据账号优惠券匹配金额等等。

测试阶段，我导入了一套之前合作过的品牌的菜单数据，不断调试之后，达到了比较满意的效果。我通过微信小程序把智能体分享给几个业内朋友测试，反馈也比较正面，但也仅止于此。

框架搭好了，但是想要把这个小工具变现，还有很多问题需要解决。

比如我没有IT背景，如果需要打通接口，是不是需要有外包的IT辅助人员？

比如我要怎么定价？定低了可能不够token费用，定高了可能没有品牌愿意买单，因为这个痛点也没到那么痛。客人已经坐进来了，总是要点餐的，快一点慢一点对正餐来说没有那么重要，本来也就最多翻2-2.5轮。

还有一个更现实的问题，嫁接在小程序上的智能体，如果小程序的开发商/收银系统/ERP服务商想要开发和推广，我的智能体会飞速被替代。因为对他们来说，客户本来就是他们的客户，系统打通毫无难度，功能开发也是很快的事情，定价上甚至只收token成本都行。

快速做一个智能体，然后就向客户推广一遍的这个商业模式，本身也很让我怀疑持久性。在这样的思考下，我觉得或许有别的商业模式可以探索。

欲知后事如何，且待下回分解。