项目需求

公司一个重要项目的立项之初，就确定其中有一个比较核心的文档录入和管理的功能。这个文档系统主要面向的用户是开发和一少部分PM。PM的定位目标是对标阿里云或者腾讯云文档系统。

开发思路

文档管理系统，需要考虑的最核心的两个问题：

文档编辑器选型
文档存储

开发之初，就考虑到了一部分用户会将其它格式下的文档复制到我们的文档编辑器中，因此旧的wiki文档的迁移等格式兼容问题需要考虑，所以采用了对格式较为通用的富文本编辑器完成该需求，它对其它文档的转换格式问题也不是很大。市场上的富文本编辑器比较成熟了，坑基本也填平了。文档存储目前不做静态化，将用户编辑的文档内容作为字符串直接存到数据库，等以后切换文档编辑器，后端不用做任何的改动。文档展示侧则直接动态渲染。

需求变更和解决方案

有一天，有一部分用户反馈，为什么我们不同markdown编辑器来完成文档的编写。PM考虑了下，这个文档系统的录入者大部分都都是开发，所以他动摇了，建议换成markdown，其实阿里云和腾讯云的文档也是markdown格式的。淡然我建议两个都保留吗，让用户去选择，markdown用来标准化我们的文档内容语法和格式，富文本作为备用的一个编辑器方便以前旧的wiki文档迁移。

与此同时，我调研了很多的markdown的产品了，有开源的，商业的。最开始我们采用了一款实用比较多的编辑器，但是实际实用过程中发现了一些编辑器本身存在的问题，联系作者提pr也没及时的受到作者的响应。所以我打算要再造一个“好用”的轮子呢。总结下“造轮子”的原因：

别的轮子不好用，有些bug不能达到及时的反馈
我们项目中有使用markdown的需求，并且可能要定制些需求
有些商业的，大部分都是费web的，我们web系统没法接入和0定制
做一款易用的编辑器并开源