2018年一月前后，我在为本科毕业论文找课题。因为选的是计算化学，而本专业又是计算机科学这种和化学前沿毫不相干的学科，选题甚是费劲。当然我也可以选择导师的RNA分子力场方向，但好奇心驱使我向着分子间相互作用和分子模拟进发，所以我选定了氢键型晶体。在参考了几篇计算化学尤其是卤键课题的文章后，我意识到还是应该在ACS的Crystal Growth & Design里集中寻找关于氢键型晶体的研究。问题就发生在寻找过程中，并且当时的想法使得我在之后的两年内完成了Research Flow的初步开发。

我设想能有一个应用程序帮助我寻找感兴趣的文章，而我所需要做的只是告诉它我对什么感兴趣。导师说过针对一个方向查阅文献，不光要查大量的文章，还要知道哪些作者经常做这个方向，他们又写了哪些其他文章。这些建议不仅利于我们完成课题调研，更让我在脑海中建立起了类似于知识图谱的图像，完善了对这个应用程序的设想。于是在2018年1月4日，我通过RSS服务在刷手机的时候发现了一篇关于氢键型共晶分子踏板运动研究的论文，并将它定为毕业论文选题。在毕业之后的假期里，我首先开发了一个简易的RSS接收器；在一年之后，苯环双键图案（分子踏板运动的典型发生环境，文章中为偶氮吡啶）成为Research Flow的图标。

其实在软件开发早期，我很少真正的去做论文搜索器的工作，而是把大量的时间花费在后台应用层。主要解决了三个课题，OneDrive同步算法、Sqlite数据库操作，强实体关系。这三个课题非常恶心，尤其是第一个。因为当你把所有逻辑和上传下载等操作一一对应之后，发现程序无法判断是否应该上传本地文件还是删除本地文件，这源于你根本无法获取OneDrive文件的更新记录，而这个记录是要在所有可能的设备上都能访问到的。当然问题肯定解决了，而且非常巧妙。数据库主要是表设计，好在全是强实体，关系由程序处理，就是改BUG，功能模块衔接等操作比较麻烦。强实体关系由用户操作（软件的宗旨是尽可能减少人类操作，而把任务交给机器）代替原先设想的Flow数据结构。除此之外，还自主解决了应用内消息机制、通知管理、数据存取、各种用户操作业务逻辑等问题。总之独立软件开发要解决很多问题，有些要靠技术，有些要靠设计，很是浪费时间。

从今年一月到二月下旬这段时间，是Research Flow开发的关键时期。因为我知道要完全完成这个应用，这个假期肯定不够用，况且我不能因为疫情的原因在家写代码荒废学业。所以我尽可能先把人类操作的那部分完成，即这个软件已经可以用了，但是不好用。不好用是因为它目前还不是机器人，而且各种功能并不是连接的很紧密。下面我介绍一下各个功能和设想。

    Tag & Topic，这应该是首页了，因为在Task开发好之前Overview页面暂时无法推出。左边的是用户输入的或者应用自己找到的标签，编辑方法类似于微博那样，#Tag#。这些标签表明当前用户对那些领域感兴趣。如果你点击某个标签，会汇总这个标签存在于哪些数据，一目了然。当然在机器人完成前Tag只是个摆设。右边是Topic，定义很灵活，可以是笔记、闹钟、提醒。在未来的设想中，Topic是获取用户需求的窗口。用户只需要在Topic中以一定格式编辑文本，就可以提交任务让机器去完成。而Chat窗口则是整个应用的门户，包含Topic。

论文管理。我不打算做PDF阅读器，因为我做的没别人的好，所以在这个页面你只能预览PDF的前十页。它的功能是告诉你，你有哪些论文需要关注。这些论文可能是你导入的PDF或者是应用帮你下载的，也可能只是一个网页链接，这些都不重要。重要的是你可以在这里标明从这篇论文中学到的东西，方便以后翻阅论文或者在自己的论文里写reference的时候知道为什么cite。It works for me. 我需要这个功能，尤其是有很多文献需要参考的时候它对我很重要。所以我不清楚其他用户是否也同样看好它，这一点我没做调研。当然功能肯定不止如此，只是还未完成。论文可以定义Tag，可以让机器去分析，可以让爬虫去爬，可以做统计，看看谁写了哪些文章，又引用了谁的文章。树结构数据库就是干这事的，这些在今后都能完成。但它比起下面三个功能，只是个独立功能。