从自然语言到物理配方：AI汽水机的软硬结合实践

1. 从一句"来杯初恋的味道"到一杯真汽水

我花了大半年时间折腾出来一台能听懂人话的 AI 汽水机：你对着它说一句"来杯初恋的味道"，它在两秒内把它翻译成糖浆配比、甜度、气泡强度、温度四组参数，然后泵开始工作，八秒后一杯冒着细泡的汽水就递到你面前。它最大的价值不在于"会做汽水"，而在于打通了自然语言到物理配方这一整条链路——把大模型的抽象理解能力，落到计量泵的毫秒级脉冲上。这篇文章写给三类人：想动手做硬件+AI 融合项目但不清楚从哪下手的爱好者、做 AI 应用开发想找落地场景的工程师、以及单纯好奇"50 万种口味"这个数字怎么算出来的朋友。我从架构、硬件、软件、翻车复盘四条线把它拆开讲，参数、代码、坑点都摆在明面上。

1.1 这个项目真正难的地方在哪

很多人第一反应是"接个大模型不就行了"，但真上手就会发现，模型能给你一段漂亮的描述，却给不了泵该转几秒。中间隔着一层语义到物理量的映射，这层怎么设计，决定了整台机器的成败。我一开始也天真，直接把用户的话丢给模型让它输出"3 毫升柠檬糖浆"，结果它一会儿输出 3 毫升、一会儿输出 30 毫升，单位都飘。

第二个难点是约束。你可以让模型自由发挥说"加点烟熏味"，但糖浆架上只有十六瓶真实存在的液体。模型必须被限制在这十六瓶的组合里选，不能凭空发明一种原料。这就需要用结构化输出加枚举约束，把它的"想象力"框在物理世界内。

第三个难点是可控的重复性。同一句话说两遍，出来的味道应该基本一致，否则用户会觉得这机器"神经病"。这就要求我们在模型之外再做一层缓存和锚定，把常见表达固定成稳定的味觉向量，而不是每次都依赖模型随机采样。这三点想清楚了，剩下的都是工程量。

1.2 大家最关心的"50 万种"从哪来

这个数字不是拍脑袋，是实打实的组合数，只不过口径要说明白——它是配方组合的数学上限，不是"每种都调过且都好喝"。我先把可调维度列出来：十六种基础糖浆，每杯从中取 1 到 4 种混搭；甜度 5 档；气泡强度 6 档；出杯温度 4 档；是否加酸 2 档；冰量 3 档。算一下风味组合本身：

• 取 1 种：C(16,1) = 16
• 取 2 种：C(16,2) = 120
• 取 3 种：C(16,3) = 560
• 取 4 种：C(16,4) = 1820

风味组合合计 2516 种。再乘上其他维度：2516 × 5（甜度）× 6（气泡）× 4（温度）× 2（酸）= 603,840。所以"50 万"其实是保守说法，理论上限超过 60 万。但这里有个诚实的提醒：大部分组合是难喝的，真正好喝的映射集中在一个很小的子空间里，这也正是需要 AI 做"翻译"而不是让用户手动调参的原因。

1.3 为什么值得做一个"实体 AI 项目"

纯软件的 AI 应用现在满地都是，但把 AI 的结果落到一个能摸到、能喝到的东西上，体验完全不一样。它逼着你处理延迟、容错、机械误差、卫生这些软件世界里不存在的问题。做完这一台，我对"AI 落地"这四个字的理解比以前深得多——模型只是整条链路里最聪明、但也是最不可靠的一环，真正决定体验的是它周围的工程。这也是我建议每个想做 AI 应用的人，都至少动手做一次软硬结合项目的原因。

2. 系统架构与口味数据模型设计

整台机器我按"感知—决策—执行"三层来分，层与层之间用明确的接口隔开。这样做的最大好处是任何一层出问题都能单独替换：比如今天语音识别换成另一个引擎，下游代码一行不用改；明天换个大模型，配比逻辑照样跑。定接口这件事我在项目早期偷懒省略过，结果第三周返工了整整两天，教训很硬。

2.1 三层架构怎么切

感知层负责把用户的语音转成文字。它对外只吐出一个字符串加一个置信度，别的一概不管。决策层是核心，负责把文字转成结构化的配方对象，内部又分两步：先把"抽象表达"映射到味觉维度，再把味觉维度量化成具体配比。执行层拿到配方就干活，把每种液体的体积换算成泵的运转时长，按顺序出料、混合、出杯。三层之间只传数据，不传状态，这样调试的时候可以逐层打印中间结果，定位问题极快。

提示：接口定义尽量用简单的 JSON 结构，别一开始就上复杂的消息队列，单机项目用不上，反而增加调试成本。

2.2 配方数据结构怎么定

配方是整个系统的"通用语言"，它的字段设计直接决定了后面好不好扩展。我最终定成下面这样，包含原料清单、每种的体积、以及目标温度、气泡等级这些环境参数。体积用毫升，温度用摄氏度，气泡用 0~5 的整数等级，全部是无量纲或标准单位。为什么强调这一点？因为早期我用过"少一点/多一点"这种模糊描述在内部传递，结果下位机根本没法处理，被迫全部重写。

{ "name": "凌晨三点的柑橘", "ingredients": [ {"syrup_id": "citrus_01", "volume_ml": 18.0}, {"syrup_id": "tonic_07", "volume_ml": 6.0}, {"syrup_id": "herb_03", "volume_ml": 3.5} ], "sweetness": 2, "carbonation": 4, "temperature_c": 4, "acid_boost": true, "ice_level": 2, "soda_water_ml": 180.0 }

这里有个设计取舍值得说：我为什么把糖浆体积和碳酸水体积分开。因为糖浆是计量泵精确控制的，碳酸水是定容注水，两者误差来源完全不同。分开之后，标定和排查都能对号入座，不会互相甩锅。

2.3 抽象表达怎么变成味觉维度

这是整个项目最有意思的部分。用户说"初恋的味道""加班到凌晨三点的感觉""下雨天配一首老歌"，这些话没有标准答案。我的做法是引入一个中间层：六维味觉坐标——甜、酸、苦、气泡感、温度感、香气指向。模型的任务不是直接给配方，而是先给这六个维度的打分，再由确定性的代码映射成配方。这样做的理由是：降维打击。让模型做"读空气、猜情绪、翻译成味觉"这件事它很擅长，让它算毫升它会翻车。把两件事拆开，各用最合适的工具做。

香气指向我用了五个方向：果香、花香、草本、奶香、焦香（烟熏/烘焙）。用一个长度 5 的权重向量表示。"下雨天的感觉"我映射成：低甜、中酸、微弱苦、中气泡、低温、草本和花香各占一半。这个映射不是唯一解，但它是稳定解，说一百次结果都一样。

2.4 锚定缓存让结果不飘

纯靠模型每次现推，同一个表达可能给出不同的味觉坐标，这就是"飘"的来源。我在决策层加了一张锚定表，把高频表达固定成写死的味觉坐标，命中就走缓存，不命中才叫模型。表里现在有 300 多条，覆盖了大部分常见的形容词和场景词。实测下来，命中率大概七成，剩下三成走模型，整体响应时间从 1.8 秒压到 0.6 秒左右。这招在成本和稳定性上都划算。

3. 硬件实操：泵、阀与管路的选型逻辑

硬件这部分我踩的坑比软件还多。核心就三件事：量要准、路要分开、洗得干净。量准靠计量泵和标定，路分开是为了防止糖浆串味和碳酸水回流，洗干净则是食品级设备的基本要求，做不到这点机器做出来自己都不敢喝。

3.1 计量泵怎么选：蠕动泵 vs 电磁泵

我最终选了蠕动泵，理由有三。第一，糖浆比较粘，蠕动泵靠滚轮挤压软管输送，不接触液体本身，只换软管就干净，卫生上省心。第二，精度够用，配合标定能做到 ±0.5 毫升的重复精度，做汽水完全够了。第三，不同糖浆之间只要换管就不串味。电磁泵便宜、流量大，但精度差、清洗难、容易堵，我试过一轮就放弃了。

泵的流量别信标称值，一定要自己标。我买的那批标称 12 毫升/秒，实测在 12V 下只有 8.6 毫升/秒，而且每台之间差异能到 15%。这个差异不管，配比直接跑偏。

3.2 碳酸水和糖浆必须是两条独立回路

这是安全问题也是味道问题。碳酸水那一路我用了二氧化碳气瓶加调压阀，配合一个带泄压阀的小型耐压罐做碳化。糖浆回路绝对不能和碳酸水回路混用一个泵或一根管，因为碳酸水有压力，一旦停泵会往回顶，把糖浆污染甚至把管路顶爆。两条路分开走，最后在出杯口用分流嘴汇合，混合才发生。这样每一路都能独立控压、独立清洗。

注意：带压力的气体和液体系统，务必装泄压阀，管路承压能力要有余量，接头定期检查。任何承压部件都不要私自改装到超出其标称范围。

3.3 主控怎么分工

我用树莓派 + ESP32双主控。树莓派负责语音识别、跑大模型客户端、管业务逻辑，因为它算力够、能跑 Linux。ESP32 只干一件事：接收体积指令，精确控制泵的启停时序。为什么不用树莓派直接控制泵？因为 Linux 不是实时系统，做毫秒级定时会抖，实测误差能到几十毫秒，对于 1.5 秒的脉冲来说误差就有 2%，累积起来味道会偏。ESP32 用硬件定时器做这活，误差在微秒级。两者之间用 USB 串口通信，115200 波特率，协议是简单的 ASCII 行协议，好抓包、好调试。

3.4 泵的流量标定：用称重法最靠谱

标定别用眼睛看刻度，用电子秤。步骤是这样的：先让泵空转把管内空气排净，然后在出液口放一个空杯，去皮，让它按固定时长运行，比如 3 秒，称重。糖浆密度按 1.2 克/毫升换算体积。重复三次取平均，算出这台泵的实际毫升/秒。把这个值写进配置文件，配比换算时按各自泵的系数算。我建议每两三个月重新标一次，因为软管会老化，流量会慢慢衰减。

4. 软件实操：从语音到泵脉冲的完整链路

软件这条链子有三段：语音转文字、文字转配方、配方转脉冲。每段都有它的脾气，我把实现和踩过的坑都摆出来。

4.1 语音识别：本地跑省心还是云端省事

我两种都试过。云端识别效果更稳，尤其在有环境噪声的场合，但要联网、有延迟、有请求量限制。本地识别我用的是一个开源语音模型，量化后在树莓派上跑，识别一句话大概 0.8 秒，离线可用，隐私也好。我的取舍是本地为主、云端兜底：本地识别置信度低于阈值时才走云端。这样日常用起来快，遇到复杂语句也不至于彻底歇菜。

def transcribe(audio_path): text, conf = local_asr(audio_path) if conf < 0.6: text = cloud_asr(audio_path) return text

提示：语音识别对短句和方言口音很敏感。我在提示用户时有意引导说完整短句，比如"来一杯偏酸、带点草本味的气泡水"，比单说"酸的"识别率和理解准确率都高一截。

4.2 提示词怎么写才不翻车

提示词的核心思路是给定枚举 + 强制结构 + 明确边界。我先告诉模型有哪些糖浆可选、甜度分几档、气泡分几档，然后要求它只输出 JSON，且字段值必须在给定范围内。为了让它别乱来，我在提示词里明确写了"只输出 JSON，不要解释，不要 markdown 代码块"。实测加不加这句，解析成功率差很多。

你是一台汽水机的配方引擎。可选糖浆有： citrus_01(柑橘), tonic_07(汤力), herb_03(草本), floral_02(花香), smoky_04(焦香), creamy_05(奶香) 等共16种。 用户描述："{user_text}" 请输出 JSON，字段如下： - ingredients: 数组，1~4 项，每项含 syrup_id 和 volume_ml(0~25) - sweetness: 0~4 整数 - carbonation: 0~5 整数 - temperature_c: 从 [22, 12, 6, 3] 中选 - acid_boost: true/false - reason: 一句话说明，不超过20字 只输出 JSON。

这里有个经验：让模型也输出一句 reason，不是为了展示，是为了排查。当某个口味离谱时，看它给的理由就知道是哪里理解偏了，调试效率高不少。

4.3 配比换算和限幅：必须有的安全网

模型输出再约束也可能越界，所以代码层必须做硬限幅。我定了三条规则：单种糖浆体积不超过 25 毫升；总糖浆体积不超过 60 毫升；甜度、气泡等级超范围直接夹到边界值。同时做一个互斥检查，比如焦香和奶香同时高占比会很难喝，就自动压低次要项的占比。这层限幅不依赖模型，纯确定性代码，跑一万次结果都稳。

def clamp_recipe(r): for ing in r["ingredients"]: ing["volume_ml"] = max(0.0, min(25.0, ing["volume_ml"])) total = sum(i["volume_ml"] for i in r["ingredients"]) if total > 60.0: k = 60.0 / total for i in r["ingredients"]: i["volume_ml"] *= k r["sweetness"] = max(0, min(4, r["sweetness"])) r["carbonation"] = max(0, min(5, r["carbonation"])) return r

4.4 配方转脉冲：一行公式背后的讲究

体积转时长看着简单：时长 = 体积 / 泵流量。但有几个细节。泵启动有加速段，停止有惯性段，真实出液量会比"流量×时长"略少，我在标定时把这部分折算进流量系数里了。多种糖浆要按顺序出料，不能同时开泵，否则管路压力互相干扰。出料顺序按体积从小到大，先出少的，减少残留误差。最后是碳酸水注入，它在糖浆之后，用来冲刷管路并把糖浆带进杯子，等于顺手做了次小清洗。

def recipe_to_pulses(recipe, pump_map, water_pump): pulses = [] items = sorted(recipe["ingredients"], key=lambda x: x["volume_ml"]) for ing in items: flow = pump_map[ing["syrup_id"]]["flow_ml_s"] dur = ing["volume_ml"] / flow pulses.append((pump_map[ing["syrup_id"]]["port"], dur)) soda_dur = recipe["soda_water_ml"] / water_pump["flow_ml_s"] pulses.append((water_pump["port"], soda_dur)) return pulses

5. 联调、翻车复盘与排查速查表

联调阶段我大概有一周时间天天在喝奇怪的液体。下面挑几个最典型的翻车案例复盘，都是花钱买来的经验。

5.1 三个经典翻车案例

案例一：串味。做完一杯焦香口味，下一杯柑橘里带烟熏味。排查发现是公共出液口的残液没冲干净。解决办法是每杯结束加一段清水冲洗脉冲，把共用段管路冲一遍，成本是每杯多十几毫升水，但串味彻底消失。

案例二：气泡不足。用户反映"气泡感 5 档还是像糖水"。查下来是碳酸水温度太高，气体溶解度低。溶解度和温度强相关，水越冷溶得越多。我把碳化罐温度压到 2~4 摄氏度后，气泡感明显上来了。所以气泡档位不只是压力问题，温度是隐藏变量。

案例三：同一句话两种味道。用户连说两遍"清爽的"，一杯偏甜一杯偏酸。原因是这句没进锚定表，走了模型随机采样。加进锚定表固定坐标后问题解决。这也印证了前面说的：模型负责新奇表达，常见表达必须锚定。

5.2 常见问题速查表

5.3 卫生维护：这活儿不能偷懒

食品级设备，卫生是底线。糖浆含糖，管路里是微生物的温床。我的维护节奏是：每 48 小时用温水冲洗整个糖浆回路，每次换糖浆瓶时单独冲洗对应管路，每两周做一次食品级清洗剂循环。出杯嘴每天擦。所有接触液体的部件都要是食品级材料，硅胶管定期更换，一般一到两个月换一次。别嫌麻烦，机器是给自己和家人用的，这步省不得。

注意：清洗后要用清水充分冲洗，避免清洗剂残留。碳酸水回路和糖浆回路分开清洗，别混。

6. 做完这一台之后，我真正学到的东西

如果说这个项目教会我一件事，那就是AI 不是万能的解题器，它是链路里最灵活、也最需要被约束的一环。让模型干它擅长的——理解语言、翻译情绪、做模糊映射；把精确计算、边界控制、硬件时序交给确定性代码。这条分工线划清楚，项目就顺了；划不清，就会陷入"为什么它这次又变了"的无尽调试。

还有一个体会是先跑通最丑的版本。我最早那台机器，树莓派搁在纸盒上，管子用胶带固定，语音识别经常听错，但它能出汽水。正是这个丑版本让我验证了整条链路可行，后面才有动力去优化泵精度、做锚定表、改管路。如果一开始就追求完美，估计第三周就放弃了。

最后分享一个我觉得有意思的扩展方向：给这台机器加一个记录功能，把每次点单的原话、模型解析结果、最终配方存下来，攒够数据之后，就能反过来分析"人们描述味道的语言规律"。这个数据集本身挺有价值，也能用来做锚定表的自动扩充。我目前已经攒了两千多条，等我跑一段时间，再回来分享这批数据里发现的规律。