我正在尝试开发用于食品订购服务的chatbot / google助手服务，目前，我是通过以下方式设计的：
有一个动态菜单列表，每次用户要求菜单时都会通过API获取（新的订购意图） 然后将显示菜单类别名称列表 然后用户发送类别名称 第二个跟进意图（选定的类别意图）将其捕获并获取该类别中的食品 然后用户发送食品名称 然后下一个跟进意图（选定的项目意图）将其捕获并询问数量。
这里的问题是，因为它是动态列表，所以我无法使用自定义实体和插槽填充并对其进行训练，因此我当前正在使用@ sys.any实体。从用户那里获取类别名称，并检查它是否存在于Webhook的菜单列表中（如果存在）显示项目列表。如果不存在，请检查拼写或输入正确的菜单类别并重新输入提示。 然后在这里，因为已经使用了“选定类别意图”，所以我现在输入的任何内容都将作为“商品名称”而不是“类别”
我通过匹配“选定类别意图”实现中的输出上下文和“选定项目意图”中的输入上下文来防止这种情况。但是这种方法存在一些问题，例如一旦选择了类别，我将无法返回并更改它，并且在回退意图之前它只能工作5次（父意图上下文的寿命）
我知道这确实是一个糟糕的设计，但是有什么方法可以使它更好？
有什么方法可以说如果用户输入了错误的类别名称，不，不就不会消耗这个意图，而是返回并获得正确的类别名称吗？
或者如果用户错误选择了类别或项目。有什么办法可以回到以前的意图，然后再做一次？
答案 0 :(得分：2)
一些观察结果可能会有所帮助：
使用会话实体
由于要动态加载类别和菜单，因此也可以动态设置这些实体和菜单。为此，您将使用Dialogflow的API创建Session Entities来修改您定义的实体。然后，您可以使用使用该实体的短语来训练自己的意图，但是当他们开始对话时，您将动态修改该实体。
不要使用跟进意图
跟进意图在非常有限的情况下很有用。一旦开始链接“跟进意图”，通常就表明您试图以一种特定的方式迫使对话进行，然后当对话需要稍微转弯时，您就会遇到麻烦。 / p>
相反，请继续使用顶级Intent进行尝试做的一切。
“但是，”我听到您问，“然后如何确保在选择菜单之前先处理类别选择？”
好吧，要做到这一点...
使用上下文
当您说匹配输出上下文时，您处在正确的轨道上。您不仅可以匹配，还可以继续 control 在您的webhook中设置哪些上下文。因此，您可以使用Input Contexts来缩小在会话的任何状态下匹配的Intent，而仅在webhook实现中设置Output Context来确定在会话的任何阶段有效的Context。您可以通过将其寿命设置为0来清除不再有效的上下文。
因此在此方案下：
最重要的是，记住...
Intents represent what the user says, and not how you react to what they say.