不是更快的出酒机，
是会看着你调酒的调酒师
现有的调酒机器人已经把「把酒做出来」解决得很好了。 我们做的是另一件事：让一杯酒的制作过程本身值得看。
Makr Shakr Veloce 的吞吐
行业区间 $30k–$100k+
和看着客人合在一起的系统
他们做得很好的那部分
先把话说清楚：现有系统不是做得差，是目标不同。 它们为吞吐量和一致性优化，并且达到了。
| 系统 | 形态 | 吞吐 | 价格 |
|---|---|---|---|
| Makr Shakr Toni | 双臂机器人（KUKA），158 瓶 | 80+ 杯/小时（官方页） | — |
| Makr Shakr Veloce | 双臂机器人，为速度设计 | 240 杯/小时 | — |
| Cecilia.ai | 屏幕形象 + 泵 · 语音对话 | 120 杯/小时 | $45,000 或 $2,000/月 |
| Yanu | 封闭机柜内机械臂 · 对话 + 支付 | 100 杯/小时 | — |
| MIXO | 8 / 20 蠕动泵 | — | — |
| TendedBar / Backbar One | 转盘 + 泵阀 | 为高吞吐设计 | — |
整套装置是围绕机器设计的：杯子放在固定夹具上、瓶子接在固定管路上、动作走固定轨迹。 在这个前提下，预编程既快又稳。那些流畅的演示视频恰恰证明了这一点——那是它们的强项，不是短板。
但他们的「AI」在哪一层？
这是整份材料的支点，而且它有原文出处。
“The recipe database contains pre-programmed ratios, sequences, and pour volumes.”
“machine learning tracks popular combinations, personalizes suggestions, and adjusts pours based on historical data.”
AI 用在「推荐喝什么」，不在「怎么动」。手臂本身仍然是一条录好的轨迹。
固定杯位 → 固定轨迹 → 成功
杯子挪了 5 cm → 同一条轨迹 → 抓空
看画面 → 算动作 → 成功
杯子挪了 5 cm → 重新看画面 → 重新算
真正的空位在哪
会聊天的调酒机器人有了，会做动作的机械臂也有了。 但没有一台把两者放在同一个身体上。
| 有没有会表演动作的身体 | 看不看客人 | |
|---|---|---|
| MIXO · TendedBar | 泵阀 / 转盘，无身体 | 无感知 |
| Makr Shakr Toni | 双臂 KUKA · 158 瓶 · 80+ 杯/时 | 官方页无相关描述 |
| Cecilia.ai · Yanu | 屏幕形象 / 机柜内，无表演动作 | 语音对话 · 会讲笑话 · 收款 |
| XLeRobot | 双臂 + 可动头 + 三路相机 | 人脸 · 表情 · 对话 |
还有一条横跨所有人的共性：无论会不会聊天，它们的手臂动作全部是预编程的。 AI 在推荐层、在对话层，就是不在动作层。
酒吧卖的从来不只是酒
如果只要液体，摇一摇预调罐更便宜。 人愿意坐在吧台前，是因为那里有人、有表演、有交流。
出酒速度
250 杯/小时。适合场馆、邮轮、机场——排队的地方。
被看着的那 40 秒
抬头看你、转动杯子让你看清颜色、把杯子推到你面前的那一刻。
交互本身就是产品
在不排队的场景里——精品酒吧、展会、门店——这一段比速度值钱。
所以我们不去和 250 杯/小时竞争。我们做那台会抬头看你的。
一次完整的服务，是四段
注意视线这一行：它在时序里出现两次，一头一尾，中间制作时是锁死的。 这不是设计偏好，是被数据推出来的结论（第 9 页给证据）。
视线：转头找到客人
手臂：静止
语音点单，表情屏回应。手臂不动，所以这一段最先能演示。
视线：锁死
手臂：抓取 · 倾倒 · 摇晃 · 搅拌
策略驱动的连续动作。
视线：锁死
手臂：转动杯身
让客人看清颜色和层次——这是现有产品里不存在的动作。
视线：回到客人身上
手臂：朝客人实际所在的方向
而不是写死的取酒口坐标。
这不是渲染图，是它真实的视野
下面的画面抽自我们已经录好的示范数据， 来自机器人头部相机的原始输出。
xlerobot-team/xlerobot-cup-grasp-20260820-0230，50 集 / 19453 帧 / 30 fps。
用 ffmpeg 从原始视频抽帧，未做裁剪或调色。三件和别人不一样的事
学出来的动作，不是录好的轨迹
视觉-语言-动作模型（VLA）直接从人类示范里学。换一只杯子、挪一个位置， 靠泛化而不是重新示教。
情绪与对话是一等公民
人脸检测 + 表情识别 + OLED 表情屏 + 语音，子系统已经在跑。 它不是加在最后的装饰，而是决定视线该看哪的输入。
面向观众的动作
旋转展示、朝人递出。这类动作在现有产品里不存在， 因为它们的客人是走过去自己取酒的。
把画面按物体分组，再交给模型
不给模型喂「杯子在 (x, y, z)」这样一个我们手算出来的坐标， 而是把画面按物体分好组，让它自己决定该注意谁。 场景里同时有瓶、杯、人的时候，这个差别是决定性的。
跑在一块巴掌大的板子上
CPU 与 GPU 共用的全部内存
本地推理，不联网
现有商用系统价格区间
球形外壳 + 单只大眼，可动 pan/tilt，深度相机与表情屏都装在上面。 相机会动，正是下一页那个约束的来源。
双臂 + 可动头 + 三路相机 + 移动底盘，全部本地运行。 这块板子装不下 70 亿参数的模型——技术选择被算力真实地约束着。 这不是缺点：它逼我们去找更聪明而不是更大的做法。
为什么制作时视线必须锁死
「什么时候看客人」这个产品决策，最后是被一行数字定下来的。
head_1 σ = 0.0000 范围 [-4.308, -4.308]
head_2 σ = 0.0000 范围 [49.846, 49.846]
所有示范里，头一次都没动过。模型从来没见过「视线在移动」的画面。
制作过程中让头跟着客人转，输入就跑出了模型见过的范围。 它不会「稍微差一点」，而是面对一类它完全没学过的情况。
深度相机装在会动的头上，它的标定是「头在某个姿态时」的标定。头一动，几何全废。
两个独立的约束指向同一个答案， 所以「迎宾和递出时看人、制作时锁死」不是我们挑的方案，是唯一能成立的那个。 好的产品决策常常长这样：不是选出来的，是被排除法剩下的。
已经在机器上跑起来的
全部是实机运行、可复现的能力，不是计划。
- 双臂遥操作 + 数据录制，VR 和主从臂两条独立通路
- 50 集抓杯示范，30 fps，三路相机同步
- 深度相机原生录制打通
- 人脸检测与跟随
- 表情识别 + OLED 表情屏
- 语音对话
- 关节级安全层：拒帧率从 96.6% 调到 0.49%
- 软件急停 + 双总线互斥保护
- 笛卡尔包络与逐关节步长上限
- VLA 策略在本机端到端跑通：看画面 → 出动作 → 驱动实机
- 训练与部署流程贯通，含云端 GPU 训练链路
- 试验记录规范：判据前置、失败模式、置信区间
我们怎么保证数字是真的
这一页通常不会出现在 pitch 里。我们放在这里，因为它是我们真正的差异。
每条结论标证据等级
实测跑过，有输出 未测没跑过
没测过的推断，不许当成测过的事实讲。
报区间，不报点估计
跑 4 次和跑 23 次在表里长得一样，但真实成功率的 95% 上界差了四倍。 我们一律用 Clopper-Pearson 精确区间。
感知方案必须过人工看图
我们写过检出率 97.6%、抖动 6.4 mm 的检测器，数字全漂亮—— 看图才发现它锁住的是机械臂自己。从此每个感知结论都要人眼过一遍。
这条规矩也用在别人的论文上
某篇工作报真机 59% vs 41%。我们用同一套方法算它给的原始计数： 29/49 vs 20/49，区间重叠，Fisher p = 0.106，不显著。 所以我们引用它的方法，不引用它的成功率。
下一步，按依赖排序
| # | 要做的 | 为什么是它 |
|---|---|---|
| 1 | 可靠地框住杯子（开放词表检测） | 后面每个动作的共同地基 |
| 2 | 相机内参 + 手眼标定 + 头部预置位 | 任何 3D 推理的前置 |
| 3 | 迎宾段接通（手臂静止，视线跟人） | 不冲突，最先能演示的一段 |
| 4 | 录倾倒 / 展示 / 递出的示范 | 这些技能只能从示范里来 |
| 5 | 面向人的安全策略（独立设计） | 朝人伸手前必须先有 |
第 3 项值得单独说：迎宾阶段手臂是静止的，所以它不和任何东西冲突， 是整个产品叙事里最先能演示出来的一段——机器人抬头看着你、跟你说话、表情跟着变。 那已经是现有产品里没有的东西了。
一句话
现有的调酒机器人把客人当成取酒的人。
我们想做的这台，把客人当成看的人。
这个区别决定了每一个技术选择： 为什么要学习式的动作而不是录好的轨迹，为什么视线控制要按阶段切换， 为什么第一版做「推出」而不是「递到手上」。
代码与数据：github.com/ginagina19992023/Robotic_challenge