耗时8个月我终于把这台AI汽水机从草图变成了能摆在桌面上正常出品的机器。最初的想法其实特别朴素家里来客人时总要问一句喝什么与其让他们在可乐雪碧里二选一不如做一台能听懂人话、现场调制的机器。做到第三个月的时候我意识到这个项目真正的难点不在硬件、也不在AI而在如何把一句抽象的话变成一杯能喝的东西。比如你说来一杯潮湿苔藓味的清晨它得知道要用什么配料、加多少量、气泡打多强、温度定在几度。这背后是一套完整的语义解析、配方生成和流体控制流程。这台机器的定位是中配意思是不追求商用级精度也不堆顶级硬件而是用大多数DIY玩家能拿到的物料和工具把AI能力和实体饮料机完整打通。整机下来硬件成本控制在三千元以内但可以实现50万种以上的配方组合全部通过自然语言交互完成。适合正在做AI硬件落地方向的开发者、想试水智能饮品的创业者以及喜欢折腾的DIY玩家参考。下面我会把整体设计、关键部件的选型逻辑、AI链路的实现、口味库的构建方式以及8个月踩过的所有坑一次讲清楚。1. 先说清楚一台会说人话的汽水机到底怎么定义1.1 这台机器解决的三个核心问题第一个问题是交互方式。传统饮品机用按钮、触摸屏或者手机App本质上都是从有限菜单里选一个。但语言调制意味着用户可以用任意自然语句描述需求这是完全不同的交互范式。比如你说来一杯清爽点、带点果香的它要能处理清爽果香这种模糊词也要能处理三份酸两份甜、多冰这种带数字的精确指令。第二个问题是配方生成。一台饮料机只要有几个原料罐排列组合就很容易过万。但真正难的是生成出来的配方必须好喝且安全。大模型很擅长做创意发散但它不会自己知道一个300毫升的杯子里最多加多少酸味剂也不会知道某些风味原料叠加会产生奇怪的味道。所以配方生成不能只靠大模型裸奔必须有一套规则层做约束。第三个问题是控制执行。AI算出一个配方只是开始接下来要把配方翻译成泵的启动时间、冰水阀的开启时长、气瓶的充气压力。这个环节看起来简单实际上泵的流量偏差、管路残留、温度波动都会让结果面目全非比算法本身更考验工程能力。1.2 50万种口味不是营销话术是组合数学我在项目立项时专门算过这个数字。粗算模型是20种风味基底包括各种糖浆、果汁浓缩液、酸味剂、盐溶液等每种基底在配方中的用量分成0-5共6档。杯子的基础水位分为5档气泡强度分为4档温度分为3档。只算风味基底这一个维度组合数就是6的20次方这已经是天文数字但这不是合理的计算方式因为真按这个来会有大量什么都不加和全是酸的无效配方。合理的算法是给每种基底一个可用的档位范围同时设定最多叠加几种基底的上限。比如一次调制最多选3种基底每种基底有4个可用档位那么风味组合就是C(20,3)乘以4的3次方约等于341亿还是太大了。实际上还要过滤掉互斥组合。如果设计成2个可选风味层1个可选的调节层酸/甜/咸/苦/鲜每层各有几十个选项乘上气泡、温度、浓度、水量这4个维度各5-10档50万是一个非常保守的数字。在系统里我用了种子的方式生成配方ID每个配方ID对应一份完整的参数表所有有效参数组合的期望值就是52万种左右。1.3 为什么是抽象口味而不是传统口味市面上所有饮料机都在做传统口味可乐味、橙子味、水蜜桃味。这些口味用户太熟悉了任何合成糖浆做出来的版本都会被拿来和原版对比结果往往是不像、不好喝。抽象口味则完全绕开了这个比照。你说来一杯雨后的青石板味没有人知道标准答案是什么只要整体风味能让人联想到潮湿、清新、带一点矿物感就是成功的。而且抽象口味天然适合AI来发挥。大模型的训练数据里包含了大量跨模态的知识它知道雨后通常和泥土、水汽、草本相关也知道青石板会让人联想到矿物质、冰凉、微苦。把这些联想映射到可用的原料组合上就是AI做饮品配方最有价值的地方。传统口味是复刻抽象口味是创作后者给AI留出了极大的发挥空间。2. 中配硬件方案把钱花在真正影响口感的地方2.1 整体系统架构水路、气路、电路、AI四层我一开始犯过一个错误就是试图把机器做成一个整体再调试。结果管路漏水、电路干扰、泵堵塞同时爆发的时候根本没法定位问题。后来我把系统拆成了四个独立层级每一层单独测试通过后再联调。水路系统负责把水变成带有特定温度和流量的基液包括储水箱、水泵、半导体制冷模块或冰块仓、流量计。气路系统负责把食品级二氧化碳充进水里产生气泡核心部件是CO2气瓶、减压阀、电磁阀、气泡罐。电路控制系统包含主控板、继电器或MOS管驱动板、传感器采集模块、电源系统。AI系统则是独立的计算单元负责语音识别、语义理解和配方生成通过串口或网络把配方参数下发给主控板。四层分离的好处是测试时可以单独验证每一层。比如纯粹测水路时可以用手动按钮触发泵看流量计读数是否准确测AI系统时可以把配方输出直接打印到屏幕上不经过实际执行。等到每一层都稳定了再逐层合并。2.2 关键部件选型与理由主控板我选的是ESP32-S3原因很实际它自带Wi-Fi和蓝牙方便和AI计算单元通信GPIO口数量够用能同时控制6路泵、4个电磁阀和多个传感器价格便宜几十块钱就能买到开发板坏了不心疼。如果追求更强性能也可以用树莓派Zero 2 W直接在上面跑语音识别但对我来说把AI计算和实时控制分开更可靠。泵的选择是这个项目里最需要较真的部件。饮料原料的添加量通常在5到50毫升之间精度要求到正负1毫升。普通直流水泵流量太大且不稳定我最终用的是蠕动泵。蠕动泵的优势是液体只接触软管、不接触泵体清洗方便而且流量相对均匀可以通过控制转速和运行时间相对准确地控制体积。当然蠕动泵也有一个问题就是软管用久了会磨损变形流量会漂移所以每隔一段时间需要重新校准。流量计我用的是霍尔式流量传感器配合泵的运行时间做双重校验。其实对中配机器来说单靠泵的时间和出厂校准数据也能凑合用但实测下来不同的糖浆黏度差异会导致实际流量偏差超过15%。加了流量计之后每次加注都有实时反馈主控可以做闭环控制。CO2气路方面我用的是标准食品级二氧化碳气瓶加减压阀出气压力稳定在0.3到0.4兆帕。气泡罐是关键水要先在罐体内和CO2充分混合再输出如果只是简单地把气体吹进水里气泡很快就会散掉。温度控制我用的是半导体制冷片加循环泵把储水罐的水温维持在4到8摄氏度。这个温度范围是口感最好的区间因为CO2在低温水里的溶解度更高气泡感也更持久。2.3 中配的取舍逻辑哪些能省、哪些不能省中配的真正意义在于知道在什么地方妥协。我个人总结出来的经验是凡是直接接触饮品、影响食品安全和口感的部分都不能省凡是只影响交互体验、不影响饮品质量的部分都可以降级。先说不能省的。蠕动泵和食品级软管不能省因为普通泵会污染原料CO2气路的所有接头和阀门必须是食品级材质这是安全底线流量计不能省不然每次出品都像开盲盒时甜时淡原料罐必须用能密封、避光的容器很多糖浆见光会氧化变色变味。可以省的部分包括外壳用3D打印和亚克力板拼接没必要做金属钣金显示屏幕可以用几块钱的OLED小屏幕甚至直接语音播报按键和旋钮这类物理交互可以不要因为整个机器的核心理念就是只用嘴说散热系统用普通电脑风扇就行不用上水冷。这整套方案下来硬件总成本在2800元左右如果手头正好有闲置的3D打印机和开发板还能再压到2000以内。3. AI链路设计与实现从语音到配方的完整闭环3.1 语音识别与意图解析不是关键词匹配是自然语言理解早期版本我试过用简单的关键词匹配来解析用户指令比如检测到柠檬就调用柠檬配方。这个方法在单一指令时还好用一旦用户说今天不想喝太酸的但想来点热带水果的感觉加一点气泡关键词匹配就完全不够用了因为不想太酸是一个负向约束热带水果的感觉是一个需要推理的模糊描述加一点气泡是一个强度调整。最终我选择了一条更通用的链路先用本地语音识别引擎把用户的语音转成文字再把文字交给大模型去解析。语音识别用了开源模型跑在中配的树莓派上识别精度在安静环境下能达到实用程度。识别出来的文本会包装成一个结构化的JSON请求包含用户的需求描述、约束条件、温度偏好等。大模型在这个环节承担的是语义理解和结构化抽取双任务。我设计了一个比较详细的提示词模板要求模型从用户话语中抽取风味方向、酸甜苦咸鲜的偏好、温度要求、气泡强度、浓度要求如果用户没有明确说就标记为未知由配方生成模块用默认策略补齐。这里最关键的一点是不要让模型自由发挥而是要求它严格输出指定格式的JSON否则下游解析会非常痛苦。3.2 配方生成大模型负责创意规则层负责安全整个AI链路中最核心的设计原则是分工大模型负责生成创意方案和抽象口味的映射规则引擎负责把创意转成可执行且安全的配方。这一层设计来源于我早期做的纯大模型版配方系统它在demo时效果惊艳但实际使用中很快暴露问题模型偶尔会建议把某种原料加到80毫升这在一杯300毫升的饮料里就是灾难还出现过建议加入一小勺海水这种根本无法在机器里执行的方案。规则引擎。/ 层包含几个关键模块。安全过滤模块检查原料叠加是否超过上限、单种原料用量是否在安全范围内、是否有原料互斥或会产生不良风味的组合。剂量映射模块把大模型给出的模糊描述映射成具体参数比如少许对应5毫升、中等对应15毫升、较多对应25毫升这个映射表是通过大量口感测试标定出来的。一致性检查模块确保生成的参数在历史可接受范围内如果某个参数偏离了预设合理区间自动拉回。大模型生成配方的流程是先根据语义解析的结果生成一个风味意图描述比如青苹果般的酸脆感以及雨后泥土的潮湿气息然后把风味意图和可用原料清单传给规则引擎规则引擎从原料数据库里挑出匹配的原料生成若干候选配方再根据用户口味偏好打分排序选最优解下发给执行层。3.3 抽象口味的具体落地案例三个实测方案第一个案例是图书馆旧书的味道。用户提出需求后系统解析出木质、纸张、微苦、干燥、回甘这几个关键词。规则引擎匹配原料库后选择了雪松木糖浆作为主调加入少量焦糖糖浆模拟书页受热后的焦香再加一点点苦精来制造旧纸张的陈旧感气泡强度设为低温度设为常温。实测喝起来确实有一种木质调的微苦回甘很接近抱着旧书闻纸页的感觉。第二个案例是雷雨后草原的空气。这个需求的语义特征是清新、青草、潮湿、凉意系统选择了黄瓜汁基底提供湿润清爽感、接骨木花糖浆提供青草和花的联想、一点点薄荷提取物提供凉意温度控制在低温气泡中等。整体口感很清透确实有那种雨后空气被洗过的感觉。第三个案例是儿时外婆家的灶台味。这是一个特别考验抽象映射能力的需求关键词是柴火、米饭、甜、焦香、温暖。系统选择了红糖糖浆模拟灶台甜味、大米糖浆提供谷物感、少量烟熏味糖浆提供柴火联想温度设为温热档这台机器特意加了一个加热模块气泡强度为零。实验反馈出乎意料地好好几位朋友喝完都说想起了老家厨房的味道。这三个案例说明抽象口味不是玄学它的本质是跨模态的意象映射先把一种感觉翻译成风味词汇再由风味词汇映射到具体的原料组合。AI在这里的价值不是发明新味道而是把这种映射的候选空间大大拓宽了。4. 口味配方库设计50万种组合是怎么做出来的4.1 基础配料体系与抽象维度映射如果只有原料没有体系配方生成就只是随机拼凑。我花了不少时间搭建了一套感官维度与原料数据库的映射体系。感官维度分为十几个轴果酸度、甜度、苦度、咸度、鲜度、木质调、草本调、花香调、烟熏调、矿物感、脂润感、清凉感、辛辣感、碳酸刺激感等。每种原料都在这些维度上进行打分比如柠檬汁的果酸度是9、清新感是7、甜度是1香草糖浆的甜度是8、脂润感是6、木质调是2。原料数据库目前收录了38种基础原料每种都有一份感官维度评分表和用量安全区间表。抽象口味的生成本质上就是把用户的语言描述转成一组感官维度目标向量然后从原料库中寻找一组原料组合使它们的加权维度得分尽可能接近目标向量。这个过程听起来复杂其实可以直接用简单的贪心算法加一个小规模优化器实现。当然大模型在其中也参与了一部分工作把儿时外婆家的灶台味翻译成感官维度向量这活交给大模型干确实最顺。但它给出的向量可能超出原料库的表达范围所以还需要归一化和裁剪。4.2 配方生成算法细节生成配方的核心算法分三步走。第一步是意图向量化把语义解析结果转成12维的感官目标向量没有明确指定的维度用默认值默认值来自用户历史口味画像。第二步是原料组合搜索在原料库中尝试不同的原料组合和配比使组合后的感官向量和目标向量的欧氏距离最小。搜索采用的方式是先从单原料方案开始评估再逐步扩展双原料、三原料组合直到距离低于阈值或者组合数达到上限。第三步是安全与可行域检查把搜索结果送入规则引擎做安全检查并计算是否能在硬件上执行比如需要加热的原料不能在制冷模块下工作。参数计算上有一个需要特别注意的地方原料之间存在非线性交互效应。比如柠檬汁和牛奶类原料组合会产生絮凝薄荷提取物和特定果味糖浆叠加会放大苦味。规则引擎里专门维护了一张交互禁忌表凡是命中禁忌的组合直接淘汰。这个表是靠一次一次试错总结出来的属于这个项目里最耗时但最有价值的知识积累。口味一致性也是一个大问题。不同批次的浓缩糖浆、不同季节的水果浓缩液在风味上都会有细微差异。我的做法是在原料罐上做一个简单的出厂批次编号系统会根据批次编号调整配方里的比例系数。这套做法不完美但能把批次差异对口感的影响控制在可接受范围内。4.3 50万种在界面里是怎么呈现的虽然系统理论上能生成50万种配方但用户不可能也没必要看到所有配方。我在交互上做了一个配方空间的展示逻辑当用户说出一个想法后系统会生成5个候选配方每个配方附带一个AI生成的名字和风味描述用户可以直接选定也可以说再换一批。这个设计让50万种不再是冷冰冰的数字而是每次都有新选择、永远不重样的体验感。本质上50万这个数字是系统的能力边界而用户交互层提供的是探索入口。这就好比一个图书馆有几百万册书读者不需要一次性看到全部只需要在检索时能得到恰到好处的推荐。5. 实操复盘8个月我踩过的坑和关键节点5.1 时间线梳理从零到一的关键节点整个项目耗时8个月回头看大体可以切成四个阶段。第一个月到第二个月是方案验证期。这个阶段做了三件事用手动定量泵手工调配了20多种抽象口味的基础配方确定了感官维度映射表的初版结构用一块ESP32开发板接了两个蠕动泵验证了泵控精度可以达到正负1毫升用开源的语音识别模型做了中文口语识别的可用性测试。这个阶段最大的产出是验证了用语言调饮料在技术上是可行的最大的坑是低估了流量校准的工作量。第三个月到第四个月是硬件整体搭建期。完成水路、气路、电路的集成把第一台原型机的雏形拼了出来。这个阶段最容易让人崩溃漏水、泵堵、串口通信不稳定、气泡水出来全是大气泡所有问题集中爆发。到第四个月末硬件系统终于达到能稳定出品一杯气泡水的程度但配方还是手动写死的。第五个月到第六个月是AI系统开发期。完成了大模型接口的对接、语义解析模块、配方生成模块和规则引擎。这是整个项目里编程密度最高的阶段也是反复调整提示词最多的阶段。最开始大模型经常输出格式错误的JSON后来我把提示词改成了必须输出严格的JSON且只能使用这些原料名称不得自创原料情况才好转。第六个月末AI系统可以独立完成从语音到配方的全流程。第七个月到第八个月是打磨期。这期间做了大量口味测试、参数校准和异常修复。第七个月中旬我组织了第一次朋友内测收集了非常宝贵的反馈有人觉得某种口味过酸有人反映语音识别在厨房环境安检中误触发。这两个月更像是产品化的过程把能跑变成好用。5.2 核心代码与配置要点整个系统的代码量并不大主控程序大概一千多行AI服务端两千多行。真正花心思的是几个关键环节的细节实现。第一是泵的校准方式。我没有采用固定脉冲数对应固定体积的方式而是在每次开机时自动执行一次校准流程每种原料泵会以标准转速运行3秒钟流量计读取实际流量主控根据实际流量和目标体积计算运行时间。这样即使管路老化、液体黏度变化也能每次保持相对准确的出品。第二是语音识别模块的使用方式。我启用了唤醒词指令双段式机器只有在听到唤醒词后才会开始录音避免把背景聊天误识别成调酒指令。同时做了简单的噪音过滤厨房环境里水龙头声、杯碟碰撞声对识别率影响不大。第三是配方JSON的字段协定。AI服务端下发给主控的每个配方是一个结构化的JSON包含原料编号列表、每种原料的目标体积毫升、气泡强度0-3、温度档位低温/常温/加热、总水量、出品ID。主控解析JSON后逐项执行。这个结构看起来简单但确保了AI系统和硬件层之间的解耦以后想换更聪明的模型或者更贵的硬件都不需要改动整套架构。第四要注意的是并发处理。用户说完一段话后AI解析、配方搜索、硬件执行整条链路可能需要8到15秒。我在这期间设置了状态灯和语音提示不然用户会以为机器没听懂。这个等待反馈的设计对体验影响非常大值得专门做一轮优化。5.3 成本清单与复现建议直接上清单都是我自己实际采购的价格供参考。部件型号/规格数量参考价格主控板ESP32-S31约60元语音处理单元树莓派Zero 2 W1约160元蠕动泵食品级调速蠕动泵6约540元流量计霍尔式流量传感器6约120元CO2气瓶食品级2L气瓶1约200元减压阀带双表减压阀1约90元电磁阀食品级12V电磁阀2约80元气泡罐食品级不锈钢气泡罐1约180元半导体制冷模块12V大功率制冷片水冷头1套约220元储水罐食品级10L水箱1约60元原料罐食品级密封罐8约160元3D打印件亚克力外壳整套1约400元电源与线材各类1批约200元杂项软管、接头、阀件等1批约300元合计在2770元左右。如果有朋友想复刻我的建议是不要一上来就照单抓药。先把水路和AI仿真跑通确认自己确实需要一台这样的机器再开始采购硬件不然很容易做到一半发现某一部分不是自己想要的改动成本很高。6. 常见问题与排查技巧实录6.1 水路气路类问题漏、堵、气化漏水是最常见也最烦人的问题。排查思路是按区段隔离先把水路从中间拆开用泵打水测试前半段再测后半段很快能定位到是泵的接口、管路的快插接头还是三通位置漏。一个非常有效的预防措施是在所有螺纹接口上缠生料带快插接头要用带食品级密封圈的不要省这几块钱。泵堵塞多半是糖浆里的果肉或结晶颗粒造成的。我的解决方案是两层过滤原料罐出口加一个80目的不锈钢滤网泵前再加一个管道过滤器。即使这样高浓度糖浆在温度低时仍然容易析出结晶所以糖浆管路我加了一小段加热带把温度维持在25度以上。气泡不足的问题很多出在气路上。我遇到过气瓶有气但出品没气泡的情况排查发现是电磁阀被杂质卡住。气瓶和减压阀之间要装一个过滤器否则密封圈碎屑会顺着气路跑到电磁阀里。另外气泡罐的密封圈需要定期更换用久了会硬化漏气。6.2 AI交互类问题识别错乱和配方翻车语音识别最典型的故障是误唤醒和识别吞字。误唤醒的解决方法是提高唤醒词门限或者使用按压触发语音识别的结合模式我把机器顶部做了一个感应区域触摸才启动录音。识别吞字的问题在方言口音上特别明显我的应对方式是把语音文本同时做大模型理解和本地关键词纠错如果大模型解析出的结果置信度很低就自动要求用户再说一遍。配方翻车的情况最常见的是AI生成了材料库之外的原料或者生成了剂量明显失调的配方。前者通过提示词和程序校验双重保险来拦截后者靠规则引擎的安全范围裁剪。还有一次比较特殊的情况AI给出了一份口感非常咸的配方原因是用户说想来点海风的味道模型试图用盐来模拟海风。后来我在规则引擎里加了一条约束咸鲜类原料在任何配方中的占比不得超过3%除非用户明确要求重口味且系统二次确认。6.3 快速排查速查表现象可能原因处理方式出品量偏少泵流量校准失效/管路易堵塞重新校准泵检查滤网气泡明显不足气瓶压力低/电池阀卡滞/密封圈老化检查气瓶余量清洁电磁阀更换密封圈口味偏差大原料罐批次变化/流量计漂移重新校准流量计检查批次ID并在系统内更新系数语音识别无反应麦克风被遮挡/唤醒词门限太高/树莓派掉线检查麦克风接口调低门限重启语音服务配方生成报错JSON格式错误/原料库缺失检查大模型接口返回日志同步原料库版本出品温度偏高制冷模块散热不良/水温未到设定值检查散热风扇和制冷片供电等待降温后再出品6.4 我踩过最深的几个坑这8个月里最打击人的不是硬件的反复漏水而是AI这个环节的能用和好用之间差了十万八千里。demo阶段AI生成一个配方只花2秒但真正接入机器后才发现从语音识别结束到机器开始出水中间用户要等差不多10秒。很多人等不了这10秒会觉得机器卡住了。后来我在交互层加了状态语音提示每过一个环节就播报一句正在理解你的需求正在调配配方马上就好体验立刻上了一个台阶。还有一个坑是液体残留导致的串味。管路里泵完草莓糖浆再泵柠檬汁前10毫升会有明显的混合味。最初测试时没注意导致很多抽象口味尝起来都有一股说不清的混合果味。解决方法是把泵和管路的清洗程序加进了日常流程每次出品前先泵一段纯水冲洗管路出品后再泵一段纯水清洗。虽然每次会多消耗一点水但口味的纯净度提升非常明显。另外原料罐不要装满加一记冷藏保存。有一次我在测试中直接把常温放置了一周的薄荷糖浆灌进去结果出品带着一股氧化后的涩味整个测试批次都废了。后来又发现不同原料的适宜保存温度不一样果汁浓缩液要冷藏部分糖浆常温保存反而状态更稳定这个要按原料说明分类处理不能一刀切。我在实际使用中感受最深的一句话是做AI产品真正难的不是让AI变聪明而是让AI的聪明能稳定地转化成可用、可靠、可交付的结果。大模型带来的新想法和风味联想固然重要但如果没有规则引擎兜底、没有泵控校准、没有管路清洗这台机器永远只能停留在能跑demo的阶段。要说后续还能怎么扩展我目前正在做的就是增加用户口味画像的长期记忆功能。让机器记住你上次说不要太酸是真的不喜欢酸还是那天嗓子不舒服。另外我还在测试把整个AI服务搬到本地部署去掉云端接口依赖让这台机器可以完全离线使用。如果你正好也在做类似的AI硬件项目或者对抽象风味图谱这套映射想法有新的点子欢迎一起交流。