关于魔镜系统的故事

2016年下半年，我们做了一个领域知识库项目，后来给那个系统取了个名字叫魔镜。

甲方一开始规划的建设内容是做领域知识库，从本体层、模式层、数据层、服务层、计算层、应用层，一个关于知识图谱全栈的建设方案。好多概念我那会儿都没听过，因为那之前对知识图谱停留在概念层面，没有系统学习。

我们做开发的总共就3个人，两个计算所员工，加一个硕士研究生（我师弟），我负责总体设计、业务后台开发和部分前端开发，同事负责数据接入处理，我师弟负责知识库的前后端开发。刚开始的时候全部需求就来自甲方的项目，跟我们对接的罗老师胖胖的，他一直说他是学数学的不懂计算机，但在我看来对知识图谱的研究属于专家级的。

7月准备标书，8月投标，9月做Demo系统，10月到广州用户单位部署试用。我们的甲方也非常希望能够做出实际成果，所以一直带着我们跟用户交流、讨论。刚开始的时候主要是我老师负责需求沟通、技术交流等，所以这中间经历了什么不太清楚，但结果就是有一天罗老师跟我们说要重新设计系统。

罗老师是这么说的：知识库这个东西太高大上了，用户听不懂、不会用，所以咱们得找个实际的业务场景，调研后发现，用户日常业务中的一个分析工具MailStore，觉得不太好用，另外他们现在的业务流程需要同时使用好几个工具，工作效率比较低，应该针对业务定制一套系统，提升用户的工作效率。

如果只是项目验收，以甲方和用户两家单位的关系，肯定是没问题的。项目经费都是从上面申请的，建设成果找个用户试用一下盖个戳很容易。但是很庆幸的是，当时大家目标非常一致，就是要让系统发挥实用效果、解决实际问题。

出发点对了，事情做起来就比较顺，中间的磕碰都只是一时的困难。

我们采用了敏捷开发、快速迭代的方式。那会儿到过年就2个多月的时间，基本上每周都要给用户看一下，用户还会经常提一些新想法。整体上面向用户的业务场景设计系统功能，但同时为了项目验收，体现一定的先进性，所以我们将领域知识库的技术理念和业务结合，用户在做任务的同时能够持续积累知识，形成领域知识库，系统能够利用这个知识库，对业务进行推荐、挖掘等。系统功能开发了一版后，又从所里协调了一位专业的UI设计赶赴现场，对系统界面进行全面美化。值得一提的是，UI设计的时候特别考虑到了系统主要用户的特点，在颜色、布局、边框、字体等方面进行了细致的设计。

核心业务不方便讲。总结起来系统具备几个特点：贴合任务、结果导出、知识积累、大数据处理、智能推荐。最终的效果就是提升工作效率，并且把过去无法完成的大规模数据快速查找变成可能。

有了这种实战效果，验收很顺利。用户方领导视察的时候，系统汇报和演示很亮眼。17年1月项目验收后，我们就开始做系统上线准备，我和老师一直待到春节前2天。我老师为我跟老板特别申请给我购买了从广州回重庆以及节后从重庆返京的机票。17年系统开始投入使用，也陆续遇到了一些问题，主要是功能有BUG还有数据处理问题，我和同事前后去了广州好几次。后来我同事工作变动，基本就是我一个人负责，包括后来在深圳另一个用户单位的部署试用。

从那以后，一直到现在，用户一直在用这套系统。18-19年，公司争取了项目二期，给重新开发了一套系统，我因为调整了工作，所以没有参与二期。据说，二期系统完全没有用起来。直到今年早些时候，用户单位的运维同事还在跟我联系，问能不能给优化一下系统。

6年前设计开发的一套系统，近三年没有维护，由于数据量大现在一个搜索能卡10秒钟，但用户至今还在用，为什么？因为真的有用！