为什么"一周菜单"App 总是先假设你家冰箱是空的

打开任何一款排菜单的 App，第一屏问的几乎都是同一个问题：这周想吃点什么。它几乎从不问你家冰箱里已经有什么。这不是产品经理漏掉的一个勾选框。这就是这类产品从骨子里的设计方式——先把菜单排好，再指望你的厨房去配合它——而这正是为什么排完一周菜单，购物清单上列的常常是家里本来就有的东西。

菜单是从菜谱库里拼出来的，不是从你家厨房里长出来的

大多数排菜单的 App，底层逻辑都差不多：选个菜系或者饮食偏好，选好要吃几顿，App 就从自己的菜谱库里挑几个，把每道菜要用的食材拼成一张购物清单。整个过程完全不知道你家冰箱此刻放着什么，因为压根没有哪一步问过。选菜的标准是花样够不够、营养够不够、照片好不好看——这些标准本身没问题，只是跟你家冰箱门架上那半个洋葱、那瓶还剩小半的咖喱酱，没有半点关系。这份菜单自成一体，逻辑完整。只是它是给一个从零开始的厨房排的，而你家的厨房从来不是从零开始。

购物清单，是这个漏洞第一次露出来的地方

购物清单是一份菜单里，人真正会照着去做的那部分，所以漏洞也是先从这里冒出来的。清单上会列着洋葱、大蒜、米、橄榄油——恰恰是大多数厨房里本来就常备着、只是量多量少的东西——因为 App 拼出来的是一份「完整需要多少」的清单，而不是「还差多少」的清单。这跟这个网站之前讲过的重复买东西是同一个结构性问题：需要知道家里有什么的那一刻，从来不是排菜单被写下来的那一刻，所以周日下午排出来的菜单，根本看不见周二晚上冰箱里真实的样子，两者从清单第一行开始就已经对不上了。

一个「家里已经有」的勾选框，改不了方向

有些 App 会在生成购物清单之前，让你先勾一遍家里已经有的东西，听起来像是解决了这个问题。实际上这只是一次性的快照，只在你坐下来排菜单的那一刻拍了一下，不是持续更新的记录。等到周三，你勾掉的那个洋葱早就用完了，没想到要提的鸡蛋反而买回来了，这份勾选清单跟它当初依据的那份记忆一样，早就过时了。一周只核对一次，本质上还是要求某个人躺在沙发上，准确回忆出橱柜此刻的状态——跟前一天晚上凭印象写购物清单，是同一种失败方式，只是外面套了一层更好看的表单。

菜单在往前排，你家厨房在往后追

一份周菜单，要求你在某个具体的周日下午，提前猜中接下来五个晚上想吃什么、能做出什么，然后照着这个猜测去采购，仿佛它已经是既成事实。真实的一周从来不会乖乖配合周日那个猜测：朋友约了出去吃饭，周二加班到很晚，某道菜临时发现少了一样没人想起来要检查的食材。这些意外不会让那顿没吃成的饭所对应的食材凭空消失——它们照样会被买回来，塞进冰箱，只是从此跟当初买它们的那个理由脱了钩，一直放到有人临时拿它们凑一顿饭，或者最终被扔掉。菜单本身没有错，它只是天生朝着一个看不见家里现状的方向在跑。

真正从冰箱出发，需要的是什么

要补上这个缺口，靠的不是一份更精致的菜单模板，也不是表单上再加一个字段。而是把两件事的先后顺序整个倒过来：App 得先持续知道家里到底有什么，再让菜谱跟着这份现状走——而不是让你在排菜单的路上，顺手交代一遍自家厨房的情况，交代完，菜单其实早就定好了。这跟一个「家里已经有」的勾选框，是完全不同性质的功能。真正被记录、被跟踪的，得是食材本身，而不是那份菜单，而且这份记录得在两次排菜单之间也一直保持更新，而不是只在每次坐下来排菜单的那一刻才被想起来。

这正是 Munch 想解决的问题。App 里没有一个单独的「排菜单」环节需要你先交代一遍家里有什么——冰箱、冷冻室和常温储藏，本来就是全家人买东西、做饭的时候一直在更新的同一份记录，每样东西入库时都带着数量和存放位置。菜谱是照着这份现有的记录去分组的：家里现在就能做出来的，和差一样食材就能做出来的。它不需要提前知道你下周想吃什么才能今晚派上用场，因为它从一开始就没打算让你提前一周排好计划。

这不是说周菜单这种做法本身不好——喜欢这种规律感的人，这套方法依然有用。真正出问题的是产品的设计方向，不是放弃它的人不够自律。把箭头倒过来——从冰箱里已经有的东西出发去想能做什么，而不是从一份菜单出发去列购物清单——买菜这件事就会重新变成补上真正、具体的缺口，而不是给一个其实从没空过的厨房重新囤一遍货。