向虚无开炮

一、在一切开始之前

1.1 妈妈们

在我开始去写这篇文章之前，我想起了我的童年。我童年的大部分时光都是在画室度过的，每年的寒假或者暑假，都会有一类嗓门很大，调门很高的家长，左手紧紧地拽着一个可能还不到她腰的小孩子，右手攥着一大叠画，用极其夸张又郑重的语调去和老师阐述她孩子的天赋是再世的“毕加索”（我打赌是因为她只知道毕加索），那个小孩子，也是高高地仰起小脑袋瓜，享受着妈妈的吹嘘带给他的快乐。而那时的我，不得不承认，唯一的想法就是把再世毕加索打一顿，哦不，是见一次打一顿。

石家庄的任何一个小孩，都不可能是再世的毕加索，不过没准有十分之一或者更多的小孩，都享受过被称为“毕加索”的自得。不得不承认，这是一种捷径，毕竟不需要付出任何实际上的努力，就可以享受毕加索的快乐。

“毕加索”们已经沉浸在一种“理想主义”的茧房中了，外界的声音，如果是赞扬，那么就会被他们当成对于他们天赋的一种肯定，而对于一些建议或者批判，则被当成了庸众的噪声，是蜩与学鸠的嗤笑，反而也成了一种对于天赋的肯定。

不过又有什么办法呢？这世界上的大部分人，不是毕加索，这不怪那些小孩子，或者他们的母亲。如果真的按照年幼的我所想的，不应该有人“抄捷径”，那么这个世界就变成了一种更加让人恶心的状态，比如说我童年见到的孩子的母亲，就要接受她的孩子，不仅在她孩子不上心的学习上，还是在她孩子“喜欢”的画画上，都远远不如那个蜷在画室的一角，每天大部分清醒时间都在思考如何逗小姑娘开心的傻逼小孩儿。

但是话说回来，真正的毕加索的妈妈呢？她应不应该选择去相信自己的孩子，去为自己的孩子争取一个更好地受教育的环境。在毕加索成为毕加索之前，谁能告诉这个妈妈，她的孩子真的是才华横溢的大画家。难道就为了一点点的现实因素考量，或者满足一下自己的道德洁癖，就不相信自己的孩子是个天才，这不是比“自我催眠”更加自私的行为吗？

所以妈妈们，总是无条件的相信自己的孩子是最棒的。

1.2 毕加索项目

软工选题和需求分析，和上面的故事是一样复杂的。直观上看，需求分析是很好做的，因为用基于客观事实说话嘛，你调研了很多人很多软件，把数据一摆，就可以得到一个答案，大家都基于事实说话，没人杠你，绝对正确。过事实远没有那么简单。

首先，项目的选题是先于需求分析的。这不是因为软工课设的安排导致的畸形，这是一个客观现象。如果都不知道要干什么，那么怎么去根据要干的事情去进行调研呢？但是这样的话，选题一定是主观的，是很取决于小组之间的某些神秘的，不受控制的因素。当然有人会说，通过调研就知道选题合不合适了，那么面对不合适的项目，应该怎么办？是直接抛弃，还是改一改，或者自欺欺人是调研的问题？不只是选题，任何一个决策，都是主观的，无论如何调研，都无法问心无愧地说自己选择了最优的路径。

其次，如果真的客观调研的话，那么就一定会意识到，软工的项目毫无生存的空间。但凡希望这个软件遵循商业逻辑，他就极大概率不可能生存下来。有什么理由相信，一个仅仅靠学分和理想聚集起来的一波基本上没有任何实习经验的愚蠢大学生，要比具有强大宣发，强大资金，完整工业部门，在商场里物竞天择出来的公司更强呢？

最后，如果真的拥有一个好的选题（甚至是一个必然成功的选题），那么是否真的有能力实现它？就好像在中国，供养一个毕加索，所有付出的代价要远远比供养一个北航学生的代价大，那么作为家长，即使知道了自己的孩子大概率会是一个卓越的画家，也大概率会将孩子培养成一名北航学生吧。如果我是毕加索的家长，即使不考虑代价，我也不愿意送它去当美术生，艺考就是对于毕加索的折磨。

1.3 亮剑

基于上面这两节，所以应该怎么样呢？

我相信这些问题，在我之前的人有人考虑过，在我之后的人也会考虑过，而我作为现在的思考者，要用我和我团队的力量给出答案。下面的一节会记录整个选题的流程，倒不是我对于自己做得决策有多骄傲，只是希望记录下来自己的思考，给后来者一点故事罢了。

我和妈妈们一样，都是无条件地相信自己的孩子的。

---

二、求索

我不喜欢自己骗自己。

所谓艺术，就是真诚地自我表达。

调查就像“十月怀胎”，解决问题就像“一朝分娩”。调查就是解决问题。

2.1 软件类型

这个问题是在假期被思考的，而且这个部分基本上是没有办法通过用户调研的方法解决，毕竟这个基本上就是最原始的问题。

2.1.1 信息交换网站

信息交换网站这个词是我自己定义的，说白了就是一个和数据库大作业很像的网站，其主要业务是操作各种信息，让信息流到更能发挥价值的地方。比如说淘宝网站，他让卖家可以将它的商品信息流向消费者，消费者掌握了这些商品数据，就可以用较低的决策代价做出决策。

对于这种网站，在某种意义上，应该是最符合“软件工程”这门课的网站，软件工程教的所有东西，对于这样的网站是必须的。需求分析当然是要做的，因为这种网站的信息都是来自用户的，这些信息最终也都会流向用户，那么搞清楚用户生产怎样的信息，消费怎样的信息，就是最重要的事情。竞品分析当然也是要做的，因为这种网站基本上在基本功能上是没有不可替代性的，一旦市场上已经有了类似的网站，要么就用更加强大的技术、资金、宣发去硬碰硬，这显然是不适合大学生软工团队的；要么就去细化市场，选择在细微处完成游击战，这就需要清楚竞品的市场占位是怎样的了。架构设计当然也是需要的，信息交换网站的可以看做一个大的数学模型，显然细致的设计所有信息的结构，是很必要的。至于团队管理之类的，也是顺理成章的事情。有时我在想，或许软件工程这门理论诞生的实践，正是 web 应用软件开发。

不过我们最终没有选择这个选题，是因为这个选题不仅生存下去的希望很小，而且还很舒服。我不喜欢骗自己。

2.1.2 校园网站

这也是一个很好的选题类型，为某个社团、课程、学院开发一个网站，这种网站一般也是信息交换网站。

这种相对于普通的信息交换网站，还要更加方便。因为需求是明确的，都是不需要调研的（可能有一些绝对），竞品也是明确的，就是没有竞品。大部分的心思放在技术上就好了，当然技术一定要过关，毕竟课程网站这种应用还是有一个非常严肃的应用场景的。而且必须承认，这种网站其实是一个多方合力的结果，不仅是软工团队，教师团队，行政团队，教务团队也在这其中发挥了不可磨灭的作用。在诸多部门间协调，也体现了团队的能力。

我个人感觉只有让信息交换网站加上校园的支持，才有可能生存下去。

我们也没有选择这类选题，因为我不喜欢一眼就看得到结局的软件。

2.1.3 非信息交换软件

这种软件不是一个信息平台，而是一个工具软件，它利用计算机帮助人们解决实际的问题（当然上面的网站也会解决问题）。我个人是非常喜欢这种软件的，因为我学计算机就是为了写这样的软件，而不是为了写上面这样的软件的。这就好像大家小时候的理想都是当科学家，当警察，当医生，但是没人愿意去当一个炒股的或者倒爷。我要把创造的能力牢牢的抓在自己的手里。

不过开发这样的软件，其实是一种“异类”。比较浅显的为 web 应用开发准备的软工理论，是没有办法匹配这种软件的。比如说我们要开发一个编译器（显然编译器也是这个范畴），那么为啥要分析用户需求，为啥要布置服务器，为啥要写架构设计，这些东西完全不用啊。

不过有说回来，似乎只有这样的软件，才更加能体会软工的智慧。如果一个编译器需要考虑用户需求了，那么就说明大概率这是为一门新的语言开发的编译器，这个项目本质是在开发一门语言。如果一个编译器需要考虑架构设计了，那么大概率说明它是 llvm，谁能否认 llvm 的软件架构设计的精妙绝伦呢？

**把一个软件当做一个工程去做，那么这个软件的选题一定是足够让人豪情万丈的。**正是基于这样的信念，我们选择了这个方向。

2.2 markdown 编辑器

2.2.1 诞生

在确定了开发一款工具软件之后，那么具体一点的选题就成了下一个问题。

在选题中，最重要的事情就是意识到大家其实没有那么多时间，这不过是一门课罢了。但是一款工具软件一定是足够复杂的（不然咋被称为“豪情万丈”），所以选题的时候就需要巧妙地在有限的精力和复杂的选题之间取得一个平衡。

我们为此制定的策略是“尽量利用现有，已经投入的资源”。简单来说就是尽量利用大家已有的技术栈。基于这种思路，我们淘汰了游戏制作，因为有些游戏制作需要游戏引擎知识，同时对于游戏策划知识也有一定要求。操作系统也被抛弃了，显然我没法找到 7 个热爱写操作系统并且对于操作系统有审美的人。但是开发一门新的语言或者一个编辑器就是一个很好的选择。对于新的语言来说，编译器的知识我们上个学期已经熟悉过了；对于编辑器，可以效仿 vscode 的模式，借用 electron 架构，进而使用数据库大作业积累下来的 web 开发经验。

除了技术栈要重复利用外，大家的审美也要重复利用，这样团队里的人才能更加积极主动地面对开发。相对于开发一款适用于量子计算的语言，显然开发一款大家更为熟悉应用场景的语言更加合适。编辑器也是同理，什么样的编辑场景大家更为常见的，我们就开发什么样的编辑器。

最终我们选择了“笔记”这个更为细化的选题。这个选题保留了“编辑器”和“语言”的特性，我们既可以考虑开发一款更适合记笔记的语言，也可以考虑开发一款更适合记笔记的编辑器，甚至双管齐下。

2.2.2 可能的特性

既然确定了选题，那么就要思考对于这款编辑器的诸多特性。我们通过头脑风暴的形式，提了如下特性：

• block 排版增强：类似于 notion 的 block，将文档中的各种元素都视为 block，可以拖拽这些 block 完成排版（其实也是源码编辑器的特性，比如说 vim 就可以编辑“字符”，“单词”，“行”，对这些单位进行轻松的复制，粘贴，修改，移动）。
• 网络共享：一个是向“共享白板”方向发展，团队共同编辑一个作品。（这个会让编辑器不纯粹，我不喜欢）。
• 画图增强：对于概念图的绘制，需要增强。
• 多端应用：可以放置到手机端或者浏览器端（如果这个不是一个立刻可以实现的东西）那么我觉得应该往后放。
• 无限链接：可以在本地完成无限链接特性。同时要保证可以每个链接块是一个独立可编辑的 md 文件，同时有一个展示结构，可以用于展示“嵌套树”。
• 数学公式增强：增加代码提示，我感觉加装一组 snippet 也可以（这其实是个方向，就是在所见即所得的编辑器中引入一些源码编辑器的优势）有没有可能分段编辑。
• 图片增强：可以手动调整图片的大小

严格意义上讲，这次的讨论并不是很有效果，因为大家没有进行调研，提出来的想法都创意性不足，很多东西都是“XX 增强”，是没有办法作为核心特征的。只有一个模模糊糊的“将源码编辑器的特征应用到所见即所得的编辑器中”。当时我们意识到，需要开展调研了。

2.2.3 对现有软件的调研

开展调研的方式就是下载软件并且使用，我们先后调研了 typora, markdown all in one, trilium, marktext, obsidian, notion, 思源笔记等软件，每个软件都是坚持使用至少三天，并且上知乎，B 站，V2EX，掘金等网站去看这些笔记软件的测评，培养审美。

这个调研大概持续了两周时间，结论大概是这样的。

笔记软件大概分为两个层次，一个是笔记编译，一个是笔记管理。

在笔记编辑层面，当前比较著名的软件采用的都是所见即所得的设计思路，这并不奇怪，因为其实 md 学习负担对于普通人来说就已经很多了，而且很多软件其实底层就不是 markdown 编辑器，而是一个富文本编辑器，这点在 notion 和 trilium 中都有体现。同时在编辑方面，一种基于拖拽的编辑方式十分普遍，用户可以通过拖拽文本块完成编辑或者双栏排版，这点在 marktext，notion，obsidian 中更为常见。同时，在幕布、 notion、obsidian 中，存在着比 typora 大纲视图更为卓越的树形视图，这种树形视图可以自由地展开节点，清晰地观察内容架构。

在笔记管理层面，除了程序员比较熟悉的文件树架构，还有一种散点图视图，这种视图是 obsidian 的主打特色，通过拓展 markdown 语法，让文档间具有相互引用的功能，这样就可以在文档间构造出一个双向链接的图模型，极大的提高了检索效率和知识体系的结构化。另一种思路是 Trilium 和 Notion 提供的无限链接模型，可以无限层的引用文献，相当于自己维护了一个更加卓越的文件系统。

此外，还有一个现象很明显，就是笔记软件的美观程度和响应速度很影响用户对于软件的使用体验，因为环境问题，我下载 obsidian 的时候采用的是 AppImage 的形式，这就导致 obsidian 的响应速度奇慢，我是打心底不愿意使用这款广受好评的软件。

2.2.4 典型用户调研和对于笔记软件的思考

为了想出我们软件的核心特征，我们开展了典型用户调研，为了能听到更为有趣的建议，所以我们的典型用户选择的是一些非本专业学生（这么看似乎不太典型）。

出人意料的是，很多人既不记笔记，也不希望记笔记或者是经常记载草稿纸或者 ppt 上的现象。因为很多时候信息是不需要高度秩序化的，这是很多学科或者项目，并没有那么深且广且可以被秩序化的技术栈，自然也没必要为了记笔记。

如果将笔记定义为“信息秩序化”的过程，那么一款好的笔记软件，所要实现的就是尽量减少秩序化所需要的代价。

同时我注意到，除了让信息秩序化这个主要的目的，热爱记笔记的人，本身是享受记笔记这个过程的，记笔记本身就很让人幸福了，所以如果能优化这种幸福感，那么笔记软件会更加受欢迎，比如说树状图的视图和散点图视图就给人一种成就感。

2.2.5 用户调研

这节较大，移到外面写了。

2.2.6 Ficus 的进击

在进行了上面的一系列思考和调研后，终于到了“创造”的时刻。我们为这款软件拟定了三个特征。

Ficus 肯定是最为核心的特征，这个创意可以用如下图来诠释：

他用一个“树”的概念在文档内和文档间完成了统一，同时还可以具有强大的功能（即视图和编辑的统一）。概念的简单性有助于用户的理解和使用（比如 Notion 的 block 概念）。

第二个特征是一个基础的 md 编辑器，我们最终放弃了开发一门新的语言的想法，这是因为基于 md 可以让我们的用户更快地适应我们的软件，同时对于之前笔记的迁移性会更高。在实际体验中我注意到，用户对于一个基础的，流畅的 md 编辑器的需求是一个很重要的部分（这点在各个开源笔记软件的 issue 和用户调研中可以反应）。

第三个特征是足够漂亮。这点是因为我们将用户的幸福放在第一位。

---

三、用户调研分析

3.1 问卷内容

1. 您平时写笔记吗？

2. 您希望自己写笔记吗？

3. 您平时每篇笔记的篇幅（以字数记）平均是多少？

4. 您笔记的横向宽度平均是多少？（即同级标题的重复的次数，比如说这篇笔记一共有 12 章，那么宽度就是 12）

5. 您笔记的纵向深度平均是多少？（即不同级标题的个数，比如一篇笔记中有“一、1.1、1.1.1”，那么深度就是 3）

6. 削减您记笔记热情的因素都有哪些？

   • 知识点太零散，整理成文档过于细碎。

   • 没有必要，我就是不喜欢记录笔记。

   • 太花费时间，写成一篇很好的笔记需要很长的时间。

   • 没有记笔记的需求（更喜欢查阅书籍，文档，文献或者其他方式检索知识）。

   • 我坚持记笔记看不出成果来，记笔记就像一个人孤独的旅行一样，很没有成就感。

   • 我写的笔记太烂了，看上去就是一团浆糊，我自己都不愿意回看。

   • 其他：

7. 您理想中的笔记编辑软件应当满足您的哪些需求呢？

   • 强大的编辑能力，可以为各种对于笔记架构的调整提供足够的支持。

   • 美观和仪式感，输出的过程可以享受快乐。

   • 流畅简洁的使用体验，不会出现卡顿，响应性强，启动速度快。

   • 其他：

8. 您理想中的笔记管理软件应当满足您的哪些需求呢？

   • 可以直观自然地显示自己构建的知识图谱。

   • 可以在知识图谱层次直接对多个文档进行联合编辑。

   • 可以有多样化的管理形式。

   • 可以建立复杂的知识图谱。

   • 更加有条理的文档管理、更加高效的文档检索。

   • 其他：

9. 您目前使用的笔记软件有哪些不足？

   • 收费。

   • 功能繁杂。

   • 响应速度差。

   • bug 多。

   • 使用不方便。

   • 我根本接触不到笔记软件。

   • 笔记软件差到我根本说不出它差到哪里了。

   • 迁移性差。

   • md 源码太丑了。

   • 其他：

10. 请勾选您听说过的软件：

    • Typora

    • Markdown All in One

    • MarkText

    • Trilium

    • Obsidian

    • Notion

    • 语雀

    • 思源笔记

11. 请勾选您使用过的软件：

    • Typora

    • Markdown All in One

    • MarkText

    • Trilium

    • Obisidian

    • Notion

    • 语雀

    • 思源笔记

3.2 调研现象

1. 有超过三分之一的人是不记笔记的

来源：1

这个结果一开始还是让人十分沮丧的，潜在用户直接减少三分之一，而且据我对于身边非计算机专业的同学采访，发现起码数学、物理、化学、生物和设计专业的同学大部分是不记笔记的。

经过我的采访，他们最终会将原因归结到“我的学科或者工作是不适合通过记笔记来为之辅助的”。

2 即使有人不记笔记，但是大部分人都希望自己记笔记

来源：1，2

1，2 题都是必选题，相比于第一题的“不记笔记”，第二题只有 15% 的同学不希望记笔记。也就是说，有一些不记笔记的人，本身是希望自己记笔记的。

3 大部分人的笔记篇幅大约在 300 ~ 3000 字

来源：3

在这个范围内的人超过了 90%。这点基本上在依赖之中，基本上超过 3000 字的笔记，就没有办法做到内容、结构的完整了。

4 大部分人的笔记的横向宽度在 3 ~ 6

来源：4

在这个范围内的人超过了 90%。

5 大部分人的笔记的纵向深度在 2 ~ 4

来源：5

在这个范围内的人超过了 90%。

6 有一小部分人对于自己的笔记的框架没有太好的把握

来源：4，5

我人工核验了出现对于字数、深度、宽度这三项指标中最大和最小的项，除去存在“50 字，宽度 10 以上，深度 10 以上”的情况（明显为异常数据或者理解错误），还有大约 5 个左右的人他们的这三项指标有些奇怪，给人感觉他们似乎并不清楚自己笔记的整体性质是什么。

7 繁琐和浪费时间是最降低记笔记热情的两个因素

来源：6

确实对于零碎的知识点，没有必要大张旗鼓的记一个笔记，甚至记笔记的功夫都没有打开电脑和软甲的时间多。同样的，如果想写出一篇很好的笔记，一定是需要很长时间的。

8 编辑能力强大和流畅是大家最为期盼的文档编辑器的两个特质

来源：7

没有想到大家这么希望一款强编辑能力的软件。

9 构建知识图谱和管理心智负担小是大家最为期盼的文档管理软件的两个特质

来源：8

这个选题其实较为平均，大家对于不同优秀的特性都有所支持，差异不大。

10 除了付费，当前笔记软件没有什么明显的缺点

来源：9

在此题中，只有收费这个选项的占比超过了 30%。其他的均在 30% 一下，而且 3 个人在“其他”中表示现在正在使用的笔记软件没有任何缺点。

11 Typora、Notion、Markdown All in One 是大家最为熟知的三款软件

来源：10

其中 Typora 一骑绝尘，占比约 80%，Notion 为 50%，而 Markdown All in One 为 30% 左右。

12 Typora、Notion、Markdown All in One 是大家使用最多的三款软件

来源：11

情况与第十题类似。

13 手写是很多人不选择 md 笔记软件的原因

来源：6，8，9

有 7 个人表示过“手写笔记更舒服，更便捷，希望支持手写识别功能”等关于“手写”的特质。

14 协作和同步是很多人的需求

来源：7，8，9

有 6 个人表示希望支持笔记的云同步和团队协作功能。

3.3 调研结论

1 “记笔记”是将信息秩序化的过程

经过调研可知，并不能将所有用户当做我们的目标用户，只有那些需要记笔记的用户，或者希望记笔记的用户，才是我们的目标用户。为了准确地把握这些用户的需求，必须先明确“记笔记”的本质。

经过讨论和思考，最终将“记笔记”定义为“信息秩序化”。这种定义符合现状，即很多人既不记笔记，也不希望记笔记或者是经常记载草稿纸或者 ppt 上的现象。因为很多时候信息是不需要高度秩序化的，这是很多学科或者项目，并没有那么深且广且可以被秩序化的技术栈，自然也没必要为了记笔记。

同时，可以看出，信息的秩序化是一个花销极大的过程，无论是对于毅力、时间、能力都是一种考量。所以开发出的软件应当尽力减轻用户的花销。

2 笔记规模问题

可以看到正常规模的笔记，最大字数约为 3000，深度最大为 5，广度最大为 8。

根据这个现象，可以看到没有必要为了某种逻辑的严谨性，而进行一些“无限特性”的开发，如“无限嵌套”。

3 现有的笔记软件已经很好了

可以看到无论是 Typora 还是 Notion 还是 vscode 插件，他们的功能已经很完备了，很成熟了。

不得不承认，这种对于基本盘的超高掌控能力，是某种意义上的入场劵。网络上不乏 10 天开发一个 markdown 编辑器的例子，但是很少有生存下来的，我个人认为是其基本盘并没有这些商用软件牢固。甚至像 MarkText 或者是 Trilium 这种开源软件也完全没法和 Typora 掰手腕。

如果想要生存下去，最基本的编辑能力必要要足够能打！

4 笔记软件是一个大集合

尽管 notion 和 vscode 都可以被叫做笔记软件，但是可以看出他们是完全不一样的两款软件，事实也确实如此。因为大家的需求是不一样的，notion 对于协作、同步、嵌套做得都足够好，而 vscode 完全不关注这些。

也就是说，即使明确了要开发笔记软件，也要接着明确到底要强化哪个方向，诸如：

• 编辑
• 协作
• 同步
• 展示
• 管理
• 特化

5 Fucking All in One

卷不过 vscode 和 notion。渴望通过增加更多类型的功能来获得用户青睐的决策，我认为是不明智的。

而且我也不喜欢不纯粹的软件。虽然真的很好用。

四、NABCD 模型

4.1 Need

浸浴在信息爆炸的滥觞中，每一个人或多或少都曾有过自己获取信息沉淀为知识的冲动。markdown 作为一个轻量级标记语言，恰如其分地安抚了当代人内容输出的悸动。

对于了解 markdown 语言的程序员来说，需要一款编辑能力强大的 markdown 编辑器，同时也需要一款功能强大的文档管理软件辅助构建自己的技术栈。对于不了解 markdown 语言的人而言，一款简单好上手的编辑器，一个优雅、直观且易读的思维导图，是每一个渴望内容输出的人的理想工具。

响应这些期盼，正是我们开发这款软件的初衷。

4.2 Approch

$\mathtt{Ficus}$ 是一款 PC 桌面应用，基于 Vue + Electron 架构进行开发，兼顾开发的效率和跨平台的优势。

利用 JavaScript 实现 Ficus 树的结构，支持对于 markdown 文本的语法树解析和编辑。

利用 Node.js 和 sql 技术实现 Ficus 森林概念，实现对于文档的管理。

4.3 Benefit

• 独创性的 Ficus 架构。
• 舒适自然的 md 编辑器。
• 简约慵懒的设计风格

4.4 Context

市面上有许多款笔记或者内容管理软件，其中不乏非常卓越的软件，我们的开发思路是在保证基础功能的健全前提下，发挥“后发先至”的优势，挖掘客户的潜在需求，改进现有软件的缺点。

针对现有软件改进如下表：

软件	现有缺点	Ficus 改进
Typora	收费、闭源、几乎没有笔记管理功能	免费、开源、提供强大的笔记管理功能
Vscode	非程序员不友好、在笔记方面不够纯粹	所见即所得、用户友好
Notion	繁琐冗杂、庞大、收费、反应慢	简约、轻量、免费、高响应性
Obsidian	粗糙的笔记管理功能	更加细化的笔记管理功能
MarkText	对中文支持不好，停止维护	更好的中文支持，持续维护

4.5 Delivery

$\mathtt{Ficus}$ 拟采用以下方式进行推广：

• 微信等社交媒体推广：并通过群聊等形式及时与用户互动。
• 内容营销：制作高质量的视频和博客来介绍产品。
• 在社区发布：在 V2EX，B 站等平台发布产品，吸引用户。

---

五、选题意义

5.1 基本介绍

$\mathtt{Ficus}$ 是一款 markdown 文档的编辑管理软件，由 $\mathtt{gg}=\mathtt{G}$ 团队开发。

$\mathtt{Ficus}$ 释义为“榕树”，榕树具有“冠盖如伞、一木成林“的特点。这也恰是本款软件想要为用户提供的核心服务：让用户的 md 文档可以像一棵榕树一样被浏览和编辑，同时让用户的多个 md 文档像榕树林一样进行多种形式的关联。我们希望用户的体验如这款软件的标语一样：
$$Branchoutyourideawith\mathcal{F}icus.$$
$\mathtt{Ficus}$ 基于 Vue3, Electron 框架开发，提供 Windows、macOS 和 Linux 系统的安装包。

5.2 核心特征

5.2.1 独创性的 Ficus 架构

ficus 架构一共分为两个层次：

• 文档内：每个 md 文档都可以根据标题等语法符号解析成一个 ficus 树 (ficus tree)。
• 文档间：多个文档解析出的 ficus 树组成成一个 ficus 森林 (ficus forest)。

在文档内，ficus 树可以帮您更加详略得当地了解文档的组织结构，同时您可以通过编辑 ficus 树调整文档的脉络，更加符合内容输出的直观逻辑。

在文档间，您可以构建多种 ficus 树间的联系，如 ficus 根 (ficus root)，ficus 柱 (ficus prop)，ficus 须 (ficus aerial)。这些不同的联系能够帮助您进行更加有条理的文档管理、更加高效的文档检索、更加直观的思维导图构建、更加便捷的多文档联合编辑。

5.2.2 舒适自然的 md 编辑器

$\mathtt{Ficus}$ 内置“所见即所得”的 md 编辑器，支持以下功能特性：

• 所见即所得的实时渲染。
• markdown 语法高亮。
• 提供“源代码模式”和“渲染模式”的自由切换。
• $\text{LATEX}$ 数学公式渲染和补全支持。
• 查找替换功能。
• 编辑快捷键支持。
• ……

5.2.3 简约慵懒的设计风格

$\mathtt{Ficus}$ 以用户为中心，会尽最大的努力来满足用户的期望，同时不增加用户的理解和使用负担。Ficus 风格具有以下特点：

• 思之繁，用之简。
• 一切都做到如此简洁明了，以至于没有任何需要解释的余地。
• 盛夏榕荫下的清凉与慵懒。

---

六、软件发布

3.1 发布策略

软件发布总共分为两个阶段。之所以这样设计，是因为笔记软件更接近于一款编辑软件，具有以下特点：

• 用户乐于尝试：我的电脑上可能已经有三十多款编辑软件了。
• 关注量大：编辑作为计算机提供的一项基础服务，造成编辑器开发的关注大是要比一般软件要大的，这点可以在多个论坛的浏览量和 github 的 star 数上得到印证。
• 用户粘性小：用户不会持续尝试一款不符合他心意的编辑软件。

总结下来就是，不太需要担心冷启动问题，但是对于软件的质量要有更高的要求。

3.2 第一阶段

应该是在 $\alpha$ 阶段完成后发布，主要有两种形式：

• 社交媒体发布，主要通过微信朋友圈宣发，同时建立用户内测群，时时关注用户反馈。
• 自举：在 $\alpha$ 结束后，团队成员的 md 编辑器更换成 ficus，并进行之后的开发，完成自举。

3.3 第二阶段

在 $\beta$ 阶段中期或者完成时发布，主要通过两种形式：

• 内容输出：考虑录制视频发布到 B 站和博客发布到博客网站。
• 论坛推广：考虑在 V2EX、知乎和掘金上发布。

3.4 质量评估指标

指标分为两类。

第一类用于反应用户数据，我们以“下载量”作为核心指标，我们希望发布一周后可以达到 300 的下载量。

第二类用于反应编辑器质量，我们会测算启动时间，打开大文件时间，诸多编辑操作的时间等一系列编辑器的性能指标。