我用 AI 写代码做了个家庭调酒小程序,才发现配方库不是答案

先说结论：我一开始以为自己要做的是一个「鸡尾酒配方库」，后来发现这个判断不太对。

真正有用的东西不是「这里有 300 个配方，你慢慢看」，而是「你家里现在有这些酒和原料，今晚能做哪几杯，差一个材料还能做什么」。

这个差别听起来很小，实际做起来完全是两个产品。

我最近用 vibe coding 做了一个微信小程序，叫 Naniya。它现在还不是一个复杂产品，主要面向家庭调酒和新手调酒：先记录家里有什么酒和原料，再根据库存判断今天能做哪些经典鸡尾酒；如果经典酒谱不够，还会按长饮、酸甜、气泡这些结构给出自由调思路。

这篇不想写成「我做了一个产品，大家快来用」的广告。更像是一次复盘：AI 写代码到底帮了什么，没帮什么，以及为什么一个看起来很小的调酒小程序，最后难点反而不在页面，而在「怎么帮用户少做判断」。

首页不是随机推荐，而是先看酒库库存，再推荐当前可做的酒。

一开始我想做配方库，后来发现太浅了

最早的想法很普通：做一个鸡尾酒配方小程序。

这个想法很容易成立。因为平时在家调酒，经常会遇到几个问题：知道一个酒名，但不知道材料够不够；家里有金酒、柠檬、糖浆，但不知道能做什么；网上配方很多，看着都对，真正动手时发现缺这个缺那个；自己随手改出一杯还不错的，下次想复现时比例已经忘了。

如果只是站在「内容库」的角度看，这件事很好做：整理一批经典鸡尾酒配方，按基酒、风味、难度分一下类，加搜索，加收藏。听起来就是一个完整产品。

但我自己用了一阵之后，觉得这个思路有点偷懒。因为用户在家里调酒时，真正的问题不是「世界上有哪些鸡尾酒」，而是「我现在能做什么」。前者是百科问题，后者是决策问题。

酒库页：先把家里已有的酒和原料放进去。

这也是我后面把 Naniya 的核心往「酒库 + 匹配」上挪的原因。用户不是先去翻配方，而是先把家里已有的基酒、利口酒、葡萄酒、软饮果汁、糖浆、苦精香料、新鲜食材、装饰调味放进自己的酒库。

选择原料时既有系统原料，也可以补充自己的库存。

「今晚能做什么」比「配方大全」更像一个工具

代码里最核心的逻辑其实很朴素：一杯酒的所有配料，只要都能在库存里找到，它就是「我能做」。

这件事不玄学，但很符合家庭调酒的直觉：不是你收藏过这杯酒，也不是它看起来很热门，而是你家里现在真的够不够材料。

酒库结果页会把当前库存能做的经典酒款列出来。

如果用户家里只够做 30 款，那展示 30 款就够了。没必要一上来给他看 300 款。

做工具和做内容库的区别就在这里。内容库会下意识追求「更多」；工具应该追求「更少但更准确」。用户打开它，不是为了看你收录了多少，而是想少做一步判断。

我后来最喜欢的功能，是「补 1 样可做」

很多人在家调酒不是完全从零开始，而是卡在一个很尴尬的位置：家里已经有一部分材料，但永远差一点。

补材料建议：补一个材料，能多解锁几款酒。

所以 Naniya 的结果页里有一个「补材料」逻辑：先排除已经能做的酒；再看剩下的每杯酒缺什么。如果一杯酒只缺 1 个系统原料，就把它归到这个原料下面，最后按能多解锁多少杯排序。

这比单纯告诉用户「你不能做这杯」有用很多。因为「不能做」没有下一步，而「补这个可以多做几杯」是一个行动建议。

酒单里也可以直接看哪些酒是补 1 样就能做。

自由调不是让 AI 瞎编，而是把调酒结构拆出来

我后来又加了「自由调」。一开始这个名字听起来像是 AI 随机生成，其实我现在更愿意把它理解成「结构化组合」。

自由调会按长饮、酸甜、气泡等结构组合当前库存。

比如基酒是骨架，茶、果汁、气泡水可以做拉长，柠檬和青柠提供酸度，糖浆和蜂蜜负责甜度，薄荷、苦精、橙皮负责香气或收尾。

截图里的「金酒苏打水长饮」就是一个典型例子：金酒做骨架，苏打水做拉长，柠檬汁提亮，简易糖浆修边，薄荷叶收尾。它不是经典酒谱，但它符合一个家庭场景里的可执行结构。

家庭调酒很多时候不是「我要复刻某个权威配方」，而是「我今天手边就这些东西，能不能做一杯不离谱的」。这时候结构比名字重要。

还有一个更像灵感入口的功能：灵感调酒师

Naniya 里还有一个入口叫「灵感调酒师」。它不是让用户从酒名开始，而是从一句场景开始。比如「雨夜旧书店」「朋友来家里」「饭后清爽」「只用我的材料」。

我希望它解决的是另一个问题：有时候你不是缺配方，而是缺一个今天晚上想喝什么的开头。

这个功能会先读场景、情绪、酒感强度和材料约束，再生成一杯特调。生成结果不是结束，它可以继续进入「我的特调」记录里，后面你可以标记调过、改比例、保存成自己的作品。

所以它不是一个和酒库无关的聊天玩具，而是接在「库存、结构、记录」这条线上的灵感入口。

原创酒款不是社区噱头，而是记忆工具

另一个我保留下来的方向是原创酒款记录。它不是一上来就做大社区，而是先解决一个很小的问题：我自己调过什么，下次怎么复现。

原创酒款先记录基本信息：名字、描述、酒精度、杯型和标签。

有时候晚上随手调一杯，觉得还不错，第二天只记得「好像放了柠檬」和「糖浆别太多」。等下次想复现，已经完全不记得比例了。

风味、原料、步骤和失误，会比一句备忘录更容易复现。

所以这个功能里会记录酒名、描述、酒精度、杯型、标签，也会记录风味、原料、步骤和常见失误。我没有把它做成一个简单备忘录，因为调酒记录如果只写一句话，下一次还是很难复现。

vibe coding 帮了很多，但没有替我想清楚产品

这次最明显的感受是，vibe coding 对我的帮助不是「让我不用写代码」，而是把一些想法很快变成可点、可试、可推翻的东西。

比如我脑子里想：「用户先选基酒，再看配方。」这句话听起来没问题。但真的做成页面以后，会发现它还是像一本菜谱。用户还是要自己翻，自己判断缺什么。

后来我换成：「用户先录入家里有什么，再让系统告诉他能做什么。」页面一做出来，产品感觉就变了。它不再是一本配方书，而更像一个很小的调酒助手。

这就是 AI 写代码有价值的地方。它让很多抽象争论变成具体体验。以前做一个想法，可能要先搭项目、写页面、接数据、调样式，做到一半你已经懒得推翻它了。现在可以更快地把一个流程做出来，然后对着手机看：这个东西我自己会不会用？

但反过来说，AI 也不能替你判断什么是重要的。它可以生成页面，可以帮你补代码，可以把一个功能做得看起来像样。但「这个功能该不该存在」「用户到底为什么要点它」「这个入口是不是太绕」，这些问题还是得自己判断。

做到现在，我觉得它更像一个小决策工具

如果用一句话说 Naniya 现在是什么，我会说：它不是一个网页配方库，而是一个按你的酒库推荐鸡尾酒的小程序。

它目前主要解决几件事：记录家里已有的酒和原料；根据库存计算今天能做哪些经典酒；按长饮、酸甜、气泡等结构给出自由调思路；告诉你补哪一个材料可以多做几款；记录自己的原创酒款、风味、原料、步骤和失误。

一开始我以为我要做一个「更多配方」的东西。现在我更想做的是一个「少一点选择焦虑」的东西。

如果你也在做类似的小产品，我会建议先别急着堆功能。先找一个特别具体的场景，问自己一句：用户打开这个东西的那一刻，他到底想少做哪一步判断？

这个问题想清楚了，很多页面和功能反而会自己变少。

我把这个小程序叫 Naniya，现在可以在微信里搜「Naniya」试试。理性饮酒，未成年人请勿饮酒。家庭调酒是一个生活兴趣，不是劝酒。