规则未必都需要对应一个 intent，同一条规则在不同场景下应该会存在共用关系。
规则的使用是自始至终的，从识别 intent 到后续的对话过程。
规则应当有抽取非可枚举值，也即子串的能力。
intent 与通常意义的槽可以看做是平级的实体，只是搜索策略不同。
规则应当分为共用和非共用，不同业务方应当使用不同的规则域。因为同一位置的同一个词可能会被不同规则抽取到不同的实体中，不同业务方之间不应相互影响，同一业务方在编写规则时也应当注意通用性。
规则应当有能力根据位置/角色识别同类实体。
相似问句语料的提供可以通过与规则编写相同的方式进行，搜索策略采用 trait 即可。
模型的训练是实时的且不可见的，通过 expression 可以即时验证结果。
还不了解的是：
如果一次标注中抽取了多个实体，那么在用户问句不完整的情况下，能否将原标注结果中全部实体的一个子集抽取出来。也即抽取的粒度，是一个实体，还是一次完整的标注？推测为一个实体，但当出现冲突时，与完整标注更接近的应当拥有更高的优先级。
由此看来：
Bot 的回复应当能够使用从用户问句中抽取过的实体值。
slot-based bot 的实体之间是平级关系，flow-based bot 的实体之间是依赖关系。
槽的必填/非必填、单值/多值、值的使用方式都被隐藏在调用的函数中。
对话状态追踪（DST）通过函数对 context 的管理来完成，候选动作排序也在函数内部处理完成，并以 context-key 的方式作用于后续对话。
与百度 UNIT 平台相比，传入 context 并由函数进行 DST 和 policy 的方式要比为答案提供设置准入条件的方法要更加灵活。
目前的 wit.ai 中似乎没有反映出多轮过程与答案系统分离的思想，还是较为原始的，从头至尾，非叶子节点中的 Bot sends 算作多轮过程，叶子节点的 Bot sends 作为答案。
Facebook 也发现对话系统能够利用的不应该只局限于用户问句中提供的信息，推出了 Bot engine，可以使用用户画像以及场景信息；意识到答案也不应当只局限于简单的文本，推出了 Built-in NLP for Messager，可以调用丰富的前端样式来做答案的展示。
对话系统应当具有节点间跳转的能力，wit.ai 采用 bookmark 来完成。阿里小蜜的在订票场景下的『换出发地』应当也是相同的原理；商品推荐时的『换一换』推测是通过该方法重复进入相同的推荐节点，但 context 中会记录该节点的进入次数，进而展示不同的结果。
常用的肯定、否定、请求更多等用户动作应被当做 intent 来处理，同时要注意不能只将其看做一些词的合集来处理，而是采用 trait 策略整体看待以识别意图。
bookmark 是可以跨 branch 访问的。
同一个 Session 中，通常只有一个 context，这个context 由我们自己的函数维护，根据 context 的不同做出不同回应，返回不同的值，而后续的对话过程又依赖于函数调用的返回值来做多轮对话的分支。
quick replies 可以每次单独设置，但也可以尝试把 keywords 类型实体的实体值词典利用起来。
还不了解的是：
废弃现有的 Stories UI 后，用户画像以及场景信息由 context 传递，由函数来做 DST，应当是没有疑问的。但前端模板的调用是由函数来做，还是由当前的 Bot sends 模块改进得到？若由函数来做，一是更为灵活，二是可以将多轮过程与答案系统分离，Bot sends 只起到澄清以及推进对话的作用，而不是同时兼具答案提供的功能。
