我们的代码不会尝试处理任何实际对话，它只是从 Twilio 获取请求（包括有关用户及其所处阶段的详细信息）并执行一些简单的功能。
第一阶段：“开始”
代码会收到来自 Twilio 的消息，其中包括已激活的 Twilio 号码以及用户所处的阶段（开始）。由于处于“开始”阶段，因此代码会激活开始功能。
它根据 Twilio 号码查找特定餐厅的表，然后返回该餐厅的菜单。
它还会向 Twilio 发送一些信息，比如具体餐厅的号码、菜单和附加内容的精简版，以便我们检查订单。
第二阶段：“选择”
代码接收用户所处的阶段（选择）以及他们的订单信息、餐厅的表单 ID 和精简菜单（之前已发送给 Twilio），因此我们不必再次查找这些内容。
基于处于“选定”阶段，代码将激活选定函数。它会检查订单是否与我们的精简菜单相匹配。如果不符合，它会告诉 Twilio，该消息看起来不像订单。
如果订单与我们的菜单相符，它会将订单记录在第一个空白行中。它还会创建一个订单 ID，该 ID 是时间和部分用户电话号码的组合。
它向 Twilio 发送一条消息，告知该订单是否与我们的菜单相符，如 克罗地亚手机号码数据 果与我们的菜单相符，则告知订单号是什么。
第三阶段：“到达”
代码接收用户所处的阶段（已到达）并激活已到达功能。它还接收描述用户车辆、餐厅特定表单 ID 和订单号的消息，所有这些信息它之前都告诉过 Twilio。
它查找餐厅表，找到与发送的订单 ID 匹配的订单 ID，然后更新该行以显示用户已到达以及他们的汽车的描述。
Twilio 处理所有上下文
你可能觉得很奇怪，每次代码找到一些信息（例如，要查找的表单 ID）时，它都会将该信息发送给 Twilio，稍后再重新请求。那是因为我们的代码根本不知道发生了什么，除了 Twilio 告诉它的内容。每次我们激活代码时，它都以完全相同的方式启动，因此它无法知道哪个用户在向 Twilio 发送短信，他们处于哪个阶段，甚至不知道我们在谈论哪家餐厅。
Twilio 会在交互过程中记住这些事情，所以我们会用它来处理所有这些事情。我们的代码是一个非常简单的“执行器”——它每次“知道”的事情不会超过五秒钟。