在这种情况下，我们的 Webhook 将向 Google Cloud 函数 URL 发出请求（稍后会详细介绍）。我们发送的请求将包括有关用户的一些信息以及我们需要代码执行的操作。该信息将采用 JSON 格式（与我们用于导入上面共享的 Twilio 流程的格式相同）。
我们的 JSON 将包含已发送消息的特定 Twilio 电话号码，以及联系我们的电话号码。它还将包括我们收到的短信内容和我们之前设置的“阶段”，因此代码知道用户正在寻找什么。
然后代码将执行一些操作
（我们稍后会介绍）并返回其自己的信息。然后我们可以告诉 Twilio 在消息中使用部分响应。
发送消息作为回应
接下来，我们可以使用收到的信息来构造消息并将其发送给用户。 Twilio 会记住您正在通话的号码，并将您的消息发送到该号码。
这是“发送并等待回复”小部件，这意味着一旦发送此消息，Twilio 将假定对话仍在进行，而不是就此结束。
在本例中，我们正在编写欢迎信息。我们可以只写出简单的内容，但我们 电话号码 想使用从 Webhook 小部件获得的一些变量。我们将该特定的 Webhook 小部件称为“get_options”，因此我们通过编写以下内容来访问从中获取的内容：
响应以 JSON 形式返回
幸运的是 Twilio 自动为我们打破了这一点。
我们可以通过编写“已解析”来访问响应的各个部分，然后编写 马特·谢尔曼 高级副总裁 营销总监 我们在响应中提供该信息的标签。事实上，代码的响应看起来像这样：
{“名称”：餐厅名称，
“dishes_string”: “您可以选择玛格丽塔披萨、夏威夷披萨、素食披萨”
“additions”：“大、中、小”}
我们通过编写“”来获取可用菜单，然后编写下面的消息，该消息将发送给联系机器人的人：
根据消息做出决定
我们不能假设每个人都会以完全相同的方式使用机器人，因此我们需要能 安圭拉讯息 够根据某些条件改变我们所做的事情。 “基于…分割”小部件是我们选择某些条件并设置满足条件时要执行的操作的方式。
在本例中，我们使用对上一条消息的响应内容，我们使用 {{options_follow_up.inbound.Body}} 访问该消息。 “Options_follow_up”是我们刚才谈到的发送和等待小部件的名称，“inbound”表示响应，“Body”表示其中的文本。
然后我们设定一个条件
如果用户回复“其他”、“不”、“帮助”等任何内容，他们就会被转到另一个轨道去打电话。如果他们回复的内容不在该列表中，他们可能正在尝试订购，因此我们接受他们的订单并使用我们的代码进行检查：