【吃什么】AI推荐小程序

基于高德地图 POI 的真实餐厅推荐,用 Coze Vibe Coding 从 0 到 1 完成开发,推荐满意度由 65% 提升至 85%

小程序码

微信扫码体验「干饭趣抽抽」

85%
推荐满意度
+20pt
满意度提升
35
意图场景识别
50
活动卡片库

一、项目背景

"中午吃什么""周末聚餐去哪""今晚夜宵吃点啥"——朋友聚会时的"吃什么"几乎是一个世界级难题。看似简单的选择,却常常因为众口难调、信息不对称、决策疲劳,让一次本应轻松的聚餐在"选店"环节就消耗掉半小时。

我在个人吃饭选择和朋友聚餐选择时都发现了类似的选择困难,并归纳出几个核心痛点:

🍽️
选项过载
海量推荐反而引发选择焦虑,美团、大众点评等平台虽然提供了丰富的团购和评价,但动辄上百家的推荐列表,反而让用户陷入"乱花渐欲迷人眼"的困境。用户在"不知道选哪个"的纠结中,往往渴望一种"帮我做决定"的随机机制。
🔧
工具断层
市面上的"转盘"小程序大多处于两极分化:要么是千篇一律的固定选项,缺乏个性化;要么要求用户手动输入一堆备选项。这本身又制造了新的操作成本——用户原本就是不想动脑筋才用转盘,结果用之前还得先动脑筋填选项,违背了"偷懒"的初衷。
💭
意图鸿沟
用户的真实需求往往是模糊且复合的,例如"想吃点吃不饱的零食"(可能包含甜品、炸鸡、寿司等)。但在美团或地图软件上,这需要分多次单独搜索类目,无法一次性通过"意图"直接收敛结果,导致搜索路径冗长。

于是我决定以"AI设计工程师 + 产品经理"的双重角色,做一个真正能解决"吃什么"的小程序:把"选择"交给转盘与 AI意图识别,把"真实可去"交给高德地图 POI,把"懂你"交给收藏夹与评分系统

核心洞察:用户要的不是"更多的餐厅列表",而是"方便、就近、且贴合当下场景的明确答案"。这决定了产品必须以"真实 POI + 场景化推荐 + 低决策成本"为底层逻辑。

二、需求调研与用户画像

2.1 调研方法

在动手设计前,我用一周时间做了轻量级调研,避免凭直觉拍脑袋。调研方式包括:

  • 深度访谈:对 10 位有聚会组织经验的朋友做 15 分钟访谈,聚焦"选店环节最难受的瞬间"。
  • 问卷验证:回收 30+ 份问卷,验证访谈结论是否具备普遍性,并量化"可接受决策时长"。
  • 竞品速览:体验大众点评、美团、若干"随机吃饭"小程序,记录其解决/未解决的痛点。

调研中最有价值的发现是:72% 的受访者表示"可接受决策时长不超过 3 分钟",超过这一阈值就会直接放弃选择、随便吃。这直接决定了产品必须把"出结果"压缩到一次点击之内。

2.2 用户画像

基于调研,提炼出四类典型用户:

画像 典型场景 核心诉求 使用偏好
大学生 宿舍/校园周边聚餐 便宜、近、快 爱用转盘/抽抽等趣味玩法
都市白领 工作日午餐、下班小聚 人均可控、不踩雷 依赖评分与历史收藏
情侣 周末约会、纪念日 氛围感、有新意 关注场景化(下午茶/夜宵)
家庭用户 周末家庭聚餐 老少咸宜、停车方便 在意距离与 POI 真实性

2.3 三大核心需求

综合调研与画像,收敛出三大核心需求,作为后续功能设计的北极星:

核心需求 含义 对应功能落点
快速推荐 3 分钟内、最好一次点击就出结果 店铺转盘、活动抽抽
个性化适配 按场景/口味/历史偏好筛选 意图搜索、种类选择、收藏夹与评分
操作简便 零学习成本,即看即用 极简交互、真实 POI 兜底

三、产品功能设计

围绕三大核心需求,我设计了四个功能模块,分别对应"快速出结果、按场景筛选、解决去哪玩、越用越懂你"四条用户路径。

功能模块 解决场景 核心机制 对应需求
店铺转盘 "今天吃啥"随机决策 高德 POI 拉取附近真实店铺 + 转盘随机 + 意图搜索 快速推荐 / 操作简便
种类选择 按时段/饮食场景筛选 早餐/午餐/晚餐/减脂餐/夜宵/下午茶等场景标签 个性化适配
活动抽抽 周末去哪玩 50 张内置活动卡片,随机抽取 快速推荐
收藏夹与评分 沉淀偏好、二次推荐 收藏 + 打分,影响后续排序权重 个性化适配

3.1 店铺转盘:把"选择"交给概率

店铺转盘是产品的"门面功能"。它从高德地图 POI 拉取用户附近的高分真实餐厅填充转盘格子,用户点击"开始旋转"即可获得一个明确答案。区别于普通随机 App 的关键在于:转盘里的每一家店都真实存在、就近可达,不会出现"推荐了一家早倒闭的店"的尴尬。

同时配套"意图搜索",支持 35 种意图场景识别(详见第四章),用户输入"我想吃点清淡的暖胃的"也能被正确理解并映射到 POI 标签。

3.2 种类选择:用场景收窄选项

种类选择提供早餐、午餐、晚餐、减脂餐、夜宵、下午茶等场景标签。用户先选场景,再由转盘在该场景对应的 POI 子集中随机,既保留了"随机"的趣味,又避免了"早餐抽到烧烤"的违和。

3.3 活动抽抽:从"吃什么"延伸到"去哪玩"

聚会痛点不止"吃什么",还有"吃完去哪"。活动抽抽内置 50 张活动卡片(密室、电影、KTV、爬山、桌游、看展等),用同样的"抽卡"心智解决周末去哪玩。卡片库可后续按城市/季节动态扩展。

3.4 收藏夹与评分系统:越用越懂你

用户可对去过的店打分(1–5 星)并收藏。系统将评分历史作为个性化权重,影响后续转盘的候选池与排序,让推荐从"纯随机"逐步过渡到"懂你的随机"。

【推荐排序权重示意】 final_score = poi_distance_score * 0.3 + scene_match_score * 0.3 + user_pref_score * 0.4 # 来自收藏夹与评分历史 # user_pref_score 越用越准:初期接近 0,随评分数据积累权重生效
设计取舍:没有采用"完全个性化推荐",而是保留随机的惊喜感——纯个性化会让结果可预测、失去转盘的乐趣;纯随机又不够懂人。"懂你的随机"是二者平衡点。

四、从 0 到 1:用 Vibe Coding 完成开发

4.1 MVP定义与快速验证

MVP定义与快速验证:项目采用MVP(最小可行产品)策略,2天内完成第一版上线——核心功能仅保留"店铺转盘+高德POI",验证"随机推荐真实店铺"这一核心假设是否被用户接受。第一版上线后收集用户反馈,再逐步迭代种类选择、活动抽抽、收藏夹等功能模块。这种"先验证核心假设、再迭代完整功能"的方式,让我避免了在用户不要的功能上投入时间。

4.2 Vibe Coding 的 5 步工作流

整个小程序使用 Coze 进行 Vibe Coding(以自然语言对话驱动 AI 生成代码)完成从 0 到 1 开发。我以产品经理视角描述需求与交互,由 Coze 生成小程序前端与云函数代码,再由我做联调与微调。整体流程如下:

【Vibe Coding 流程】 1. 需求描述 → 用自然语言向 Coze 讲清页面/交互/数据流,不断迭代完善PRD文档 2. 代码生成 → Coze 输出 wxml/wxss/js + 云函数 3. 真机预览 → 微信开发者工具扫码预览,记录问题 4. 对话微调 → 把问题用自然语言反馈给 Coze,迭代修复 5. 联调上线 → 接入高德 POI、配置意图识别,发布体验版

这套流程让一个以设计/产品为主的角色,也能在没有专业开发的情况下,两天内完成小程序从原型到可体验版本的落地。

4.3 实战技巧

这个项目最大的亮点不是某个功能,而是验证了"以产品+设计角色,用 Vibe Coding 独立交付一个小程序"的可行路径。传统开发与 Vibe Coding 的对比:

维度 传统开发 Vibe Coding
角色配置 产品+设计+前端+后端 多人协作 产品+设计 1 人即可驱动
需求→原型 Figma 画稿 → 前端还原 自然语言描述 → 直接生成可运行页面
迭代方式 改代码、提 PR、走评审 对话式微调,所见即所得
交付周期 数周到数月 两天内出MVP
能力杠杆 依赖工程人力带宽 用 AI 放大产品/设计的交付半径

在这个过程中,我作为"AI设计工程师"承担的核心工作是:

  • 需求结构化:把模糊的"做个吃饭小程序"拆成可被 AI 理解的页面、交互、数据流描述。
  • Prompt 编排:为 Coze 工作流编写稳定的意图识别 Prompt,保证 35 种场景识别准确率。
  • 结果校验:对 AI 生成的代码与 POI 结果做真机校验,过滤幻觉(如编造不存在的店名)。
  • 体验把控:转盘动画、过渡反馈、空状态等细节,根据实际体验不断优化迭代。
方法论提炼:AI 编程不是"让 AI 全自动写完",而是"人负责定义正确的问题与体验标准,AI 负责高速生成与试错"。人的角色从"写代码"升级为"写需求 + 验结果"。

4.4 高德地图 POI 接入

"真实存在的店"是产品可信度的底线。通过高德地图 POI 接口,按用户当前定位 + 场景关键词检索附近真实店铺,回填到转盘候选池。核心调用逻辑示意:

// 高德 POI 周边检索(示意) const res = await amap.placeAround({ location: `${userLng},${userLat}`, // 用户当前定位 keywords: sceneKeyword, // 如 "早餐" / "火锅" / "夜宵" radius: 3000, // 3km 内 types: "050000", // 餐饮服务大类 sortrule: "distance", // 按距离排序 offset: 20, page: 1 }); // 过滤无效 POI 后,填入转盘候选池 const candidates = res.pois .filter(p => p.business_hours && p.tel) // 在营业 + 有电话 .slice(0, 6); // 取 6 家填转盘
真实 POI 的价值:过滤"在营业 + 有电话"的店铺,从根本上杜绝了"推荐到闭店"的体验损伤,这也是产品上线后满意度能快速爬升的关键之一。

4.5 35 种意图场景识别

智能搜索的难点在于:用户不会输入规范的菜品名,而是说"清淡点""暖胃""适合带小孩""加班后来一顿"。我梳理了 35 种常见意图场景,映射到高德 POI 的关键词与类型,让自然语言能直接驱动检索。

意图类别 典型表达 映射 POI 关键词
清淡养生 "清淡点""暖胃""养生" 粥店 / 素菜 / 蒸菜
重口解馋 "来点辣的""重口""解馋" 川菜 / 湘菜 / 火锅
场景适配 "带小孩""加班夜宵""约会" 亲子餐厅 / 烧烤 / 西餐
饮食约束 "减脂""低卡""无糖" 轻食 / 沙拉 / 减脂餐
……共 35 类 覆盖早/午/晚/夜宵/下午茶 + 口味 + 约束 + 人数 分别映射对应 POI 标签

意图识别本身通过 Coze 的工作流 + 大模型节点实现:用户输入 → 意图分类节点输出场景标签 → 标签驱动 POI 检索 → 结果回填转盘。整套链路在云端完成,前端只负责展示与转盘动画。

35 种意图场景的提炼方法:从调研访谈的用户原话中,按"意图动词+场景名词"维度归纳整理,与AI沟通需求中共提炼出35种意图场景,例如:
  • "附近、便宜、吃饱" → 工作餐场景(面食、快餐等)
  • "开车、有包间、多人" → 聚餐场景(人均100+等)
  • "夜宵、便宜、近" → 夜宵场景(烧烤、小吃、甜品等)
  • "不想吃太饱" → 轻食/甜品/烧烤场景(边界case)

意图识别准确率:v2规划中引入自动评测,对35类意图做混淆矩阵量化。当前仅做人工抽样验证,未做系统性统计。

五、项目成果

小程序上线体验后,通过用户回访与小范围问卷,对推荐满意度做了前后对比。核心成果如下:

指标 上线初(v1) 迭代后(v2) 变化
推荐满意度 65% 85% +20pt ↑
"推荐店真实可去"认同率 58% 92% +34pt ↑
二次使用率(次周回流) 40% 73% +33pt ↑
满意度从 65% → 85% 的关键驱动:① 高德 POI 真实店铺过滤,消除"推荐闭店"的硬伤;② 35 种意图场景识别,让"模糊表达"也能命中;③ 收藏夹与评分让推荐越用越准,提升二次使用率与长期满意度。

六、项目复盘与反思

做得好的地方:

  • 先调研后设计,用"3 分钟决策阈值"这一量化洞察锚定产品形态,避免功能堆砌。
  • 坚持"真实 POI 兜底",把产品可信度建立在数据质量而非营销话术上。
  • 用 Vibe Coding 验证了产品/设计角色独立交付的路径,为后续项目复用。
  • 保留了"懂你的随机"这一平衡设计,没有滑向纯推荐或纯随机两个极端。

不足与改进方向:

  • 35 种意图场景主要靠人工梳理,覆盖度有限,长尾表达仍可能误识别,后续考虑用few-shot + 历史查询自动扩充。
  • 收藏夹评分的个性化权重目前偏简单(线性加权),数据量上来后可换成更稳健的排序模型。
  • 活动抽抽的 50 张卡片为静态内置,缺乏与季节/天气/城市的联动,是下一步迭代重点。
  • Vibe Coding 生成的代码可维护性一般,需在产品稳定后做一次结构化重构,便于长期演进。
核心复盘:"吃什么"看似是个小问题,真正难的是把"真实可去 + 场景适配 + 决策低成本"三件事同时做对。AI 与 POI 解决了"真实可去",意图识别解决了"场景适配",转盘交互解决了"低决策成本"——三者缺一不可。
本页