本周工作思考
继续上周的脚步生成器的开发，本周有一半的时间用在了脚本生成的开发和完善了。测试的典型场景准备的4套，为了验证，json格式和yam格式都要写了一份。典型场景一般是多余2轮对话，所以上周设计的算法实现上问题不大，本周测试上数据比较极端，2轮对话都是自动回复，这个其实在真实的用户场景中不会出现，但是用户很可能会验证脚本编辑器和Chatbot的产品能力，可能会这么写，所以针对这些场景做了算法上的调整。之前的算法的思路是Flow，对话流的形式，把Bot和Human个字的对话分别放到队列了，因为所有的对话都是围绕人的对话进行的，所以转译的过程就是基于人类对话进行，简单说就是一个循环，Bot一句，Human一句，加上跳转结构，就形成了转译后的对话格式。这种算法比较简单，而且需要固定的对话写法，这种算法我用在了基于google sheet的脚步生成工具中，还能勉强用用，放在脚本编辑器里，就解决不了系统提示的位置问题。为了解决这个问题，把基于对话流的实现改成基于轮次流的写法，基本思路是把对话转成一个一个的对话组，这个一个对话组我称为轮次，其中包括一个对话的三个角色：Bot，Human，System，这样各种信息都存在在轮次里。总的来说，脚本转译要保留的信息包括：各个角色的对话顺序，对话内容，逻辑生成跳转关系，附加上每个对话的设置信息。
在开发过程我也遇到了一些不好解决的问题，主要有2个，Chatbot开发术语和脚本的文法。Chatbot开发术语是个统一规范的问题，本质上是开发生态的问题，这是个看起来没啥，有开发经验的伙伴都知道，关键术语的提炼和命名是系统设计的第一步，命名对了，后面的动作就都对了，这个确实十分重要的事。比如在开发过程中我经常会遇到一些命名，比如轮次，对话，场景，脚本，提示，对话失败提示等等，这些次在开发中意味概念，背后对应着开发设计思考，现在网上很难找到公认的叫法，也可能是各家的Chatbot的实现各不一样，提炼的术语也就不同。不过这也说明各家都在摸索前行，各家都各自的Chatbot的技术细节对外界都有所隐藏。
另外一个就是脚本的文法规范，定义哪些脚本是合法，哪些是不合法，各个关键词的用法如何， 比如2轮自动对话是否是对话引擎支持，一轮次对话怎么写，目前这些都还要再开发过程中逐渐完善和对齐。