我们使用actions.intent.OPTION来处理 Google 操作中列表响应类型的选择。actions.intent.OPTION不仅处理用户选择(触摸)输入，还处理列表后的用户(语音/文本)响应，并将用户响应很好地映射到列表中的项目。它还在一定程度上处理拼写错误。
但是，很难处理不想从列表响应中进行选择的用户响应。基于谷歌官方指南 (https://developers.google.com/actions/assistant/responses#list)，我们使用建议芯片来透视或扩展对话。
我有一个用例，其中用户可能会使用很少可能的文本来指示他/她不执行选择。例如：
bot: which food do you want?
(showing list)
- rice
- salad
- pizza
(suggestion chip)
not in this list
这些是我们可以处理的用户响应：
- 触摸列表中的选择(米饭、沙拉、比萨饼)
- 指示列表中项目(或类似于列表中的项目)的用户文本或语音。Google 行动可能会将"炒饭"视为米饭选择。
- 触摸建议芯片("不在此列表中")表示用户不需要列表中的所有项目。我们可以处理此对话流。
但是，如果用户说出其他文本，例如"我改变主意"、"让我们做其他事情"、"让我们再做一次"或"重新启动此步骤"，我们将无法处理此问题，因为 Google 操作和对话流会自动将这些文本映射到列表中最相似的项目(字符串相似性)。
处理用户响应的任何好做法，谁不选择建议芯片旁边的列表中的任何项目？我觉得一个建议芯片不足以处理用户响应的许多变化。
当用户通过语音选择列表项时，助理会将输入映射到列表项的键和同义词。然后，密钥将作为输入发送回对话流代理。当映射不成功时，不会触发actions_intents_OPTION事件，并且输入只是与所有其他输入一样与所有意图进行匹配。这意味着您可以通过简单地为它们添加正常意图来捕获诸如"让我们做其他事情"之类的请求。要确保此意图在列表选择流之外不匹配，您应该在显示列表时设置上下文，并将该上下文作为输入上下文添加到ChangeMyMindIntent。
以下是更详细的工作方式：
- 正常的列表选择将由
FoodSelectionIntent捕获。此意图响应actions_intents_OPTIONS事件，即不需要有训练短语。它应该具有food_selection输入上下文，以将其与其他列表选择意图分开。 - 然后，您可以为用户除了实际选择项目(
ChangeMyMindIntent、RestartIntent)之外可以发出的所有请求添加其他意图。这些也应该具有food_selection上下文，以便它们在对话的任何其他点上都不匹配。 - 呈现列表时，也会设置
food_selection上下文。这可确保下一个 Webhook 请求将包含有效的列表选择(由FoodSelectionIntent捕获)或您已限定为food_selection上下文的替代意图之一。
不要忘记在此 - 流完成后删除
food_selection上下文(将其生命周期设置为 0)，以免限制下一个请求的意图匹配。