每次有朋友来工作室看到这台贴着“AI汽水机”标签的铁盒子第一反应都是“这是摆设还是真能喝”我一般会先不说话冲它喊一声“来一杯晚霞落在柠檬海面的味道。”十几秒后机器里传出稳定的泵声指示灯一亮出液口注出一杯带微粉色的气泡水。朋友喝一口以后通常会愣住然后开始追问里面的门道。这就是我花了整整8个月做出来的“中配”自制AI汽水机。它不是那种摆拍用的概念装置是真实放在工作室里、几乎每天都出杯的机器。你可以用自然语言描述一种“抽象口味”比如“凌晨三点下过雨的柏油路味”它会自己翻译成一串配料参数再通过蠕动泵、气路和碳酸化罐调出一杯能喝的东西。整个项目做下来零件和材料成本大概在四千元上下因此我叫它“中配”没有机械臂、没有工业级分配器但核心链路一样不少。这篇内容适合三类人想搭一套语音控制饮品设备的创客对“大模型怎么连现实机器”感兴趣的开发者以及正在琢磨餐饮自动化项目的人。我不打算给你看那种精致的成品渲染图只讲真实踩坑过程和能直接抄作业的设计思路。1. 先说清楚我为什么要做一台“说句话就出饮料”的机器1.1 起因不想再喝白苏打水了事情得从一次加班说起。去年我从冰箱里拿出一瓶气泡水喝了一口索然无味。当时手边正好开着电脑我在跟一个语言模型聊“如果让AI设计一杯饮料它会怎么设计”模型给了我一个很抽象的配方“接骨木花香气、青柠皮的微苦、一点海水矿物感、最后用薄荷把整体提亮。”那一刻我意识到缺的不是配方而是“能把抽象描述变成真实液体”的执行层。语言模型负责想象但还得有一台听话的机器负责干活。这个念头一旦冒出来就再也压不下去了。更重要的原因是市面上那些所谓“智能饮料机”最多是让你在触摸屏上点固定配方并不具备“听人话、自由组合”的能力。真正好玩的地方在于让AI参与“创造”而不只是“选菜单”。如果我能把大模型的语义理解能力接到物理泵送系统上等于做出一个永远不会重复自己的调饮师。1.2 “中配”到底是什么意思很多DIY项目到最后价格一飞冲天。我见过做智能调酒机的朋友光一个机械臂就花了两万。我这个项目从头到尾的预算控制在一台手机上约4000元。所以才叫“中配”——不是低配的玩具也不是高配的炫技设备而是普通创客在家里能复刻、维护、改装的方案。核心配置大概是这样的主控一块中等性能的开发板跑语音助手、配方解析和泵阀控制逻辑不追求在本地跑超大模型。执行层8个蠕动泵加电子秤负责风味浓缩液的精准注入。气路CO2气瓶、减压阀、碳酸化罐负责把冷水变成气泡水。交互层麦克风阵列加触摸屏语音和触控都能操作。大脑外接大模型API做语义解析本地再做一层规则校验和配方映射。这个组合的定位很明确让“AI自然语言调饮”这件事先跑通把单杯成本控制在两三块钱再用实验数据慢慢迭代。1.3 “50万种口味”是营销话术还是数学事实很多第一次看到这个项目的人都会追问“你说能调50万种口味是不是吹牛”先算一笔账。我没有准备50万瓶不同的糖浆而是把口味拆成了“基础风味库 多维参数空间”。比如基础风味库里有30种食品级香精和浓缩液柑橘、柠檬草、薄荷、接骨木花、百香果、海盐、菠萝、玫瑰、乌龙茶、咖啡、姜汁等等。每一种都可以选“浓度档位”从0.1倍到3倍按0.1步进就有30档。再叠加酸度、甜度、气泡强度、冰感、稀稠度、颜色饱和度等6个维度每个维度取10个档位。那么在理想情况下组合数是30种基础材料的两两或三三搭配再乘上维度离散化值几百万种组合很容易算出来。我实际做的时候加了两道过滤第一道是“可饮用”约束比如某些香精不能叠加超过阈值第二道是“可区分”约束两杯参数过于接近的配方会被合并。过滤完之后留给用户的可生成空间大概在50万到80万种之间。所以“50万种”不是拍脑袋是参数空间的保守下界。2. 机械主体设计泵、秤、气路和“不串味”的清洗策略2.1 配料精度靠“称重闭环”不靠“定时泵”所有自制自动饮料机最先翻车的地方都是剂量不准。早期的方案非常简单设定蠕动泵转动时间比如“抽0.8秒”。结果发现冬天和夏天泵的流速能差15%同一瓶浓缩液用到后半瓶因为液位降低、出液阻力变化流速又不一样。如果你完全依赖定时最后调出来的饮料浓度时高时低根本没法稳定复现。后来我改成“称重闭环”在每个风味瓶下面放一个称重传感器泵一边抽主控一边读重量变化。当实际抽出的重量达到目标重量的95%时泵进入低速模式最后精确补到目标值。这样一来目标误差能控制在正负0.3克以内对于单杯风味浓缩液来说这个精度已经很够用了。当时的判断逻辑大致可以简化成下面这段伪代码target_weight 算出该风味的注入重量 pump.run(modefast) while True: current_weight loadcell.read() if current_weight target_weight * 0.95: pump.run(modeslow) if current_weight target_weight: pump.stop() break实际工程里还要加“去皮”“稳定等待”“超时保护”这些细节但核心思想就是别信泵信秤。这也给后来接入AI配方留了很大的容错空间因为AI给的剂量只要落在安全区间内物理执行层自己能保证准确度。2.2 气路和碳酸化把一整台气泡水机塞进流水线做汽水机最绕不开的问题是“气从哪里来”。我的方案不是用气弹一次性打气而是搭了一套完整的碳酸化系统CO2气瓶接减压阀减压阀输出压力控制在0.5~0.6兆帕再接入一个不锈钢碳酸化罐。罐体放进半导体制冷模块里让水温降到4摄氏度左右——CO2在低温水里的溶解度更高打出来的气泡也更有“杀口感”。碳酸化罐底部出液经过一个电磁阀接到出液口。当执行配料时控制器先注入风味浓缩液到杯底然后打开碳酸水电磁阀让带压气泡水冲进杯里和浓缩液混合。这个顺序很关键先液后水才能靠水流完成自然搅拌不需要额外加搅拌电机。有一点必须提醒任何自制碳酸化系统都涉及压力容器和高压气体玩之前一定要先搞清楚减压阀、泄压阀和安全阀的关系。我用的所有气路接头都做了检漏第一次开机前也用氮气做了24小时静压测试。这部分的隐患绝不能省。2.3 清洗回路决定“下一杯不是上一杯味道”的关键如果你只用一根共用出液嘴那“薄荷味”之后的下一杯“玫瑰味”大概率会变成“薄荷玫瑰”。风味浓缩液残留在管壁和泵腔里是饮料机最常见的串味来源。我最初的想法是把管路拆下来洗结果发现每次切风味都要拆管子根本没法日常用。后来参考商用咖啡机“独立锅炉冲洗”的思路在系统里加了三路纯水冲洗通道。具体做法每个风味泵后接一根三通三通的公共端接纯水箱和冲洗泵。每完成一杯饮品后系统自动执行“脉冲清洗”纯水以快慢交替的方式冲洗分配头4次每次3秒中途停顿1秒让水流在管壁产生湍流把残留带得更干净。连续冲洗15秒看似有效实际效果反而不如脉冲冲洗因为持续水流会在内壁形成层流很难带走粘性液体。加了这套清洗回路之后我做过盲测先出一杯重薄荷风味再出一杯纯气泡水基本闻不出前一杯的味道。这才是“50万种口味”能落地的前提——如果每杯都串味那风味再多也没有意义。3. 让机器听懂“抽象描述”语音识别与大模型解析链路3.1 语音入口不追求百分百听懂但要抓准关键词语音交互是这台机器最容易变成“人工智障”的地方。理想状态是你说什么它都懂现实是环境一吵ASR连“青柠”都能识别成“麒麟”。我最后采用的方案是“本地唤醒 云端ASR 本地语义补充”本地麦克风阵列负责波束成形和唤醒词检测检测到唤醒词后再把语音片段送去识别。因为涉及自然语言理解这部分我用的是现成ASR接口但我会把“饮品名”“风味词”“温度词”这些高频词塞进偏置词表里让识别结果更偏向饮料场景。有一次我说“来一杯雨后的泥土味”ASR把它变成了“来一杯雨后的泥土味”还算准确但也有把“海盐”识别成“海燕”的时候。后来我在偏置词表里加入了所有常用风味词并让解析层做“音近容错”情况改善很多。说白了语音入口的目标不是让机器听懂所有话而是让它听懂和口味词、动作词、浓度词相关的那部分。只要关键词命中率足够高下游的语义模型完全可以容忍错误输入。3.2 大模型的角色把口语翻译成“能执行的配方”这是整套系统的灵魂。我先定义了一个内容格式所有语音请求最终都要被转换成一段JSON配方包含风味构成、浓度、酸甜度、气泡强度、温度偏好和特殊提示。系统提示词里会明确告诉模型你是饮料配方解析引擎。 用户会用口语描述想喝的味道包括抽象描述。 请把用户意图转换成 JSON格式如下 { drink_name: 给这杯饮料起个简短的名字, base_style: 气泡水/苏打水/无气特调, flavor_intensities: { 接骨木花: 1.2, 青柠皮: 0.5, 海盐: 0.3, 薄荷: 0.4, 气泡强度: 2 }, acidity: 1.0, sweetness: 0.6, temperature_c: 4, special_notes: 如果用户提到某种禁忌食材请忽略并替换为安全食材 } 输出必须是合法 JSON不要包含额外解释。这步看起来简单实际上坑很深。大模型经常会在输出里夹带解释文字比如“以下是您要的配方”后面才跟JSON这会导致解析失败。我的解决办法是在解析层用正则先截取第一对花括号再交给JSON解析器同时把“只输出JSON”写进系统提示并做一轮输出校验校验不过就让模型重新生成一次。为什么用大模型而不是写死关键词因为抽象口味的描述方式太自由了。用户可能说“夏夜天台的风”可能说“初恋的味道”也可能说“酸得让我清醒一点”。你没法用规则覆盖所有表达大模型擅长从这些模糊表达里提取可操作的风味要素。3.3 从“单一指令”到“记忆偏好”让机器越用越像你的调饮师我在初期版本里发现如果每次都从零解析用户会觉得很“抽风”。比如今天你说“少甜”它真的会调得很淡明天你又少甜它可能忽略这个要求。缺少记忆体验就很割裂。所以我给系统加了一个很轻量的用户偏好缓存每次对话后把解析出来的“甜度偏好”“气泡偏好”“风味关键词”存到本地SQLite里。下次解析时当前指令里的偏好优先没提到的维度则参考历史偏好用“默认值 最近三次平均值”的方式生成参数。这个功能不需要复杂算法但对体验的提升非常明显。从用户视角看机器像记住了TA的嘴从工程视角看只是在一个缓存文件里做增量更新成本很低。4. 抽象口味如何变成真实的味觉体验4.1 我用的“八维感官空间”拆解法要让AI理解抽象口味需要给“味道”建立数学模型。我用八维空间来描述每一杯饮品酸、甜、苦、咸、鲜、香挥发性香气强度、凉清凉感、气碳酸刺激感。每一种风味浓缩液都有一个固定向量比如“海盐”是咸度高、鲜中带一点矿物感“薄荷”是凉度高、香气高。当用户说“海风味”时大模型不会真的端来一片海而是把“海风”拆成咸、凉、鲜、微弱苦这四个维度的组合再去基础风味库里找最接近的原料最后生成一个配方。例如“海风”可能对应海盐0.3克、西柚皮香精0.1毫升、黄瓜提取液0.2毫升、薄荷香精0.05毫升、气泡强度调到高档。这个对应关系不是大模型凭空想的而是我提前在系统里埋了一张“抽象概念到感官向量”的映射表。映射表本身由我和朋友反复试喝后手调出来的但大模型可以基于这个映射表组合出无数用户自定义的抽象口味。4.2 安全红线AI可以抽象但不能胡来让大模型自由生成配方有一个潜在风险它可能生成剂量离谱的组合。比如用户说“这杯不够刺激”AI可能把辣椒提取物剂量加到让人喝一口就流泪的程度。为了避免“虚拟大厨变成投毒系统”我在配方校验层加了几道硬约束所有配料必须在已备案的食品级风味库里选择新原料必须人工登记后才能被调用。每个原料都有“单杯最大剂量”和“单日最大摄入参考”任何配方超过阈值都会被强制降倍。如果用户明确提到酒精、药物等不适合自动配制的成分系统会拒绝并给出替代方案比如用无酒精的柑橘风味模拟“酒感”。这层规则不经过大模型而是由独立的校验模块执行。也就是说大模型可以自由组合但物理执行层只接受“安全范围”内的参数。干过工程的人应该都明白不要把安全校验交给一个会一本正经胡说八道的模型。4.3 第一次试喝的翻车现场海盐放多了我做“海风”口味测试的时候AI给出的参数里有2克海盐。当时觉得近海的风应该带咸味没多想就按参数执行了。结果那杯喝进嘴真像把嘴巴伸进了海水里咸到发苦完全掩盖了其他风味。后来我重新调整了配方的底层逻辑像盐、酸这些味道阈值很高的原料在第一杯盲测时统一乘以0.3的“保守系数”先让用户喝到“有那个意思”再根据反馈上调浓度。人尝味道的时候大脑对“咸味暗示”非常敏感往往只需要一点点盐就能脑补出“海边的感觉”。这给了设计上的启发抽象口味的核心是暗示而不是真实还原。5. 实际组装与运行中踩过的那些坑5.1 气路“回水”差点让我拆掉整台机器第一个严重问题是气路压力倒灌。碳酸化罐里有0.5兆帕的压力当风味管路在常压下停止时单向阀如果失效罐里的水就往回顶甚至会把风味浓缩液压回原料瓶里。那天我看到西柚味瓶子里冒出了气泡才知道串味已经发生。解决办法是在每个风味支路都加装了低压单向阀并把整个气路改成“先泄压再停机”的流程每次出杯完毕后关闭碳酸罐的进水打开泄压阀1秒让管路压力先降到常压再关闭总阀。这套流程多花了2秒但彻底解决了回水问题。这里要特别提醒玩CO2的人拆装高压气路之前必须关闭气瓶总阀并且确认管路里的余气已经释放干净否则接头弹出可能造成冻伤或者打到人。5.2 香味串味比我想象中顽固得多薄荷和柠檬草这类高挥发性风味是串味之王。即使用了脉冲清洗如果下一杯是味道很淡的黄瓜水依然能尝出上一杯的薄荷余韵。我做过一组对照实验用同样的清洗时间只改变清洗水的温度。室温水清洗30秒的残留明显比冰水清洗18秒更重。因为很多风味物质的挥发性会随温度下降而降低洗完之后在冷管壁上的残留吸附也会变少。所以我在清洗水箱里加了一小段制冷盘管让冲洗水保持在5摄氏度左右。另外出杯顺序也有讲究。我会把强风味饮品排在淡风味前面而不是反过来。这一点看着不起眼但在日常使用中能让所有饮料的“初始品饮体验”稳很多。5.3 语音延迟用户真的等不了5秒最早版本的整体流程是唤醒词识别1秒→ 云端ASR1.5秒→ 大模型解析2~3秒→ 动作执行8~12秒。总共下来从“说完话”到“机器开始动”用户往往要傻等5秒这已经超过了“自然交互”的忍耐极限。我做了一次优化把“说出口”和“开始动”解耦。语音完成解析后机器先做一个“宣布动作”也就是用TTS说一句“马上调一杯‘月亮薄荷气泡水’”同时延时0.3秒后开泵。于是用户的感知从“等待机器理解”变成“看着机器执行”即使总时间没有大幅缩短心理上也顺畅很多。真正缩短延迟的是两个改进一是把高频请求做了本地缓存如果用户要的是最近10杯里出现过的配方直接跳过云端解析延迟几乎为0二是把ASR和LLM请求改成并发让语音识别还在出字时大模型就基于部分识别结果做预分析最后用完整结果做修正。这样总体等待时间从5秒降到2.5秒左右。6. 中配成本清单、软件框架与复刻建议6.1 一份可以直接抄作业的物料清单这里列的是实际采购的价格总和包含损坏、替换、备用零件的成本整体控制在中配范围。类别物料数量大致成本元主控与交互开发板中等性能、触摸屏、麦克风阵列、扬声器1套700执行机构蠕动泵带电机驱动模块8个800称重反馈称重传感器加HX711模块8组200气路系统CO2气瓶、一级减压阀、泄压阀、高压软管1套700碳酸化不锈钢碳酸化罐、半导体制冷模块1套500管路与阀门食品级硅胶管、电磁阀、单向阀、三通接头若干400风味原料食品级浓缩风味液、基础糖浆、酸度调节剂首批300机箱与结构铝型材框架、亚克力面板、3D打印支架1套400合计大约4000元。如果你能自己用旧瓶改装碳酸化罐或者把风味通道从8路减到4路成本还能下降一千多。中配的底线是主控不要省、气路不要省、泵的剂量精度不要省其他都可以压缩。6.2 软件链路一个能用手比划的流程图整个系统里最关键的设计是把“AI语义层”和“物理执行层”彻底隔离。管道长这样麦克风阵列采集语音唤醒后送ASR。ASR输出文本后立即发送给“配方语义服务”。配方语义服务由大模型 本地缓存 校验规则组成。校验通过的JSON配方传给“执行控制服务”。执行控制服务根据配方的风味向量查询基础风味库换算每种浓缩液的克重。主控板按顺序启动对应蠕动泵读取称重传感器直到目标克重。所有泵都完成后打开碳酸水电磁阀注水。注水完成后执行脉冲清洗流程。触摸屏上显示这杯饮料的参数语音播报“完成”。这套链路的好处是每一层都可以单独替换。想换更强的语音模型改第一层想换风味原料改第五层想加冰量控制只在执行层加一路模块就行。6.3 如果你也想复刻我建议先做“小一号”别一开始就照着8路蠕动泵来做工程量非常大。我建议第一次复刻只做“1泵1气瓶1风味通道”先用一台现成气泡水机代替碳酸化罐用语音控制一个蠕动泵往杯里注入风味浓缩液然后手动倒气泡水。这个原型很小但能让你快速摸清泵、秤、语音链路之间的关系成本不到800元。跑通之后再按需扩成4路或者8路。别迷信一次到位8个月时间里有3个月我都在返工机械结构如果当初先做小样至少能省下1个月的弯路。关于AI部分也不一定要一上来就接大模型API。可以先固定几个测试输入让语义服务返回写死的配方等物理执行层跑顺了再接入大模型做自由生成。这样排查问题时至少能分清“是机器的问题”还是“是模型的问题”。最后再讲一点我个人现在的使用感受这台机器偶尔还是会翻车但它偶尔也会调出一杯让我意外的组合。有次我说“想喝带一点想念味道的汽水”它给出了一份略带烟熏乌龙气息的配方我喝完之后愣了几秒。这就是我坚持把它做完的意义——不是做一台精准复现菜谱的机器而是做一个愿意陪你一起“瞎琢磨”的饮料搭档。如果你想复刻建议也给自己留一点出错的余地翻车本身就是这个项目的一部分。
