CASE 02 · 今天吃什么 AI小程序

02BACKGROUND

背景

每天做饭"吃什么"的决策焦虑

// 问题

做饭这件事，最难的不是"怎么做"，而是每天都要重新回答一次"做什么"。打开菜谱 App 翻半天，看完一堆"美食发现"还是没决定，最后往往又点了外卖。现有工具的重心在内容与带货，没有一个真正替你拍板的。

// 痛点清单

决策瘫痪：给的是"更多选择"，不是"确定答案"
不贴场景：没有"按人数 / 忌口 / 时令"的组合逻辑
采购难接：菜单有了，还得自己算要买多少
工具不纯粹：多数 App 重心在带货，而非帮你做决定

用户故事：作为家里的做饭主力，我希望打开小程序选好人数和忌口，就得到今天午晚餐的确定答案，并附一份按人数算好的采购清单——好让我别再为"吃什么"纠结半小时。

03SOLUTION

方案

一条纯前端的"摇骰子"决策流水线

// 流程

① 选人数1 / 3 / 5+ → ② 选标签忌口 / 偏好 → ③ 读时令系统月份 → ④ 生成双菜单午 + 晚 → ⑤ 采购清单按人数聚合

// 技术栈

前端：微信小程序原生（WXML / WXSS / JS）
引擎：utils/engine.js 纯算法模块，零后端、离线可用
数据种子：152 道菜谱 / 14 个标签 / 12 月时令规则（静态 JSON）
约束分级：hard（过敏 / 宗教）永不放宽；soft（健康类）仅评分加权
保差机制：换一批传 excludeIds，评分降权 −1000 + 随机扰动

// 关键决策

为什么纯前端、零后端？MVP 的目标是"快速验证一件事是否成立"。把逻辑全放客户端，不用起服务、离线可跑，也不涉及用户数据上云的隐私压力。

为什么 hard / soft 严格分离？过敏、清真这类是安全红线，绝不能因为"没有候选"被系统自动放宽；而健康类偏好只是加分项，永远不该阻断结果。这条从架构上就锁死了。

04APPLICATION

应用

三类人群的典型使用方式

// 使用场景

3 人家庭晚餐：选 3 人 + 无忌口，直接得到午晚双菜单与采购清单
独居青年：1 人场景，算法自动缩减份量与采购量
控糖 / 健身：勾"低GI / 高蛋白"软标签，符合条件的菜优先靠前
过敏 / 宗教忌口：勾 hard 标签，含相关食材的菜全部排除并明确提示

// 典型用户路径

路径1（日常）：打开小程序 → 选人数 → 选标签 → 点"抽今日菜单" → 看双菜单 + 清单 → 一键复制去采购

路径2（不满意）：点"再摇一次" → 得到一份与上次零重叠的新菜单（保差机制保证）

"它不给你更多选择，而是帮你更快做决定——这才是'今天吃什么'真正缺的东西。"

05RESULT

效果

MVP 到 R6.5 的迭代数据

152

菜谱库（八大菜系）

186

引擎自测通过 / 0 失败

14

标签维度（hard / soft）

// 迭代前后对比

维度	MVP	R6.5
菜库规模	110 道	152 道，覆盖八大菜系
营养维度	无	今日营养小结（蛋白/碳水/纤维）
菜谱详情	一句话概述	有序步骤 + 每菜营养参考
引擎自测	162 通过 / 0 失败	186 通过 / 0 失败，P0=0

// 定性反馈

自我评价："它没有让我'发现更多喜欢的菜'，而是把每天半小时的纠结压缩成一次点击。对一个常年做饭的人来说，这才是最实在的价值。"

06REVIEW

复盘

从"美食发现"收敛为"决策支持"

// 做对了什么

先定"不做什么"：把 Won't Have 清单锁死（不做社区、电商、视频菜谱），MVP 范围极小
契约先行：Spec 锁定函数契约与 AC1–AC15 验收标准，改代码不改契约
约束分级：hard / soft 从架构上分离，杜绝"软偏好阻断结果"这类隐患

// 踩了什么坑

菜库太薄：早期 110 道容易重样，R5 扩到 152 道并保证 90%+ 是家常菜
按钮重复：结果页一度上下各有一个"再摇一次"，UI 去重后只留底部主 CTA
细节欠打磨：12px 字号偏小、间距非 4px 倍数，R5 统一整改

// 下一步迭代

后续计划：
- 铺满 152 张手绘菜图（当前 emoji 兜底）
- "高纤维"标签进 UI 目录，让用户可勾选
- 接入微信云开发，让历史 / 收藏跨设备同步

"工具的价值不是给你更多选择，而是帮你更快做决定。"