机器人向前一步，人可能退后半步，一只机械手伸到面前，我们也会迟疑片刻，才决定如何回应。

我想在《空框AI》里，研究这些细小的相遇。

我们习惯追问机器能做什么，也需要耐心看看，它的每一次动作，会怎样改变人的判断、感受和行动。那些短暂的等待与配合，构成了技术进入生活的具体模样。

这个系列叫《人与机器人之间》，写给产品经理、设计师，也写给第一次听说HRI的人。

HRI，即人——机器人交互。我们会从机器人的身体与感知讲起，逐步讨论语言、目光、距离和动作，再进入协作、信任与交互评估。

我希望既能把技术讲得明白，也能真正从人的角度出发深入思考。

第一篇，从一瓶水开始。

一个简单的问题：机器人什么时候该松手？

假设一台机器人把水递到你面前，你伸手握住瓶子，它还攥着；你轻轻往回拉了一下，没拿动，于是又加了点力，这时它突然松开，你的手往后晃了一下，总算把水接了过来。

水没有掉，只是接过来的这一刻，你还拿不准，刚才究竟是自己太着急，还是它反应慢了。

如果给机器人写一份需求文档，“递水”这个行为，大概会被拆成识别瓶子、抓取、移动、伸手。到了最后，可能只剩一句——用户接过物品，任务完成。而“接过”这两个字，把许多事情轻轻带过去了。

机器人怎么知道你接稳了？你又怎么知道，它已经准备松手？

人与人递东西时，常常不用把这些问题说出口。眼神、手势、力道，还有对方身体的一点变化，足以让动作继续。换成机器人，我们就需要把这些看似自然的配合，一点点辨认出来。

这正是HRI关心的事，它研究人怎样使用机器人、与机器人共同活动，以及如何设计和评价这些过程，研究对象也不限于会说话的人形机器人。

递水，是一个很小的入口。沿着它往里走，会遇到感知、控制、人的判断，以及产品应该怎样作出取舍。

它凭什么知道你接稳了？

先试一个直觉上的办法，让机器人看着你的手——手伸过来，握住瓶子，它就松开。

但手指环绕着瓶身，不代表已经握得足够牢。你可能刚碰到瓶子，还在寻找合适的位置；也可能正准备换个握法……摄像头看见了这个动作，却未必能据此判断，你是否已经能够承住瓶子的重量。

再加上力传感器呢？机器人可以感受到有人在拉瓶子，或者发现自己承担的重量正在减少。这些信息能帮助它判断，交接是否正在发生。

不过，一次碰撞也会造成受力变化。人拉了一下，也可能只是在试探它会不会松手。

这里有一个很重要的区别——传感器能够提供位置、接触和受力等信息，但对方已经拿稳则需要系统根据这些信息作出判断。

在机器人技术里，这涉及状态估计，我们想知道的状态，往往无法直接测量，只能通过能够测到的信号去推断。产品需求里，有很多类似的表达——用户已经准备好、用户想要继续、用户完成了操作……

它们读起来都很明确，落实到机器上，却需要逐个追问，依据是什么？

一项2022年的交接研究，就把两类信息结合起来：视觉用于判断接收者的手指是否环绕物体，机械臂的关节扭矩信息用于区分拉动、持握和碰撞，再综合决定是否释放。扭矩可以先理解为关节受到的转动作用，它的变化能帮助系统判断接触带来了怎样的受力变化。

这是一种具体的研究方案，它值得关注的地方，是把有人碰到了物体和现在适合松手之间的判断过程，认真做了出来。

而判断条件本身，也会改变体验。假设我们把拉力超过某个值作为释放条件之一，这个界限就是阈值。其他条件相同时，阈值调低，轻轻一拉就可能触发释放，也更容易被较小的意外受力触发；阈值调高，人就可能需要拉得更用力。

在工程界面里，这可能只是一个参数。但在拿水的人手里，它表现为怎么还拿不下来。因为我们不能默认，每个人都会用相同的方向、相同的力度取物。

一个在熟练测试人员手里很顺畅的设置，换个人就可能显得迟钝。

参数调整到这里，已经牵涉产品选择——这段配合需要人付出多少力气，又允许人有多少不同的习惯。

接水的人，也在判断

人不会始终按照预定的方式接那瓶水。

机器人握着不放，你可能继续拉，也可能松手；如果它说“请取用”，你可能更早伸手。

拿不下来时，有人会怀疑自己操作错了，有人会觉得机器出了故障，转头去找工作人员。

这些反应，又会成为机器人下一刻收到的信息。

机器人根据人的动作调整，人再根据机器人的反应调整。双方的行为就这样接在一起，一个很小的停顿，也可能改变后面的过程。

理解到这里，反馈闭环就不难了——机器人获得信息、作出判断、执行动作，然后继续观察发生了什么，并据此调整。对于交互来说，这个循环里还有一个会理解、会迟疑、会改变主意的人。

因此，一句提示也会影响系统接下来面对的情况——“请取用”暗示现在可以拿，如果语音已经播出，机械臂却仍在调整位置，语音模块与运动模块各自正常运行，放到一起，时机却未必合适。

一句话的长度，一个动作结束的时刻，在这里都有实际的分量。

这也是设计师和工程师需要坐在一起讨论的地方。设计师要知道，系统此刻掌握了什么信息；工程师也需要知道，一个动作或一句话，会让人产生什么预期。

自然一点、礼貌一点，还不足以让这样的配合发生。我们需要继续往下思考，提示出现时，机器人是否已经到达适合交接的位置？人开始接取以后，它是否还会移动？如果迟迟无法确认，怎样结束这次尝试，才不会让人和机器僵在那里？

这些问题，也不一定都靠增加说明来解决。有时，把瓶子放低一点，让人更容易握住；把可拿取的位置露出来，减少寻找；让动作停得更明确，给对方留出回应的时间，就可能改变整个过程。

具体有没有帮助，要放回实际使用中观察，设计可以让人的动作更容易发生，也更容易被机器理解。

也可以换一种递水方式

讨论到这里，产品经理还应该往前一步思考——用户需要喝到水，我们为什么选择让机器人把水直接递到手里？

也许可以把水放在托盘上，让用户自己拿；也许可以送到桌边，放稳之后再提示。

一旦这样调整，需要解决的技术问题也变了。

手递手时，有一段时间是人和机器人共同支撑物体，系统需要判断重量怎样转移，以及何时释放。如果先放到稳定的支撑面上，再由人拿取，就可以免去双方同时持握物体的这一步。

新的方案仍然有自己的要求，人要能够够到，放置位置要合适，机器人也可能需要确认物品是否被取走。但交接已经不必在双方同时动作的几秒钟内完成。

有些场景适合这样做，有些则不适合。如果使用者不方便起身，或者伸手范围有限，把水直接递到手边就可能有明确价值，此时，精细的交接能力值得投入。

反过来，如果使用者只是顺路取一瓶水，一只机械手带来的价值就需要重新衡量。

我觉得，这是HRI对产品工作很有帮助的一点——它让技术方案和人的处境始终处在同一张桌子上。

我们可以改进感知与控制，也可以调整物体的位置、动作的顺序，或者重新分配人与机器的工作。选择哪一种，需要知道使用者是谁、身处怎样的环境，又希望省下什么。

在画出那只机械手之前，这些事情就值得讨论。

把人做的那部分，也算进去

现在再看最开始的那次递水。

水最终到了人手里，是一个必要的结果。但如果只记录成功，就会漏掉中间的迟疑、两次拉动，以及突然松手带来的晃动。

这些细节能告诉团队，下一步应该改哪里。

人是在等机器人，还是不知道该怎么拿？机器人是在等待足够的接取证据，还是处理信息太慢？补一句提示有没有用，还是应该改变交接的位置？

同样一句拿水很费劲，背后可能藏着不同的原因。

我也会留意测试时站在旁边的人。如果工作人员需要提醒现在拿、再拉一下、别松手等，这些话应该一并记录。

它们完成了一部分交互工作，说明产品还有信息没有表达清楚，或者仍然依赖人的临场帮助。

熟练的人常常会把这些空缺补上，甚至不觉得自己多做了什么。但第一次见到机器人的人，未必知道该怎样配合。因此，评价交互时，需要同时看任务结果和完成过程。

物体有没有被稳妥接走，花了多长时间，人有没有反复尝试，是否需要旁人介入……

HRI里有许多技术问题，也有许多这样的细节——手停在半空，人等着一句没有到来的提示，工作人员伸手扶了一下。它们不一定出现在演示的重点里，却会留在使用者的感受中。

写需求时，不妨在用户接过物品这里多停一会儿。

把这几秒钟里，人需要知道什么、机器能够判断什么，都写得具体一些。

至于那只会递水的机械手，可以等我们知道它究竟为谁省下了什么，再决定要不要造。

一瓶水在两只手之间停留的几秒，藏着技术与人相处的分寸。

松得太早，风险落在人身上；握得太久，帮助又成了牵制。写在程序里的释放条件，到了生活中，就是一个人是否需要猜测、用力，或者为自己的迟疑感到局促。

设计越往深处走，越需要看见人的不同。

他有自己的力气、习惯和节奏，可能慢半拍，也可能临时改变主意。这些差异应当像技术参数一样，成为设计的起点。

让人保有按照自身意愿行动的余地，是我们赋予机器能力时，也应当承担的责任。

我期待的交互，最后可以安静地退到生活背后：水到了手里，人不再琢磨该怎样配合一台机器，只是拧开瓶盖，喝了一口。

注：文中的递水场景为设计推演，具体交接策略需要结合硬件条件与实际使用环境验证。