DIY语音控制汽水机：从抽象语言到可执行配方

做这台机器之前，我自己也没想到会从一个玩笑变成一个能摆在吧台上出杯的完整设备。标题里那句“用语言调制50万种抽象口味”听起来很像营销话术，但真把这台东西从图纸变成实物，我花了整整8个月。如果你也玩过单片机、搞过DIY，或者对AI应用落地有兴趣，这台“中配”汽水机的完整思路、硬件选型和各种踩坑记录，应该能给你不少参考。它不堆料、不炫技，核心解决一个问题：怎么把一句“我要一杯下过雨的草地味”，变成一杯真的能喝、还不难喝的汽水。

1. 项目概述：一台会“听懂话”的汽水机是怎么立项的

1.1 从一句玩笑到正式立项

起因特别俗。2024年底朋友来家里聚餐，我临时用浓缩柠檬汁和苏打水兑饮料，朋友随口说“这要是能用嘴喊出来就好了”。正常人笑一下就算完，我回家却认真想了很久：现在语音识别、大模型、嵌入式控制器都成熟到离谱，为什么不做一台“你说口味，它出饮料”的机器？

立项前我给自己定了三个硬性标准：第一，不能用手机App当唯一入口，必须有语音交互原生的体验；第二，“口味”不能是预设的20种按钮，而是真的能识别抽象描述生成配方；第三，成本控制在普通DIY爱好者能接受的范围，也就是标题里说的“中配”。这个“中配”不是指CPU，而是指整台机器的硬件配置：不算人工，物料成本四千以内，主控用国产开发板，语音链路本地跑，不上昂贵工控机。

1.2 这台机器到底是什么

说白了，它就是一个“语音驱动的自动调饮设备”。整机分三块：出液系统、气泡系统、AI决策系统。出液系统里装着若干瓶食品级浓缩风味液，通过蠕动泵精确注入杯底；气泡系统负责提供碳酸水基底；AI决策系统接收用户说出的自然语言，比如“带点烟熏感的橘皮味”“图书馆旧书的干燥感觉”，然后把它变成一组可执行的配方参数——加什么、加多少毫升、气泡多强、要不要额外点缀。

这里说的“50万种抽象口味”，不是真准备了50万瓶原料，而是配方参数空间足够大。用一个简单的数学视角看：我设计了20种基础风味液，可以单用也可以两种混合；酸甜苦咸鲜五个口感维度各分5档；气泡强度分4档；温度模拟3档；再加上可选的点缀风味。组合起来大约是几万到几十万的量级，经过配方引擎过滤掉明显难喝的组合后，仍然能覆盖很宽的口味空间。

1.3 什么人适合看这篇

这项目跨度不小，如果你是纯软件背景，可以重点看第3、4章，理解硬件和AI怎么握手；如果你是硬件玩家，第4章讲的语言到配方的映射思路，可能是你以前没接触过的东西。即便你完全不打算复刻，光是“抽象描述到具体出液参数”这条链路，也值得琢磨——它几乎是所有AI硬件产品的核心难点。

2. 整体思路与核心方案选型

2.1 为什么选“中配”而不上顶配

立项时我也纠结过：要不要上树莓派5加摄像头，搞一套“全自动识别杯子、自适应学习口味偏好”的顶配方案？后来想通了，做这种个人项目最怕的不是功能少，而是系统复杂度爆炸导致永远走不到调试完成那天。所谓“中配”，就是把每个环节都压到一个“够用且皮实”的平衡点。

顶配的坑在于：每个子模块都要花时间去优化，而其中大部分优化对最终出杯口感没有任何贡献。语音识别再聪明，也没法弥补泵不准；摄像头再先进，也解决不了管路清洗问题。我最后砍掉了所有“为了智能而智能”的功能，保留了“语音进、配方出、汽水落杯”这条最小闭环。这句话也想送给所有做DIY的朋友：个人项目的第一优先级是能完整跑通，而不是参数堆到纸面上好看。

2.2 硬件主控选型：ESP32-S3还是树莓派4B

这是第一个让我犹豫了两周的决定。成品里两种方案都能见：树莓派像个小电脑，跑Python、跑模型、接摄像头都方便，缺点是需要外设、需要风扇散热、启动慢，而且系统越复杂越容易崩；ESP32-S3是单片机，启动秒开、稳定、便宜，但内存有限，跑不了大模型。

我最后用了双主控架构：ESP32-S3负责所有实时控制——泵、阀、传感器、出液流程；树莓派4B（2G版本）只做一件事，跑语音识别和配方引擎，把结果通过串口发给ESP32。这个架构等于把“实时性任务”和“智能性任务”解耦，各自崩溃都不会影响对方。实际测试下来，哪怕树莓派后台识别卡了5秒，ESP32这边依然能安全地把上一杯配方执行完。

2.3 50万种口味的数学：组合空间怎么算出来的

“50万”这个数字，我在设计初期就较真地算过，不是拍脑袋。基础风味我做了20种成品浓缩液，分为三类：果味10种（柠檬、橙、莓果、桃、苹果、芒果、西柚、荔枝、菠萝、百香果），草本类5种（薄荷、罗勒、迷迭香、紫苏、芫荽），香料类5种（肉桂、姜、花椒、烟熏、焦糖）。配方允许选1种主风味，或者按比例选2种混合，那主风味组合就是20加上C(20,2)即190，共210种。

接下来是口感参数：甜度5档、酸度5档、苦度3档、咸度3档、鲜度3档，相乘是675。再叠加气泡强度4档、出品温度模拟3档（通过加冰水、常温苏打水、微温水三种基底实现），又是12倍。210 × 675 × 12 = 170万。但这里很多组合是“数学上存在、味觉上灾难”，比如八角加大量芒果。所以配方引擎里加了口味合理性过滤器，过滤后大概是50万上下。这个数字就是这么来的：不是吹出来的，是用乘法算出来的。

2.4 软件链路四层设计

整机的软件从麦克风到出杯分成四层：语音识别层、意图解析层、配方生成层、运动控制层。

• 语音识别层：麦克风阵列拾音，本地跑语音转文字模型，输出纯文本。
• 意图解析层：把文本里的口味关键词、情绪词、场景词抽出来，结构化。
• 配方生成层：根据结构化参数计算各种浓缩液、基底、气泡量的具体毫升数。
• 运动控制层：ESP32执行泵的启停、时间控制、气阀开关。

四层之间用JSON格式传递数据。语音层吐出的是一条文本，意图层吐出的是一个包含风味、口感、质地的对象，配方层吐出的是“加3.2ml柠檬浓缩液、2.1ml薄荷糖浆、120ml苏打水”这样的数组，控制层只管执行。这样每一层都能单独测试，出了问题也方便定位。我强烈建议任何做类似项目的人，哪怕刚开始只想做个按钮控制的简易版，也要先把数据接口定义好。没有清晰的接口，后期加AI能力时你会想砸机器。

3. 硬件架构与机械组装实录

3.1 配料系统的核心：蠕动泵选型和精度校正

这台机器最关键的机械部件是蠕动泵。它通过滚轮挤压硅胶管来输送液体，最大的好处是液体只在管内流动，不接触泵体，非常符合食品卫生要求。我用的是直流减速蠕动泵，额定电压12V，最大流量约每分钟240ml，单只价格大概45元。总计4个泵：3个装风味浓缩液，1个装可选点缀液，比如海盐溶液或青柠汁。

泵的精度是第一步要解决的问题。蠕动泵本质上靠“挤”液体，流量会受管径、液体粘度、温度影响，实测同一只泵在同一种液体上，前10秒和后面30秒的瞬时流量会差15%。解决方案不是换高精度泵，而是做流量标定：每次更换浓缩液瓶后，我让泵以固定功率空打30秒，用量筒接水，记录实际出液量，反推出“每毫升对应多少毫秒的泵运行时间”。这个标定结果存进ESP32的NVS存储器，每次换瓶都会覆盖更新。实际用下来，单次出液精度能做到±1.5ml，对汽水来说完全够了——别说汽水，手冲咖啡这种讲究的，误差2ml也没人喝得出来。

3.2 气路与碳酸化：气泡水的灵魂

汽水机必须有气泡，这部分的方案我前后改了三版。第一版直接用市售气泡水机的手动打气罐，每次要手按几下，不符合“全自动”目标；第二版买了一体化的电动碳酸化罐，结果发现它内部把碳酸化过程锁死在固定流程里，我没法用代码控制气泡强弱。最终第三版采用的是「5L食品级CO2钢瓶 + 减压阀 + 自制碳酸化罐」方案。

工作流程是：电磁阀打开，CO2从钢瓶经减压阀到碳酸化罐，罐内预装了4°C的冰水，通过摇动或曝气棒让CO2充分溶解，再用另一个电磁阀把碳酸水放到杯子里。之所以必须预冷，是因为温度越低CO2溶解度越高，室温水打出来的气泡又大又容易消散，4°C水打出来的气泡细密持久。减压阀我设定在0.35MPa，这个压力下，杯壁能看到细密的气泡缓慢上升，口感最接近市售苏打水。整个气路的人工干预就是每半个月换一罐CO2，成本大概28元。

3.3 结构设计与外壳制作

外壳的框架是2020铝型材，稳定好固定；四周面板用3mm亚克力激光切割，前面板留了一个触控屏孔、一个杯托位、一个出液嘴位。内部布局遵循一个原则：水路和电路物理隔离。前半部分是泵、管路、碳酸化罐，后半部分是树莓派、ESP32、电源模块，中间加了一块3mm亚克力隔板。一旦管路漏水，不会直接淋到主板上。

这个布局看着简单，但我是吃过亏才确定的。第3个月做原型时，我把电源模块和蠕动泵放在同一层，有一次浓缩液管接口松脱，液体顺着管壁流到降压模块上，当场冒烟烧了一块ESP32。从那以后“水路电路隔离”成了铁律。另外大家做类似东西时，一定要在所有泵的下方加一个接水盘，漏液至少有一个集中的去处，别让液体流得到处都是。

3.4 食品安全：食品级材料与清洗设计

做饮用设备，“能不能吃”是底线。所有跟液体接触的部件，包括浓缩液瓶、硅胶管、蠕动泵管、碳酸化罐、出液嘴，全部是食品级材质。硅胶管我用的是铂金硫化食品级硅胶管，虽然比普通管贵一倍，但不会释放异味，长时间泡在浓缩液里也不发黄。

清洗是更现实的问题。浓缩液含糖，特别容易滋生细菌，所以我设计了自动清洗流程：每次出杯后，系统自动用一个清水泵泵送50ml纯净水，通过三通阀冲洗整个出液管路，然后吹气0.5秒把残留水排掉。每周末还会手动执行一次深度清洗：把管路接到专用的柠檬酸清洗液里循环10分钟，再用清水循环15分钟。这套流程执行下来，用了半年多，管路里没有发现任何滑腻感或霉斑。

4. AI语音识别与抽象口味引擎

4.1 语音识别方案怎么落地

开头说“用语言调制”，落到工程上就是语音识别加意图理解。我试过两种方案：完全离线用ESP32-S3自带的ESP-SR做唤醒词加固定命令，以及树莓派上跑一个轻量ASR模型。最后选定的是混合模式：ESP32-S3只负责“唤醒词”——听到“汽水机”三个字才激活主系统，避免日常对话误触发；激活后麦克风阵列采集3秒音频，树莓派调用FunASR做语音转文字。

选择FunASR是因为它对中文口语的鲁棒性很好，哪怕是“我要一杯类似下雨天那种潮潮的味道”这样黏糊的长句，也能准确转成文字。模型我用的是普通话识别base版，在树莓派4B上识别一段3秒音频大概需要1.2秒，虽然不算快，但整个对话流程本来就是“说完等待出杯”，1秒延迟完全可以接受。识别结果会同时打印在触控屏上，用户确认无误后，再进入配方引擎。这个“确认”环节是我后来加的，早期直接出杯时，识别错了就只能倒掉重来。

4.2 抽象语言到底怎么映射成配方

这是整个项目最有意思的部分，也是“抽象口味”的核心。传统做法是预设关键词表，比如“草莓”对应草莓浓缩液，“薄荷”对应薄荷浓缩液，但是遇到“旧书的干燥感”这种完全没有食材词的金句，关键词表就废了。

我的做法分两步走。第一步，建一个“风味感知词库”。把大量形容词、名词、场景词，人工标注到12个基础味觉维度上。举个例子，“雨后”这个词，我标注为：清新8分、甜度2分、酸度3分、泥土感（归到特殊香料类）6分；“旧书”标注为：木质（归到烟熏/焦糖类）7分、干燥感（苦度5分、酸度1分）。这个标注过程很费功夫，但它是整个配方引擎的地基，我前后整理了两周，包含了大约300个词。

第二步，用本地部署的Qwen2-1.5B模型做补全。用户说出一句话后，ASR出的文本会先做一次关键词匹配和向量匹配，如果置信度低，就交给大模型，让它把这句话拆解成“核心风味、甜酸比例、气泡强度、温度感受、可选点缀”五个字段，以JSON格式输出。比如输入“想喝一杯凌晨三点便利店的感觉”，模型可能输出：base_flavor=柠檬+焦糖，sweet=3，sour=4，fizzy=4，temperature=冷，notes=微咸。这五个字段再交给配方生成层，就能得到具体毫升数。

4.3 配方向量化的具体实现

为了让“匹配”不只能做关键词，我的词库其实是向量化的。每个风味维度我定义好之后，任何一个词都被表示成一个12维向量，比如“薄荷”=清新9、甜1、酸2、凉感8，其余为0；“花椒”=麻感（我用苦度4+特殊香料8表示）、温暖6、刺激6。用户句子的向量是所有关键词向量的加权平均，然后拿这个平均向量与已知配方库里的所有配方向量做余弦相似度计算，取相似度最高的几个配方，再按相似度做线性插值。

为什么要做线性插值？假设用户说“70%的薄荷加上30%的青柠”，配方引擎找到这两个配方的向量，按0.7/0.3比例合成一个新的中间向量，反算出各风味液毫升数。这样能让“50万种”真实存在，而不是每次都是模板里那几个固定配方。不过我必须说明，线性插值不是所有组合都好喝，所以我给每个配方都标了一个“安全度”分数，低于安全阈值的组合会自动往最近的已知好评配方靠拢。

4.4 遇到“听不懂”的抽象表达怎么办

即使有大模型兜底，我也遇到过几次完全没法解析的输入，比如“我要喝会唱歌的云”。如果系统硬要生成配方，大概率出黑暗饮料。这里我设计了一个“渐进式兜底策略”：第一层，尝试向量匹配；第二层，向量匹配失败就调用大模型解析；第三层，大模型给出的字段置信度太低，就触发表情提示触控屏，让用户换一种描述，同时给出三个可选的近似提案——“会唱歌的云，要不要试试棉花糖苏打加一点薄荷清新感？”

这个兜底太重要了。一方面避免做出难喝的东西毁掉用户信心，另一方面也顺势把交互变成了对话而不是死板的命令。第一次测试时，朋友说“来一杯夏夜”，系统提示“夏夜——是否尝试薄荷青柠苏打加冰？”朋友点头，出杯后他说“还真有那么点夏天的感觉”。这大概就是抽象口味的意义：不是复刻具体的味道，而是唤起一种联想。

5. 8个月实操进度与成本盘点

5.1 按月的开发时间线

整个开发周期是8个月，如果纯粹按分解任务来看，真正有效工作时间应该不到150个工作日，剩下大量时间花在采购等待、方案推翻重来和“思考人生”上。我把过程写成时间线，给大家一个心理预期：

• 第1个月：需求定义，跑通“语音到文本”的最小验证。用现成麦克风和笔记本跑ASR，确定识别链路靠谱，这步如果走不通，后面全白搭。
• 第2个月：硬件选型、采购，开始搭电路原型。用面包板接第一个蠕动泵，写最简单的“通电转3秒停”。
• 第3个月：搭建完整水路系统和第一版结构框架，完成了第一次整机手动出杯——虽然丑到不忍直视。
• 第4个月：烧掉一块ESP32后大改布局，加入接水盘和干湿分离隔板，稳定性和安全性大幅提升。
• 第5个月：泵标定、流量闭环、气泡系统联调，解决了气泡水喷涌的问题。
• 第6个月：开始做风味词库和大模型解析，把语言映射链路跑通。
• 第7个月：整机联调、语音全链路测试，开始请朋友来盲喝，收集反馈。
• 第8个月：外观打磨、优化交互细节、写维护文档。做完后摆在家里吧台，正式服役。

这个节奏比我自己预期的慢，主要因为机械精度问题反复返工。如果只做静态展示用的原型，4个月足够了；但要做到“每天都能稳定出杯”的日用设备，多花的时间非常值得。

5.2 精度校准与口感测试方法

泵校准和气泡压力调好了，口味才是汽水机的灵魂。我的测试方法是“对照杯法”：同一配方打两杯，一杯机器出，一杯人工用量筒和注射器严格按照配方手调，让3个朋友盲喝，区分哪杯是机器做的。这个测试能发现很多微妙问题——比如泵的时序导致液体混合顺序不同，某些风味会突出或变淡。

最后我总结出口感的三个关键规律：第一，酸味和甜味不能同时使劲，甜酸比超过1.2:1时整个口味会变得浑浊，这是味觉上的“掩蔽效应”；第二，涩感主要是单宁类浓缩液加多了，用量必须精确到0.5ml以内；第三，气泡强度必须最后调整，因为CO2会改变舌头的感知，让酸度更锋利、甜度更低。所以配方引擎里加了一个“倒入气泡后再补一笔糖浆”的可选步骤，实际测试中这个细节让很多配方的接受度提高了不止一个档次。

5.3 硬件成本清单

详细成本我整理了一张表，方便想复刻的朋友做预算。所有价格都是2024年我在国内平台实际购入价，不同店铺会有波动。

风味浓缩液和糖浆的样品成本另算，我前前后后买了不下30种，花了500多，最后稳定下来20种作为常驻配方，其余仍在测试。整体来看，“中配”的物料成本确实很亲民，一桌朋友来玩时，这1600块钱换来的快乐值回票价。

6. 常见问题与排查技巧实录

6.1 问题速查表

把使用中和测试中遇到最多的问题整理成一张表，方便你第一次开机时快速对号入座。

6.2 三个我踩得最深的坑

第一个坑是“流量计闭环做了但没完全做”。早期我发现蠕动泵流量不稳定，就买了霍尔流量计，理论上应该能测量实际流量然后实时调整泵速。结果实测发现，这种便宜的霍尔流量计在低流速时分辨力差得离谱，每秒只有一两个脉冲，计算出的流量波动很大。最后我放弃实时闭环，改用“定期标定+开环控制”，精度反而更稳。设备越简单越皮实，在低精度传感器上套复杂的算法，只会把噪声放大。

第二个坑是“神经网络的输出不能直接信”。有一次大模型把“微辣”解析成了sour=5，配方引擎出了杯酸度爆炸的饮料。刚开始我觉得是模型问题，后来想到深层问题：意图解析层需要一个“字段合理性校验器”，比如sour的范围是1-5、temperature只能是冷/常温/温、base_flavor必须在风味库中。校验不过就触发兜底询问。这一步之后，再没出现过“辣味变酸味”的离谱情况。

第三个坑是物理层面的，气路爆炸。有一阵子每次气泡罐泄压都会发出很响的“噗”声，我以为是正常排气。后来拆开发现泄压阀弹簧已经疲劳，压力到0.5MPa才开启，差点超压。从那以后我养成了一个习惯：每周用压力表测一次罐内静态压力，并且备用泄压阀必须采用不锈钢弹簧，别用铜的，时间久了弹性衰减明显。

6.3 日常维护与清洗流程

这台机器要长时间稳定服役，维护比制作更重要。我现在的日常流程很简单：每天关机前，自动执行一次60mL清水冲洗管路，然后吹气排空；每周末，手动把管路接到柠檬酸清洗液中循环10分钟，再用清水循环15分钟，清洗液是食品级，能溶解管路内的糖垢；每月，更换一次蠕动泵段硅胶管，因为那一小段管子长期被滚轮挤压，弹性衰减最快；每月，检查CO2钢瓶余量（称重法），低于满量程20%就换。

还有一个特别容易忽略的点：浓缩液瓶口的密封圈也要定期检查。它在频繁开关过程中容易变形，密封不严会导致风味液挥发、结晶，堵住泵的入口。有一次“桃味”出液越来越慢，就是因为密封圈坏了，浓缩液在瓶口结了一层糖晶。换了个密封圈，问题立刻解决。维护这东西，你不主动找小问题，小问题就会在某次聚会时变成大事。

做完这台汽水机，我个人最大的收获不是那个“50万种口味”的数字，而是“把抽象描述变成可执行参数”这件事本身。你在纸上画一堆流程图时觉得每一步都合理，但真到用户说“我想要一个没有月亮的夜晚的味道”而机器真的出了一杯微苦带气泡、有烟熏尾韵的饮料时，你才会意识到，所谓的AI产品，其实就是把一个很模糊的愿望，翻译成一组极其具体的物理动作。这8个月里我反复体会到一个道理：AI部分再聪明，最终都要落在一滴液体、一克糖浆、一个G的CO2上。想让机器真正有用，不能只研究模型，还得把手弄脏，去拧螺丝、调阀门、洗管路。这台汽水机没有多先进的技术，但它是一个完整的、能每天陪你喝一杯的系统。后续我打算再给它加一个“口味日志”，记录每个人喝过什么评价如何，然后反向微调配方参数——让机器越用越懂你，这大概就是下一个8个月的事了。