“友善”是一种人性化的人际关系。所有其他含义都是衍生的。我们认为其他人的行为使我们感觉良好“友好”，并且很容易将该定义扩展到机器和计算机接口的行为。不幸的是，在过去的几十年里，我们都被灌输了“友好与效率”或“易用性与权力”之间的虚假权衡。

对于第一次使用Unix的用户来说，列出目录的“友好”命令可能是“你能告诉我当前文件夹的内容吗”，而古怪的，深奥的神秘“ls”可能看起来像是一个缩影。冷漠和敌意。与此同时，如果经验丰富的系统管理员被迫键入“友好”版本而不是ls或交换后者丰富的“简单”选项，他们很可能会认为这种情况明显不友好。因此，工具的“友好性”在旁观者眼中。

然而，谈到人际关系，除了一小部分病人，每个人对“友好”的定义几乎都是一样的。我们进一步尝试从其原始背景中应用形容词，定义越发散，最终形成军事俚语，可以指用于消灭数百万“敌人”的“友好”500 kT弹头，而这些“敌人”反过来对武器的“友善”深感不安。

相反，情况越接近人际关系，就越容易就什么是“友好”达成一致。在用户界面世界中，它与自然语言交互并没有太接近。在任何具有NLU的系统前面，突然变得更容易，不仅容纳各种用户，而且设计友好的界面充满信心：设计师，作为人，具有识别友好对话的天生能力。

例如，一个人会不会认为一个人忽略了他们试图对话的尝试是友好的？当然不是，机器人将以同样的方式判断。与此同时，一个过于健谈的机器人不会在小组对话中等待它，并且响应聊天室中发出的每一个短语都会让人感到被视为具有类似行为的人类 - 或者更糟。

要点：友善是大多数人的自然状态，对于任何努力模仿它们的构造来说都是绝对的必需品。幸运的是，它很容易实现，甚至更容易验证。

任何曾打电话给技术支持组织的人都知道“友好”和“乐于助人”之间的区别。显然，训练你的人类代理人要友善而不是有帮助要容易得多（虽然我已经看到了非常有用的例子，但我们可以说，情感保留的代表）。使用bot代理同样难以实现有用吗？在某种程度上，这是因为机器人只是人类设计师优势和劣势的投射。呼叫中心员工和机器人设计师可以同样懒惰和惰性，并以非常类似的方式影响他们的客户：前者直接和后者通过机器人行为来预测他们的缺点。

在编写对话框时，我们根据自己与其他人交互的经验这样做。因此，我们本能地要求机器人获得一定程度的尊重和尊严，作为我们自己的部分实例。另外（更糟糕的是），我们决定工作的某些“公平”分裂：如果你这样做，我会这样做例如，“如果你想让我为你创建一个lambda函数，那就好好阅读关于这个主题的帮助，并学习你应该问我的确切方法。”我们要求与毕竟，用户，我们都是人类。但“我们”不是！如果只是因为那会让人类用户感到不舒服（他们也会遭受与作者相同的人与人之间的互动妄想），机器人不应该过度ob媚和自我贬低。但是，机器人应该始终提供尽可能多的任务，并以其他方式协助其人类用户。例如，如果用户询问“我的训练舱如何进行”，平庸的机器人将检测到“获取吊舱状态”意图，并将引出“请指定您想要状态的吊舱列表”。

这是一个典型的例子，“我会这样做”，如果你这样做“无益的模式：机器人正在以人类用户提供”训练吊舱“的精确名称列表为条件。假设用户不完全是Kubernetes向导，我们可以很容易地看到以下顺序：

网络搜索，“我如何列出一个部署中所有豆荚”，并在学习的是：

“我如何找到k8s部署标签或选择器”，并在更多阅读之后：

kubectl describe deployment rigd-train， 然后

kubectl get pods -l=service.name=rigd-train，最后，经过多次复制和粘贴后，机器人要求的“正确”消息：

get pods status for pods rigd-train-6b86c69-nfpzb, rigd-train-6b86c69-xcvkv

机器人不仅让人类通过篮球跳跃来获取帮助条件信息，而且在此过程中将自己的角色减少到无关紧要，因为通过检索训练吊舱的名称，用户已经看到了“他们是如何做的。 “

在这种情况下，正确的行为是什么？一个有用的机器人也将从“部署名称”实体中提取值“training”，它将对Kubernetes集群中的部署执行模糊匹配，它将暂时匹配“rigd-train”，它将显示：

rigd-train-6b86c69-nfpzb 1/1 Running 0 2d

rigd-train-6b86c69-xcvkv 1/1 Running 0 2d

但是，如果机器人弄错了怎么办？如果“训练”部署的实际名称是“模型维护”，并且事实证明“rigd-train”是跟踪最靠近RigD总部的Caltrain站的出发时间的服务怎么办？没问题，这就是为什么它被称为“机器学习”。机器人会问，“我做对了吗”，用户会说，“甚至不远程”，那就是那个。人类完全理解错误是暂时的，而恶劣的态度是永久性的，而且他们对前者比对后者更宽容。

要点：始终提供尽可能多的工作;永远不要求机器人自己获得的信息;不要害怕犯错：用户可以帮助修复错误，但设计不错。正如约翰·沃尔夫冈·冯·戈斯所说的那样，如果当时有机器人，那就是“如此强烈的话。”

并非所有机器人都具有自然语言能力。只要组成输入的指导清晰且毫不费力地可访问，部署需要高度结构化输入的服务肯定没有错。如果您的服务是与CLI聊天，那么您就是输入格式的最终权威，并且您有权要求用户遵守已发布的规则。他们将理解培训是使用该服务的条件。经典UI（GUI和CLI）是人类训练的文字示例：要使用系统，必须训练人类用户完全按照机器的方式并且没有偏差（过度拟合，硬化术语）。这就是为什么人们流利使用一个系统的UI时，如果没有重新训练就试图使用另一个系统的UI表现不佳。

但是，如果您的机器人声称具有自然语言界面，则将以完全不同的比例进行判断。人类可能是可训练的并且渴望学习新的界面，但如果机器人质疑他们已经拥有的技能，那么对于机器人来说这并不顺利。要求特定的句子结构，如“必须有谓词和主语”或词汇“必须包括我们批准的关键词之一”（不告诉用户这些关键词是什么的额外敌意点）是大多数人保证的关闭。即使您的用户无限容纳并愿意学习“自然”语言的细节，更有效的方法是什么：

AI“培训”不是单向过程。当人类与机器人交谈时，机器人会被分配给其决策的标签训练。然而，人类也受到机器人“帮助”系统的训练，并最终受到人类对机器人努力的成功或失败的影响。Bot UI的主要目标之一（和成功标准）是对人类的培训较少，对机器的培训较多。在这种情况下，“更多”和“更少”当然是主观的。毕竟，几乎所有人类用户都在幼儿时期接受了大量的培训，以获得这些自然语言技能。NLU只是让人们无需学习每个程序的特定“语言”。从绝对意义上讲，人类参与机器人对话可能需要大量培训，

建议可能会有所帮助，并且有专门提供建议的机器人。然而，未经请求的建议同样来自机器人，因为它来自人类（有时更是如此）。特别是当建议去执行机器人本身可以执行的某项任务时，或者以更适合机器人的方式格式化输入。这些类型的建议简直就是用户培训，应该避免。

关键点：人机交互是一个双向培训过程，但自然语言机器人的设计者应该抵制诱导用户如何与机器人交互的诱惑，而应该专注于培训机器人如何更好地理解用户。人类用户可能会下意识地将自然语言机器人提升到一个人的身份，但更高的位置也会带来更大的责任。

如果伟大的阿西莫夫还活着，他可能会想出一套完善的聊天机器人行为规则。但在他缺席的情况下，这项任务对于任何人来说都是一场公平的比赛。以下是我对“聊天法”的看法：

机器人总是友好的：

机器人从用户那里学习，而不是强迫他们从中学习

声称理解自然语言的机器人并不限制用户的语法，语法或词汇 - 当它不像人类那样理解用户的意图时，它就会承认它。

机器人永远不会在1：1对话中以沉默回答用户输入

机器人总是很有用：

机器人永远不会要求用户提供可以自行检索的信息

机器人能够引导用户完成它可以执行的每个功能的每个选项

机器人永远不会要求用户从列表中进行选择而不提供对该列表的访问权限

机器人不怕犯错误：

错误实际上是改进的机会（通过提供更多的培训数据）

人类对机器人错误的宽容远远超过他们丑陋的堂兄 - 计算机错误。

需要明确的是，除了阿西莫夫的原始法律之外，这些都不是代替的。自第一个“我，机器人”故事以来，管理人类行为的立法已经激增。如果机器人还能获得一些额外的规则，这是公平的。