我想知道Dialogflow中是否有针对意图，事件和上下文的约定的命名约定。
如果没有，那么如果您共享自己的命名约定，我将不胜感激！
答案 0 :(得分：3)
不幸的是，没有任何东西，而且该系统足够灵活，因此无关紧要。选择有意义的名称（duh）。
尽管大多数示例都使用它，但我避免在名称中使用空格。我将它们更像函数名一样对待，因此在其中保留空格会破坏我的美观。
我倾向于将Intent根据他们正在进行的会话的哪一部分进行分组，这是通过使用设置的上下文进行管理的，并通过点将零件和子零件名称分开，因此它看起来像是包装名称。我将把Intent命名为
calculate.fallback
calculate.number
calculate.operation
fallback
welcome
“计算”的输入上下文均为“计算”。
最重要的是，请记住，意图（以及它们的名称）代表了用户所说的，而不是代表了代码的作用。这是与函数名称不同的大方法。
答案 1 :(得分：2)
老实说，真的没关系！只要它易于在代码中复制并且可以清楚地看到/理解可能正在您的代理上工作的其他任何人，那么一切都很好。通常，尽管使用诸如CamelCase之类的典型编码符号可能不是一个坏主意。
答案 2 :(得分：1)
我将从基于服务的公司项目的角度回答这个问题。
在我的项目中，我们将意图的命名约定与内置的小谈话意图使用了相似的命名约定，因为它易于理解和分类。如FAQ.Comapny.your_question，Buy.Drinks.coffee等。
（出于某些未知原因，我们将意图的主要类别的首字母大写，在闲聊中，所有字母都应为小写）。
对于事件，我们对通用常量使用了类似的表示法，例如INVOKE_EVENT。
对于参数和上下文，我们使用了snake_case即coffee_cost。
基本上，只要它易于理解和复制就没有关系。但是您应该始终具有一个基本结构，您和您的整个团队在整个项目中都会遵循该结构。
答案 3 :(得分：1)
我发现说“只要对别人很容易理解就没有关系”确实有点矛盾。如果有命名约定，则使人们更容易理解新的Dialogflow机器人。
这是我的看法：
我使用点对意图进行分组并暗示层次结构。理想情况下，意图名称的第一部分只是一个单词，可以清楚地表明意图的主要主题。例如
name将是接收用户名作为输入的意图。 name.confirm是接收该名称确认的后续意图。 name.confirm.yes就是用户给出确认的意图。
这是在正在收集联系人数据的机器人的上下文中，因此暗示了 input 功能。在更多类型的聊天机器人中，您可以将意图类型添加为第一个单词，以更好地对意图进行分类。例如。 input.name.confirm.yes或FAQ.shipping.overseas或smalltalk.agent.location（“你在哪里？” ）。
我对后备意图使用相同的方法：fallback.name是当机器人在等待用户输入名称但不理解答案时触发的后备意图。
对于上下文，我使用驼峰式大小写。例如，awaiting_email是机器人在等待用户输入其电子邮件地址时设置的上下文。获得电子邮件地址后，我将设置一个上下文email来转发信息，以便其他意图可以将其用作上下文。或者，如果我要收集有关用户的几条数据，则将设置上下文user，其他意图可以访问某些参数，例如通过user.email。
我也制作了有关该主题的视频：https://youtu.be/kgKuS2RJcy4
很明显，每个人的角度都略有不同，因为他们的应用领域不同。我相信我们最终会达到一个共同的标准！